软件开发过程之《软件是这样炼成的》ppt课件.pptx

《软件开发过程之《软件是这样炼成的》ppt课件.pptx》由会员分享，可在线阅读，更多相关《软件开发过程之《软件是这样炼成的》ppt课件.pptx（69页珍藏版）》请在三一办公上搜索。

1、软件是这样炼成的,制作人：郑培泰2016年6月25日,开篇故事,某政府要建造一座20层的办公楼，用于机关单位办公。建筑面积2万平米，投资预算1.2亿。某建筑设计研究院参与了楼房设计。某建筑公司承接了大楼的建造工程。同时，政府聘请了监理公司参与工程的监督管理。,那么，整个大楼从筹划到建造完成是怎样一个流程呢？,这和软件开发流程有什么相似的地方吗？,Back,开篇故事分析（一）,政府单位：是客户，大楼这个产品的使用者。所关心的是：,投资的规模楼层高度、建筑面积建造地址的选择大楼的功能要求其他需求,点评：从客户那里，能了解到他们需要的是什么。是产品设计、开发的最根本依据。,Back,开篇故事分析（二

2、）,设计研究院：产品的设计者，主要工作：,第一步：了解客户所关心的东西客户需求,点评：设计研究院分析客户需求，并将需求转化为产品设计，再将设计蓝图细化落实为施工图纸。,第二步：根据客户需求进行大楼的设计选择合适的体系结构（居民楼、办公楼、教学楼）选择合适的建筑风格（中式、欧式、其他）进行楼体结构设计、外观设计、水电气管道设计、消防安全设计等，形成设计蓝图。,第三步：根据设计蓝图，设计具体的施工图纸。,投资的规模楼层高度、建筑面积建造地址的选择大楼的功能要求其他需求,Back,开篇故事分析（三）,建筑公司：根据施工图纸和施工规范施工完成大楼的建造。,施工图纸、手册施工规范施工工具、器械建筑材料工

3、地搭建等,点评：建筑公司，相当于程序员，配置好软硬件开发环境，根据设计图、手册和编码规范，完成软件的“建造”工作。,监理公司：负责施工工程的质量鉴定控制和验收工作。,Back,故事总结建筑工程与软件开发流程对比图,区别：,Back,进入正题：软件是这样“炼”成的,本书作者：王朔韬研究软件企业开发过程改进和软件架构,出 版 社：清华大学出版社,主要内容：从需求开发到软件成型交付的整个软件开发流程。全书以投核保系统为唯一案例，全程记录了软件开发、设计的全过程。,编写特点：“学院派”（注重理论）与“应用派”（注重应用）结合，不过分注重抽象概念的定义，结合实际案例理解为主。比如：当一个概念不容易去弄明

4、白是什么时，就先去弄明白它能做些什么、怎么做、他的引入带来的好处，然后再去思考它是什么。,Back,正题：软件是这样“炼”成的内容结构,上册分三篇：软件需求开发软件架构设计（概要设计、详细设计）数据架构设计,两册六篇125章，今天只讲上册。,涉及三个评审一个讨论：需求报告评审会概要设计评审会数据库设计评审会关于详细设计的讨论,Back,第一篇：软件需求开发,Back,1.1需求分析报告评审会第一个评审会,项目名称：投核保系统项目规模：大型金融项目产品经理：在项目合同签署10天就完成了业务调研和需求分析 报告的编写参会人员：客户代表、市场部、产品开发部、质量保证部、测试部、 评审专家顾问等PPT

5、 讲解：产品经理开始对需求分析报告PPT进行讲解，前后用了 10分钟讨论意见：PPT讲解结束，大家都觉得汇报非常成功。评审专家：公司聘请的改进公司当前项目开发管理流程的顾问，向与 会的每个人提问了解情况，提出评审意见。,专家评审意见：,不通过,为什么呢,？,存在的问题：需求分析报告脱离了业务调研报告，没有业务调研报告，闭门造车凭空设想没有实际意义。将组织机构图照搬为系统结构图。文档结构不清晰，逻辑混乱。对UML和面向对象分析方法一知半解，专业知识不够。领域类图抽象不完整，对领域类图的理解不够，不能为系统架构过程提供任何知道没有具体的指标，用词含糊，无法为架构师和测试人员提供测试标准。,【现场情

6、景】,点评： 该案例中，出现的问题也是很多软件开发企业存在的问题。尤其是很多中小软件企业，不注重软件开发前期的准备工作。由于工期紧张，为了节省时间往往需求调研还不够充分的情况下，就开始进入了软件设计开发阶段，造成后期编码过程中不断翻工、修改，甚至出现推到重做的情况。 所谓磨刀不误砍柴工。下面要讲的内容就是“磨刀阶段”之“业务调研阶段”，主要包括：面向对象和UML等基础知识、业务调研报告的结构和编写要求。,Back,1.2 面向对象的概念（一）,系统分析法中最流行的方法：面向对象分析法。面向对象的建模语言：统一建模语言（Unified Modeling Language，UML）业界内认可对比较

