软件体系结构参考文献

㈠ 需要说明一个软件系统的各个层次的每一个程序(模块)设计考虑的文件是什么

摘要：
本文是在概要设计实践和学习中的一些心得与学习笔记，希望与大家分享，如有不妥之处欢迎指正。
关键字：
概要设计，结构化，OOD
正文：
在需求明确、准备开始编码之前，要做概要设计，而详细设计可能大部分公司没有做，有做的也大部分是和编码同步进行，或者在编码之后。因此，对大部分的公司来说，概要设计文档是唯一的设计文档，对后面的开发、测试、实施、维护工作起到关键性的影响。
一、问题的提出
概要设计写什么？概要设计怎么做？
如何判断设计的模块是完整的？
为什么说设计阶段过于重视业务流程是个误区？
以需求分析文档还是以概要设计文档来评估开发工作量、指导开发计划准确？
结构化好还是面向对象好？
以上问题的答案请在文章中找。
二、概要设计的目的
将软件系统需求转换为未来系统的设计；
逐步开发强壮的系统构架；
使设计适合于实施环境，为提高性能而进行设计；
结构应该被分解为模块和库。
三、概要设计的任务
制定规范：代码体系、接口规约、命名规则。这是项目小组今后共同作战的基础，有了开发规范和程序模块之间和项目成员彼此之间的接口规则、方式方法，大家就有了共同的工作语言、共同的工作平台，使整个软件开发工作可以协调有序地进行。
总体结构设计：
功能（加工）－>模块：每个功能用那些模块实现，保证每个功能都有相应的模块来实现；
模块层次结构：某个角度的软件框架视图；
模块间的调用关系：模块间的接口的总体描述；
模块间的接口：传递的信息及其结构；
处理方式设计：满足功能和性能的算法
用户界面设计；
数据结构设计：
详细的数据结构：表、索引、文件；
算法相关逻辑数据结构及其操作；
上述操作的程序模块说明（在前台？在后台？用视图？用过程？······）
接口控制表的数据结构和使用规则
其他性能设计。
四、概要设计写什么
结构化软件设计说明书结构（因篇幅有限和过时嫌疑，在此不作过多解释）
任务：目标、环境、需求、局限；
总体设计：处理流程、总体结构与模块、功能与模块的关系；
接口设计：总体说明外部用户、软、硬件接口；内部模块间接口（注：接口≈系统界面）
数据结构：逻辑结构、物理结构，与程序结构的关系；
模块设计：每个模块“做什么”、简要说明“怎么做”（输入、输出、处理逻辑、与其它模块的接口，与其它系统或硬件的接口），处在什么逻辑位置、物理位置；
运行设计：运行模块组合、控制、时间；
出错设计：出错信息、处错处理；
其他设计：保密、维护；
OO软件设计说明书结构
1 概述
系统简述、软件设计目标、参考资料、修订版本记录
这部分论述整个系统的设计目标，明确地说明哪些功能是系统决定实现而哪些时不准备实现的。同时，对于非功能性的需求例如性能、可用性等，亦需提及。需求规格说明书对于这部分的内容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求。
这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特点和功能。在随后的文档部分，将解释设计是怎么来实现这些的。
2 术语表
对本文档中所使用的各种术语进行说明。如果一些术语在需求规格说明书中已经说明过了，此处不用再重复，可以指引读者参考需求说明。
3 用例
此处要求系统用用例图表述（UML），对每个用例（正常处理的情况）要有中文叙述。
4 设计概述
4.1 简述
这部分要求突出整个设计所采用的方法（是面向对象设计还是结构化设计）、系统的体系结构（例如客户/服务器结构）以及使用到的相应技术和工具（例如OMT、Rose）
4.2 系统结构设计
这部分要求提供高层系统结构（顶层系统结构、各子系统结构）的描述，使用方框图来显示主要的组件及组件间的交互。最好是把逻辑结构同物理结构分离，对前者进行描述。别忘了说明图中用到的俗语和符号。
4.3 系统界面
各种提供给用户的界面以及外部系统在此处要予以说明。如果在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，可以指引读者参考需求说明。如果系统提供了对其它系统的接口，比如说从其它软件系统导入/导出数据，必须在此说明。
4.4 约束和假定
描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。
另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。这种情况下，要求清楚地描述与本系统有交互的软件类型以及这样导致的约束。
实现的语言和平台也会对系统有约束，同样在此予以说明。
对于因选择具体的设计实现而导致对系统的约束，简要地描述你的想法思路，经过怎么样的权衡，为什么要采取这样的设计等等。
5 对象模型
提供整个系统的对象模型，如果模型过大，按照可行的标准把它划分成小块，例如可以把客户端和服务器端的对象模型分开成两个图表述。在其中应该包含所有的系统对象。这些对象都是从理解需求后得到的。要明确哪些应该、哪些不应该被放进图中。所有对象之间的关联必须被确定并且必须指明联系的基数。聚合和继承关系必须清楚地确定下来。每个图必须附有简单的说明。
6 对象描述
在这个部分叙述每个对象的细节，它的属性、它的方法。在这之前必须从逻辑上对对象进行组织。你可能需要用结构图把对象按子系统划分好。
为每个对象做一个条目。在系统对象模型中简要的描述它的用途、约束（如只能有一个实例），列出它的属性和方法。如果对象是存储在持久的数据容器中，标明它是持久对象，否则说明它是个临时对象（transient object）。
对每个对象的每个属性详细说明：名字、类型，如果属性不是很直观或者有约束（例如，每个对象的该属性必须有一个唯一的值或者值域是有限正整数等）。
对每个对象的每个方法详细说明：方法名，返回类型，返回值，参数，用途以及使用的算法的简要说明（如果不是特别简单的话）。如果对变量或者返回值由什么假定的话，Pre-conditions和Post-conditions必须在此说明。列出它或者被它调用的方法需要访问或者修改的属性。最后，提供可以验证实现方法的测试案例。
7 动态模型
这部分的作用是描述系统如何响应各种事件。一般使用顺序图和状态图。
确定不同的场景（Scenario）是第一步，不需要确定所有可能的场景，但是必须至少要覆盖典型的系统用例。不要自己去想当然地创造场景，通常的策略是描述那些客户可以感受得到的场景。
7.1 场景（Scenarios）
对每个场景做一则条目，包括以下内容：
场景名：给它一个可以望文生义的名字
场景描述：简要叙述场景是干什么的以及发生的动作的顺序。
顺序图：描述各种事件及事件发生的相对时间顺序。
7.2 状态图
这部分的内容包括系统动态模型重要的部分的状态图。可能你想为每个对象画一个状态图，但事实上会导致太多不期望的细节信息，只需要确定系统中一些重要的对象并为之提供状态图即可。
8 非功能性需求
五、概要设计怎么做
结构化软件设计方法：
详细阅读需求规格说明书，理解系统建设目标、业务现状、现有系统、客户需求的各功能说明；
分析数据流图，弄清数据流加工的过程；
根据数据流图决定数据处理问题的类型（变换型、事务型、其他型）；
通过以上分析，推导出系统的初始结构图；
对初始结构图进行改进完善：所有的加工都要能对应到相应模块（模块的完整性在于他们完成了需求中的所有加工），消除完全相似或局部相似的重复功能（智者察同），理清模块间的层次、控制关系，减少高扇出结构，随着深度增大扇入，平衡模块大小。
由对数据字典的修改补充完善，导出逻辑数据结构，导出每种数据结构上的操作，这些操作应当属于某个模块。
确定系统包含哪些应用服务系统、客户端、数据库管理系统；
确定每个模块放在哪个应用服务器或客户端的哪个目录、哪个文件（库），或是在数据库内部建立的对象。
对每个筛选后的模块进行列表说明。
对逻辑数据结构进行列表说明。
根据结构化软件设计说明书结构对其他需要说明的问题进行补充说明，形成概要设计说明书。
OO软件设计方法：
在OOA基础上设计对象与类：在问题领域分析（业务建模和需求分析）之后，开始建立系统构架。
第一步是抽取建立领域的概念模型，在UML中表现为建立对象类图、活动图和交互图。对象类就是从对象中经过“察同”找出某组对象之间的共同特征而形成类：
对象与类的属性：数据结构；
对象与类的服务操作：操作的实现算法；
对象与类的各外部联系的实现结构；
设计策略：充分利用现有的类；
方法：继承、复用、演化；
活动图用于定义工作流，主要说明工作流的5W（Do What、Who Do、When Do、Where Do、Why Do）等问题，交互图把人员和业务联系在一起是为了理解交互过程，发现业务工作流中相互交互的各种角色。
第二步是构建完善系统结构：对系统进行分解，将大系统分解为若干子系统，子系统分解为若干软件组件，并说明子系统之间的静态和动态接口，每个子系统可以由用例模型、分析模型、设计模型、测试模型表示。软件系统结构的两种方式：层次、块状
层次结构：系统、子系统、模块、组件（同一层之间具有独立性）；
块状结构：相互之间弱耦合
系统的组成部分：
问题论域：业务相关类和对象(OOA的重点)；
人机界面：窗口、菜单、按钮、命令等等；
数据管理：数据管理方法、逻辑物理结构、操作对象类；
任务管理：任务协调和管理进程；
第三步是利用“4＋1”视图描述系统架构：用例视图及剧本；说明体系结构的设计视图；以模块形式组成包和层包含概要实现模型的实现视图；说明进程与线程及其架构、分配和相互交互关系的过程视图；说明系统在操作平台上的物理节点和其上的任务分配的配置视图。在RUP中还有可选的数据视图。
第四步是性能优化（速度、资源、内存）、模型清晰化、简单化（简单就是享受）。
六、概要设计的原则
总体原则和方法：由粗到细的原则，互相结合的原则，定性分析和定量分析相结合的方法，分解和协调的方法和模型化方法。
要系统考虑系统的一般性、关联性、整体性和层次性。
分解协调：目的是为了创造更好的系统。系统分解是指将一个复杂的系统分解为若干个子系统，系统协调一是系统内协调，即根据系统的总结构、总功能、总任务和总目标的要求，使各个子系统之间互相协调配合，在各个子系统局部优化基础上，通过内部平衡的协调控制，实现系统的整体优化；
屏蔽抽象：从简单的框架开始，隐含细节；
一致性：统一的规范、统一的标准、统一的文件模式；
每个模块应当有一个统一命名的容易理解的名字；
编码：由外向内（界面－>核心）；
面向用户：概要设计是对于按钮按下后系统“怎么做”的简要说明；
模块、组件的充分独立性、封闭性；
同时考虑静态结构与动态运行；
每个逻辑对象都应当说明其所处物理对象（非一一对应）；
每个物理对象都有合适的开发人员，并且利于分工与组装。（详细说明见本人另一篇文章：系统构架设计应考虑的因素）；
确立每个构架视图的整体结构：视图的详细组织结构、元素的分组以及这些主要分组之间的接口；
软件构架与使用的技术平台密切相关，目前常用的平台有J2EE、.NET、CORBA等等，因此具体的软件构架人员应当具备使用这些平台的软件开发经验；
通过需求功能与设计模块之间的列表对应，检查每个需求功能是否都有相应的模块来实现，保证需求功能的可追溯性和需求实现（模块）的完整性，同时可以检查重复和不必要的模块。
在需求调研分析过程中对业务处理过程了解的完整性和准确性非常重要。调查了解清楚所有的业务流程才能设计出适合各流程业务节点用户业务特点和习惯的软件，使开发出来的软件更受欢迎。当然在进行软件概要设计时，要尽量排除业务流程的制约，即把流程中的各项业务结点工作作为独立的对象，设计成独立的模块，充分考虑他们与其他各种业务对象模块的接口，在流程之间通过业务对象模块的相互调用实现各种业务，这样，在业务流程发生有限的变化时（每个业务模块本身的业务逻辑没有变的情况下），就能够比较方便地修改系统程序模块间的调用关系而实现新的需求。如果这种调用关系被设计成存储在配置库的数据字典里，则连程序代码都不用修改，只需修改数据字典里的模块调用规则即可。
七、概要设计的重要输出
编码规范：信息形式、接口规约、命名规则；
物理模型：组件图、配置图；
不同角度的构架视图：用例视图、逻辑视图、进程视图、部署视图、实施视图、数据视图（可选）；
系统总体布局：哪些部分组成、各部分在物理上、逻辑上的相互关系；
两个不可忽视的输出：
与需求功能的关系：对于需求中的每一个功能，用哪一层、哪个模块、哪个类、哪个对象来实现（一对多关系）；反过来，应当说明将要创建的系统每一层、每个模块、每个对象、每一个类“做什么”，他们是为了帮助实现哪些功能（一对多关系）。（需求的颗粒度在一开始往往是比较粗的，因此根据功能点对于整体项目规模的估计或得到项目WBS其误差范围也是比较大的。更为重要的原因是，需求往往不是编码工作分解的准确依据，因为一个需求的功能点可能对应多个代码模块，而多个需求的功能点也可能只对应一个或少数代码模块，同时还有软件复用等因素要考虑，因此只有在概要设计完成以后才能准确地得到详细设计或编码阶段的二次 WBS，并估计较为准确的整体项目规模。）
逻辑与物理位置：每个对象在逻辑上分别落在哪一层、哪个模块、哪个类；在物理上每个模块、每个对象、每一个类放在哪个应用服务器或客户端的哪个目录、哪个文件（库），或者是建立在数据库管理系统中的什么东东（过程、函数、视图、触发器等等）。
八、结构化与面向对象方法特点比较
1. 从概念方面看，结构化软件是功能的集合，通过模块以及模块和模块之间的分层调用关系实现；面向对象软件是事物的集合，通过对象以及对象和对象之间的通讯联系实现；
2. 从构成方面看，结构化软件＝过程＋数据，以过程为中心；面向对象软件＝（数据＋相应操作）的封装，以数据为中心；
3. 从运行控制方面看，结构化软件采用顺序处理方式，由过程驱动控制；面向对象软件采用交互式、并行处理方式，由消息驱动控制；
4. 从开发方面看，结构化方法的工作重点是设计；面向对象方法的工作重点是分析；但是，在结构化方法中，分析阶段和设计阶段采用了不相吻合的表达方式，需要把在分析阶段采用的具有网络特征的数据流图转换为设计阶段采用的具有分层特征的结构图，在面向对象方法中则不存在这一问题。
5. 从应用方面看，相对而言，结构化方法更加适合数据类型比较简单的数值计算和数据统计管理软件的开发；面向对象方法更加适合大型复杂的人机交互式软件和数据统计管理软件的开发；
参考文献：
《实用软件工程》第二版，郑人杰、殷人昆、陶永雷等著
《微软项目：求生法则》Steve McConnell著，余孟学译
《软件工程：实践者的研究方法》（第5版）Roger S.Pressman著
《软件构架实践》SEI软件工程译丛，林·巴斯著
《RUP2000》电子版；
《UML与系统分析设计》张龙祥著；
《面向对象的分析与设计》杨正甫著；

