actor是在系统之外与系统相互的某人或某事物,小编倒不以为定时器是系统内部的1个物

Q:请教咖啡兄了,类似调度那种必要怎么描述,比如数据库调度,1天做一回备份。又比如说自身系统里必要每一分钟做一些数额解析处理,那种供给没有哪个用户来驱动,怎么样定义它的用户,小编起来把定时器作为用户,但发现那已经是促成了,那能够把调度本身作为个用户吗,那样调度做的政工就能够一本万利的用用例来叙述了。作者那一个体系大概会遇上各种近乎景况,比如数据变动而做的业务。缺少经验阿。

版型

在UML里有二个概念叫版型(stereotype)/类型/构造型。那些定义是对三个UML成分基础定义的扩张,在同三个因素基础定义的基本功上给予尤其的意思。版型只是UML的一种扩充手段,本人并不关乎太多的构思和方法,而是在建立模型的不及等级,为了差别视图之间的不等观点,会动用不相同图示来表示。

A:象这种情景定时器是actor。
actor的概念并不是人,而是站在系统边界外(系统边界依照分析需假诺足以扩大缩短的)驱动系统的漫天人,事,物,甚至规则。系统边界划定后,边界以内的,只有用例。边界以外的,向系统积极发出动作的,是为actor,被动的从系统获得音讯的,是为接口。

参与者

参加者(actor)在建立模型进程中是由于大旨身份的。actor是在系统之外与系统互相的某人或某事物。

要弄领会何人是参预者首先要弄精通系统的分界。怎样分明系统之外和连串之内吗?可以通过回答以下三个难点来规定:

  • 何人对系统有着明显的对象和供给同时主动发出动作?
  • 系统是为着何人服务的?

职能须求的用例有一个特征是:“不存在没有插手者的用例,用例不该自行运转,也不应有积极运行另四个用例”。这表明没有黄参预的急需肯定有别的东西在产生运维动作,应当找到这些东西,那个东西正是四个插足者,它恐怕是另四个总计机系列、八个计时器、贰个传感器或许三个JMS新闻。

在搜寻到场者的进度中,能够通晓一下题材,扶助明确参与者:

  • 哪个人负责提供、使用或删除音讯?
  • 什么人将选拔此功能?
  • 何人对有些特定功能感兴趣?
  • 在集体中的什么地点选拔系统?
  • 什么人负责补助和维护系统?
  • 系统有这几个外表财富?
  • 别的还有那多少个系统将索要与该系统开始展览互动?

新万博manbetx官网,参与者一定是平素并且主动地向系统一发布出动作并收获反馈的,不然就不是参预者。

Q:接着下边这么些难点,actor是属于系统边界之外的人、事、物,不过定时器应该是属于系统里头的叁个物,笔者可不得以如此清楚,认为计算机的钟表是Actor,以一秒钟时间距离调度为例,Actor正是1分钟、2秒钟等这一个秒钟点。

事情骨干

业务骨干(business
actor)是参预者的二个版型,尤其用于定义业务的加入者,在急需阶段选择。业务骨干是与工作系统全部互相的人和东西,他们用来鲜明业务范围。业务骨干是参加者的多个版型,所以工作骨干必须服从加入者的持有定义。

注:在软件项目里,业务范围和连串范围是见仁见智的。业务范围指那一个项目所关联的具有客户业务,这一个工作有没有总结机连串参加都客观存在。系统范围则是指软件将要完结的这几个对应于事情职能的体系功效,从功效性供给来说系统范围是业务范围的3个子集。

在开头须求阶段,请务必使用工作骨干,时时牢记业务骨干是客户实际上中国人民解放军海军事工业程高校业作里的到场者,没有电脑类别,没有抽象的测算角色。业务骨干必须在骨子里工作里能找到呼应的地点或人口。若是您对获得工作骨干不是很自信,请回答以下难题:

  • 事情骨干的称呼是或不是是客户的政工术语?
  • 工作骨干的天职是还是不是在客户的地方手册里有对应的定义?
  • 事情骨干的事体用例是不是都以客户的政工术语?
  • 客户是或不是对事情骨干能如愿精晓?