7、高的一种语言,什么是对象？,万物皆对象！,比如：一辆汽车、一个人、一张成绩单、一份课程表,什么是类？,具有相同属性和功能的所有对象的集合。,比如：交通工具、淄博人等,什么面向对象？,面向对象是一种对现实世界理解和抽象的方法，是计算机编程技术发展到一定阶段后的产物。,Back,1.2 面向对象的概念（二）,什么是接口？,是一个抽象的概念，是指系统对外提供的所有服务。,接口描述系统能够提供哪些服务，但不包含服务的实现细节。每个对象都是服务提供者，所以每个对象都有接口。,类和接口的对比！,类：Class！ 接口：Interface！,类是对象的集合接口是服务的集合，没有实现代码接口一般需要某个类来支

8、持他(实现它的服务细节)接口的真正用途：提供一种规范。实现这个接口的类，实际上就是满足了这个接口的规范。,比如：世界上有1000种插头,但只有两种插口，2孔和3孔,类,接口,支持,Back,1.2 面向对象的概念（三）,面向对象的三个技术！,一、封装：是一种信息隐藏技术,二、继承：是类与类之间的一种关系（父类、子类关系）,三、多态：是将多种不同的特殊行为进行抽象的一种能力,是指将一组数据和与这组数据有关的操作放在一起，形成一个能动的实体对象封装机制的目的就是将对象的使用者和设计者分开,类层次反映了现实世界中普遍存在的一般与特殊的关系，本质是从已有的类基础上扩充、改造得到新的类。可以修改和重写父

9、类中的方法。优点：提高软件的重用性，便于实现多态性便于系统的扩展,使得语言具有根据对象的不同类型以不同方式处理通常要结合继承性一起发挥作用,Back,1.2 面向对象的概念（四）,什么是面向对象分析技术？,面向对象分析方法（Object-Oriented Analysis，OOA），是在一个系统的开发过程中进行系统业务调查以后，按照面向对象的思想来分析问题。,建模语言：UML语言UML动态模型图：包括交互图、行为图（一）交互图：时序图、协作图；（二）行为图：状态图、活动图。UML静态图：包括类图、用例图、包图、组建图、配置图,面向对象软件设计一般步骤：需求分析、分析设计、编码实现、测试和维护。

10、,面向对象的基本准则：,信息隐藏：通过对象的封装来实现。减少通信开销：设计中应做到子系统的各个部件之间的通信量达到最小。良好的可扩展性：继承和多态在程序设计中有很好的可扩展性。高内聚：内聚度高的模块很容易理解很容易被服用、扩展和维护低耦合：使系统中某一部分的变化对其他部分的影响降到最低，各个系统模块之间应该相互独立。,Back,1.3 UML介绍（一）,UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言，用模型来描述系统的静态特征和动态特征。 UML可以从不同的角度为系统架构进行建模，为不同的开发人员，形成不同的视图。,UML的组成：,图：UML中分9种（后面讲）,视图：是有一个或多

11、个图组成的对系统的抽象。分5种（后面讲）,模型元素：包括事物和关系,通用机制：包括修饰、注释、规格说明、通用规划和扩展机制。,图是UML的重要组成部分,所有的视图都可以由前述的9种基本图组成。,UML图分为静态图和动态图：静态图主要包括：用例图、类图、对象图、组件图、部署图。动态图主要包括：协作图、状态图、活动图、顺序图。,UML视图分五类：用例视图：从用户角度来描述系统应具有的功能，是对系统的抽象表示逻辑视图：是从系统的静态结构和动态行为角度分析如何实现系统的功能实现视图：主要供开发者使用，进程视图部署视图：主要描述系统的部署方式,UML图：,UM视图：,事物：代表一切可以定义的东西。分为：

12、结构事物、行为事物、分组事物,2. 关系：把事物联系在一起，组成有意义的结构。分为：关联关系、依赖关系、泛化关系、实现关系、聚合关系,Back,用例是抽象出来的用以描述人或事物具有哪些功能的概念。需求分析中用例图会用到。后面再讲.,1.3 UML介绍（二）,UML关系，能够很好的将用户所理解的事物符号联系起来，描述一个有意义的结构。 UML中，根据不同的视图对关系进行分类，但大体一致,用例关系,关联关系：最直观简单的关系。UML中用实箭头表示,包含关系：原有类分出的几个功能片段。基类没有了被包含类是不完整的。用虚箭头加include,扩展关系：在原有类的基础上进行功能扩展，扩展类具有相对的独立