㈡ 系统架构文档怎么写

你这不是系统架构文档,而是概要设计文档和详细设计文档.

㈢ 软件工程 关于教学管理系统的体系结构设计

这不是分的问题

㈣ 一般系统结构理论的参考文献

[1] Fuyong Lin, et al., 2013. Developing an organization design framework and sample based on the total relationship flow management theorems, IEEE Transactions on Systems, Man and Cybernetics: Systems, Vol. 43, No. 6, 2013: 1466-1476
[2]林福永，2012，钱学森系统科学思想及其形式化发展，钱学森先生诞辰100周年纪念文集//中国科学院院士工作局编，科学出版社
[3] Fuyong Lin, T. C. Edwin Cheng. 2007a. The structural theory of general systems applied in management: total relationship flow management theorems. International Journal of General Systems, 36(6)
[4] Fuyong Lin, Kai Sun. 2007b. Network’s relationship flow-behavior theorems – the structural theory of general systems applied in network. Systems Engineering – Theory & Practice, 27(9)
[4] 林福永，孙凯，2007b，复杂网络关系流与行为关系定理——一般系统结构理论在复杂网络中的应用，系统工程理论与实践，27(9)
[5] 张启人，林福永，2002，复杂性科学中复杂性根源的研究及其结果，系统工程理论与实践，22(10)
[6] 林福永，刘人怀，2001，复杂性科学中从简单到复杂的自然法则的研究及其结果，自然杂志，23（4）
[7] 林福永，何敏，2000，一般系统结构理论，见：许国志院士等《系统科学与工程研究》，上海科技教育出版社
[8] Fuyong Lin, T. C. Edwin Cheng. 1999. The Principles and Laws of General Systems and Their Applications. Kybernetes - The International Journal of Systems & Cybernetics, 28(1)
[9] Fuyong Lin, T. C. Edwin Cheng. 1998a. The Structural Model of General Systems and its Proof. Kybernetes - The International Journal of Systems & Cybernetics, 27(9)
[10] 林福永，1998b，一般系统结构模型的数学分析及其结果——若干一般系统原理与规律，系统工程理论与实践，18(12)
[11] 林福永，1998c，《一般系统结构理论》，暨南大学出版社
[12] 林福永，吴健中，1997a，一般系统结构理论及其应用（I），系统工程学报，12(3)
[13] 林福永，吴健中，1997b，一般系统结构理论及其应用（II），系统工程学报，12(4)
[14] 钱学森，1987，《论系统工程》，湖南科学技术出版社

