第6章(1) PIM建模技.ppt

1、软件工程,宁夏医科大学 理学院 杨德仁 2016/11/11,第6章(1) PIM建模 系统用例图的进化：通过用例规约,Warm up: use case realization,There is MORE THAN ONE way to carry out a use case. In UML-speak, we say that a use case can have MANY realizatons. This happens when you are doing modeling task. Choose one realization use-case realization旨在分离

2、需求和实现。,Warm up: Analysis,Asystematicexaminationandevaluationofdataorinformation, by breaking it into itscomponents/partsto uncover theirinterrelationships. Opposite ofsynthesis. OOA是developing requirements and specification that expressed as a systems object model，including information model/object

3、model, and behavior model/state model. An examination of data andfactsto uncover and understand cause-effectrelationships, thusprovidingbasis forproblem solvinganddecision making.,大纲,传统方法的鸿沟及eMDA解决方案 书写用例规约的目的:2种桥接 用例规约建模理论 关键要素及其识别 编写有效用例规约的模式 10个用例规约建模指南； 书写执行步骤的准则 如何书写良好的用例规约？ 12 Tips for Writing

4、 Use Case Specification 书写用例规约的陷阱和常见的错误 用例规约建模实例(从ATM取款) 优化业务对象：增加属性 评估用例规约 目的与关键要素,指南,需求审核常犯的10个错误,传统方法的鸿沟及eMDA解决方案,鸿沟：从用例图到软件对象有鸿沟，难以逾越 传统OO方法（见第2章-2） 责任驱动的软件方法Responsibility-driven designing(RRD)： ： 责任是方法的抽象， 对象从哪里来？Class Responsibility Collaborator (CRC) ：类，责任，协作；没有涉及到GUI、控制对象（serverlet等）等 URDAD

5、 责任从哪里来？找出责任的宿主？迭代！ ICONIX过程模型 从用例图到鲁棒图也有鸿沟！正如从业务用例图到活动图 eMDA解决方案： 通过用例规约桥接，进而用鲁棒图图示化表示,书写用例规约的目的:桥接涉众,SRS: software requirements specification,桥接涉众：客户，业务人员，设计人员,书写用例规约的目的:桥接模型,模型 过渡性：具有探索性质，所谓软件分析 从外部向内部过渡 既非纯用户角度 也非纯设计角度 矛盾性：解析用例图，要首先文字化！ 解决方案？合理的机制 桥接模型，驱动（drive）着设计 从用例图到鲁棒图：用例规约 向OO设计过渡：从鲁棒图到类图和

6、序列图,Use Case Specification,AUse Case Specificationis a textual description of the functionality provided by the system. It may be phrased in the form of a dialog between the actor and the system or other forms. It captures actor-system interaction. That is, it specifies how a user interacts with a s

7、ystem and how the system responds to the user actions.,AUse Case Specificationis a textual description of the functionality provided by the system. It may be phrased in the form of a dialog between the actor and the system or other forms. It captures actor-system interaction. That is, it specifies h

8、ow a user interacts with a system and how the system responds to the user actions.,Use Case Specification,A Use Case Specification describes how a use case, which is logically defined by the use case diagram, is logically realized within an analysis model in terms of routes and events flows The purp

9、ose of Use Case Specification is to separate the concerns of the system stakeholders, which are typically captured by the use case model and system requirements, from the concerns of the system designers. In doing so, the designers can choose to realize the use case diagram without affecting the use

10、 case diagram.,用例规约建模理论,关键要素及其识别 GUI 路径： N* What happens? What else can happen？ Such as 错误处理？ 探索用例规约的各种路径，遍历系统的响应机制 书写和精化路径： “主-谓-宾”主动语态Sb. Does Sth 业务规则（在业务活动过程中） 用于为业务对象增加属性属性！ 参照GUI中的输入和输出框，为对象加属性！ 语境的转化： 基于业务对象，从用户语境到对象语境 利用优化的业务对象 识别主要的窗体对象（输入和输出），即所谓界面对象 识别（潜在的）控制对象（协作性，消息！）,用例规约建模理论Top 8 Use