A:小编倒不以为定时器是系统内部的1个物。如若是系统之中的,它必须向外提供劳动,也正是系统外有人在使得它,它是不主动实施的。从UML的见地来说,区分系统内外并不是总计机的上下,不是温馨的代码和人家的代码,也不是早已部分代码和即将付出的代码。而是主张者和服务者,或驱动者和执行者的差异。
一旦您把定义器认为是系统之中的,那么必须还有另一个系统外的事物来驱动它,哪怕只需要发出三回新闻定时器就初始活动工作。就好像,上帝轻轻拉动了一下,世界自此开首按常理运营。
A:把哪些作为贰个用例,前提是您事先划定了四个境界。站在分界外的是actor,边界内的是用例。边界是很要紧的。它决定了你的见地和能够得出的结果。例如,对于站在笼子外的你来看,笼子里的猴子是用例,而只要笼子里的猴子来看,用例正是你了。那是意见各异。边界同时能够控制粒度。比如,你站在小车外时,你看来的事物是车体大小,颜色。你在汽车里时,你看看的是仪表盘,方向盘。当把仪表盘拆开,你见到的是电路,展现版…
用例获得也是如出一辙道理,哪些是actor,哪些是用例,粒度如何,取决于你对此边界的认定.

作业工人

何以区分是参加者照旧政工工人?最直接的艺术是判断是在分界之外依旧境界之内。纵然边界尚不清楚,能够通过上边包车型大巴多个难题补助澄清:

  • 他是高歌猛进向系统发生动作吗?
  • 她有全部的事体目的吧?
  • 系统是为她服务的呢?

那四个难点答案只若是不是定的,那自然是事情工人。以人工坐席这几个事例来说,人工座席唯有在售票人打电话的场合下才会领票,由此她是毫无作为的;定票的结尾目标是得到机票,但人工座席只承担订,最后票并不到她的手里,因而他从没完好的政工指标;系统是为订票者服务的。相当强烈,人工坐席只或者是2个作业工人。

Q:果要分析用例,那么考勤登记里的注册上班时间和注册下班时间算多个用例吗,还是考勤登记就是二个用例,依据楼主表达的用例的首先个天性:这件事是相对独立的,小编想应该是分为五个用例吧?
A:用例分为作业用例和系统用例。业务用例描述业务须要,系统用例描述系统必要。业务用例最重要的少数是能不能够完整表述actor主演的愿意。所以您先要弄明白什么人在使得考勤登记,他的目标是什么。
自作者觉着只登记上班和只登记下班应该都以目标的一片段,所以应该登记考勤是工作功能率例。至于上班和下班是或不是在系统用例阶段要分手,取决于你打算在系统层面将它分成八个逻辑功用依旧1个。
Q:小编今后在做二个类型,把具有的涉嫌到的业务都细分成添加、删除、浏览等等类似的多少个个小的用例,那应当都是工成效例了,那请问小编的系统用例是哪些呢?应该怎么写?可能说有必不可少写啊?(你可以拿贰个电子商务的系统作例子教导一下,谢谢了!)
A:你罗列出的那个用例实际上都以系统用例了,你还怎么再细分呢?业务用例是指的事务目的,例如说维护职员档案,那是多少个完全的事情目的,也是一个工作成效率例。至于敬爱办法,有手工业的,有活动的,有的只可以加不能够删,有的只好修改,有的只赏心悦目….那一个,是促成业务目的的法子。在那几个办法中,打算纳入软件开发范围的,才称为系统用例。
Q:那小编是否足以这么精晓吧,若是把业务用例举行职能上的撤销合并的话,分成若干个小的用例,那么那一个小的用例是还是不是正是系统用例?
就象维护人士档案,假使细分成添加档案,修改档案,删除档案,查看档案等等。。。
若果你的答案是毫无疑问的话,那本身是否足以继续这么敞亮:一般景色下,业务用例实际上是在三个相比高的范围上来看业务逻辑,更接近于用户的第3手供给,而系统用例则是工作逻辑的事无巨细的细分,更类似与程序的宏图了?
A:非常小对喔。系统用例和事务用例的区分并非是分开。
请小心通晓:业务用例是用来捕获成效性需要的,功能性须求是由actor的业务目的来体现的。也等于对于actor来说,他所肩负的事情须求由一文山会海的事体目的结合。比如二个档案管理员,他的政工指标便是维护档案。比如论坛管理员,他的工作目的有珍爱用户,维护帖子等..那么些工作指标构成actor任务的全套。业务用例呈现了要求。
而急需的落实有种种主意。怎样落到实处它,是由系统用例来反映的,它们并不是多个不难易行的剪切关系,尽管看上去象。就说敬爱档案吧,那样三个政工目的,会有三种分歧的用例场景去完结它,这个现象包含哪些充实档案,如何修改档案,如何删除档案….对于系统用例来说,正是通过分析这几个现象,来支配哪些情形中的哪些部分是要纳入系统建设范围的。比如体贴档案工作功效率例中,要是由于有个别原因,修改档案很困苦,只可以通过先删除,再全部重建的格局来促成,那么系统用例就充实档案,删除档案,而没有改动档案。
事务用例和体系用例是分别站在客户的事情视角和种类建设理念来规划的。业务用例不是看似,而是完全的第3手要求,系统用例也不是业务逻辑的事无巨细划分,而是系统对要求的达成方式,但不是与程序设计无关,它只是说,要建设的系统功用性需要由那一个种类用例构成。
于是工成效例和系统用例都以急需层面,它们各自代表了业务范围和系统范围。
Q:楼主的系统一分配析员之路第②篇讨论的是哪些是用例,第1篇探讨了涉众。那里一贯有多个疑团怎么从涉众中找出系统的actor?
就拿网上海教室书借阅系统来说,教室的一部分决策者希望查询系统得到他们想精晓的音信,那里要不要把作为1个actor,若是是actor的话,有没有要求有“综合查询”用例
A:如若某涉众直接运用电脑体系,则该涉众正是3个备选actor。要是四个涉众使用微型总结机连串的目标是均等的,则只须求一个actor。
首长希望查询系统获得他们想精晓的消息,假诺那几个音讯唯有经理索要,它实在是actor,如若有很多涉众都在应用,应当考虑是或不是有另一个actor代理这一个涉众来行使。至于“综合查询”用例,作者觉着是不可信赖的,至少在必要阶段,须求掌握知道查询什么。而是否“综合”起来,取决于设计而不是须要。
Q:例如领导直接询问系统获得上架图书的总结情状,领导也一贯询问系统得到借出图书的总计情形。笔者想说的是:领导希望查询的音信可能和几个用例都有陆续。
那个时候该怎么处理那种景况呢?
A:http://coffeewoo.itpub.net/post/9169/227772
那篇小说中研讨到部分关于查询的标题。拷贝到那里。