㈤ ARM体系结构与编程的参考文献

1. KaiHwang著.王鼎兴，沈美明等译《高等计算机系统结构并行性可扩展性可编程性》北京：清华大学出版社1995
2. 郑纬民，汤志忠编著.《计算机系统结构》北京：清华大学出版社1998
3. NucleusPLUSReferencemanual.AcceleratedTechnology
4. L7200-05SDB-HWusersmanual.LinkUpSystemsCorporation2000
5. L7210DataBookRev1_2.LinkUpSystemsCorporation2000
6. DDI0100E_ARM_ARM.ARMLimited2000
7. DUI0068B_ADS1_2_Assembler.ARMLimited2001
8. DUI0151A_ADS1_2_LinkUt.ARMLimited2001
9. DUI0067D_ADS1_2_CompLib.ARMLimited2001
10. DUI0065D_ADS1_2_CodeWarrior.ARMLimited2001
11. DUI0058D_ADS1_2_DebugTarg.ARMLimited2001
12. DDI0192A_720T_R3.ARMLimited2000
13. DAI0048A_scatterload.ARMLimited1998
14. AdamCaly.n.Motorola,Inc.
15. DennisEdwards.ExecutingOutofROM.2002EmbeddedSystemsConference,SanFrancisco

㈥ 软件体系结构设计的目录