11、Case Modeling Guidelines指南,Items 1-4 relate to describing system usage（系统使用）, 1. Organize your use cases with actors and use case diagrams. 2. Remember that your use case is really a runtime behavior specification. 3. Write your UCS in active voice. 3.1. Follow the two-paragraph rule（主流与备流）. 3.2. Wr

12、ite your UCS using an event/response flow, describing both sides of the user/system dialogue. 4. Use GUI prototypes and screen mock-ups. driving the design from the use cases,用例规约建模理论Top 8 Use Case Modeling Guidelines指南,Items 5-8 relate to putting the usage description into the context of the object

13、 model（语境转化）. 5. Write the UCS in the context of the object model. You cant drive object-oriented designs from UCS unless you tie your UCS to objects. 6. Write your UCS using a noun-verb-noun sentence structure. The nouns are the object instances. The verbs are the messages between objects. 7. Refer

14、ence domain classes by name. 8. Reference boundary classes (e.g., screens) by name. “The system displays the Checkout page showing the users default billing and shipping addresses.”,用例规约建模理论书写执行步骤（场景法）的准则,（1）步步为营，过程向前推移 ； （2）明确地写出“谁控制球”即主动者的作用； 从俯视的角度来编写用例；用户、系统乃至其对象 （3）使用简单语法：主语+谓语动词+直接宾语 （4）包含“合理”

15、的动作集； 如“确认”，而不是“检查是否” （5）可选择地提及时间限制； （6）习惯用语及其改进： “用户让系统A与系统B交互”；要分开来写，用户与系统A怎么样，然后系统A和系统B怎么样。 “循环执行步骤X到Y，直到条件满足”；,编写有效用例规约,UCS：多个不同场景的集合 场景：事件或动作序列 行为：执行者actor发起的请求 必须掌握的三个概念： 范围：真正被讨论的系统是什么？ 主执行者：谁要实现有价值的目标？ 层次：目标的层次性，高还是低？,编写有效用例规约,有效用例模式，清华大学出版社 用例规约的读者和编写者 几组人在阅读和使用用例： 最终用户 业务专家 程序员 用例编写组必须包括：

16、具有编程背景的人，以获得描述所要求的准确性和精度； 熟知业务规则的人； 熟知在实际中如何使用系统的人；,编写有效用例规约,团队（Team） SmallWritingTeam 3人组成的团队，容易交流和达成一致；可以使用几个SmallWritingTeam，应当指定一位用例设计师，以保证所有用例与愿景一致。 ParticipatingAudience 没有涉众提供的信息和反馈，就不能满足其需要； 尽可能使客户和内部涉众积极参与用例开发。 BalancedTeam 为小组配备具有不同专长的人员，维护涉众利益，确保团队中有开发人员和最终用户。,编写有效用例规约,用例规约书写过程 BreadthBef

17、oreDepth 先广后深，逐步增加细节，完成概述后，不断细化。 SpiralDevelopment（螺旋式开发） 理解系统行为很费时，要求渐进式分析；采用迭代的、宽度优先的方式，每次迭代都提高用例规约的准确性和精度。 基本过程： 从简单开始，如参与者/用例列表； 简要描述场景，即高层用例规约，以包含用例的主要范围； 扩展摘要的子集，并填充细节；评审并调整 TowTireReview（评审） 进行两轮评审： 小组内部的小范围评审，要重复多次； 由整个团队评审，只进行一次。 QuittingTime（终结） 用例规约完整并符合actor需要后，停止开发； 用例规约完整性的检验： 完整、可读、逻辑

18、上正确 对开发人员足够详细。,编写有效用例规约,用例规约集 SharedClearVision（共识的愿景） 缺乏清晰的系统愿景可能会导致优柔寡断，涉众之间不能达成共识，导致项目瘫痪。 愿景陈述应该包括：系统目标；系统将解决的问题；系统不会解决的问题；涉众是谁； VisibleBoundary（明确的边界） 列举与系统交互的人员与设备， 明确化系统与其环境的可见边界； ClearCastOfCharacters（清晰的角色） 识别和清晰描述出与系统交互的actor(角色)。,编写有效用例规约,用例规约集 UserValuedTransactions （有价值的事务） 识别系统为actor提供以

