搜索
—————————————————————————东南大学计算机科学与工程学院《软件工程》复习总结（根据张敏灵老师的英文PPT）—————————————————————————第一章软件系统的特点：1.复杂的创造很多功能实现许多不同的（往往又是矛盾的）目标包含许多组成部分不同的参与者开发流程和软件生命周期经常持续很多年2.容易发生变化客户或终端用户需求变化发现错误开发者有了很好的理解新技术出现，员工变迁软件工程的定义：1.建模软件工程师通过建模解决复杂性问题模型：系统的抽象体现，使我们可以回答系统的问题并直观理解系统2.问题求解在有限的预算和时间下，模型寻求合理的解决方案OOSE：object-orientedsoftwareengineering需求获取需求分析系统设计对象设计实现测试3.知识获取软件工程师收集数据，组织成信息，形成知识非线性过程4.原理驱动软件工程师需要了解作出决定的环境条件和做出这些决定的基本原理用来应对变化SE概念：技术、方法和工具的集合，可以在有限的时间、预算以及变化出现的情况下实现高质量的软件系统参与者和身份系统和模型生产产品（内部产品+交付产品）功能需求和非功能需求符号，方法，方法论方法论：方法的集合，解决一类问题或说明如何以及何时每个方法需要被用到本书用到的方法论：1.需求获取和分析2.系统设计和对象设计3.变化相关的活动4.配置管理SE不仅是有关开发，也关于管理开发活动：需求获取，需求分析，系统设计，对象设计，实现测试管理活动：交流，原理管理，软件配置管理，项目管理，软件生命周期第二章UML：UnifiedModelingLanguage面向对象软件建模中出现的标准创始人：OMT(JamesRumbaugh)OOSE(IvarJacobson)Booch(GradyBooch)用途广泛：功能模型：用例图（用户角度）对象模型：类图（对象、属性、联系、操作角度）需求分析—分析对象模型—应用概念系统设计—系统设计模型—系统接口描述对象设计—对象设计模型—解决方案对象的详细描述动态模型：交互图—在一系列对象之间进行一系列消息交换来描述行为状态机图—针对某一个对象的状态转换活动图—针对控制和数据流描述行为用例图：描述系统功能，在需求获取和分析时使用，从外部角度来关注系统行为用例：描述系统提供的功能，产生用户可见的结果参与者：任何与系统交互的人（用户，另一个系统，系统的物理环境）参与者在系统边界外，用例在系统边界内（乃们一定要记住用例名是写在这个椭圆下面的啊TT学长考试的时候全写在里面了！）类图：描述系统的结构类：描述具有相同结构和行为的对象集的抽象对象：在系统执行过程中被创建、修改和销毁的类的实体有状态（包括属性值和与其他对象的联系）类图的成分：类，对象，属性，操作，联系交互图：在用例中涉及的对象（参与对象），表现的就是这些对象之间发生的交互状态机图：转换包括对象未来可以转向的状态和转变条件活动图：活动：代表一系列操作执行的建模元素针对活动来描述系统行为其他活动的结束、对象的可用和外部的活动都可以出发活动的执行与流程图相似：控制流（操作发生的顺序），数据流（操作中对象的交互）用例图：《extend》代表异常或很少调用的用例，箭头指向被扩展的用例《include》代表被分离出来的用例，箭头指向使用的用例《inheritance》代表一个用例可以通过添加细节特化另一个更一般的用例，箭头指向那个一般的用例用例描述：1.用例名称2.参与者3.事件流4.进入条件5.退出条件6.特殊需求类图：表现系统的结构需求获取分析中对应用域概念建模在系统设计中对子系统建模在对象设计中说明类的详细行为和属性类：代表一种概念，封装属性和操作，每个属性有一个类型，每个操作有一个签名,只有类名是强制的信息实例/对象：实例代表一种现象，实例名有下划线，名字可以只包括类名关系也可以通过属性来刻画关系类可以用自己的操作和属性，用虚线连在关系线上聚集：共享聚集：表示一种“属于”继承，空心菱形组合聚集：更强形式的聚集，生命周期必须一致，实心菱形限制（qualification）：减少关系的复杂性继承：“是一种”的继承，通过分类简化分析模型，子类继承父类的操作和属性包：可以用UML包机制来组织子系统对象模型建立步骤：1.找到新的类2.定义名字、属性、方法3.找到类之间的关系4.标注一般的关系（has\owns,etc.）5.决定关系之间的多重性6.重审关系7.找到分类（使用继承）8.简化、重组顺序图：在分析中，优化用例描述，找到更多的对象（参与对象）在系统设计中，优化系统接口消息—参与对象，消息是参与对象中的方法水平虚线箭头代表数据流在消息前有个*代表迭代重复发送消息，在消息前有个[布尔表达式]代表一种发送消息的条件消息指向一个对象的激活（就是对象下面的长方形）则代表创建（creation），在最后的激活上有个代表销毁，销毁可以代表一个对象有用的生命的结束状态机图：状态：满足一个对象（或系统）某种属性的一种情形转换：被事件、条件或时间触发的状态转变Action动作：不可被打断的，有转换action，内部转换action，entry/action,exit/actionActivity活动:在状态内部的可能是长时间的活动，当退出转换被调用的时候activity会被打断，用do做标签嵌套状态机：内部转换来减少复杂度活动图：是状态图的特殊形式活动图中的状态是活动（“功能”）活动结束自动跳转，不需要驱动活动图对于描述系统的工作流程非常有用活动允许对“决定”（一个菱形）和“并发性”（竖线，包括把控制流分成几个线程和同步多个活动）进行建模活动还可以被分成若干个泳道，代表这些活动是被哪个对象或子系统实现的第三章角色：定义了责任（要去做什么）责任被指定到角色身上，角色被指定到人身上任务：描述了被管理人员追踪的最小数量级的工作，包括：1.角色2.工作产品3.开始时间4.计划工期5.需要资源工作产品：可见的任务产出，交付到用户手中的叫作交付产品活动：一系列相关的任务可能会以不同的名字再次被包含到更高级的活动当中允许关注分离在活动中存在优先关系计划内沟通：问题陈述，客户评审，项目浏览，同行评审，现状浏览，集思广益，发布，事后浏览……计划外沟通：需求的澄清，需求的变化，问题求解同步沟通机制：面对面交谈，问题和正式会面，会议，同步群件异步沟通机制：电子邮件，新闻组，万维网，Lotus公司的Notes（其他重点可以看书，还是多看看中文比较好，毕竟试卷是中文....）第四章软件生命周期：需求获取，需求分析，系统设计，系统细节设计，实现，测试需求说明用自然语言，分析模型用UML功能需求：描述系统和环境之间的交互，与实现无关非功能需求：不与功能行为直接相关的方面1.可用性：必须是可测量的（网购需要的步数）2.鲁棒性（健壮性）：错误的输入，外界环境的改变…3.有效性：系统正常运行时间的比例（不要总是down机）4.性能5.可支持性限制（伪需求Pseudorequirements）：由客户或环境提出需求确认：1.正确性：是否代表了客户的本意2.完整性：系统能应用的场景是否全面3.相容性：没有相互矛盾的需求4.明确性：需求只能有一种解释方式5.可实现性：需求能够被实现和交付6.可追踪性：每个系统行为都可以追踪到一系列的功能需求需求获取的不同方式：1.绿地工程：需求从用户和客户处抽取2.再工程：新需求从现存系统中抽取3.界面工程：需求从技术使能者或新的市场需求抽取场景：一种陈述性描述，所描述的是，在人们使用计算机系统和应用的时候他们所做的和所经历的。（这是根据老师PPT上的原句翻译的，个人认为书上99面的翻译是错的。原句是：”Anarrativedescriptionofwhatpeopledoandexperienceastheytrytomakeuseofcomputersystemsandapplications.”）As-is场景：描述了当前情况，常用于再工程项目，通过观察用户并将他们的活动描述成场景，一次来理解当前系统Visionary空场景：描述了未来的系统，常用于绿地工程和再工程项目。开发者和用户两个方面。关于用例的在前面已经有了，再稍作补充：用例是场景的抽象提取用例可以被多个对象使用分析的关键：从用例出发，找到参与对象第五章对象建模的步骤：1.类定义2.寻找属性3.寻找方法4.寻找类之间的关系实体对象：代表被系统追踪的持久性信息（应用域对象，也被称作“业务对象”）边界对象：代表用户和系统之间的交互控制对象：代表系统所执行的控制任务不同的对象类型让我们更好的应对变化对象类型起源于Smalltalk(AlanKay):Model,View,Controller(MVC)Model-EntityObjectView-BoundaryObjectController-ControlObject版型机制，模板机制（stereotypemechanism）：在UML中可以引入新的建模元素类型《String》Name还可以用图标(icons)和图形符号来定义模板在用例中寻找参与对象：1.选中一个用例，观察事件流2.做语法分析（Abbott’sTechnique），名词就是对象或类的候选项，动词就是操作的候选项3.定义不同对象的类型注意：这只是在用例中寻找对象，如果是整个对象定义过程，则是如下：1.从用户和应用域专家处获得一系列场景2.从场景中抽取出用例3.再进行上面“用例中寻找参与对象”的过程，同时还要进行的是组建UML类图组建类图的过程：1.类定义（语法分析，领域专家）2.属性和操作的定义（有时在类之前就被发现）3.类关系的定义4.多重性的定义5.任务的定义6.继承的定义动态图为对象模型发现和补充操作顺序图：布局：第一列——初始化用例的参与者第二列——边界对象第三列：管理剩余用例的操作对象创建：边界对象在用力初始化的时候被创建，控制对象由边界对象创建访问：实体对象被控制对象和边界对象访问，实体对象决不能调用边界对象和控制对象构建顺序图中，可能会有新出现的事件，这些事件可以被认为是接受这个事件的类的一个public权限的操作集中控制式结构，操作可以交换顺序，有新需求时可以插入新操作非集中式控制结构，操作之间有很强的联系和顺序性UML状态图符号（Notation）事件是斜体，条件用[]括起，动作和活动之前都要加/Notation是根据Harel的工作基础上建立起来的超状态：其中有很多嵌套子状态从其他状态进入超状态是进入的第一个子状态从超状态的任意一个子状态都可以离开两种类型的并发性：系统并发性：对象并发性：导航路线：状态图可以被用作用户接口的设计状态：界面名称活动/动作：在界面名下面，前面有个“·”，一般只有退出动作会写出来状态转换：退出动作的结果（点击按钮、选择菜单、光标移动）Modelverification检验模型之间转换modelvalidation把模型结合实际进行比较（更高一层），正确性、完整性、一致性、无歧义性、可实现性对象模型占主要：系统有很多类，这些类的状态无关紧要，但是类之间的关系很复杂动态模型占主要：模型有很多事件：输入、输出、异常、错误等功能模型占主要：模型执行复杂的转换（计算包含许多步）RAD(RequirementAnalysisDocument)第六章“Therearetwowaysofconstructingasoftwaredesign:Onewayistomakeitsosimplethatthereareobviouslynodeficiencies,andtheotherwayistomakeitsocomplicatedthattherearenoobviousdeficiencies.”-C.A.R.Hoare设计目标是对不同利益关注者的权衡子系统：在UML中以包的形式出现对象模型中的对象和类是子系统的“种子”服务：功能模型中的用例是服务的“种子”服务在系统设计中被定义子系统接口：是服务的优化