13、性。基类没有了扩展类也是完整的。用虚箭头加extend,泛化关系：表示继承关系，子例与父例相似，继承父例的所有结构、行为和关系，但表现出更特别的行为。用三角箭头表示,Back,1.3 UML介绍（三）,类关系,关联关系：最一般简单的关系。UML中用实线表示,泛化关系：继承关系，同用例关系。用空心箭头表示,实现关系：类与接口之间最常见的关系。用虚线空心箭头表示,依赖关系：一个对象的存在需要另外一个对象的存在。用虚线箭头表示。用虚线箭头表示,聚合关系：整体与部分的关系，且整体与部分可分离，均具有独立的生命周期。用实线空心菱形箭头表示,组合关系：整体与部分的关系，比聚合关系更强，整体与部分不可分割，

14、其中一个部分的生命结束就代表整体的结束。用实线实心菱形箭头表示。,依赖是最弱的关系。关联、组合和聚合都是依赖关系的一种。组合和聚合关系也是关联关系的一种。关联、聚合、组合，关系一次增强！,Back,1.3 UML介绍（四）,包关系,包的组成：类、接口、组件、节点、协作、用例、图，以及子包,包：可以理解为文件夹，名称空间。用于将元素根据语义进行分组,包的表示：UML中，包用两个矩形来表示,包的关系：引入和访问依赖关系（可访问其他包，前提得先引入该包。具有传递性）、泛化关系,组件：又叫构件，可以是一组接口。,组件分类：三大类配置组件、执行组件、工作产品组件。,组件关系：,组件关系：组件与接口的关系

15、（分实现关系、依赖关系）、组件与组件的关系(依赖关系，同类之间的依赖关系),Back,1.3 UML介绍（五）,UML机制，就是UML绘图时的辅助功能。UML机制包括修饰、注释、规格说明、通用划分和扩展机制,通用机制,规格说明：描述系统的细节,修饰：对模型元素进行修饰，增加了模型元素的语义。比如加粗、下划线,注释：是一种图形符号用来限制或给一个元素加上注释。注释用一个带有折角的矩形表示,通用划分：类、对象二分法，接口、实现二分法。,扩展机制,UML扩展机制允许使用者自定义些自己构造型语言成分。,UML扩展机制包括：构造型、约束、标记值。,Back,1.4 业务调研方式,尽量到各部门，各科室的办

16、公现场去调研，尽量不要以召集会议的方式进行调研。尽量收齐所有业务单据、台账、报表、业务流程、规章制度等材料，以及相应的电子版材料。细节研究。用户无法面面俱到，需要我们去分析、理解和提问绘制业务流程图。在业务调研结束后，及时整理业务流程图，可以手工业务流程，现场请求客户确认。,一般是在调查问卷填写结束和面谈结束后、需要跨部门或跨职能业务流程确认时进行。,采用该方法的原因：专业差别、沟通困难，但可以将某些元素总结出来以问卷的形式针对性了解。 问卷调查的优点：能够方便快速的获取软件开发所需的信息内容,（一）问卷调查,（二）面谈,（三）组织讨论,Back,1.5 业务调研报告的编写（一）,业务调研,整

17、理静态结构,整理动态结构,非业务调研,文档整理,问卷调查,面谈方式,部门岗位职责描述,组织讨论,组织结构图,文档变动性调研,原始表单整理,业务流程图,地域性调研,部门变动性调研,业务流程变动性调研,岗位职责变动性调研,编写流程：,Back,1.5 业务调研报告的编写（二）,业务调研报告的静态结构,首先绘制单位的组织结构图。,再对部门职责进行描述，一般采用表格形式。,然后对每个岗位承担的职责详细描述，一般采用表格形式。,最后对每个岗位职责上生成的原始资料整理，分门别类的处理。（数据字典里会用到）,Back,1.5 业务调研报告的编写（三）,业务调研报告的动态结构,即业务流程图，采用泳道图的方式绘

18、制，再对各运行节点用表格进行描述。,业务流程图：是物理模型。描述的是组织内各单位、人员之间的业务关系、工作顺序、业务信息流向图表。,用途：帮助系统分析人员找出不合理的流。,分类：顶层业务流程图、底层业务流程图。,泳道式业务流程图,Back,1.5 业务调研报告的编写（四）,非业务调研,非业务调研其实就是在企业现有业务运行的基础上，需要对客户进行进一步沟通，了解客户在业务范围之外的一些特殊情况。,客户系统的运行地域性变动,部门变动性：单位内部部门的组织结调整的频繁程度,业务流程变化性：组织结构内部对业务流程调整的频度,岗位职责的变动性：某些岗位的工作职责的变化频率问题,文件资料的变动性：文档的变

