演示文稿分析类状态图基础和画法.ppt

演示文稿分析类状态图基础和画法
第一页，共二十八页。
（优选）分析类状态图基础和画法
第二页，共二十八页。
分析类
分析类的概念
–在分析模型中，分析类是概念层次上的内容，用于描述系
统中较高层次的对系统的内部行为，即系
统内部必须做什么才能响应外部的要求。
–可能的情况
•用例描述的内容足够充分，不用补充直接可用；
•现有事件流中没有明确定义系统内部应该执行的行为，直接在现有用
例描述中作出补充行为；
•独立于原始用例描述系统的内部行为。
注意：没有必要规定系统的哪些部分完成哪些特定任务。
第十一页，共二十八页。
MiniLibrary：补充用例描述
举例：“登记还书”用例
第十二页，共二十八页。
识别分析类
识别边界类
–通常，一个参与者与一个用例之间的交互或通信关联对应
一个边界类。
第十三页，共二十八页。
识别分析类
识别边界类应当注意的问题
–边界类应关注于参与者与用例之间交互的信息或者响应的
事件，不要描述窗口组件等界面的组成元素；
–在分析阶段，力求使用用户的术语描述界面；
–边界类实例的生命周期并不仅限于用例的事件流，如果两
个用例同时与一个参与者交互，那么它们有可能会共用一个边界类，以便增加边界类的复用性。
第十四页，共二十八页。
MiniLibrary：识别边界类
第十五页，共二十八页。
识别分析类
识别控制类
–控制类负责协调边界类和实体类，通常在现实世界中没有
对应的事物。
–一般来说，一个用例对应一个控制类。
第十六页，共二十八页。
识别分析类
识别控制类应当注意的问题
–当用例比较复杂时，特别是产生分支事件流的情况下，一
个用例可以有多个控制类。
–在有些情况下，用例事件流的逻辑结构十分简单，这时没
有必要使用控制类，边界类可以实现用例的行为。
•举例：MiniLibrary系统中的用例“登录”
–如果不同用例包含的任务之间存在着比较密切的联系，则
这些用例可以使用一个控制类，其目的是复用相似部分以便
降低复杂性。
•通常情况下，应该按照一个用例对应一个控制类的方法识别出多个控
制类，再分析这些控制类找出它们之间的共同之处。
第十七页，共二十八页。
MiniLibrary：识别控制类
第十八页，共二十八页。
识别分析类
识别实体类
–实体类通常是用例中的参与对象，对应着现实世界中的“事物”
第十九页，共二十八页。
识别分析类
识别实体类应当注意的问题
–实体类的识别质量在很大程度上取决于分析人员书写文档
的风格和质量；
–自然语言是不精确的，因此在分析自然语言描述时应该规
范化描述文档中的一些措辞，尽量弥补这种不足；
–在自然语言描述中，名词可以对应类、属性或同义词等多
种类型，开发人员需要花费大量的时间进行筛选。
思考：如何识别MiniLibrary的实体类？
第二十页，共二十八页。
MiniLibrary：识别实体类
第二十一页，共二十八页。
定义交互行为
交互图可以将用例和分析对象联系在一起，实现将用例的行为分配到所识别的分析类中，并且帮助开发人员发现和补充前面遗漏的分析类。
第二十二页，共二十八页。
MiniLibrary：“登记借书”基本流
第二十三页，共二十八页。
MiniLibrary：“登记借书”基本流
第二十四页，共二十八页。
MiniLibrary：分析类
将“登记还书”用例行为分配到相应的分析类之后，系统的一些分析类具有相应的职责
第二十五页，共二十八页。
建立分析类图
定义关系
–找出分析类之间的关联关系，并通过泛化实现复用。
定义属性
–按照一般常识，找出对象的某些属性；
–认真研究问题域，找出对象的某些属性；
–根据系统责任的要求，找出对象的某些属性；
–考虑对象需要系统保存的信息，找出对象的相应属性；
–对象为了在服务中实现其功能，需要增设一些属性；
–识别对象需要区别的状态，考虑是否需要增加一个属性来
区别这些状态；
–确定属性表示整体与部分结构和实例连接。
第二十六页，共二十八页。
MiniLibrary：分析类图
第二十七页，共二十八页。
检查分析模型
检查“正确性”
–用户是否可以理解实体对象的术语表？
–抽象类与用户层次上的概念对应吗？
–所有的描述都与用户定义