搜索
基于面向对象的软件分析与设计一般性步骤-2-内容安排一般性步骤若干规则文档规约术语项目-3-内容安排一般性步骤若干规则文档规约术语项目-4-步骤１问题陈述用文字结合图表的形式，从各个项目关系人，尤其是用户的角度，描述系统要做什么２需求分析用例图，活动图，用例规约，补充规约和术语表３架构分析架构文档，用包或类图的形式描述架构；软件系统的设计模式；系统关键抽象图；用例实现，用顺序图或协作图描述用例实现过程-5-步骤４用例分析用例的交互图，用例中的事件流图，设计系统的分析类，对分析类的机制进行设计５设计元素的设计设计类图；子系统和接口图，应描述子系统和接口之间的关联；至少一个映射表，将分析类映射到设计元素，推进系统设计的过程６系统运行时刻架构设计一个或多个类图或进行（线程）图，应明确参与类、类的属性和操作，以及类之间的关联-6-步骤7分布式系统的设计一个或多个部署图，描述节点、连接以及在节点上部署的软件、硬件、协议等制品８用例设计一个或多个用例及系统的参与类类图；子系统设计应给出顺序图、设计元素图（类图）9类的设计给出最终的参与类类图，完成类的所有参数包括，属性、操作、关系及类的策略模式10数据库设计基于编程环境和平台，设计系统的数据库表或数据对象-7-内容安排一般性步骤若干规则文档规约术语项目-8-若干规则规则１软件分析设计过程是一个迭代过程规则２软件分析与设计，采用“敏捷开发+RUP”的理念，具体应用时可适当删减规则３大量工程实践表明，需求文档中，至少要完成：问题陈述、用例析取、用例规约、补充规约、术语表-9-若干规则规则４工程实践表明，设计文档中，必须完成：系统架构文档、系统架构设计图、系统关键抽象（实体类）类图、系统分析类的设计、类的机制分析与设计、子系统的划分与设计、接口设计、设计类的设计等规则5系统运行时刻架构设计、系统部署设计可以丰富并充实系统的设计方案，使设计方案更加完善和严谨-10-内容安排一般性步骤若干规则文档规约术语项目-11-文档规约１需求分析问题陈述(ProblemStatement)用例图(UseCaseModelMainDiagram)用例规约(UseCaseSpecification)补充规约(SupplementarySpecification)术语表(Glossary)其他，如活动图(ActivityDiagrams)-12-文档规约2架构分析用文字描述架构设计方案(ArchitecturalDecisions)架构图(TheArchitecturalDesignDiagram)系统关键抽象（实体类）图(TheKeyAbstractions:Classdiagramcontainingthekeyabstractions)-13-文档规约3设计元素设计子系统及其接口(DesignSubsystemsandtheirInterface)分析类到设计元素的映射表(TableMappingAnalysisClassestoDesignElements)用文字描述划分子系统的原则；用类图描述每个子系统及其接口设计；用表描述分析类到设计元素的映射-14-文档规约4系统运行时刻架构设计用类图或进行图描述运行时刻架构用类图或进程图、线程图，描述解决系统运行时刻可能出现的冲突的方案5分布式系统系统部署图，描述系统部署的方案，其中应解释节点和链接-15-文档规约6用例设计交互图，对每个用例描述其实现过程，为类的详细设计（确定类的操作）奠定基础参与类图（VOPC），即包含系统全体类的类图，写出类之间的关联。实现系统需求分析中要求的功能-16-文档规约7类的设计类图，描述系统最终的架构设计方案；建议用“包”体现，应描述出各层架构“包”之间的关联类图，为每个用例设计类交互图，改进更新系统中各用例的用例实现图（用交互图表达）状态图或状态机，描述类的对象状态系统完整、详细的类图，包括类的操作、属性、关联等，即应描述出每个类的所有参数及其细节-17-文档规约8数据库的设计数据表或类图，结合系统中将采用的DBMS设计数据库表或数据对象9测试方案和测试用例设计测试方案(TestPlan)测试用例(TestCase)-18-内容安排一般性步骤若干规则文档规约术语项目-19-术语1用例模型包括角色（参与者）、用例及其关联角色是系统的外部环境，一般分为使用者，其他软件和硬件三种情况2（需求分析中的）术语表定义系统中术语的领域知识、解释条款或其他名词，通常，这个文件可以作为一个非正式的数据字典，以便项目关系人获取必要的信息3补充规约描述系统全局性的非功能需求，作为问题陈述和用例规约的补充-20-术语4模式对一个软件系统提供：一个共同问题背景下共同的解决办法；一种比较小粒度的技术解决方案；一个总体解决方案的一部分5架构对一个软件系统：定义了一个解决问题的一般性方法，概括地提供了一个解决方案6用例实现用交互图、类图描述，针对用例，提供分析和设计制品，并使上述制品满足分析到设计的可追溯性要求-21-术语7确定（类）构造型确定类的名称；确定类的边界类、控制类或实体类8分析类指确认了名称、构造型和操作的类9关键抽象分析领域知识、分析需求分析、分析术语表、分析域模型或商业模式。确定系统要存储或惯例的信息，将其设计为系统的实体类-22-术语10设计类类的所有参数细节都已经确定，包括类的名称、构造型操作，属性、关联、策略模式、可见性等11用例分析完成每个用例的实现，析取系统的关键抽象，设计分析类12识别设计元素完成设计类的设计，设计系统的子系统，设计系统的子系统接口-23-术语13设计元素设计类、子系统、子系统接口14分析类机制在应用软件系统中，根据应用需求，一些类需要具备特殊的性质，如安全性、分布性、持久性等。此时用一个表把需要特殊处理的类及其性质明确列出15子系统通常粒度比较大，其实现了一个或多个接口、子系统之间低耦合、可以即插即用-24-内容安排一般性步骤若干规则文档规约术语项目-25-项目1课程资源管理系统2课程讨论管理系统3在线答疑系统4课程作业管理系统5在线讲义管理系统6课程公告系统7课程计划（活动）管理系统-26-项目说明说明教师可以放置多种形式的教学资源，主要分为三大类：文档（如字处理文档、电子表格、演示文档和纯文本文档等）、网站链接和可直接显示在网页中的简单文本文件。资源库、作业和日程表都引入小组的概念。教师可为学生设置不同的访问权限，决定哪类用户可以具有浏览、发布、修改或删除特定文件夹中的文件。同时，也可以在发布资源时将共属性设置为“可公开访问”，这样，任何用户皆可浏览此资源。概念解释资源分类整理：可以根据资源的标题、大小、创建者和最后修改日期来分类。1课程资源管理系统-27-项目说明说明可为师生提供结构化的在线交流功能，讨论的内容可按照内容的类别分门排列。在讨论区中，师生可回复某个主题的文章（平面式讨论）。同时，管理者也可对讨论参与者对当前主题的发文权限进行定义。概念解释类别与主题：类目是讨论工具的最高层面，主题显示于类别之下，参与者对特定主题的回复将自动分组排列于其下。删除：只有站点管理者，教师和其它拥有特定权限的用户方可删除讨论区的内容。2课程讨论管理系统-28-项目说明说明教师与学生都可以利用聊天室工具来进行实时的文字对话与交流。教师可非常容易地创建一个“在线办公时间”来与学生进行各种交流，回答学生的提问或向学生提出各种教学问题等。同时，不同的学习小组或项目组也可利用聊天室来进行不受时间和空间限制的学习交流。概念解释多个聊天室：允许教师或管理者创建多个聊天室，每个聊天室可用于不同类型的交流。3在线答疑系统-29-项目说明说明教师可在线为指定的班级学生创建、发布、收集作业及评分。同进为教师提供多种成绩计分方式，包括字母等级计分、分数计分、等级计分、及格/不及格和不计分。所布置的作业可以计分或不计分的方式直接在线提交，在允许的情况下，学生也可重新提交一份作业。在批阅作业时，教师可将学生提交的全部作业一次下载至本地计算机。当教师发布作业成绩后，学生可在线看到教师的评语及作业成绩。概念解释诚实宣言：要求学生保证其所提交的作业为独立完成，而未借助于他人的帮助。4课程作业管理系统-30-项目说明说明让教师在线编辑自己的电子讲义并按照章节有序编排。编辑时还可方便地插入Word、Powerpoint等文件，也可插入视频、音频等多媒体文件，链接到外部web站点，导入、导出符合IMS标准的电子讲义。5在线讲义管理系统-31-项目说明6课程公告系统说明在系统中，通知工具可用于向特定课程的学习者发布学习活动安排信息。在发布通知时，教师可附加多种附件，如文档和URL链接。概念解释分类:通知可按照主题、发布者、可访问者或日期进行分类-32-项目说明7课程计划（活动）管理系统说明教师或站点管理者可利用系统来发布日历格式的通知。该日历具有天、星期、月、年和平列四种显示模式。在使用中，许多教师利用日程表来发布给全班同学的阅读材料研究组和院系项目组经常会利用日程表发布各种交流安排。概念解释活动列表：要想看到一个日程表中全部的活动列表，点击“查看”下拉框后选择其中的“全部活动的列表”。如何通过领域模型发现类猜数游戏输入一个数，如果猜中了显示“你猜中了啊”然后程序结束，如果猜的不对，系统则告诉你的数是太大还是太小，然后要求你重新输入新的数，直到猜中为止。开始归纳问题描述出用例的事件流用例事件流：-系统应该准备一个正确答案-玩家可以输入一个答案-系统应该比较玩家输入的答案和正确答案-系统应该显示玩家每次输入的结果开始归纳问题注意把握下面的几个基本要点第一是不要涉及内部的流程别出现“如果输入不正确，就怎么怎么样”的句子，这些并不是正确的问题，正确的问题必须是明确的，清晰的，如果可能的话全部按照“什么可以干什么”的格式来写。第二是不要一开始就进入细节包涵太多细节的问题将会是一个长长的清单，这种清单根本没什么用。尽量从最高一层分析，但也不要简单到“用户可以玩游戏”这种笼统的问题。总之一个原则是全面、清晰、明确要做好问题域分析完全取决于设计师的水平与能力，这就不是可以简单的看看书能达到的了。获得名词列表为发现出类提供信息把问题清单中的名词都提出来，得到一个名词列表，这就是类的来源（不过不忙，这只是初步过程）名词列表：-系统-玩家-正确答案-答案-游戏结果筛选名词除掉无关的名词但要注意的是，不是名词列表中的所有的名词都能作为类的，接下来需要进行筛选-玩家是参与者，应该放到用例图上去-系统太笼统，不能成为一个对象的名称-答案和正确答案容易混淆，但称为输入答案又容易被误解成一个动作，干脆叫做玩家答案-结果不明确，察看前面的需求，应该分解成错误信息和完成信息根据名词列表发现出其中的类对前面的名词列表进行筛选完毕后，得到一个下面的名词列表名词列表：-正确答案-玩家答案-错误信息-完成信息根据名词列表发现出其中的类在这个列表中缺少了系统，显得太单薄回过头再仔细察看需求，应该引入一个游戏引擎，由它来充当调度者（控制类）。同时，我们再引入一些Helper类以实现游戏的交互（边界类）发现的分析类：-游戏引擎-正确答案-玩家答案-错误信息-完成信息-游戏的交互根据名词列表发现出其中的类要注意的是在这个阶段中所发现出的类，并不是最终要实现的类，而是一个分析类利用分析类的主要目的是帮助设计师理清系统的关系，将需求文稿中错综复杂的关系整理成一个脉络清晰的完整系统根据规则，应该包含有三种分析类：边界类、实体类和控制类在本问题中，它们分别是：边界类：游戏的交互实体类：正确答案、玩家答案、错误信息和完成信息控制类：游戏引擎获得更清晰的需求描述游戏引擎应该准备一个正确答案玩家可以输入一个答案游戏引擎应该比较玩家答案和正确答案游戏引擎应该显示玩家每次输入的结果分析类的层次（纵向关联）错误信息和成功信息需要一个基类，玩家答案和正确答案也是一样分析类之间的关联（横向关联）在本问