UML摘要

Use Case[@more@]

Reference to Learning UML Figure4-9

Use an extend dependency when a use case is optional to another use case. Because the Maintain Project, Maintain Activity, and Maintain Task use cases extend the Manage Project use case, the Manage Project use case must be developed before the others; otherwise, the other use cases won't have a use case to extend. Likewise, the Administer System use case must be developed before the Startup System and Shutdown System use cases, Startup System must be developed before Restore Data, and Shutdown System must be developed before Backup Data. However, once Administer System is developed, Startup System and Shutdown System may be developed in parallel or concurrently, because they are not directly related.

=================

It is important to understand the difference between include and extend dependencies and use-case generalization. An inclusion use case does not have knowledge of the base use case that includes it, an extension use case does not have knowledge of the base use case that it extends, and the Maintain Activity use case in Figure 4-8 has no knowledge of the use cases that it extends, so they can't involve the actors of the base use case in their behavior sequences. For example, the Log Activity use case in Figure 4-6 has no knowledge of the use cases that include it. However, a more specific use case receives or inherits the actors, behavior sequences, and extension points of its more general use case, so it can involve the actors of the more general use case in its behavior sequence. For example, the Generate Report use case in Figure 4-13 has knowledge of the Publish Status use case and may involve the Project Manager actor in its behavior sequence. An inclusion use case must be developed before its base use cases, an extension use case must be developed after its base use cases, and a more specific use case must be developed after its more general use cases.

===================================

You usually apply use-case modeling during requirements activities to capture requirements that define what a system should do. Use-case modeling typically starts early in a project and continues throughout a system development process. It is usually done as a series of workshops between users and analysts of a system in which ideas can be explored and requirements may be fleshed out over time.

Component modeling typically starts after the design of the system is fairly complete, as determined by your system development process.

You typically apply deployment modeling during design activities to determine how deployment activities will make the system available to its users; that is, to determine the elements of the system on which deployment activities will focus.Like component modeling, deployment modeling usually starts after the design of the system is fairly complete, as determined by your system development process.

You usually apply interaction and collaboration modeling during analysis and design activities to understand the requirements and determine how a system will satisfy its requirements. Interaction and collaboration modeling usually start after requirements have matured enough, as determined by your system development process, and continue in parallel with class and object modeling (Chapter 3) throughout a system development process.

Class and object modeling usually start after the requirements have matured enough (as determined by your system development process) and continue in parallel with interaction and collaboration modeling (Chapter 6) throughout the system development process, while focusing on the elements that make up the system and their relationships.

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7845854/viewspace-924430/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/7845854/viewspace-924430/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1.系统需求 2 2.需求分析 4 2.1功能设置 4 2.2模块划分 5 2.3识别参与者和用例 6 2.3.1 顾客Customer用例图 7 2.3.2 系统管理员用例 13 2.3 静态结构模型 16 2.3.1 类Customer 17 2.3.2类Goods 18 2.3.3类Order 19 2.3.4管理员 20 2.3.5标题title类 20 2.3.6二级标题类 21 2.3.7公共操作类 22 2.3.8类图 23 3.动态行为模式 23 3.1时序图 23 3.1.1顾客注册成为会员时序图 24 3.1.2顾客反馈信息时序图 25 3.1.3顾客浏览商品时序图 26 3.1.4顾客查询商品时序图 27 3.1.5顾客购买商品时序图 28 3.2.6管理员添加商品时序图 29 3.2.7管理员删除商品时序图 29 3.2.8管理员添加二级商品目录时序图 30 3.2.9管理员删除二级商品目录时序图 31 3.2.10管理员编辑促销产品时序图 31 3.2.11管理员编辑条款信息时序图 32 3.2.12管理员编辑购买流程时序图 33 3.2.13管理员删除会员时序图 34 3.2.14用户结算时序图 35 3.3.活动图 35 3.3.1用户顾客的活动图 35 3.3.2管理端管理员的活动图 36 3.4协作图 38 3.4.1顾客登录协作图 38 3.4.2顾客注册协作图 38 3.4.3顾客浏览商品协作图 39 3.4.4反馈信息协作图 39 3.4.5顾客查询商品协作图 40 3.4.6顾客购买商品协作图 40 3.4.7管理员删除会员协作图 41 3.4.8管理员添加商品协作图 41 3.4.9管理员添加商品标题协作图 42 3.4.10管理员删除商品协作图 42 3.4.11管理员删除标题协作图 43 3.4.12管理员编辑文本协作图 43 4.系统数据库设计 44 4.1数据库的需求分析 44 4.2数据库的逻辑设计 44 5.参考文献: 47
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值