19、化频度，比如文档格式、文档数据项、文档的使用者,非业务调研是需求分析中非功能性功能需求的基础！,Back,1.5 业务调研报告的编写（五）,业务调研报告内容格式,目标组织结构（一）组织结构图（二）部门职责描述（三）岗位职责分析,目标流程设计（一）分层说明（二）一层业务流程图：泳道图、运行节点描述（三）底层业务流程图：泳道图、运行节点描述,表单资料整理（一）需要整理的格式文件（二）不需要整理的格式文件（三）不惜要整理的图像文件,现行系统状况 当前系统建设情况、存在的问题、可重复利用的资源等，以便在此基础上进行系统建设。,非业务分析（一）地域性调研：城市分布、办公区域分布、物理地址分布等（二）部门

20、变动调研：比如新部门的增加（三）业务流程变动性调研：（四）岗位职责变化性调研：（五）文档变化性调研：,特别期许（一）为了适应客户工作过程流程的灵活变化，要求系统至少能够实现业务流程定制工作。（二）无纸化办公，除签字部分。（三）自动化程度高，系统自动实现一些功能，并给出，比如，初审意见。（四）工作角色变化灵活化。为适应工作人员职责的灵活变化，系统能够根据不同的角色分配系统功能。（五）数据访问权限设置，不同职级的人员查血的信息不同,Back,业务调研报告小结,回想本篇驱动案例中存在的问题。UML基础知识的了解和一份内容完整、结构清晰的业务调研报告，解决了案例中第1、第2和第4条问题。业务调研报告的

21、编写，是为了给需求分析报告编写依据。需求分析报告不能脱离业务调研报告。那么如何从业务调研报告中挖掘需求，形成需求分析报告呢？,Back,1.6 用例规划需求分析最基础部分,什么是用例？,用例是系统给外部提供的可视化的功能单元。代表的一个外部功能块，不考虑内部实现过程,UML表示：椭圆，下方标注用例名称,用途：从外部看系统该有的功能，将客户的想法用更加容易理解的图形化样式展现出来。,来源：业务调研报告。抽取自关键业务中的动词或动词词组。,前面“用例关系”中提到过,用例具有参与者，是与用例有来往的人或事物，是系统的外部实体。,用例的参与者,UML表示：用人形图标表示，下方为参与者名称,用途：一个系

22、统中必然有参与者，否则系统没有任何存在意义,参与者与用例连接在一起，表示两者之间有信息交互,参与者的存在是为了执行用例的,参与者之间的关系类似于类关系。最常见的就是泛化关系继承关系。,Back,什么是用例图？,用例图是业务调研后，最先用来跟用户交流讨论的UML图,用途：从外部看系统该有的功能，将客户的想法用更加容易理解的图形化样式展现出来。,来源：业务调研报告，抽取自关键业务中的动词或动词词组。,1.6 用例规划用例图,组成：参与者、用例、用例间的关系,用例描述,用例图仅仅是文字说明的补充，需要结合用例描述来完成。用例描述往往会被一些系统分析员所忽略。,Back,1.6 用例规划从业务流程中归

23、纳用例,Back,1.7 数据字典需求分析中最易被忽略的部分,什么是数据字典？,数据字典是一个定义应用程序中使用的所有数据元素和结构的含义、类型、数据大小、格式、度量单位、精度以及允许取值范围的共享仓库,数据字典是需求分析报告的重要组成部分,数据字典的维护，一般独立于软件需求规格说明,数据字典确保了数据在整个开发过程中的唯一性，指导系统架构师、数据架构师、程序员等完成架构和实施等工作,与数据字典有关的概念：,元数据：关于数据的数据。元数据引领好数据,数据元：对象类与其某种特性构成的数据表示，可以对应多个意思。如人和年龄，构成数据元“人的年龄”。,数据集：为特定的目的而收集的、具有特定主体的一组

24、数据，是若干数据元的集合体。如姓名完全表示有姓名、昵称、化名、笔名、中文名、外文名、曾用名、曾用名使用时间等。,这里所讲的数据字典与数据库设计中的数据字典概念要大。它是为所有的开发人员服务的，包括为数据库设计提供服务,Back,1.7 数据字典解读业务调研，编写数据字典,解读业务调研报告,业务调研报告是系统分析和设计的唯一入口，不能脱离它编写数据字典用例规划，是根据业务调研报告中的业务流程图解读出来的而数据字典，是从业务碉堡恭的原始表单中整理出来的,分析用例与原始表单关系，检查用例汇总是否有遗漏的原始表单，如有遗漏及时补充。建立原始表单整理表,编写数据字典的编写规范，包括数据命名规范、数据集编