加入者与涉众的涉嫌

涉众(stakeholder),也号称干系人。涉众是与要建设的这些体系有好处相关的漫天人和事,涉众的利益要求会潜移默化系统的建设。但并不是负有的涉众都以系统的出席者。

到场者是涉众代表。参与者对系统的须求直接影响系统的建设,他们的渴求正是系统供给的根源。参与者通过对系统提议供给来赢得他所代表的涉众的补益。

有少数是值得研商的,就是查询用例。那是2个比较独特的东西,因为查询的目的可以很明朗,也得以很模糊。比如,笔者就只是查查看而已,看完了哪些也不做;也大概是因为自身要租房,所以查询;还足以因为是自作者要查完后修改笔者早已发布的音讯…类似那样的不等目的还有很多,显著大家不容许每2个对象都去定义三个查询XXX业务用例。同时,3个询问可能是超过多少个工成效例的,比如把求租、寻租和用户音信汇聚在3个询问结果里面。在那点上本人也无法判断你特别目的的用例:找房屋消息业务用例,和您朋友通用指标的用例:查询消息工成效例哪三个是科学的,事实上都以科学的,也都有道理,取决于客户须求中针对查询的渴求,到底是专门指标,照旧模糊目标。

参加者与用户的涉嫌

用户(user)是指系统的使用者,通俗一点说正是系统的操作员。用户是插手者的意味,可能说是出席者的实例或代理。并非全部的出席者都是用户,然则贰个用户能够代办多少个插手者。

