【ASE第四次作业】课程总结
前言
不知不觉一学期就这么过去了。第一节课吴老师的“恐吓”仿佛还在眼前。当时我真的纠结了很久，害怕自己不能完成。现在想想，吴老师还是十分关爱我们的，没有当时说的那么可怕。但高等软工的确也是名不虚传，这的确是本学期我付出的时间和精力最多的一门课。当然，收获也是巨大的。接下来，我按照项目开发的过程捋一捋自己的收获。
项目开发全过程的收获
领域分析
领域分析，可以类比于“审题”。根据项目的内容，通过对现实世界的了解，从各个角度去对系统进行描述。
首先要明确的就是项目是什么。如这学期我们组的项目是：
基于订单的家庭工厂协作系统（需求、设计、实现和测试）
项目描述：典型的生活日用品制造业往往由一组家庭式工厂协同配合，共同生产和组装，完成最终订单。系统有几个关键功能：下单(接单)、订单分解、订单分配、订单进度追踪、订单完成风险评估、订单完成效果分析等。要求实现基于网页或手机端的系统。
根据这个项目内容，我们会使用一些术语，如订单、工厂、任务等等。这些术语是在领域分析的过程中提取和整合出的。用于统一而精准的描述系统。
然后是架构，包括
从领域角度给出系统中涉及的人、物、硬件设备、软件系统、组织机构等。
这一步分析的意义是从架构的角度，笼统的找出系统的内容和边界，明确我们思考的范围。在我们的项目里，大致包括家庭工厂、订单中介、系统平台等。我们在第一次分析的时候，就出现过问题，错误地把顾客也当做了系统涉及的一部分。
有了架构，相当于圈定了系统的范围。而系统不是孤立存在的，系统只有和外界进行信息交换，才有价值。对运行环境的问题就是在考虑这一层的问题。比如接到的订单就是本系统的输入，进度追踪的信息等等就是输出。
在系统内外的交互确定后，下一步就是对系统本身进行分析。而最基本的就是系统在运行过程中的流程如何。在系统的不同流程之间，也会存在信息的流动。对这一层次的分析，可以帮助我们进一步了解系统的结构和功能划分。
最后，则是对用户的识别和目标的分析。它们包括
对领域系统的环境分析和流程分析，识别领域系统的用户及特征。和对领域系统的多个角度综合分析，以及项目的要求，确定待开发系统的目标，表现为满足用户的哪些期望， 以及需要用户提供哪些信息，并反馈给用户哪些信息。要求按照条目来整理分析结果。
这一步使系统能够针对性的实现客户的需求和目标。
以上领域分析的流程，是为了使我们更好地认识问题和系统“是什么”。来源于领域的知识是前提，而各种UML图是帮助我们理清思路的重要工具。
工具：领域知识、UML（用例图等）
需求分析
领域分析解决的问题是我们的项目对象“是什么”，像是一个程序员在现实世界搜集知识的过程。到了需求分析这一环节，问题细化为了“要做什么”。二者之间的差别在于针对性。在一个领域内，完全可能有不同的需求。比如，我们的订单平台主要是为了进行生产协作；可能另一个客户需要的平台是产品设计或利润分配。那么由于对象类似，领域架构可能会有一些相似之处，但越到细微之处，比如分析流程或用户时，就会越有差别。
又比如，同样的一个平台。给一百个家庭工厂用的，和给一万个家庭工厂用的，就算目的功能相同，其需求也会完全不同。在系统的运行效率、稳定性、安全性、算法复杂度上都会有很大的不同。
这也是需求的两个方面，一方面是“功能性需求”——就是具体的用户需要什么功能；另一方面是“非功能性需求”——系统在性能等方面的必要约束。
进行需求分析的过程其实很难归纳出特别完善的方法能够一点不落的找到全部需求，就像淘米一样每次都会找到更多，但又难免落下。除去很传统的项目，可以花大量时间一步步进行全部步骤外，我认为对于大多数情况——需求分析都是一个需要反复迭代的过程。
另外我尤为记忆深刻的，是吴老师对“价值”的强调。某种程度上这是更高一层的思考，毕竟做一个用户要求的复读机也是可以的。对价值的思考，是在想我们为什么要做这个系统。既可以用于自省（有没有走偏了路），又可以用于升华（创造出更好的系统）。
在这一阶段，用例图是最重要的工具，因为用例图直指功能。除此之外，RUCM作为用例图的加强加细版、类图等其他UML图作为辅助也十分有用。
工具：UML（用例图、类图等）、RUCM
设计模型
设计建模的过程，就是从需求模型的“要做什么”转换为具体的“要怎么做”的过程。是填补客户需求和程序代码之间存在的gap的一座桥梁。设计模型的追求，让我概括就是：既能包含需求模型的全部需求，又能按图索骥的根据模型实现代码。
因此，某种程度上，设计模型就是“脑内跑代码”的过程。针对所有的需求，面对类图，一个个输入、一项项函数调用，如果在类图里全部能够连贯完成，那便可以“按图索骥”方便地进行实现了。如果发现了什么地方不清楚，状态图、顺序图、活动图等等一起来，弄明确才罢休。
因为设计模型中需要这样的细化，因此模型的分模块/组件就十分重要。它可以减轻系统的耦合，去掉冗余的盘根错节。因此在这一阶段也引入了组件和组件图等新的概念。在设计建模阶段，类图是最重要的UML图。OCL则是方便而明确描述系统各部分约束条件的语言。
工具：UML（类图等）、OCL
当初的期望与计划VS现实结果
期望
-
了解科学、规范的软件工程理论方法和思路。
-
在实践中掌握软件工程中的各种基本技能，如UML、一门实用的编程语言（如，java）、文档撰写、软件测试等等……
-
锻炼软件开发过程中与队友进行高效的沟通合作的能力。
-
培养“软件工程”的思维方式，弥补一部分本科期间计算机系学生潜移默化形成的基本“常识”。
-
获得一次难忘的经历。
计划
个人部分
-
项目开始前掌握UML的基本知识，自学软件工程的基础知识。在接下来的课程和项目中出现任何不懂之处，立刻通过查资料和请教他人等方式解决，不拖延到下周。
-
项目开发中出现常识性的问题不要羞涩，及时向队友或助教求助，尽快解决问题不影响任务进度。
-
每周反省问题，做好时间分配。
团队部分
-
明确项目的进度规划和分工，每周交流。
-
有问题及时沟通和反思，互帮互助。
-
积极透明的团队交流氛围。
现实结果
期望部分中，1、5可以说是圆满完成了。在整个三个阶段的设计过程中，我都有着极充分的参与。一遍一遍地提出和推翻再修改；每个阶段的逐层递进……实践的确是最好的学习计算机的方式。软件工程这门课中提及的设计思想在这一学期的课中不断为我思考和使用，使我受益匪浅。
2、3、4则或多或少各有缺憾。软件工程的基本技能上，UML、RUCM、OCL等等建模工具我都实际使用过了。java也依靠自学入了个门，水平尚在能用若干个类和函数的组合，以及搜索引擎的帮助下，完成一些项目简单功能编写的水准。但我对项目前后端的全貌构成还未有了解，在项目实现阶段起到的只是辅助作用，十分惭愧。文档撰写全程都是分工合作，但几次下来对总体文档的内容和结构也算比较清楚。但软件测试是一点也没涉及，全都交给了何佳慧大佬去做……
沟通方面，由于团队小伙伴过于优秀，还有王康同学经常的鼓舞（不愧是班长大人！），反倒是一直都比较顺畅，没什么可“锻炼”的地方hhh（雾）。
第4点的思维方式同1，感觉收获颇丰，但是计算机的常识还是欠缺一些。尽管在交流过程中对许多原来陌生的词比如MySQL、vue、Springboot等等都有了概念，知道了大致的意思，但由于最终的整合工作是几位大佬carry的，我对具体使用方法仍然缺乏实感，是个缺憾。
个人计划部分，基本上都做到了——毕竟完全不拖延也的确不现实，但整个学期下来也一直都没有过分拖延的情况，稍有犯拖延症也都是在能准时和及时完成任务的限度之下。团队计划部分，也是由于小伙伴给力，几乎没有什么困难，这3点从一开始大家都自觉做的很好。
写在最后
整理了一遍大致的过程。这里也没什么特别多想说的话了。软件工程的诸多原则和方法，不像数学公式、算法等等是具体而机械的。单纯的记忆和背诵没有意义，它只有在实践中内化于心才能发挥其价值。我十分感谢这一学期讲课与指导我们的的吴老师和孙老师，十分感谢小组内共同合作的伙伴，也感谢其他小组给我们的压力动力与灵感。