25、号规范、数据项命名规范、数据项英文命名规范等，建立系统数据字典编写规范,对应原始表单，建立系统数据集确认表,对应数据集，对数据项进行归类整理，建立数据集数据项列表,为所有数据项建立字典说明其定义、数据类型、标识符等。,将所有的输将解释说明编排整理汇总，完成数据字典数据库的创建。,Back,1.8 领域类图描述的是系统中的操作对象,什么是领域类？,用例是系统的外部功能数据字典是对系统中的数据类型的描述领域类是用例这个系统功能的操作对象。,领域模型来自业务描述中的名词以及对名词的抽象,领域模型是一个分析模型，是帮助分析人员、用户认识现实业务的工具，是需求分析的产物，描述的是业务中涉及的实体及其相互

26、之间的关系,领域类包括三大要素：领域类的名称、具有的属性、对这些属性的操作,表示：三格矩形图,领域类图的可见性（封装属性）：分四种，private、public、protected、Package,Back,1.8 领域类图领域类图设计,领域类图的设计原则,1.独立于实现类原则；2.弱关联原则；3.服务需求原则；4.数据结构无关原则,第一步：提取领域类图,整理原始表单：将原始文档表单和用例进行匹配，建立用例与文档关系表。将有效匹配的文档资料初选为系统中的类。补充类图：为保证数据的完整性和安全性需要添加其他的功能和用例，所以应该补充一些类图。这些就是类的雏形。类图分割：为了设计上的方便，往往需要

27、对类进行进一步分割，进行分析设计。,领域类的操作一般以用例为单位，所以结合用例和领域类进行操作对比，建立类操作对比图然后形成类初选表最后结合数据字典设计，建立领域类图确认表,从业务调研报告中，挖掘领域类图,第二步：为所有领域类，添加操作；然后为各领域类画领域类图。,Back,1.8 关于非功能需求分析,什么是非功能需求？,非功能需求是指对系统提供的服务或功能的约束。系统分析员经常会忽略掉。,非功能需求不像功能需求那么直观和容易理解，比较的抽象，但确实非常重要。因为它是影响软件的性能和可用性的关键所在。,非功能需求关心的是整个系统的特性，比功能需求更关键。功能需求没有实现可能只是降低了系统的可用

28、性；功能性约束没有满足，可能就会导致系统无法使用,非功能需求的内容范围有：物理需求、实施需求、设计约束、可支持性、接口需求、可用性、性能、可靠性等,Back,采取调查问卷的方式让客户回答，建立客户非功能需求调查问卷，包括需求名称、关键指标、是否理解含义、具体要求等。,如何获取用户的非功能需求？,将不同的用户进行分类，针对不同的用户设计不同的调研内容，建立客户非功能需求调研指标包括客户姓名、部门、职位、关注指标等,非功能需求分析的主要内容：,（一）物理需求分析：是指软件运行的硬件环境要求比如：业务应用服务器，Web应用服务器，数据库服务器,（二）实施需求分析：是指开发过程中，需要的实施环境和设施

29、。比如：运行平台（操作系统），数据库工具，开发语言和工具，建模工具，绘图工具，测试工具等,（三）易用性需求分析：涉及到美工和界面，人机工程，交互式设计，心理学，用户行为模式等方面。主要有三个原则：易见、易学、易用。,（四）性能需求分析：如响应时间，用户数（吞吐量）,（五）可靠性需求分析比如：应用服务器故障问题，数据库故障问题,1.9 需求分析报告项目的宪法,需求分析报告,需求分析报告是业务调研报告或可行性分析报告后的重要文档，相当于项目的宪法,需求分析报告是客户合同的一部分，主要任务是描述系统要做什么，而不关心如何做。,需求分析报告评审等级是项目评审中最高高级别的评审，参与人数也是最广的,需求

30、分析报告的基本依据是业务调研报告。有事还在此基础上进一步扩展，然后与客户沟通，讨论大家一致可接受的需求,Back,需求分析报告编写中，严禁使用形容词等描述性语言进行系统描述，特别是性能需求的分析方面，必须是可测试的数量词准确说明,1.9 需求分析报告包含哪些内容,需求分析一般包含哪些内容？,项目风险分析,产品范围,产品功能,Back,用户类型和特征,运行环境,假设和设计约束,用户界面需求,硬件接口,软件接口,通信接口,系统功能需求,系统非功能需求,数据字典定义,词汇表等,前面我们学了用例图、领域类图、数据字典。就可以用在需求分析报告中。系统功能需求，一般采用用例和领域类图来描述说明数据描述数据

31、描述一般采用领域类图结合数据字典来说明,1.9 需求分析报告报告的编写,可以分为六部分：,Back,第一篇：软件需求开发（小结）,业务调研报告是需求开发的基础，也是一整个项目开发的基础需求调研中的静态结构：公司有哪些部门、部门有哪些岗位、岗位与哪些职责、职责需要完成的文档资料需求调研的动态结构：业务流程图（泳道图）分两层，顶层业务流程图和底层业务流程图对客户原始表格资料整理，保证数据的准确性，为后期编写数据字典提供依据。解读业务调研报告，完成用例规划、完成用例描述、完成领域类图设计。所有的需求开发图都来自于对业务调研报告的准确理解之上。,Back,第二篇：软件架构设计,Back,2.1概要设计