除此以外补充有个别,倘若是混淆的,平日查询XX作为某3个用例的扩充或然隐含。例如,要刨除用户,必须先查询,查询是去除的壹个涵盖。或许,要删减用户,能够间接从列表中剔除,也得以设定条件查询,查询是去除的多少个恢弘
Q:看了一些遍了,确实收益匪浅啊,还不符合规律不知晓,关于增加和删除改查那样的用例,比如三个管理种类,基本都有这一个操作,倘诺把它们作为系统用例,那么有诸如此类1个结果,四处都有诸如此类的用例,那样存在是不是有含义,假诺没有意义来说,是或不是能够用三个‘维护XX’那样的一个用例来代表?
A:
自小编说系统用例,附带的趣味是这几个系统用例是可复用的。随地都有那一个操作,那么它们应该被视为是可复用的一对。
比如,Hibernate提供了增加和删除改查的API,你要做的事情是发生HQL。Hibernate提供了增删改查的API就是可复用的片段,但它是系统的,与客户工作非亲非故。
那是用Hibernate做例子来讲,假使您的档次中不用任何的第二方框架,完全是友善的,要幸免各市都有诸如此类的用例,那么你们就要在友好的品类框架里达成那个与业务无关的的种类用例,那么与事务有关的用例就可以用“维护XX”来代表了,因为“维护”的效果已经落到实处了。
尽管不是如此做的,假若要保证文档和代码的一致性,那无处是增加和删除改查不可防止的。省略掉当然也能够,只不过必要我们达到共同的认识:全体带“维护”的用例都席卷“增删改查”
Q:谢谢,曾几何时出版你的书,好想看看,增添本人的辨析能力!还有一标题想请教一下,比如说教室登记图书那样一个轩然大波,若是把它看做三个用例,难题正是:新图书登记上架从前是要对图书分类,那么那一个图书分类应该作为单独用例,如故登记图书中的包涵用例,这么些进程本来就从未清晰的底限?
A:表面上看没有清楚的尽头,实际上有。你那个题材是个用例粒度的题材,到底多大方便?那个标题实际上是有显然界限的,就看你挑选的境界在哪个地方。比如,你选拔的境界是漫天体育场合管理,那么登记图书就是体育场所管理中的一个政工环节,而图书分类是看不到的。假设选用的界线是登记图书管理,那么分类图书、装订图书、编辑概要等等就是适合的用例。
就此说那么些进度是有明显界限的,注重于您所选取的界线。
Q:对边界依旧相当小清楚。请问一下面际的选料是或不是有自然的准绳或规则?是或不是由项目组成员本人来分明那几个境界?
A:边界就是你面对的标题领域。边界的操纵没有严刻的条条框框,但有经验可循。面对一个复杂的题材时,为了能够把标题弄精晓,人们会把一切难题分解成一些小的难题领域,那就形成了界限。在品种初期,边界可能是很常见,一点也不细的,随着项目标举办,音讯越来越多,越来越周全,边界也会趁机清晰,细致。
在分析进度中,边界绝不是一动不动的,在类型的不等等级,面对分化的难点,总有很四种大概的界线选择。没有正规判断是非,只可是边界选取的结果要方便分析问题。当然,不佳的疆界选用会导致分析困难。如若根本无须边界的概念,那难题就是一锅粥了。
Q:

参预者与剧中人物的关联

角色(role)是到场者的天职。剧中人物是1个抽象的概念,从过多参加者的任务中架空出同样的那部分,将其取名而形成三个角色。叁个剧中人物表示了系统中一类任务。

除此以外,由于二个用户能够代办八个加入者,因而二个用户能够有所五个职务,也正是能够被钦命两个剧中人物。

系统建模时平常遇上的干活流类型应用的建立模型方法

CheckList

如何确定保障发现的加入者是未可厚非的呢?下边提供了贰个checklist:

  • 是否已找到全体的参预者?也正是说,是还是不是已经对系统环境中的全体角色都进展了表明和建立模型?
  • 种种参预者是还是不是至少涉及到叁个用例?删除未在用例表明中提及的具备出席者,或与用例无通讯关联关系的持有到场者。
  • 可见列出至少两名可以看成特定参预者的人手?就算不可能,请检查插足者所建立模型的角色是不是为另2个剧中人物的一片段。若是是如此,应该将该到场者与另三个插手者合并。
  • 是还是不是有参加者担任与系统有关的一般剧中人物?若是有,应该将他们统一到三个主演中。通讯关联关系和用例表达表明参预者和系统是何许互相关系关系的。
  • 是或不是有多个参预者担任与用例相关的一样角色?如若有,应该使用参加者泛化关系来为她们共享行为确立模型。
  • 一定的参加者是不是将以两种(完全不相同的)方式选拔系统?恐怕,他选拔用例是不是是因为多少个(完全两样的)指标?假使是这样,恐怕应该有八个参加者。
  • 加入者是或不是有直观名称和描述性名称?用户和客户是否都能领略那么些名称?加入者的名称必需求与其角色相符。不然,应对其展开更改。

 

