本文背景:工作中需要对某电子政务系统进行需求抽取,电子政务系统本身具有高复杂性的业务流程,并且业务规则十分庞杂。
本文目的:记录下简要分析过程,以便以后进行类似分析时候更容易把握需求。
首先,我们都知道,需求分析是一个很复杂的过程,一方便需要与客户交谈获取领域知识,业务流程,另外一方面还需要考虑到技术上的实现。作为开发人员往往容易考虑到技术上的技术,而忽略了原本的业务流程。引用“DDD”中的一些话“在启动一个软件项目时,我们应该关注软件涉及的领域。软件的最终目的是增进一个特定的领域。为了达到这个目的,软件需要跟要它服务的领域和谐相处,否则,它会给领域引入麻烦,产生障碍、灾难甚至导致混乱等。我们怎样才能让软件和领域和谐相处呢?最佳的方式是让软件成为领域的反射(映射)。软件需要具现领域里重要的核心概念和元素,并精确实现它们之间的关系。软件需要对领域进行建模。”。
我觉得一个完善的软件,最重要的是符合业务领域业务流程,即到业务进行到什么阶段就该做什么事,而不是把所有业务功能都丢在一个版面上,让软件使用者自己通过自身的领域知识进行选择。这样的例子很多,例如,ATM取款机中已经没钱了,那么就不应该显示“提款”这个功能,例如ATM取款机已经通信故障了,那么所有功能都不应该显示,因为这些功能在ATM的当前状态是不可见的,是不可操作的,所以按照ATM机的业务规则,他是不能出现的。 但是,大型企业与政府的业务流程可不仅仅如此,他们的可达状态远远比ATM复杂得多,例如一个玩具生产系统(技术法律允许就接单做),假设他们的玩具根据材料分塑料玩具、橡胶玩具、布料玩具、木制玩具,每种机动类型的玩具又分电动玩具、非电动玩具,整个玩具生产的正常业务流程是 接收订单---->建立项目单----->分配项目单----->生产玩具----->完成订单 ,好了,现在假设一下每个阶段的业务规则, 接收订单 需要根据 玩具材料类型+玩具机动类型 产生不同的参数, 比如现在接收到一笔 塑料电动玩具 的订单, 除了常规参数以外(价格 数量),还需要输入 塑料耐热性,塑料的环保型,以及电动方式是否为电池,是否无线等等,假设每种组合类型都需要这样进行操作,现在细看一下
接收订单 这个过程,4*2=8种参数输入(这里结果之所以为8的意思是两种类型的任意组合输入参数的不一样,就是说 都为电动玩具的塑料玩具与橡胶玩具 他们的电动参数 是不一样的)。
好了,这个是第一个过程,这里仅仅是冰山一角,现在假设进入第二个过程了,建立项目单,假设这个过程没什么区别,就是像可行性研究,看看我们厂子是否可以搞定这笔单子,这个又跟玩具类型+玩具机动类型关系了,比如 木制电动玩具,先要考证 电动过程中是否会使得木制玩具着火等等,等通过这一道又一个道的检验,那么才可以进入下一个工作周期。好了,现在进行分配项目单了,这个基本上是一致的,只是把一个单子指定到一个生产车间罢了(事实上,任何分配都有很多种,这里是简化了再简化)。
到了生产阶段,这个阶段要处理的信息可与具体的玩具类型具有很大关联了,每种类型的玩具需要记录的信息就有许多地方不一样了,意味着各种用例出现的条件受限制了,比如“测量塑料玩具的耐热程度”这个过程很显然是在类型位塑料玩具的情况下才会出现的。
仔细从头来看整个系统,姑且叫他 玩具生产系统吧, 很复杂的系统, 一层套一层,每个层次的工序还可能不一样,就像“测量塑料玩具的耐热程度”,可能要分在干燥、潮湿情况下的数据,这样十分复杂的系统应该怎么做呢?
我觉得,首先肯定是进行业务建模的,但是要表达出整个玩具生产的全部过程似乎不是那么容易,那么多的分支。第一步,应该确立业务用例,所谓业务用例,就是一个完备的,对于用户来说是可见并且有业务价值的,例如取款是业务用例,而输入卡号跟密码却不是。第二步,描述业务规则,我个人看法用矩阵进行比较规则并且数量较大的业务规则描述会比较适合。第三步,利用状态图显示影响系统全局状态的用例,这个过程大概是这样的,首先我们当前系统的五个订单状态是这样的 未接收的---->接收订单中---->建立项目单中----->分配项目单中----->开始生产----->完成订单 那么至少我们可以抽象出影响状态的五个用例,新接收订单,新建项目单,分配项目单,开始生产,生产完成。 这五个用例都会使得整个项目的状态发生变化,但是不仅仅是这五个而已,例如新建项目单的时候进行项目考究时候发现项目无法完成,那么订单状态也会发生改变,然而这种改变完全根据每种材料的不同进行判断,所以这些会影响状态的用例需要逐步进行填充。
然而这些仅仅是业务建模,仅仅是现实世界如何操作这项业务,下一步需要进行系统建模,系统建模主要加入需要关注的界面细节,业务可执行细节,例如在之前的玩具厂例子中,在某个订单状态就限定了能操作的业务功能,就需要在某些地方表现出来。
分享到:
相关推荐
### UML建模实验报告知识点总结 #### 一、UML与软件...综上所述,通过本次实验,不仅学习了UML的基本理论知识,还掌握了如何使用Rational Rose这一工具进行软件系统的建模,这对于后续的学习和实践都具有重要意义。
2. **用例建模**: 创建用例图来描述系统的主要功能和用户交互。 3. **静态建模**: 通过类图、对象图和包图等描述系统的静态结构。 4. **动态建模**: 使用行为图描绘系统的动态行为。 5. **系统实现与测试**: 基于UML...
《UML实验报告》主要...实验的实践环节强调了UML在实际项目开发中的应用价值,同时也强调了对建模工具的熟练运用和心得体会的积累,这对于未来从事IT行业,尤其是系统分析和设计岗位的人来说,是至关重要的能力培养。
这篇实验报告涵盖了软件工程中的多个...通过这四个实验,学生不仅掌握了Rational Rose的使用,更深入了解了软件工程中的需求分析、用例建模、流程建模等核心概念,这对于未来进行软件设计和开发是非常宝贵的实践经验。
2. 在用例图设计中添加参与者和用例,并用表示关系的箭头将它们联系起来。 3. 根据分析添加适当的参与者、用例、关系后,形成的最终结果。 4. 建立与借阅者相关的类图,并添加属性和方法。 5. 建立管理员处理借阅的...
用例建模不仅是需求收集的过程,也是需求分析和验证的重要手段。 7. **其他文档** "新建 Microsoft Office Word 文档.docx"可能是未命名或者暂时未详细描述的文档,它可能包含了对UML的其他方面,例如类图、对象图...
最后,心得体会部分记录了设计者在项目实施过程中的感悟和收获,总结了遇到的挑战和解决问题的方法,这对于提高未来的设计能力大有裨益。致谢部分表达了对指导老师的感谢和对团队成员协作的认可。 综上所述,UML...
此实验报告通过具体案例展示了UML建模技术在实际软件开发中的应用,帮助学生理解如何使用UML工具(如Start UML)来清晰地表达系统的需求和行为,为后续的系统设计和实现奠定了基础。通过这样的实践,学生不仅学会了...
### 软件工程试验模板知识点解析 ...综上所述,通过这次实验,学生们不仅能够深入理解需求分析和用例建模的基本概念,还能亲身体验到软件开发过程中的各个环节,从而提高自己的软件工程实践能力。
【软件工程实验指导书】是辽宁工业大学2013年为软件工程课程设计的一份实践教程,旨在通过一...在实践中运用这些知识,不仅能够深化理论理解,还能提升团队协作和文档编写的能力,为未来从事软件开发工作打下坚实基础。
3. **熟悉用例建模的基本过程**:从系统需求出发,经过一系列步骤完成用例模型的构建,包括确定参与者、识别用例、细化用例等。 #### 实验环境与工具 - **硬件环境**:配备有微型机的计算机实验室。 - **软件工具*...
在软件工程的学习中,了解和掌握使用工具进行系统建模是非常关键的一环。Rational Rose 是一款著名的统一建模语言(UML)工具,用于帮助软件开发者清晰地描绘出系统的结构和行为。在这个实验报告中,学生通过创建...
接下来,实验体会部分鼓励学生反思自己的学习成果,包括他们对需求获取的理解、实践中的困难以及解决策略。这有助于深化理论知识与实际操作的结合,同时也可以提出对课程或方法改进的建议。 最后,思考题引导学生...
总结这次建模过程,我深刻体会到UML作为一种强大的建模工具,能够帮助我们系统地分析和设计软件系统。它不仅提供了规范化的图形表示,使团队沟通更为直观,还使得复杂逻辑变得易于理解和实现。通过这次实践,我增强...
本实验旨在通过实践帮助学生掌握如何运用统一建模语言(UML)来描绘软件开发过程中的各种图形,从而理解和表达软件的需求。 一.实验目的 1. 基本操作的掌握:实验的第一个目标是让学生熟练运用UML工具绘制软件...
在这个过程中,深刻体会到理论与实践相结合的重要性,同时也认识到团队合作在项目成功中的关键作用。 综上所述,餐饮管理系统的设计与实现是一项复杂但非常有意义的工作,它不仅能够帮助餐饮企业提高运营效率和服务...
《UML实验报告》主要涉及了UML(统一建模语言)在软件开发中的应用,特别是在设计自动售卖系统和类中描述的事画用例图的实践中。报告详细介绍了实验的各个阶段,包括分析、设计、调试和结果分析,旨在帮助学生理解和...
在实践中,这些关系帮助我们更好地组织和理解系统的功能需求,为后续的设计和实现提供了清晰的蓝图。 **体会和总结** 通过这次实验,我对Rose建模工具的使用有了实际操作经验,对于用例图的构建有了更深入的理解。...
UML是软件设计中的标准化建模语言,涵盖了多种模型元素,包括角色、用例、类、数据模型等。课程设计要求学生能够精确地理解和应用这些元素来表达系统的功能需求。 具体来说,学生需要完成以下步骤: 1. 对系统的...