32、文档评审会第二个评审会,项目名称：仍然是投核保系统项目规模：属于大型金融项目软件架构师：总结了上次需求开发的经验，这次架构设计报告评审编 写比较仔细，在正式会议之前项目组内已经进行了预先评 审，项目组各成员都填写了评审意见小组成员意见：18人填写了评审意见表，12人表示没有意见各人观点：测试经理认为架构设计对他们无关紧要；编程人员觉得概 要设计的文档与他们无关，认为详细设计文档做的太细致影 响程序员的自由发挥，还要拿出大量的时间去编写文档，浪 费时间，影响进度。评审专家：评审专家认真听取了每个人的意见后，开始看小组提交的 概要设计说明书。,专家评审意见：,还是不通过,为什么呢,？,存在的问题：

33、文档结构不合理内容不够全面对软件架构的基本知识缺少了解。UML五视图不全面、不规范。,【现场情景】,点评： 评审没有通过的最根本原因是，缺少对软件架构知识的了解。小组成员对犯了“短视”毛病，对软件架构设计不够重视。,Back,2.2 软件架构,什么是软件架构？,软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件,逻辑架构：主要任务是描述软件系统中元件之间的关系，比如用户界面，数据，外部接口等相关概念。物理架构：就是描述软件系统中元件是怎样放在硬件上的系统架构：系

34、统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能。系统架构要求难度大于其他架构，对软件架构师本身技术要求非常高。,架构由许多不同的架构视图来表示。这些视图本质上是以图形方式来摘要说明，主要包括:用例视图、逻辑视图、实施视图、进程视图、配置视图,架构的种类？,架构有哪些视图？,Back,2.2 软件架构软件重用,什么是软件重用,软件重用就是指在多次不同的软件开发过程中重复使用相同或相近软件元素的过程。包括程序代码、测试用例。设计文档、设计过程、需求分析文档等。,可靠性:安全性:可伸缩性:软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场

35、扩展得可能性。可定制化:同样的一套软件，可根据客户群的不同和市场需求的变化进行调整。可扩展性:在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展。可维护性:一是排除现有的错误，二是将新的软件需求反映到现有系统中去。客户体验:软件系统必须易于使用。市场时机:软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。,架构设计的目标是什么？,软件架构构建的就是语意完整、语法正确、有可重用价值的单位软件。,Back,2.3 体系结构、设计模式、软件框架体系结构,什么是体系结构？,软件体系结构是具有一定形式的结构化元素，即构件的集合。包括

36、处理构件、数据构件、连接构件。是架构设计的内容，且易于被绝大多数人所理解。,处理构件：负责对数据进行加工,数据构件：是被加工的信息,连接构件：把体系结构的不同组件连接起来,体系结构在开发过程中的重要作用？,软件体系结构是构建软件大厦的蓝图。软件体系结构有很多种，不同的体系结构，构件不同风格的软件。一定要选择合适的体系结构，就像居民楼的蓝图不能用来建造学校宿舍一样。,软件体系结构建模的目标：,可重用性。使用软件重用技术可以减少软件开发过程中大量的重复性工作，提高软件的生产效率，降低开发成本，缩短开发周期。,Back,2.3 体系结构、设计模式、软件框架设计模式,什么是架构模式？,架构模式也叫架构

37、风格，描述软件系统里的基本的结构组织或纲要。架构模式提供一些预先定义好的子系统，指定他们的责任，并给出把他们组织在一起的法则和指南。常见架构模式有：C/S结构、B/S结构。,什么是设计模式？,设计模式是一套被反复使用、多数人所知晓的、经过分类编目的、代码设计经验的总结使用设计模式是为了可重用代码，让代码更容易被他人理解，保证代码的可靠性。设计模式是代码真正工程化设计模式是软件工程的基石。,设计模式和体系结构的关系：,体系结构是设计模式实现的指导思想。设计模式研究的是一个设计问题具体的解决方法一个体系是一种或多种设计模式和代码的混合体。,Back,2.3 体系结构、设计模式、软件框架软件框架,什

38、么是软件框架？,软件框架是一种半成品，是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构,框架的作用是什么？,框架由于提取了特定领域软件的共性部分，所以在此领域内新项目的开发过程中代码不需要从头编写，秩序在此框架的基础上进行二次开发和调整就能满足要求。这样可以提高软件的质量、降低成本、缩短开发时间，使开发越做越轻松，软件效益越做越好，形成一个良性循环。,框架和平台是一回事吗？,框架是一种半成品，需要开发人员二次开发实现具体的功能。平台的概念比较宽泛，可以是一种操作系统、一种应用服务器、一种数据库软件、一种通信中间件。所以可以这样认为，平台主要是指提供特定服务的系统软件。框架侧重于设计