19、满足其业务目的的有价值的服务（完整事务）； 避免基于表单/界面的用例集； EverUnfoldingStory （折叠式故事） 将用例规约组织为分层形式，可将其展开获得更多细节，可将其折叠起来隐藏细节，显示其上下文； 三个级别的用例规约： 概要级：需要用多个用户目标会话来完成； 用户目标级：满足了主参与者的特定价值目标； 子功能级：满足用户目标级用例或另一子功能部分目标；,编写有效用例规约,用例规约 CompelteSingleGoal（完整的单一目标） 每个用例规约用来描述一个完整且定义良好的目标： 与一个定义良好的参与者相关； 对参与者或参与者代表的涉众是有价值的； 与在这一级别上为系统确

20、定的其他目标一致 避免与具体接口细节联系，而成不完整目标的用例规约 VerbPhraseName （动词短语命名） 用代表主actor目标的主动动词短语命名用例规约。 ScenarioPlusFragments（场景加片段） 将成功的故事情节编写为简单场景，放上展示会发生什么情况的故事片断。,编写有效用例规约,用例规约 ExhaustiveAlternatives（完备的可选路径） 必须捕获在用例中处理的所有分支和失败情况。 Adornments（额外区域） 在用例规约模板的场景文本之外创建额外区域，来填写对用例有用的补充信息；用例和其他补充需求紧紧相扣，如性能需求、用户界面说明、约束条件、业

21、务规则、数据字典等。 PreciseAndReadable（精确而可读） 用例要足够可读，以便使涉众阅读和评估； 用例要足够精确，以便开发人员可以理解待建系统。,编写有效用例规约,场景和步骤 Detectable Conditions：只包含可检测的条件 Levels Steps 步骤数目适中，39步，仅在目标之下的抽象级别 Actor Intent Accomplished Actor的意图要完成 Forward Progress （向前进！） 消除或合并对actor没有推进作用的步骤 简化那些会分散读者对目标实现的注意力的内容 防止分析瘫痪（ analysis paralysis） Tec

22、hnology neutral（技术中立） 以技术中性的语言编写用例规约,用例规约建模理论如何书写良好的用例规约？,Warm up 把握系统的actors, 有哪些actors？ actor 独立于系统，要使用系统提供的那些功能？ Use Case要明确开始和结束，要有明确的范围 视角：探索系统的实现机制（从系统内部）， 尽量少用GUI，除非该GUI与功能有关。 Use Case本身高聚合，Use Case之间应该低耦合， Use Case功能单一，粒度小 不关注其它Use Case，不牵扯其他Use Case做的事情。 如何描述Use Case的步骤？ 要把握好“度”，基于“明确性”。,用例

23、规约建模理论 Tips for Writing Use Case Specification,Tip 12. Do you need User Stories?（用例的基础！先于用例） *Tip 2. Define your use case actors *Tip 11. Generate a Use Case Model Diagram Tip 1. When creating use cases, be productive without perfection Tip 6. Identify the key components of your use case Tip 7. Name

24、 and briefly describe your use case Specification Tip 3. Define your Sunny Day Use Cases (Primary Use Cases) Tip 8. Create the use case basic flow Tip 9. Create the use case alternate flows Tip 10. Produce your use case document *Tip 5. Create a use case index *Tip 4. Identify reuse opportunity for

25、use cases,用例规约建模理论 Tips for Writing Use Case Specification,Tip 12. Whats the difference between a User Story and a Use Case? What is a User Story? Simply put, written from the context of the user as a simple statement about their feature need. They should generally have this format. As a -role-, I w

26、ant -goal/desire- so that -benefit- How is a User Story different than a Use Case? While a use case is highly structured and tells a story, the User Story sets the stage by stating the need. A User Story is the prelude to the use case by stating the need before the use case tells the story. How does

27、 the User Story fit into the process? User Stories are great as an activity in collecting and prioritizing the high level features. Getting this initial feedback from the customer is a simple way of trying to get all of their needs identified and prioritized. The User Stories will then morph themsel