在公司应用建立模型中,大家平时蒙受的一种状态:某种业务,它由一多元顺序相关的事情活动结合,这么些事情活动一般由区别的人居然不相同的部门承受,约等于说为了贯彻多少个事情目的必要差别的义务的人或机构通力同盟。
我们考虑三个315服务系统处理消费者投诉的利用,在事情模型中,它只是多少个政工用例,大家就把它叫“顾客投诉”。
“顾客投诉”能够那样一种现象来叙述:

张大头近来买了一部无绳电话机,刚用了没多长期发觉是一部水货,张大头万分气愤,找到商店需求退货,不料售货员态度蛮横,不理睬他,张大头不能,只得向315热线投诉。
315的受理人士承受了她的投诉,并记录了投诉人的音讯以及投诉讼案件的形似处境,如手机型号、商行、购买时间等,然后要求张大头在家等音讯。315组织的管理人士相当的慢接受了新的投诉讼案件消息,并将它分配给处理人士李曲去处理。然后,李曲起先拍卖这件事情,李曲找到李大头,把它的无绳话机首先拿去鉴定,仅承认确实是水货,然后李曲和张大头拿着检查报告到铺子,必要他俩退货,几番交涉,商行退货了事。然后李曲将那个的处理结果写了报告交给管理人士。管理职员向张大头进行了回访,确认了此事,并签署了审批意见,然后结束了这件案子。

好了,现在要求开发那些应用,供给人士认为有以下多少个业务活动:
(前台)电话受理
(经理)分派职务
(调查人士)处理案件并编写案件处理告知
(COO)电话回访用户,签署审查批准意见,结束案件
需求职员一样觉得接纳用例来描述需要既可以比较清晰又切合项目开发的渴求,根据原先的习惯,我们获得了以下用例模型:
依据用例的概念,它应该是理所当然的,但用例之间没有关系,总令人觉着没有更好地展示出事情之间的细致的涉及,实际上大家简单察觉,这么些工作都以围绕着3个投诉讼案件来进行的,借使能够很好的描述它们的涉嫌对于工作的领会和用户的最后价值是有帮带的,毕竟哪个人会动用1个唯有电话受理,却不处理的事情使用呢。当然那种关系在事情模型是中得以看出来的,因为都包罗在“顾客投诉”业务用例中,但难点是并不是怀有系统都建立工作模型,而且如何在系统用例中反映它们的涉嫌啊,同时用例的轩然大波流描述也会并发像“受理后将案子传给主任”等“将…传递给…”的叙说,因为它们确实涉及密切。
理所当然有人建议那种措施:将用例之间加上带箭头的连接线来表示:
但遗憾的是这并不是一种科学语义的象征方法,有个别UML的CASE工具(像TogetherJ)甚至根本不让绘制那样的图形。更为首要的是假若老总须要依照“填写处理报告”用例的结果来控制是“结案”,照旧要求“案件转移”到任何机构,又应当在怎么地点描述呢。
当然也能够考虑单独绘制一张活动图来讲述。但是那个可是都以关怀在象征方法上的一字不苟,更为主要的是什么从效果(业务)的涉及上怎么着更好地反映它自然具有的自然正视关系。

借问coffewoo兄那种情景下怎么开始展览用例建立模型。
别的,该系统贯彻时(姑且不考虑数据与逻辑分离原则),可以还是不可以完成为五个《顾客投诉类》,在那之中该类中有多个法子:(前台)电话受理
;(CEO)分派任务 ;(调查职员处理案件)编写案件处理报告;
(老板电话回访用户)签署审查批准意见,结案。这里一时将《案件处理告知》完成为《顾客投诉类》的两本脾性。
A:

这一个考虑是您协调的吗?真的非常的厉害!能够考虑那几个标题,能够说您对用例方法的理解已经非深入了!觉得你那一个题材很有趣,小编会把它看成一篇博文发出来的新万博manbetx官网 1