第一篇基础篇：软件体系结构的理论
第1章绪论1.1软件体系结构的概念演化
1.1.1软件体系结构的定义
1.1.2软件体系结构的理论基础
1.2软件体系结构形式化方法概述
1.2.1基于CHAM的体系结构形式规约
1.2.2基于Z语言的体系结构形式规约
1.2.3基于一阶逻辑的体系结构形式规约
1.2.4基于图论的体系结构形式规约
1.2.5目前形式化方法存在的问题
1.3软件体系结构描述语言概述
1.4软件质量与质量模型
思考题
第2章软件建模的基础
2.1一个简单例子
2.2面向对象特性
2.2.1封装性
2.2.2继承性
2.2.3多态性
2.3接口
2.4设计原则
2.4.1SRP单一职责原则
2.4.2OCP开闭原则
2.4.3LSP里氏替换原则
2.4.4ISP接口分离原则
2.4.5DIP依赖倒置原则
2.5UML2的各种图
2.6需求建模：用例
2.6.1一个用例图例子
2.6.2用例与参与者
2.6.3用例图
2.6.4用例间关系
2.6.5用例对需求建模
2.7基本结构建模
2.7.1一个类图例子
2.7.2性质
2.7.3对象图
2.7.4操作
2.7.5接口
2.7.6关系
2.7.7关系建模
2.7.8类图
2.8高级结构建模
2.8.1公共扩展机制
2.8.2包和包图
2.8.3复合结构
2.8.4模板
2.9Kruchten4+1模型描述软件体系结构
2.9.1逻辑视图：面向对象的分解
2.9.2过程视图：过程分解
2.9.3开发视图：子系统分解
2.9.4物理视图：从软件到硬件的映射
2.9.5场景视图：汇总
2.9.6视图间的交流
2.9.7模型的迭代过程和软件文档
思考题
第3章软件体系结构的形式化
3.1软件的生命周期
3.2基于抽象代数的形式化方法
3.2.1构件
3.2.2连接件
3.2.3软件体系结构
3.2.4软件体系结构关系
3.2.5软件体系结构范式
3.3基于粒度计算的形式化方法
3.3.1软件体系结构演化
3.3.2属性合成和跟踪
3.3.3软件体系结构多视图表达及集成
3.3.4软件体系结构风格和软件体系结构风格发现
3.4*基于π演算的形式化方法
3.4.1π演算基本语法
3.4.2π演算约简关系
3.4.3π演算迁移关系
3.5*动态软件体系结构的形式化描述：化学抽象机
3.5.1化学抽象机模型
3.5.2软件体系结构描述
思考题
第4章软件体系结构的风格
4.1管道和过滤器风格
4.2仓库风格和黑板风格
4.3事件驱动风格
4.4客户机?分配器?服务器风格
4.5分层系统风格
4.6解释器
4.7面向服务的体系结构
4.7.1面向服务体系结构中的组成元素
4.7.2面向服务体系结构的设计原则
4.8过程控制环路模式
思考题
第5章体系结构描述语言
5.1典型ADL
5.1.1C2概述
5.1.2Darwin与Wright概述
5.1.3ACME概述
5.1.4UniCon概述
5.1.5Aesop概述
5.1.6Rapide概述
5.1.7MetaH
5.1.8SADL概述
5.2πADL的概述
5.2.1πADL体系结构描述框架
5.2.2πADL体系结构风格描述方法
5.3πADL体系结构行为规约
思考题
第6章软件质量建模方法
6.1软件质量建模与分析
6.1.1风险分析的基本概念
6.1.2风险分析的基本方法
6.1.3图形化建模语言
6.2实证分析：软件体系结构的质量
6.2.1地面智能机器人的软件系统
6.2.2解决方案1：过程控制环路模式
6.2.3解决方案2：分层架构模式
6.2.4解决方案3：基于事件驱动的隐式调用模式
6.2.5解决方案4：黑板体系模式
6.2.6解决方案比较
思考题
第7章设计模式
7.1设计模式概述
7.2设计模式的分类
7.3创建型的设计模式
7.3.1Factory
7.3.2Prototype
7.3.3Builder
7.3.4Singleton
7.3.5Adapter
思考题
第8章战场环境中自适应服务的软件组合框架
8.1服务的描述与特征
8.1.1服务模型
8.1.2服务事务处理
8.2TSCF服务组合框架
8.2.1TSCF框架
8.2.2服务代理设计
8.2.3服务组合协调
8.3服务调度流程控制的应用实现
8.4小结
思考题
第二篇软件复用与构件库的设计
第9章构件库研究现状
第10章软件复用概述
第11章构件技术
第12章Web构件库实现
第三篇软件规模的度量
第13章软件规模度量研究现状
第14章FPA方法
第15章FPA方法的实际应用及其不足
第16章FPA方法的改进
第17章改进后FPA方法的应用及实例试验
第四篇软件的性能抗衰
第18章软件的性能问题与抗衰技术18.1软件性能衰退
第19章新型软件抗衰策略
第20章细粒度软件抗衰策略研究
第21章细粒度重启技术研究
第22章细粒度软件抗衰策略模型研究
附录A缩略词及中英文词汇对照附录B软件体系结构支持工具参考文献
……

