系统分析与设计 || HomeWork4

    xiaoxiao2022-07-14  149

    HomeWork4

    A. 简答题


    1. 用例的概念

    在软件和系统工程中,用例是一列操作或事件步骤,用于表示系统所提供的服务,它定义了系统是如何被参与者所使用的,它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。同时,用例也是一组相关的成功和失败场景集合,用来描述参与者如何使用系统来实现其目标。

    2. 用例和场景的关系?什么是主场景或happy path?

    1). 关系:每个用例提供了一个或多个场景。其中场景是指使用场景,用来说明系统可以做什么,系统是如何和用户或其他系统交互的,从而获得一个明确的业务目标。

    2). 主场景:场景中最成功的一个,也就是用户与系统发生主要交互的那个。相对的可选场景则是不怎么频繁的交互和异常。

    3). happy path: 没有异常或错误条件的默认场景,即用户和系统可以很顺利、无误、符合预期地进行交互。

    3. 用例有哪些形式

    1). Brief(high level):通常是主场景的总结,在早期分析需求的过程中,breif形式可以帮助开发者和客户快速了解软件系统的主题和应用范围等信息,可以快速创建。

    2). Casual(简便格式):非正式的段落格式;覆盖多个场景的几个段落,与breif近似,在早期需求分析过程中,有助于快速了解主题和范围。

    3). Fully:用例中所有的步骤和变化都写得很详细,包括前置条件等应用环境。所有的用户样例都已经定制出初步版本后,优先级更高的用例会被详细编写。

    4. 对于复杂业务,为什么编制完整用例非常难

    复杂业务的场景多且复杂,并且其间关系复杂,再加上业务与需求本身就是需要不断迭代来确定的,编制用例时难以涵盖全部场景;对于单个场景,也难以考虑到所有的用户-系统的交互情况,所以复杂业务是很难编写出完整正式的用例的。

    5. 什么是用例图

    用例图是指由参与者(Actor)、用例(Use Case),边界以及它们之间的关系构成的用于描述系统功能的视图。

    6. 用例图的基本符号与元素

    参与者:参与者是与系统交互的人或物。首先当然包括开发系统用户,除此之外,与开发的系统有关联的其他系统也算是参与者。

    符号是一个小人。

    用例:用例是参与者可以感受到的系统服务或功能单元。我理解的就是用户可以使用开发的项目去做的任何事情。任何用例都不能在缺少参与者的情况下独立存在,同样,任何参与者也必须要有与之关联的用例。

    符号是一个圆框。

    系统边界:指系统与系统之间的界限。把系统边界以外的同系统相关联的其他部分称为系统环境。

    符号是一个方框。

    关联关系:表示参与者和用例之间的交互。为通信途径,任何一方都可发送或可接收消息。

    符号是一个虚线箭头:---->,箭头指向消息接收方。

    包含关系:包含关系用来把一个较复杂的用例所表示的功能分解成较小的步骤。包含用例是必须的,如果缺少包含用例,基用例就是不完整的。包含关系最典型的应用就是复用。这种情况类似与在过程设计语言中,将程序的某一段算法封装成一个子过程,然后在从主程序中调用这一子过程。

    符号是一个虚线箭头,有<>标识。箭头方向指向被包含者。

    扩展关系:扩展关系是指用例功能的延伸。与包含关系不同的是,扩展用例是可选的,如果缺少扩展用例。不会影响到基用例的完整性。

    符号是一个虚线箭头,有<>标识,箭头方向指向被继承者。

    泛化关系:用例的泛化指的是一个父用例可以被特化形成多个子用例,用我们熟悉的语言来说就是继承关系。

    符号是一个实线箭头,箭头是个小三角,指向父用例。

    7. 用例图的画法与步骤

    (1). 确定参与者

    在获取用例前首先要确定系统的参与者,开发人员可以通过回答以下的问题来寻找系统的参与者。

    谁将使用该系统的主要功能。谁将需要该系统的支持以完成其工作。谁将需要维护、管理该系统,以及保持该系统处于工作状态。系统需要处理哪些硬件设备。与该系统那个交互的是什么系统。谁或什么系统对本系统产生的结果感兴趣。
    (2). 确认用例

    用例图对整个系统建模过程非常重要,在绘制系统用例图前,还有许多工作要做。系统分析者必须分析系统的参与者和用例,他们分别描述了“谁来做”和“做什么”这两个问题。

    在确认用例的过程中,通过回答以下几个问题,系统分析者可以获得帮助。

    特定参与者希望系统提供什么功能。系统是否存储和检索信息,如果是,由哪个参与者触发。当系统改变状态时,是否通知参与者。是否存在影响系统的外部事件。哪个参与者通知系统这些事件。
    (3). 确认参与者与用例关系

    用例除了与参与者发生关系外,还可以具有系统中的多个关系,这些关系包括包含关系、扩展关系和泛化关系。应用这些关系的目的是为了从系统中抽取出公共行为和其变体。

    8. 用例图给利益相关人与开发者的价值有哪些

    对于利益相关人:

    可以直观看到系统的结果和用户的功能体验, 保证系统按照用户的需求进行设计。用例能够根据需要对复杂程度和形式化程序进行增减调节, 即能够响应用户(利益相关人)提出的需求, 而用例图则使得这种调节更加便利, 可以通过修改图形间的关系实现。

    对于开发者来说:

    用例图是设计者设计过程的结论与参考, 设计者与开发者之间的交流工具, 开发者开发过程的蓝图。用例图使得开发者能够更明确地获得需求, 更好地理解需求。用例图可以指导开发和测试, 同时可以在整个过程中对其他工作流起到指导作用。

    B. 建模练习题(用例模型)


    1. 选择2-3个你熟悉的类似业务的在线服务系统(或移动 APP),如定旅馆(携程、去哪儿等)、定电影票、背单APP等,分别绘制它们用例图。并满足以下要求:
    请使用用户的视角,描述用户目标或系统提供的服务粒度达到子用例级别,并用 include 和 exclude 关联它们请用色彩标注出你认为创新(区别于竞争对手的)用例或子用例尽可能识别外部系统和服务

    2. 然后回答下列问题:

    a. 为什么相似系统的用例图是相似的

    从上面两幅图可以看出,两个相似的查询系统的用例图几乎是一样的。这是因为相似系统的主要业务逻辑类似,比如查询系统通常只是查询内容的不同,而登录、注册、查询、预定、管理订单这些基本功能都是相同的。

    b. 如果是定旅馆业务,请对比 Asg_RH 用例图,简述如何利用不同时代、不同地区产品的用例图,展现、突出创新业务和技术

    订旅馆业务可以结合用户曾经预定选择的周边要求来给用户推荐旅馆,同时可以设计新上线旅馆的优惠来增加旅馆的客户量和知名度。

    c. 如何利用用例图定位创新思路(业务创新、或技术创新、或商业模式创新)在系统中的作用

    在用例图中对创新用例使用某种颜色进行高亮标记。可以很方便地让需求方、开发人员快速了解该系统的创新模式。

    d. 请使用 SCRUM 方法,选择一个用例图,编制某定旅馆开发的需求(backlog)开发计划表

    IDNameImpEstHow to Demo1注册53点击注册按钮,输入手机号,获取验证码,正确填写验证码,输入密码2登陆53点击登录,输入手机号,选择密码登录或短信验证码登录,填写密码或获取验证码并正确填写验证码3搜索酒店1510通过位置、种类、价格、档次等属性筛选或排序酒店,或直接通过酒店名查找酒店4预订酒店2016选择酒店后,选择房间类型,根据条件筛选房间,确定入住日期,预付定金5管理订单2014选择订单,点击退订,返回定金 根据任务4,参考 使用用例点估算软件成本,给出项目用例点的估算。 简单用例:1到3个事务,权重=5一般用例:4到7个事务,权重=10复杂用例:多余7个事务,权重=15 用例事务计算原因UC权重注册42简单登陆32简单查询酒店77一般预订酒店44一般管理订单64一般
    最新回复(0)