39、和开发过程，它通过调用平台提供的服务而其作用,软件架构、体系结构、设计模式、软件框架之间的关系？,软件架构是绘制蓝图的整个过程体系结构就是这个蓝图指导“施工图纸”开发的思想设计模式是实现该体系结构的一种解决方法。（比如MVC是一种设计模式）软件框架是建立在体系结构基础上的半成品、模块工具。（比如Struts是为实现MVC模式而开发的框架）UML是描述架构、框架和设计模式的建模语言Visio是UML建模工具,Back,2.4 软件架构与时序图什么是时序图,什么是时序图？,时序图属于动态视图，是描述对象之间是如何互助协作的，以实现用例功能是对用例的进一步说明，描述系统内部的动态结构和内部各对象间通

40、信关系时序图是显示对象之间交互的图，这些对象是按照时间顺序排列的。,Back,2.4 软件架构与时序图组成元素,时序图包含哪些元素？,（一）对象：置于顶部，表示交互开始时对象已存在；不在顶部，交互时创建对象间的左右关系不重要，但为了图的清晰整洁：交互频繁的对象尽可能排在一起初始化真个交互活动的对象放在最左边,（二）生命线：表示对象的生存时间。生命线开始，对象创建；生命线结束，对象销毁。,（三）消息：对象之间的交互式通过互发消息实现的。一个对象可以请求另外的对象做事情消息是来源对象指向目标对象的。消息包括：简单消息、同步消息、异步消息简单消息：直线箭头。同步消息：实心箭头。源对象发出消息（请求）

41、，然后等待目标对象处理结果接受到回应。异步消息：单箭头。源对象发出消息后，就去干其他事情去了，不用等待回应消息。,（四）激活：对象处于休眠状态，需要消息来激活。对象处于激活状态，表明该对象正在执行某个动作激活在UML时序图中用一个细长的矩形框表示，矩形的高度表示对象执行操作所经的时间。对象接收到消息是可由自己来完成，也可以调用其他对象来完成。,参与者,对象,生命线,消息,激活,Back,2.4 软件架构与时序图时序图的用途,时序图的用途,领域类图、用例图是从系统功能和结构的角度来分析系统的，都是围绕着系统的外部结构进行描述的，不考虑具体实现过程,时序图是从系统本质开始描述。从用例的内部结构开始

42、描述；解释的是用例内部对象之间的关系，是对用例的细化。它按照时间顺序清晰描述了用例这个功能块中各用例之间的通信关系。,时序图的创建，依托于领域类图和用例图！,Back,2.4 软件架构与时序图绘制时序图,时序图绘制步骤,选择要绘制时序图的用例（不是所有的用例都需要绘制时序图）,列出用例的事件流（事件流，展现了消息的推送过程）,Back,把子系统作为黑匣子，根据事件流绘制没有内部对象的时序图（简单时序图）,揭开黑匣子，将每个服务替换为用例中用到的对象，然后添加相关消息（复杂的时序图）,2.5 软件架构与活动图包含哪些元素,活动图的组成元素？,（一）活动状态具有一个入口和至少一个外出转换用圆角矩阵

43、表示,Back,（二）动作流活动之间的转化，表示两个状态或动作状态之间的关系用实线箭头表示,（三）开始和结束开始：实心圆，实际是一个占位符结束：带边框的实心圆，表示流程的结束,（四）动作状态动作状态是指原子的，不可中断的动作用平滑的圆角矩阵表示,（五）分叉与汇合分叉：表示一个控制流被多个控制流代替，是并发的汇合：是分叉的反向，是指多个控制流合并为一个控制流,（六）分支同一个出发时间，可根据不同的条件转向不同的活动，每个转移就是一个分支。在UML活动图中，分支的控制用菱形来表示。,（七）对象流对象流是控制流的一种活动图中可以出现对象，对象可以作为活动的输入或输出,（八）判断菱形表示判断，可以控制

44、动作流的走向,（九）泳道泳道的主要作用就是区分负责活动的对象,2.4 软件架构与时序图时序图的筛选,时序图的筛选,前面说过，不是所有的用例都需要画时序图！那么如何筛选适合做时序图的用例呢？,列出所有的用例，根据每个用例中所包含的对象的多少进行筛选。少于三个对象的可考虑不画时序图,Back,对象多但流程说明的步骤少，说明时序图复杂度低，也不考虑绘时序图,对象少流程步骤也少，但涉及其他的用例较多，应考虑对其编写时序表,根据上述三个指标，编写时序图筛选表,2. 5 软件架构与活动图什么是活动图,什么是活动图？,活动图是UML中的动态视图活动图描述活动的顺序，展现的是从一个活动到另外一个活动控制流。活

