第5章需求与验证剖析.ppt

构建分析模型的理由 分析模型比用例模型更加结构化、更加清晰直观 所以分析模型的构建过程实际上也是不断深入理解用例模型的过程，同时也是剔除用例的自然语言描述中可能存在的模糊性和不一致性的过程 分析模型是用例模型与软件设计模型之间的“桥梁” 它比用例模型更接近于设计模型，更适合于软件设计师设计软件系统的结构、构思软件求解算法，更易于为不太熟悉业务的软件设计师所理解，换言之，理解分析模型对业务知识的要求远低于理解用例模型 几点说明 需求分析立足于需求、立足于用户 仅从用户的角度、以用户易理解的方式描述需求 要注意减轻用户理解的负责，建议流程 业务/功能、机构人员分解（业务术语） 业务流程描述（业务术语） 业务分析（用例） 业务对象（数据）描述（数据字典） 仅从概念的层面描述 类间关系用线条表示，而不用字段表示 业务流程（动态分析）（数据流图） 基于图4-7 所示的家庭保安系统初步的领域概念模型，考虑到“开关机及复位处理”、“系统配置”和“传感器监测”用例均需记录日志，“日志查询”用例需要使用该日志，所以引入“日志”概念类，其主要属性包括时间、动作描述、动作执行者。 由于报警时必须描述异常事件的发生位置并且在日志中记录发现异常的传感器编号，所以“传感器”概念类具有“编号”和“安装位置”两项属性。 扩充机制适合于以下应用场景： ⑴建模者希望向模型的读者或实现者传递UML标准语义无法表达的