在答复你的题材以前作者先扯点别的东西,与这么些标题标答案相关。前几天中午作者跟二个同事闲谈SOA,天马行空的扯了诸多以后也许的商务情势和动用模型。尽管聊天的情节玩笑和吹嘘皮的成份居多,然则观点计算起来就是三个:on
demand
business,也正是所谓的商务随需应变。在我们的高调里,今后的应用类别处于一种“不分明”状态,例如,要是你想交手提式有线电话机费,你会呈请1个交费服务,不过你不知道那么些交费服务最后将您的开支交到了哪家银行,依然哪家运转商,还是某在那之中介机构,你只领悟您的缴费成功了。甚至,交费服务的开发者本身也不明了会交到哪个地方,它依据一定的规则(例如目速度最快的、最稳定的、手续费最低的…等等)搜索能够承受交费请求的任何服务提供商提供的劳动,并调用它们。那个进度是动态而不是优先定义的。社会上的一一服务单位都提供了五花八门的劳务,而个人或中服务中介则足以本身定义本身的归结服务以赢得毛利。例如,你能够定义2个集交手提式无线电话机费、交水力发电费、交有线电视费、纳税….等等服务于寥寥的一榄子交费服务。换句话说,业务流程由使用者决定而不是服务提供商!于是,应用系统模型变为服务机关提供劳务,而使用者在行使时自行定制业务流程。

所以扯下边的传说是因为在你的考虑中,你的猜疑在于你认为一旦效果之间的作业关系不能清楚的代表出来,那么业务模型不能够建立,随之编写程序也成为不容许。正如你所说:不过那个只是都是关切在象征方法上的校正,更为首要的是如何从效益(业务)的涉嫌上如何更好地显示它自然具有的自然重视关系。

唯独本身并不这么看。作用(业务)之间的关联真就是“自然依赖关系”么?不,功效(业务)之间的涉嫌是因需而存的。用你所举的例证来说,如“组长须求依据“填写处理报告”用例的结果来决定是“结束案件”,依然要求“案件转移”到任何部门”之类的思想政治工作涉及并不是当然注重的,而是由315案子处理条例等等的平整来控制的,更精神的说,是如此的规则也是因为处理消费者投诉的急需而发生的。回到本身事先的传说,商务随需应变,怎么领悟?需是精神,商务是花样,商务随需而变。一旦消费者投诉必要有变,你所说的“关系密切的、自然依赖的”业务就完全有也许不再涉及密切,不再相互依赖。假设那样,你还以为必供给把用例之间因为最近事情而发出的涉嫌用作“天然、本质”的始末来定义吗?

将用例定义为“独立”的,不定义它们中间的涉及的道理就在这里。用例之间自然从没所谓的当然形成的客观关系,它们之所以爆发关联,是因为事情场景的内需,换言之,是因为急需的内需。需要变了,业务场景就变了,但工作场景变了却不代表用例会变。举个最简便易行的例证,未来无数大中城市已经联合了110,119,112等应急电话,原来打111头好报匪警,打11伍只好报火警。但方今打110既能够报匪警也足以报火警。大家发现,供给变了,业务场景变了,但是用例却没变,大家不会看出民警挥舞着警棍冲入火场,也不会看到消防警拖着消防栓狂追小偷。由是得出结论:110不对等匪警,它只是匪警出警用例的一个作业场景而已,因为这几个事情场景,110应急程序和匪警爆发了关系,但以此关系不是自发的。大概有一天大家种种人手提式无线电话机上都有2个紧迫事件按钮,一按就足以与所谓城市应急处理核心联系,而110,119,112之类服务程序则恐怕光荣下岗,而武警、消防警、急救中央依然一个都无法少。

不知你获得答案了吗?那种情状下进展用例建立模型跟你今后不以为奇的做法一般无二,用例还是是独立的;它们之间的“关系”照旧映今后各个现象中;不要试图在用例之间用怎么着线来代表用例之间有作业关联;不要将未来的业务关系认为是用例之间的自发关联。

万一的确完结了自作者与同事海吹的不行现在,你所能做的是提供符合的用例,将其落到实处为劳动;而事情场景,则是由消费者自身来支配,通过劳动搜索引擎从海量用例(服务)中挑出自个儿看中的,拖拖拽拽,定义出一些本性化的例如“购房一条龙服务”、“生活花费一条龙服务”、“挑选女对象一行服务”之类的业务流程供自个儿使用,那才是真的的商务随需应变,on
demand business!

呵呵,憧憬ing…