专题课程
【课程背景】
好像总是没有足够的时间来完成建模、分析和设计工作,总是过早地进入到编码阶段。没有分析设计工作给编码质量带来巨大的隐患。要提高代码的质量,必须遵循软件工程的基本规律。
ICONIX是面向对象的精简的开发过程的方法论。研究的是如何使用较少的投入完成从需求到编码的过渡。
本课程综合并精简了面向对象的分析设计过程,形成了从需求到编码较小的工程活动集合,即能保证编码的质量,又能保证开发效率,确保开发过程中的每个活动都具备不可或缺的价值,而不是在做无用功。
本课程讲解了如何把用例分析、领域模型、健壮性分析、动态模型、静态模型等面向对象的分析设计活动合理的组织起来,并对每个工程活动如何执行、何时执行、执行的程度与结果都给出了明确的要求。
【培训特色】
1.案例贯穿始终。使用实际的项目,把需求建模、分析、设计完整做一遍,通过案例讲解每个步骤的做法。
2.经验分享。在每个工程活动中,总结常犯的错误及其解决方案。
3.现学现用。在随堂练习中巩固课程的效果。
【目标收益】
通过ICONIX过程把建模、分析、设计技术贯穿起来,把需求顺滑的过渡到设计,再有设计过渡到编码,每次过渡都是无缝链接,确保开发过程的质量。
Ø 如何建立系统模型?
Ø 如何把面向对象的模型与MVC建立关系?
Ø 如何分配类的职责?
Ø 如何建立静态模型?
Ø 哪些动态模型是有价值的?
【培训对象】
需求分析师、软件设计师、软件工程师、项目经理等
【课程大纲】
主题 |
内容 |
第一部分 ICONIX过程概述 |
讨论:代码为啥改来改去? 如何使用最少的投入完成从需求到编码的过度 较小UML建模技术—ICONIX思想 构造系统时的重要问题 谁是系统的用户(参与者),他们想完成何种工作? 何为“现实世界”(问题域)对象,它们之间存在何种联系? 每个用例需要何种对象? 在每次用例交互,对象是如何协作的? 如何处理实时控制问题? 在具体细节上,实际上准备如何建立该系统? ICONIX OOA&OOD框架 ICONIX过程—4个阶段 |
第二部分 面向对象分析 |
绘制高层类图 领域建模 领域的概念 领域建模的目的 领域建模的产出 域类的较佳来源 领域建模的活动: 识别类 建立归纳关系 建立类间关联 开发关联类 绘制高层类图 领域建模训练 领域建模综述 领域建模10个典型的错误 • 10.立刻给关联指定多重度(multiplicity),确保每个关联都有明确的多重度 • 9.对名词和动词做过度的分析,而背离初衷 • 8.不对用例和时序图进行研究,就将操作分配给类 • 7.在确保已满足用户需求之前,对代码进行优化以提高重用性 • 6.对于每个“部分(part-of)”关联,就使用聚集还是组合(composition)而争论不休 • 5.未对问题空间进行建模之前,就假定一种具体的实现策略 • 4.将类命名为难以理解的名称,而不是直观的名称 • 3.直接进行实现结构,如友元关系和参数化类 • 2.在域类和关系型数据库表之间建立1对1的映射 • 1.对早的执行“模式化”,将导致根据同用户问题毫无关系的模式创建解决方案 用例建模 用例的基本概念 用例建模的目的 用例建模的产出 分析层用例 设计层用例 用例之间的关系 归纳关系 包含关系 扩展关系 用例图 用例描述 练习:用例建模 原型 原型概述 原型法工作流程 原型法的优缺点 关于原型系统的基本原则 • 区分两种原型系统: 抛弃型原型 演化型原型 • 原型化难以理解的需求 • 尽快将抛弃型原型交付给客户,不必考虑质量 • 必须注意精选正要开发的原型系统所包含的特性,使其能真正达到预期的目的 • 决不把抛弃型原型系统发展成为系统 • 利用原型减少软件开发的风险 与原型有关的度量数据 需求评审 需求评审10条典型的错误
|
第三部分 面向对象初步设计 |
面向对象初步设计概述 建立需求与设计之间的桥梁 健壮性分析 健壮性分析的目的 健壮性分析的产出 健壮性分析的流程 • 1,检查用例的正常性 • 2,检查用例的完整性 • 3,对象确认 • 4,初步设计:对象分类 • 5,执行健壮性分析 • 6,更新域(静态)模型 对象分类 • 边界对象 • 实体对象 • 控制对象 健壮性图的规则 • 动作者只能与边界对象交谈 • 边界对象只能与控制体和动作者交谈 • 实体对象只能与控制体进行交谈 • 控制体即能跟控制对象交谈,也能跟边界对象交谈,不能跟动作者交谈 案例:健壮性分析 练习:健壮性分析 健壮性分析与静态模型的反馈循环 初步设计评审
|
第四部分 面向对象详细设计 |
面向对象详细设计概述 面向对象详细设计 详细设计的目的 详细设计的产出 详细设计的流程 动态模型 时序图 状态图 活动图 协作图 动态模型注意点 • 过度使用这些图会导致分析崩溃 • 不要为具有两种状态的对象绘制状态图 • 协作图在实时、分布式系统中是实用的 • 要避免分析崩溃就要知道需要建立那些模型 • 不要为建模而建模 10个绘制时序图的要点 • 10.需要为每个用例绘制一张顺序图。 • 9.顺序图应该匹配于相关用例的叙述流。 • 8. 为每一个完整的用例绘制一张唯一的时序图,只有管理唯一的顺序图非常困难的时候,才把图分开。 • 7.对象间的消息调用类上的操作。 • 6.如果在开始绘制顺序图时陷入困境,很可能是因为没有正确编写用例或没有完成健壮性分析。 • 5.通过研究系统的动态行为,了解包含在静态模型中的类需要哪些属性与操作 • 4.牢记顺序图时制定行为分配的工具。 • 3.当在详细层上研究系统用法时,其实是在给问题域对象添加解决方案空间对象。 • 2.把基础结构、框架和帮助者对象纳入设计,设计模式通常是有帮助的,这是OOD真正发生的地方 • 1.在顺序图空白处写下最初的需求层文本,这提供了可视化需求跟踪 关键设计评审 |
第五部分 面向对象分析设计总结 |
10种导致用例分析崩溃的做法 • 10.在静态模型中的每个关联末尾放置基数指示器。 • 9.为每个功能需求编写一个用例。 • 8.为每张顺序图绘制一张协作图。 • 7.每张协作图上包含整个脚本,不侧重关键事务。 • 6.为静态模型中的每个类绘制状态图。 • 5.在协作图上花费几小时处理消息信号。 • 4.为整个系统绘制一张巨大的多层级的状态图。 • 3.通过顺序图直接从需求层用例跳到详细设计。 • 2.在需求模型结束之前,做了大量的详细设计工作,在需求结束后,重复几次设计。 • 1.创建了数以百计的状态图,每张状态图包含两种状态。 |
- 上一篇:COSMIC估算分析师认证培训
- 下一篇:代码评审技术