28、ves into the business requirements and use cases.,用例规约建模理论 Tips for Writing Use Case Specification,Tip 1. To write use cases, be productive without perfection（先广后深：先范围再细节） When it comes to writing effective use cases, you dont need to be a perfectionist and concern yourself with getting it right the

29、 first time. 别完美主义，过早陷入细节而疏忽了全局 Developing use cases should be looked at as an iterative process where you work and refine. 迭代过程 You can always refine it later, so again, dont go for perfection from the get-go (begin). Loosen up and have some fun while youre doing it. 一蹴而成不可能,用例规约建模理论 Tips for Writi

30、ng Use Case Specification,Tip 2. Define your use case actors There are possibly over a dozen actors that interact with Ebay, from buyers and sellers, down to suppliers, wholesalers, auditors(稽核员), and customer service. But were going for grass-roots, so who are the basic users of Ebay? BUYER and SEL

31、LER. Do you notice how the actors arent John and Sue which would be people? While John may be a seller and Sue may be a buyer, An actor is a Role. And a role in this case would be that of a buyer and that of a seller in the case.,用例规约建模理论 Tips for Writing Use Case Specification,Tip 11. Generate a Us

32、e Case Model Diagram You can use the G use case modeling tool to produce a use case model within a few clicks. Once you define your use cases and actors, just go into the reporting section and click on the Use Case Model report and thats it. From the main use case model, you can continue to drill do

33、wn into the use cases.To see what this looks like, click the use case model sample now. In several places in this document, I have stated effective use cases rather than just use cases. The purpose of the use cases is for effective knowledge transfer from the domain expert to the software developer

34、- these use cases will serve as software requirements. If they dont make sense to the person building the software, they are not effective. There are several sources on the web for writing effective use cases including the book by Alistair Cockburn.,用例规约建模理论 Tips for Writing Use Case Specification,T

35、ip 3. Define your Sunny Day Use Cases Use the 80/20 rule （黄金分割规则）- if you write an exhaustive list of all possible use cases, typically 20% of the use cases will account for 80% of the activity. The other 80% of the use cases would support 20% of the activity. Sunny Day use cases is in reference to

36、the use cases that are most likely going to occur when all goes well. You always want to focus on the sunny day scenarios first because you can then pivot off(支点关闭) these and figure out your rainy day scenarios (or edge cases) later. Now Collect your Rainy Day Use Cases After you have a well-defined

37、 list of your primary use cases, youll want to collect the list of edge cases (rainy-day) and prioritize them in terms of likeness.,用例规约建模理论 Tips for Writing Use Case Specification,Tip 8. Create the use case basic flow An effective use cases needs to have the basic flow before moving forward with wr

38、iting the alternate flows. The basic flow of a use case represents the most important course of events or what happens most of the time, sometimes referred to as the Happy Day Scenario because it is what occurs when everything goes well - no errors or exceptions. Another reason why the basic flow is

39、 so critical is because its much easier to fully comprehend the exceptions once the norm is understood and if the basic flow represents 70% of the system, the development staff is much more prone to implementing the correct code in the first pass. For example the basic flow should be to describe the

40、 happy day scenario for your use cases such as placing a bid. For a consumer to play a successful bid, what is the primary flow when everything goes as planned.,用例规约建模理论 Tips for Writing Use Case Specification,Tip 9. Create the use case alternate flows The basic flow is the key ingredient to your us

41、e case. However, providing more detail to the consumers of your use case is always a good thing. The alternate flows providing the following: An exception or error flow to any line item in your basic flow An additional flow, not necessarily error based, but a flow that COULD happen A few examples of

42、 alternate flows are: While a customer places an order, their credit card failed While a customer places an order, their user session times out While a customer uses an ATM machine, the machine runs out of receipts and needs to warn the customer,用例规约建模理论 Tips for Writing Use Case Specification,Tip 4

43、. Identify reuse opportunity for use cases In this step, you are going to cross the bridge into object modeling. Dont get overly concerned about terms like generalization, inheritance and extends. 用例之间的关联关系：包括和扩展 What does the word general mean? Something is broad and not as detailed.,用例规约建模理论 Tips