㈦ 急用毕业论文文献：一种基于Java技术的网络管理软件的设计方案 的参考文献 要近几年的。。高手们速度了。

魏勇. 一种基于Java技术的网络管理软件的设计方案[J]. 硅谷，2010，（20）：83.
雷明剑. Java Applet技术在网络管理中的研究及应用[D]. 重庆：重庆大学，2007.
许晓宁. Java Native Interface应用研究[J];计算机科学，2006，（10）：295-296，299.
李天科. 基于Web网络管理体系结构[J].农业网络信息，2006，（06）：67-69.
丁文学,蔡瑞英. 基于CORBA的XML映射中间件研究[J]. 微处理机，2009，（02）：45-48，52.
朱玉，张研. 一种基于Java技术的网络管理软件的设计方案[J]. 微计算机信息，2005，（14）：57-59, 157.

以上应该差不多了，一篇论文至少要有3-5条参考文献。

㈧ 一般参考文献后中著作后面有[R][J][D][M]等符号代表什么详细点

参考文献的著作来中R代表科技报自告，J代表期刊，D代表学位论文，M代表专著。

参考文献类型及文献类型，根据GB3469-83《文献类型与文献载体代码》规定，以单字母方式标识，主要有：

专著M ； 报纸N ；期刊J ；专利文献P；汇编G ；古籍O；技术标准S ；

学位论文D ；科技报告R；参考工具K ；检索工具W；档案B ；录音带A ；

图表Q；唱片L；产品样本X；录相带V；会议录C；中译文T；

乐谱I； 电影片Y；手稿H；微缩胶卷U ；幻灯片Z；微缩平片F；其他E。

(8)软件体系结构参考文献扩展阅读

主要类型的参考文献的格式为：

1、专著、论文集、学位论文、报告

[序号]主要责任者.文献题名[文献类型标识].出版地：出版者，出版年.起止页码（任选）.

2、报纸文章

[序号]主要责任者.文献题名[J].刊名，年，卷（期）：起止页码.

3、专利文献

[序号]专利所有者.专利题名[P].专利国别：专利号，出版日期.

㈨ 求一篇关于 软件体系结构分析 的论文