45、动图从实心圆开始，经过圆角矩形（活动）、菱形（判断）、转换线，在泳道中来回穿梭，最终到达终点。,Back,2.5 软件架构与活动图与其他图的区别,活动图与流程图的区别？,流程图着重描述的是处理过程，主要的控制结构是顺序、分支、循环，每个处理过程之间有严格的顺序和时间关系。,Back,活动图描述的是对象活动的顺序关系、所遵循的规则，着重表现的是系统的行为，而非系统的处理过程。,活动图是面向对象的，流程图是面向过程的,活动图能够表示并发活动的情形，而流程图不行。,时序图是针对某一个用例中对象之间的活动顺序关系的。,时序图的自身特点使得他对系统的分析不够完整。无法满足条件转换、分支分叉的表述。,时序

46、图确定了用例之间对象的交互顺序，也确定了对象之间的消息（方法和参数），偏向于对象的构造,活动图指明了程序中某个方法体的活动特征，在某种条件下的对象调用,活动图与时序图的区别？,2.5 软件架构与活动图活动图的设计,从业务调研报告中挖据信息，设计活动图,需求分析报告，设计活动图选择要绘制活动图的用例确定活动图的层面，是顶层还是普通层确定活动图中使用的对象，用泳道分开确定活动的开始节点和终止节点将开始节点和结束节点的所有活动都找出来确定所用泳道的对象流分析分支、分叉，并绘制出来确定动作流，并绘制出来添加活动图说明表，对活动图进行补充说明（活动、参数和对象流、说明）,Back,2.5 软件架构与活动

47、图活动图的筛选,Back,列出所有的用例来，根据用例包含的活动多少进行筛选。活动数量少的说明活动件通信简单，可以不考虑画活动图根据活动图中涉及的对象多少进行判断。如果对象多，但活动步骤少，也不一定要画活动图存在其他事件流，一般需要绘制活动图存在多个条件判断的，分支较多，有必要画活动图存在多想选择的，分叉较多，这类用例活动图绘制的优先级较高综合指标，编制活动图筛选表（主事件流步骤，其他事件流步骤、分支判断、分叉判断、对象数）根据需要，挑选出其中一部分用例绘制活动图。,活动图的筛选,和时序图类似，并不是所有的用例都需要活动图,2.6 软件架构与状态图什么是状态图,什么是活动图？,状态图主要用于描述

48、一个对象在其生命周期内的动态行为。表现为一个对象所经历的状态、引起状态转移的时间、和因状态转移而伴随的动作。可以用状态机图来建模。状态图的重点是描述控制流状态图是个动态视图,Back,2.6 软件架构与状态图包含哪些元素,状态图的组成元素？,（一）状态：指在对象的生命周期中的某个对象的条件或状态所有对象都有状态，状态是对象执行了一系列活动的结果当某个时间发生后，对象的状态将发生改变状态用圆角矩形表示，初态用实心圆点表示，终态用内嵌圆点表示,Back,（二）转移：是连个状态之间的诶关系，表示对象在原状态下执行一定的动作更，并在某个特定事件和条件下进入目标状态。事件标记：是转移的诱因，可以是一个信

49、号、时间、条件变化和时间表达式警界条件：满足该条件时，事件才引发转移结果：对象状态转移后的结果,（三）动作：是一个可执行的原子操作，也就是说动作是不可中断的，其执行时间使可以忽略不计的。,（四）自身转移：状态可以有自身状态的转移，称为自身转移。,（五）组合状态：含有子状态的状态的状态。组合状态在某个时刻可以同时达到多个子状态。,（六）并发区域：状态可以分为区域。,2.6 软件架构与状态图状态图的设计,状态图的设计,（一）确定状态图的上下文，找到要做状态图的目标对象（比如一个用例）（二）选择初始状态和终结状态初始状态和终结状态其实是个伪状态，其他的状态全是中间状态。（三）发现对象个各种状态（四）

50、确定状态可能发生的转移（五）吧必要的动作加到状态或转移上（六）绘制状态图,Back,状态图的筛选方法,根据用例的包含的状态的多少筛选分析用例中的所有事件，和事件对状态的改变，如果结构相对复杂，则需要单独进行分析分析用例的分支和分叉情况，越复杂越有限画状态图最后，综合所有指标编制状态筛选表,2.6 软件架构与活动图活动图的筛选,Back,列出所有的用例来，根据用例包含的活动多少进行筛选。活动数量少的说明活动件通信简单，可以不考虑画活动图根据活动图中涉及的对象多少进行判断。如果对象多，但活动步骤少，也不一定要画活动图存在其他事件流，一般需要绘制活动图存在多个条件判断的，分支较多，有必要画活动图存在