44、for Writing Use Case Specification,Tip 5. Create a use case index After producing your initial visual list of use case actors and goals, we can take this list and create an initial use case grid which provides the basis for the use case index. Every use case will have various attributes relating bot

45、h to the use case itself and to the project. At the project level, these attributes include scope, complexity, status and priority.,用例规约建模理论 Tips for Writing Use Case Specification,Tip 6. Identify the key components of your UCS,用例规约建模理论 Tips for Writing Use Case Specification,Tip 7. Name and briefly

46、 describe your UCS Now that you have a general understanding of what a use case consists of, we are ready to start creating our use case. Typically, while the name of your use case is being discussed, people will start briefly describing the use case. Use plain english and keep it simple. Getting ba

47、ck to our use case example. For example: Use Case Number: 1 Use Case Name: Buyer Places a Bid Description: An EBAY buyer has identified an item they wish to buy, so they will place a bid for an item with the intent of winning the auction and paying for the item.,用例规约建模理论 Tips for Writing Use Case Sp

48、ecification,Tip 10. Produce your effective use case document A few reasons why its that much easier to learn a system through use cases then a traditional requirements document is probably because with use cases, you are introduced to concepts at a high level, walk through a living scenario and then

49、 presented with specifications last. “Effective use cases rather than just use cases. The purpose of the use cases is for effective knowledge transfer from the domain expert to the software developer - these use cases will serve as software requirements. If they dont make sense to the person buildin

50、g the software, they are not effective. There are several sources on the web for writing effective use cases including the book by Alistair Cockburn.,用例规约建模理论 10个常犯错误,10. Write functional requirements instead of usage scenario text. 非使用场景 9. Describe attributes and methods rather than usage. 非使用而是属性

51、和方法 8. Write the use cases too tersely 太简洁. 7. Divorce yourself completely from the user interface. 没有界面 6. Avoid explicit names for your boundary objects 边界对象的歧义性. 5. Write using a perspective other than the users, in passive voice. 视角和时态不对 4. Describe only user interactions; ignore system response

52、s 动作没有响应 3. Omit text for alternative courses of action. 没有备用路径 2. Focus on something other than whats “inside” a use case, such as how you get there or what happens afterward. 描述不着边界，要进行内部探索！ 1. Spend a month deciding whether to use includes or extends. 太注重用例关系,用例规约建模理论编写用例规约容易出现的问题,使用用例表示非行为信息， 性能

53、需求无法在用例中描述； 较低目标层次上的用例太多， 无法展示系统将给最终用户提供的功能； 用户界面太细化， 用户界面应属于设计范畴，鼠标、按键等内容不应出现在用例中； 太冗长， 最好在39步； 目标实现不完整， 尤其是缺乏错误处理； 句子是片断， 主、谓、宾应该尽量完整；,系统用例规约建模实例,系统用例规约建模实例,系统用例规约建模实例,系统用例规约建模实例,系统用例规约建模实例,系统用例规约建模实例,来源： http:/www.hippo-software.co.uk/downloads/Example%20Use%20Case%20Specification.pdf,Evaluate Us

54、e Cases Specification,An important goal of any requirements specification is to support validation of the requirements. There are two main ways to evaluate UCSs: Potential customers and users can read the UCSs and provide feedback. To make customer or user validation more effective, it is important

55、to keep the steps simple, concrete, and at the right level of detail. Software designers can review UCSs to find potential problems long before the system is implemented.,Evaluate Use Cases Specification,The requirements review session ensures that the system as described genuinely matches up with t

56、he requirements. Its a collaborative review session involving the customer representatives, end users (actors), and marketing peoplebasically, all the project stakeholders who have a vested interest in ensuring the requirements fit their view of the system. 目的 确保用例及其规约能解决功能需求问题 把系统需求分配给用例 确保客户明白，设计是基于这些需求的： 用例及其规约 系统原型（GUI） 确保设计师明白,Evaluate Use Cases Specification,基本问题 系统的