软件体系结构论文：一种面向方面软件体系结构模型
摘 要: 为了分离软件系统中的核心关注点和横切关注点，通过引入面向方面软件开发的思想设计了一种面向方面软件体系结构模型，并详细分析了该模型的三个基本构成单元，即构件、连接件和方面构件。最后通过一个网上支付实例验证了该模型具有一定的理论意义和实用价值。
关键词: 面向方面软件体系结构;横切关注点;构件;连接件;方面构件
20世纪60年代的软件危机使得人们开始重视软件工程的研究。起初，人们把软件设计的重点放在数据结构和算法的选择上，然而随着软件系统规模越来越大，对总体的系统结构设计和规格说明变得异常重要。随着软件危机程度的加剧，软件体系结构(software architecture)这一概念应运而生。软件体系结构着眼于软件系统的全局组织形式，在较高层次上把握系统各部分之间的内在联系，将软件开发的焦点从成百上千的代码上转移到粒度较大的体系结构元素及其交互的设计上。与传统软件技术相比，软件体系结构理论的提出不仅有利于解决软件系统日益增加的规模和复杂度的问题，有利于构件的重用，也有利于软件生产率的提高。面向方面软件开发(AOSD)认为系统是由核心关注点(corn concern)和横切关注点(cross-cutting concern)有机地交织在一起而形成的。核心关注点是软件要实现的主要功能和目标，横切关注点是那些与核心关注点之间有横切作用的关注点，如系统日志、事务处理和权限验证等。AOSD通过分离系统的横切关注点和核心关注点，使得系统的设计和维护变得容易很多。
Extremara大学的Navasa等人［1］在2002年提出了将面向方面软件开发技术引入到软件体系结构的设计中，称之为面向方面软件体系结构(aspect oriented software architecture，AO-SA)，这样能够结合两者的优点，但是并没有给出构建面向方面软件体系结构的详细方法。
尽管目前对于面向方面软件体系结构这个概念尚未形成统一的认识，但是一般认为面向方面软件体系结构在传统软件体系结构基础上增加了方面构件(aspect component)这一新的构成单元，通过方面构件来封装系统的横切关注点。目前国内外对于面向方面软件体系模型的研究还相对较少，对它的构成单元模型的研究更少，通常只关注方面构件这一构成单元。方面构件最早是由Lieberherr等人［2］提出的，它是在自适应可插拔构件(adaptive plug and play component，APPC)基础之上通过引入面向方面编程(AOP)思想扩展一个可更改的接口而形成的，但它关于请求接口和服务接口的定义很模糊，未能给出一个清晰的方面构件模型。Pawlak等人［3］提出了一个面向方面的框架，该框架主要包含了一个方面构件模型———Java方面构件(Java aspect component，JAC)，但该方面构件模型仅包含了切点(pointcut)，并把AOP中装备(advice)集成到了切点的表达式中，它主要从实现的角度进行了阐述，并没有给出详细的方面构件模型。本文没有只关注面向方面软件体系结构中方面构件这一构成单元模型，还详细分析了它的另外两个构成单元，即构件和连接件，因为面向方面软件体系结构各部分之间是相互关联的。
1面向方面软件体系结构相关概念
面向方面软件体系结构涉及诸多概念，以下将分别介绍。软件体系结构在软件工程领域有着广泛的影响，但当前仍未形成一个统一的、标准的定义。目前国内外普遍认可的看法是软件体系结构包含构件、连接件和约束［4］。其中约束描述了体系结构配置和拓扑的要求，确定了体系结构的构件与连接件的连接关系。这样就可以把软件体系结构写成
软件体系结构(software architecture)=构件(components)+
连接件(connectors)+约束(constraints)
构件是软件体系结构的基本元素之一。一般认为，构件是指具有一定功能、可明确辨识的软件单位，并且具备语义完整、语法正确、有可重用价值的特点，然而目前对于构件的具体结构及构成并没有一个统一的标准［5］，而且一些主要的构件技术也没有使用相同的构件类型。另外，当前被广泛接受的构件定义并不包含具体的软件构件模型(software component model)。例如，Szyperski等人［6］给出了软件构件一个很有名的定义:软件构件是一个仅带特定契约接口和显式语境依赖的结构单位，它可以独立部署，易于第三方整合。但是关于软件构件模型有一个被普遍接受的观点是:软件构件是一个具有服务提供和服务请求功能的软件单元［7］。
连接件是软件体系结构另一个基本的构成元素，是用来建立构件间交互以及支配这些交互规则的构造模块。连接件最先是由Shaw［8］提出来的，她建议把连接件作为软件体系结构中第一类实体，用来表示普通构件之间的交互关系。目前对于连接件尚未形成统一的认识，尽管在软件体系结构中强调了连接件存在的必要性，但是关于连接件模型的研究还很少，连接件的实际应用还不成熟。
面向方面软件体系结构在传统软件体系结构的基础上增加了方面构件单元。通常认为，方面构件是封装了系统横切关注点的一类特殊的构件。目前关于方面构件模型的研究还处于起步阶段。
2面向方面软件体系结构模型
由于传统软件体系结构模型包含构件、连接件和约束，而面向方面软件体系结构是在传统软件体系结构的基础之上扩展了方面构件，所以面向方面软件体系模型结构包含构件、连接件、方面构件和约束。其中约束描述了面向方面体系结构配置和拓扑的要求，确定了体系结构的构件、连接件和方面构件之间的连接关系，而构件、连接件、方面构件是它的三个基本的构成单元。以下对这三个构成单元的模型进行详细的设计。
2.1构件模型
构件模型由以下几个要素构成(图1):
(a)端口。
构件的服务请求和服务提供功能是通过端口来实现的。端口是构件与外部环境进行交互的惟一通道。一般的构件模型通常采用两种端口，即双向端口和单向端口。在使用双向端口的构件模型中，服务请求和服务提供功能可以在同一个端口中实现。本文中的构件模型使用单向端口，此种端口分为请求端口和服务端口两种类型。
(a)服务端口。构件通过服务端口向其他构件提供服务。构件通过服务端口向其他构件的请求消息进行应答，返回响应消息。每个服务端口对应一个接口。
(b)请求端口。构件通过请求端口向其他构件请求服务。构件为了实现自己的业务功能，需要通过请求端口向其他构件发送请求消息。每个服务端口也对应一个接口。
(b)接口。
它定义了一个到多个业务功能。这些业务功能由服务端口进行提供，并由请求端口进行使用。一个接口限定了一个特定端口可以进行的交互功能，接口是构件间交互的契约。通常的接口类型有:Java Interface、WSDL 1．1 portTypes和WSDL 2．0 Interfaces等，也可以自定义接口类型。
(c)属性。
与类或对象相似，构件也具有属性，属性可以在构件使用前进行配置，它能够反映构件在交互过程中状态的变化。
2.2连接件模型
连接件是用来建立构件间交互以及支配这些交互规则的体系结构构造模块。连接件为构件间信息交互提供传输和路由服务。在最简单的情况下，构件之间可以直接完成交互，这时体系结构中的连接件就退化为直接连接。在更为复杂的情况下，构件间交互的处理和维持都需要连接件来实现。对于构件而言，连接件是构件的粘合剂，是构件交互的实现，也可以看做是一种特殊的构件［8］。与构件相似，连接件也具有端口。连接件的端口可分为两种类型，即源端口(source port)和目标端口(target port)。源端口用于接收构件请求端口中的消息，目标端口用于向构件服务端口中输入消息。连接件通常需要使用一种合适的绑定(binding)机制，构件的请求端口使用这种绑定机制来描述服务请求的方法，构件的服务端口也使用这种机制来描述构件进行请求的方式。常用的绑定机制有:WebService Binding和JMS Binding等，也可以自定义绑定机制。与构件一样，连接件也具有属性，来表示构件间交互的状态变化，如图2所示。

