尚学堂马士兵UL部分视频学习笔记.doc

第一部分： 1、总纲： 2、走向UML 3、uml概览【大略看一下】 4、User Case 最重要了 5、静态系统建模 6、动态系统建模 7、系统架构【component deploy】。。。。。。。。到此基本完成 8、正确认识UML 9、UML高级话题 10、UML常见问题 11、UML常见工具比较 12、up 13、UML与UP相铺相成 14、UP常见问题 15、分析模式 16、设计模式 17、架构模式 18、综合练习与示例 19、浅谈：MDA【软件工程新宠】 20、复习 第二部分： 走向UML 听听历史：【当小说听就行了】 。。。。。。 软件：将显示业务逻辑解析到计算机。。。努力将自然语言解析到计算机语言之间的鸿沟最小 没方法 数据流法 信息建模图[E--R图] 以上上面主要用于面向过程 后来出现了面向对象了 OO建模可以很大程度上帮助我们设计稳定\复用性高软件 为什么要建模呢? 规模很大的系统告诉你从哪下手就像将房子一样 可视化建模：UML最大作用提供一套标准的沟通语言 UML帮我们： 定义出软件的架构 抽象出可复用的组件 。。。。。。 UML的历史 OOAD面向对象的分析设计语言 BOOTH OOSE OMT 1997年UML一统天下 第三部分：UML的概览 鸟瞰UML UML各种图形的名称与作用 UML如何用于开发过程简略介绍 用于描述系统结构： 用例图：需求捕获，测试依据 类图：静态系统架构 对象图：对象之间的关联 构件图：构件之间的关联 部署图：构件的物理部署 用于描述系统行为： 顺序图：不活User Case 在某个时间场景上时间执行顺序 协作图：强调对象之间的写作 顺序图与协作图之间可以互相转换，而其中的信息不会丢失 状态图：描述关键类生命周期的转化 活动图：流程图，描述某个方法或User Case的执行过程。 通常合在一块使用 1、识别Actor【跟系统打交道的最直接的人或者模块】 课管员、学生、教授、独立的学校计费系统 识别User Case【Actor对我们系统所做的操作】 课管员：建立和发布课程表 学生“维护自己的课程表 教授：取得人员名单 财务系统：取得计费信息【不用画出用例图，因为对立计费系统不会操作选课系统，而是把选课情况发个计费系统】 在UML中没有对不对，只有合不合适，在team中都赞同的话，就算是合适 粒度的粗细根据不同情况而不同 说明每个User Case的文档 。。。。。。。。 User Case的本质在于描述文档，而不是图。 使用Activity 图分析特定的User Case： 根据 User Case和Document抽象出静态类图。Logical View中 根据Document中的名词抽象出类 根据类和User Case的路径制作Sequence 图【代表完成一个User Case路径的时候，Actor和系统内部相互作用的时间顺序】 引入两个概念：1、界面类2、控制类 构成 MVC 箭头指向某个类本身，说明这个类附有这个责任比如3课程类负责告诉别人我这个课程有没有开放。。 7、从sequence图就可以抽象出业务方法。 8、在sequence图中按F5就可以自动转换为协作图： 【协作图】 两个说的都是相同的东西，但是强调重点不同sequence图强调的是时间上的顺序 协作图强调的是类与类、对象与对象之间的协作关系。 9、使用state chart说明关键类的状态图【不是所有的类都有的】 10、使用component图说明程序的逻辑组织 11、使用deploy说明系统的部署 【10、11暂时不演示】 UML是怎样和开发过程结合到一块的： 瀑布式开发过程 必须要求需求稳定住 后面才能进行【从建筑业拿过来的】 不成功：不承认需求的不断变化 UP模型 承认了变化，接受了变化 成功。 UP分为四个阶段，初始，精化，构建【编码】，交付【使用部署图】 UML在不同的阶段的不同用途。 。。。。。。 总结：【牢记！！！】 1完成User Case以及document。 2对于比较复杂的User Case 使用Activity辅助说明【或者sequence】。 3根据User Case Document和Activity 分析业务领域的概念，抽象出概念模型 4根据概念模型抽象出类。 5分析类的职责与关系做出类图【通常先不做方法，制作属性然后做6，然后根据刘抽象出方法。】。 6根据类图制作出sequence【顺序图】、Collaboration【协作图】、State Chart【状态图】等各种图示。 7根据图示重复迭代5-6，直至“完美“，没有完美，够用就行了。 8Coding【编码】 9测试并修改,必要从前面开始改起，或从1，或从5【内部测试】 10部署并与用户一起测试 11从实施与