《UML面向对象建模与设计》8~11章

虽然写这个博客主要目的是为了给我自己做一个思路记忆录,但是如果你恰好点了进来,那么先对你说一声欢迎。我并不是什么大触,只是一个菜菜的学生,如果您发现了什么错误或者您对于某些地方有更好的意见,非常欢迎您的斧正!

目录

第8章—高级交互建模

8.1用例关系

8.1.1包含关系

8.1.2扩展关系

8.1.3泛化

8.1.4用例关系的组合

8.2过程式顺序模型

8.2.1带有被动对象的顺序图

8.2.2带有临时对象的顺序图

8.3活动模型的特殊结构

8.3.1发送和接收信号

8.3.2泳道

8.3.3对象流

第9章——概念小结

第10章——过程概述

10.1开发阶段

10.2开发生命周期

10.2.1瀑布式开发

10.2.2迭代开发

第11章——系统构思

11.1形成系统概念

11.2阐释概念

11.3准备问题陈述


第8章—高级交互建模

√复杂的用例可以用包含扩展泛化关系在小型用例的基础之上构建起来。

√用例:外部可见的功能,对系统提供的服务进行描述。用椭圆表示。

8.1用例关系

8.1.1包含关系

√包含(iinclude)关系:将一个用例合并到另一个用例的行为序列中。被包含的用例就是√子程序——它表示那些原本必须要被重复描述的行为。

√用例建模的目的:确定系统的功能,以及参与者与系统之间通用的控制流。

√个人理解:两个用例都要用到的另一个用例。

 

√图:用例  安全会话 和 做交易  都包含用例  验证密码。

8.1.2扩展关系

√扩展(extend)关系:给用例添加增量行为。(个人理解:添加有条件的行为)

√扩展关系有一个附加条件:只有当控制到达插入位置时条件为真的情况下,才会发生扩展行为。

8.1.3泛化

√泛化(generalization):可以显示一个通用用例的特定变体。通过插入额外的步骤或细化步骤,子用例特化父用例。

√父用例可以是抽象的或具体的——抽象用例无法直接使用。

√类可以多重继承,但用例却不允许出现这种复杂性。

√个人理解:把某个基础的功能更加详细化。

8.1.4用例关系的组合

√用例关系的一个小复习:

关联:参与者用例之间的通信

泛化:继承

包含:把一个复杂的用例表示的功能分解成较小的步骤

扩展:功能的延伸,为基础用例添加一个有条件的附加功能

√包含关系意味着被包含行为是配置系统中一个必要部分,而扩展关系则暗示着没有增加行为的系统也会有意义。

8.2过程式顺序模型

8.2.1带有被动对象的顺序图

√在第7章中,所有对象都是并发活动的。在发送消息后,对象还保持在活动状态,并可以响应其他消息,而不用等待响应。

√使用过程式代码,所有的对象并不总是主动的。多数对象是被动的,没有自己的控制线程。被动对象在调用的时候才会被激活

√一旦操作执行完成,控制权就会返回给调用者,被动对象就会变成不活动的。

√UML用细长的矩形条表示对象执行的时间段。这个时间段被称为激活(activation)控制焦点(focus of control)

√对象存在的整个时间段被称为生命线(lifeline),因为它显示了对象生存的时间。

8.2.2带有临时对象的顺序图

8.3活动模型的特殊结构

8.3.1发送和接收信号

8.3.2泳道

√泳道(swimline):把活动图分为行和列,每一称为一个泳道。把一项活动放在某条泳道内表明它会由组织内的某个人或某些人执行。

8.3.3对象流

√在活动图的执行过程中,同一个对象经常会经历好几个状态。

√UML显示某个状态中的对象值的方法就是把  状态名  放在  跟在对象名的后面  的方括号中。

第9章——概念小结

第10章——过程概述

√软件开发过程(software development process):通过使用一系列预定义技术表示法,为有组织的软件生产提供了基础。

10.1开发阶段

√分析:包括两个子阶段:领域分析(domain analysis)应用分析(application analysis)。领域分析关注现实世界中传达应用语义的内容。应用分析描述应用为用户可见的计算机层面。

√系统设计:广泛利用各种阶级论做出策略决策。架构(architecture):用于解决应用问题的高层计划策略

10.2开发生命周期

10.2.1瀑布式开发

瀑布式开发严格要求以线性顺序执行软件开发的阶段,不需要回溯。

√适用于那些理解得非常透彻的应用,从分析和设计中能够得到期望输出。

10.2.2迭代开发

√首先,你开发出系统的基点——分析设计实现交付可工作代码。然后扩大系统范围,为已有的对象增加属性行为,以及增加新的对象。当系统演化成最终可交付产品时,会经历多次迭代

√每次迭代都包括一整套完整的阶段:分析设计实现测试

 

第11章——系统构思

系统构思(system conception):要处理的是某项应用的起源

11.1形成系统概念

√新的功能。给现有系统增加功能。

√改进。消除限制或泛化系统工作的方式。

√简化。让普通人执行以前分配给专家的任务。

√自动化。人工过程自动化。

√整合。组合来自于不同系统的功能。

√类比。寻找和其它问题领域的类似之处,检查它们是否具有实用的思想。

√全球化。到其它国家旅行,观察它们的文化和商业惯例。

 

11.2阐释概念

√应用程式是为谁做的?要清楚地了解哪些个人和组织是新系统的利益相关人。两类最重要的利益相关人是经济担保人和最终用户。经济担保人资助开发新系统,用户最终确定新系统的成功与否。

√它解决了哪些问题?确定新系统将具备哪些功能,而没有哪些功能。

√它会用在什么地方?

√何时会需要它?时间有两个很重要的侧面。①可行时间②必须时间。我们必须保证由技术可行性  驱动的期望时间 与 业务所需时间之间的一致性。

√为什么会需要它?清晰地理解新系统的动机

√它是如何工作的?

 

11.3准备问题陈述

√整个开发过程中,应该区分需求、设计和实现。

√需求:从用户的观点来描述系统的行为。

√设计决策:是工程选择,提供由需求确定的行为。

√实现:要处理的是用程序代码最终将构想变为现实的过程。

√在投入时间和金钱进行开发之前,需要先评估系统的可行性、开发系统的困难和风险系统的需求以及成本效益比

猜你喜欢

转载自blog.csdn.net/weixin_40851250/article/details/84953015