2.3复合构件模型
构件可分为两种，即原子构件和复合构件。前者是不可再分的构件。后者是可再分构件，它封装了若干个子构件。子构件间通过连接件相互连接，且子构件的端口也可以暴露成为复合构件的端口，子构件也可能是复合构件。如图3所示:复合构件A包含两个子构件B和D，子构件B和D通过连接件C进行相连，构件B的服务端口E暴露成为复合构件A的服务端口F，其请求端口G暴露成为A的请求端口H。
2.4方面构件模型
方面构件是面向方面软件体系结构的一个核心的构成单元，它封装了横切关注点，这是与传统软件体系结构最大的不同之处。图4给出了方面构件模型，与普通构件一样，方面构件也有服务端口和请求端口以及属性，但是它还有普通构件所没有的方面端口。当一个构件具有一个方面端口时，即可认为此构件就是方面构件。一个方面端口中包含若干个方面，这与一般面向方面编程(AOP)技术中方面概念有所不同。面向方面编程具有以下四个基本概念:方面(aspect)、连接点(joinpoint)、通知(advice)和切点(pointcut)。连接点是应用程序执行过程一个定义明确的位置，如方法调用是一种典型的连接点。切点是一系列连接点的集合，是方面的作用点。通知表述了在切点所选定的连接点处要执行的动作，常见通知类型有before、around和after等，分表代表在连接点之前、连接点附近和连接点之后执行相应的通知代码。方面是用来描述和实现横切关注点的基本单位，由切点和通知构成。方面端口中的方面横切关注的是构件，这与一般AOP(如AspectJ)横切关注的对象(object)不同，由于构件能够表达对象所不能表达的请求服务的能力［9］，这使得方面端口中方面所采用的连接点模型和切点语言具有很大的不同。

2.4.1连接点模型
该连接点模型包含两种不同类型的连接点，即构件服务端口中的服务提供操作和请求端口的服务请求操作。由于构件的内部结构通常被视为黑盒，因此连接点模型应该仅考虑构件的外部可见元素，如构件请求端口和服务端口中的服务操作。如果连接点模型包含构件的属性，那么它将会破坏构件的分装性。
2.4.2切点语言
用来选用连接点的切点语言基于切点表达式，表1给出了切点的五个组成部分，即component、jp_type、port、interface和service，然后分别对其进行了说明。其中，jp_type代表选用的连接点类型，可以是请求端口中的服务、服务端口中的服务或所有端口中的服务，详细如表1。表2给出了切点语言的一些例子，其中正则表达式基于java．util．regexp包。

2.5面向方面软件体系结构模型
面向方面软件体系结构由构件、连接件、方面构件组成，详细请参见图6。

3基于面向方面软件体系结构模型的网上支付实例
近年来，网上购物发展迅速，网上支付是消费者主要的支付手段之一，图7给出了基于面向方面软件体系结构的网上支付模型，它由四个原子构件，即一个复合构件、两个方面构件和三个连接件组成。其中WebClientComponent代表客户端构件，它可以向网上银行构件WebBankComponent请求AccountService()服务，该服务有三个参数，即username、password、cost，分别对应于用户的网上银行账户名、密码及购买商品的消费金额。
〈component name="WebClientComponent"〉〈required．port name="WebClientRequest"〉
〈java．interface interface="AccountServiceInterface"〉〈service name="AccountService()"〉
〈param name="username"type="string"/〉
〈param name="password"type="string"/〉
〈param name="cost"type="float"/〉
〈/service〉〈/java．interface〉
〈/required．port〉
〈/component〉
连接件AccountServiceConnector用于连接客户端构件和网上银行构件，它采用WebServiceBinding绑定机制。
〈connector name="AccountServiceConnector"binding="WebServi-ceBinding"/〉
〈source name="S"/〉〈target name="T"〉
〈/connector〉
〈connect．source from="WebClientComponent．WebClientRequest"to="S"/〉
〈connect．target from="T"to="WebBankComponent．Bank-Re-sponse"/〉
网上银行构件是一个复合构件，由账户服务构件Account-ServiceComponent、账户数据库连接件AccountDBConnector和账户数据库构件AccountDBComponent组装而成。其中该复合构件的服务端口也使用接口AccountServiceInterface，这是为了兼容客户端构件请求端口使用的接口。
身份验证构件AuthenticationComponent用于验证用户的身份信息，它通过UserInfoConnector连接件访问用户信息数据库构件UserInfoDBComponent。
pointcut="WebBankComponent;BankResponse;AccountServiceInterface;AccountService()"
是该方面构件的方面端口中使用切点的表达式。
为了保证数据库构件UserInfoDBComponent和AccountDB-Component的安全性，方面构件SecurityComponent使用方面端口Security监视这两个构件的服务端口，使得在这两个构件服务调用之前增加日志和事务功能，而日志和事务功能在系统中通常表现为横切关注点，面向方面软件体系结构能够对它进行很好的封装，便于设计和维护。
〈aspect．component name="SecurityComponent"〉〈aspect．port name="Security"〉〈aspect〉〈pointcut="UserInfoDBComponent;UserInfoResponse;*;*|Ac-countDBComponent;AccountDBResponse;*;*"/〉〈advice．role="before"action="Log()"/〉〈advice．role="before"action="Transaction()"/〉〈/aspect〉〈/aspect．port〉〈required．port name="UserInfoRequest"/〉〈/aspect．component〉
4结束语
本文给出了一种面向方面软件体系结构模型，详细设计了它的三个基本构成单元模型，即构件、连接件和方面构件;最后通过一个网上支付实例验证了该模型有效性和实用性，为面向方面软件体系结构的实际应用奠定了一定的基础。笔者将继续完善该模型的相关理论，研究面向方面软件体系结构的工程化应用方法。
参考文献:
［1］FABRESSE L，DONY C，HUCHARD M．Foundations of a simpleand unified component-oriented language［J］．Journal of ComputerLanguages，Systems＆Structures，2008，34(2-3):130-149．
［2］LIEBERHERR K，LORENZ D，MEZINI M．Programming with as-pectual components，T R NU-CSS-99-01［R］．［S．l．］:NoutheastamUniversity，1999．
［3］PAWLAK R，SERNTURIER L，DUCHIEN L D，et al．JAC:an as-pect-based distributed dynamic framework［J］．Software Practiceand Experiences，2004，34(12):1119-1148．
［4］李千目．软件体系结构设计［M］．北京:清华大学出版社，2008．
［5］马亮，孙春艳．软件构件概念的变迁［J］．计算机科学，2002，29(4):28-30．
［6］SZYPERSKI C，GRUNTZ D，MURER S．Component software:be-yond object-oriented programming［M］．2nd ed．［S．l．］:Addison-Wesley，2002．
［7］LAU K K，WANG Z．Software component models［J］．IEEE TransSoft Eng，2007，33(10):709-724．
［8］SHAW M．Procere calls are the assembly language of software in-terconnection:connectors deserve first-class status［C］//Proc of InICSE Workshop on Studies of Software Design．1993:17-32．
［9］NAVASA A，PREZ M A，MURILLO J M，et al．Aspect orientedsoftware architecture:a structural perspective［C］//Proc of Workshopon Early Aspects．2002．

㈩ 软件体系结构的图书

作者：(美)肖
出版社：清华大学出版社
出版时间： 2007
ISBN: 9787302145509
开本：16
定价: 29.80 元 软件体系结构作为从软件设计抽象出来的一门新兴学科，目前已经成为软件工程一个重要研究领域。本书作者MaryShaw和DavidGarlan作为软件体系结构最早的研究者，在体系结构领域做出了大量先导性的工作。
本书共有8章：绪论、软件体系结构风格、案例研究、共享信息系统、软件体系结构描述、软件体系结构的分析与评估、特定领域的软件体系结构和流行的软件体系结构等。本书第1-4章主要译自MaryShaw和DavidGarlan的著作。根据目前软件体系结构的现状、以及编译者多年的教学实践经验，在第1章和第5章加入了部分新的内容，并重新编写了第6章、第7章和第8章。其中第6，7章是在参考了大量相关研究的基础上，结合作者在图书馆领域的亲身实践编写的。
本书可以作为计算机专业研究生和高年级本科生的软件体系结构课程的教材或参考书，也可作为软件开发人员的参考手册。 第1章绪论
1.1什么是软件体系结构
1.2软件体系结构研究的内容和范畴
1.3体系结构设计原则
1.4软件体系结构研究的现状
1.5全书的安排
第2章体系结构风格
2.1体系结构风格
2.2管道过滤器
2.3数据抽象和面向对象组织结构
2.4事件驱动，隐式调用
2.5分层系统
2.6知识库
2.7解释器
2.8过程控制
2.9其他常见的体系结构
2.10异构体系结构
第3章案例研究
3.1上下文关键字
3.2仪器软件
3.3移动机器人
3.4定速巡航控制
3.5复合混合风格的三个案例
第4章共享信息系统
第5章软件体系结构描述
第6章软件体系结构的分析与评估
第7章特定领域的软件体系结构
第8章流行的软件体系结构
参考文献
bn-qiange