实验八 团队作业5:团队项目需求建模与系统设计(2)
实验八 团队作业5:团队项目需求建模与系统设计(2)
项目 | 内容 |
---|---|
课程班级博客链接 | 2018级卓越班 |
这个作业要求链接 | 实验八 团队作业5:团队项目需求建模与系统设计(2) |
团队名称 | 玛卡巴卡小分队 |
团队成员分工描述 | 熊文婷:任务1,2; 杨子豪:任务4; 贾傲羊:任务4; 于泽浩:任务3,5; 团队协作:任务2,4; |
团队的课程学习目标 | (1)学习使用UML建模工具Visio; (2)掌握面向对象需求分析建模技术; (3)理解和掌握面向对象软件系统设计原理、设计过程和技术。 |
这个作业在哪些方面帮助团队实现学习目标 | (1)在学习使用UML建模工具Visio的时候; (2)在通过查阅资料学习面向对象需求分析建模技术的时候; (3)在学习面向对象软件系统设计原理、设计过程和技术的时候; (4)在撰写完档回顾所学内容的时候。 |
团队博客链接 | 实验八 团队作业5:团队项目需求建模与系统设计(2) |
团队项目Github仓库地址链接 | 仓库:实验八 团队作业5 |
任务1:对实验七的团队项目互评
任务1:按团队项目互评名单,对互评方《实验七 项目需求分析建模与系统设计(1)》的项目成果进行评价,具体要求如下:
(1)阅读互评团队项目博文作业并进行评论,评论要点包括:博文结构、博文内容、任务分工与时间耗费。将以上评论内容发布到互评团队博客评论区。
(2)下载并阅读互评方团队项目资料。
-
阅读互评团队项目博文作业并进行评论
-
结对方团队博客链接:天马行空队——实验七博文
-
博客点评
-
-
下载并阅读互评方团队项目资料
-
结对方Github项目仓库链接:天马行空队——实验七仓库
-
结对方仓库
-
下载内容过程
-
下载结果
-
文档点评
他们团队做的好的方面是文档自己添加了封面;
格式方面:格式是论文的格式,图片放置的大小不一致,图片题注有问题,各级标题分不清;
内容方面:面面俱到,把能包含的方面都写了,整个文档包含的内容较为全面;-
各级标题问题
注:二级标题和三级标题一样,没有缩进。
-
文档图片问题
注:图片大小不一样,不美观。
-
3.互评团队作业评分成绩:135 分
-
任务2:使用Visio,应用面向对象分析方法(OOA),完善团队项目的《软件需求规格说明书》
任务2:使用Visio,应用面向对象分析方法(OOA),完善团队项目的《软件需求规格说明书》,并将该文档上传到团队项目Github仓库,文档内容要求如下:
(1)采用用例图表示项目功能需求,模型使用规范一致的图形符号和文字描述内容;
(2)参考《构建之法—现代软件工程》8.5节功能的定位和优先级,给出功能分析的四个象限;
(3)选择适当的UML模型,建立问题域对象模型;
(4)完善项目的WBS,估计各项任务所需时间
-
采用用例图表示项目功能需求
-
参考《构建之法—现代软件工程》8.5节功能的定位和优先级,给出功能分析的四个象限
-
内容学习
杀手功能:OCR文字识别技术,可以在屏幕上取词解释,拥有独家权威词典,等等。
外围功能:良好的界面设计,在各个平台上都能运行。
必要需求:单词短语释义的准确性(如果达不到这一点,用户就不会来使用)。
辅助需求:可以做各种皮肤(这也许能让一些用户更喜欢这个软件,但不是决定因素)。 -
四个象限
-
-
选择适当的UML模型,建立问题域对象模型
-
完善项目的WBS,估计各项任务所需时间
-
文档上传记录
任务3:查阅资料,回答以下问题
-
什么是C/S结构?
-
什么是C/S架构
C/S架构是第一种比较早的软件架构,主要用于局域网内。也叫 客户机/服务器模式。
它可以分为客户机和服务器两层:
第一层: 在客户机系统上结合了界面显示与业务逻辑;
第二层: 通过网络结合了数据库服务器。
简单的说就是第一层是用户表示层,第二层是数据库层。
这里需要补充的是,客户端不仅仅是一些简单的操作,它也是会处理一些运算,业务逻辑的处理等。也就是说,客户端也做着一些本该由服务器来做的一些事情,如图所示:
C/S架构软件有一个特点,就是如果用户要使用的话,需要下载一个客户端,安装后就可以使用。比如QQ,OFFICE软件等。
-
C/S架构的优点
1 C/S架构的界面和操作可以很丰富。(客户端操作界面可以随意排列,满足客户的需要)
2 安全性能可以很容易保证。(因为只有两层的传输,而不是中间有很多层)
3 由于只有一层交互,因此响应速度较快。(直接相连,中间没有什么阻隔或岔路,比如QQ,每天那么多人在线,也不觉得慢)
-
C/S架构的缺点
可以将QQ作为类比:
1 适用面窄,通常用于局域网中。
2 用户群固定。由于程序需要安装才可使用,因此不适合面向一些不可知的用户。
3 维护成本高,发生一次升级,则所有客户端的程序都需要改变。
-
引用来源:深入理解B/S与C/S架构
-
-
什么是B/S结构?
-
什么是B/S架构
B/S架构的全称为Browser/Server,即浏览器/服务器结构。
Browser指的是Web浏览器,极少数事务逻辑在前端实现,但主要事务逻辑在服务器端实现。
B/S架构的系统无须特别安装,只有Web浏览器即可。
其实就是我们前端现在做的一些事情,大部分的逻辑交给后台来实现,我们前端大部分
B/S架构的分层:
与C/S架构只有两层不同的是,B/S架构有三层,分别为:
第一层表现层:主要完成用户和后台的交互及最终查询结果的输出功能。
第二层逻辑层:主要是利用服务器完成客户端的应用逻辑功能。
第三层数据层:主要是接受客户端请求后独立进行各种运算。
如图所示:
-
B/S架构的优点
1、客户端无需安装,有Web浏览器即可。
2、BS架构可以直接放在广域网上,通过一定的权限控制实现多客户访问的目的,交互性较强。
3、BS架构无需升级多个客户端,升级服务器即可。可以随时更新版本,而无需用户重新下载啊什么的。 -
B/S架构的缺点
1、在跨浏览器上,BS架构不尽如人意。
2、表现要达到CS程序的程度需要花费不少精力。
3、在速度和安全性上需要花费巨大的设计成本,这是BS架构的最大问题。
4、客户端服务器端的交互是请求-响应模式,通常需要刷新页面,这并不是客户乐意看到的。(在Ajax风行后此问题得到了一定程度的缓解) -
引用来源:深入理解B/S与C/S架构
-
-
什么是MVC设计模式?
MVC全名是Model View Controller,是模型(model)-视图(view)-控制器(controller)的缩写,一种软件设计典范,用一种业务逻辑、数据、界面显示分离的方法组织代码,将业务逻辑聚集到一个部件里面,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
-
Model、View、Controller
Model(模型)是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
View(视图)是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
Controller(控制器)是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据,控制用户输入,并向模型发送数据。 MVC是一个框架模式,它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件:模型、视图、控制器。它们各自处理自己的任务。最典型的MVC就是JSP + servlet + javabean的模式
Model:常用javabean去实现,通过各种类来对数据库的数据进行获取,并封装在对象当中。 View:常用JSP来实现,通过可直接观察的JSP页面来展示我们从数据库中获取的数据。
Controller:常用servlet来实现,通过servlet来获取经过javabean包装过的对象(已存入数据库中的数据),然后再发送数据传输到JSP界面。
-
引用来源:浅谈什么是MVC设计模式
-
任务4:使用Visio,应用面向对象设计(OOD)方法,撰写团队项目软件系统设计说明书
任务4:以任务2的成果为基础,使用Visio,应用面向对象设计(OOD)方法,撰写团队项目软件系统设计说明书,以回答:软件是如何实现用户需求的?文档内容要求如下:
(1) 采用适合的软件设计模式设计软件系统总体结构;
(2) 设计软件系统数据库逻辑结构;
(3) 说明软件重用方案;
(4) 设计关键类的重点服务。
-
文档内容(采用适合的软件设计模式设计软件系统总体结构)
-
文档内容(设计软件系统数据库逻辑结构)
-
文档内容(说明软件重用方案)
-
文档内容(设计关键类的重点服务)
-
项目仓库上传文档截图
任务5:完成团队博文作业
-
博文撰写
-
各项任务实际花费的时间和分工
任务名称 计划用时(min) 实际用时(min) 分工 任务1 60 60 *文婷 任务2 300 340 *文婷; 团队协作 任务3 60 120 *泽浩 任务4 330 400 *子豪; *傲羊; 团队协作 任务5 90 150 *泽浩; 注:本次实验虽有个人分工和团队协作,但在实际过程中以团队协作为主,个人分工任务为此成员主导进行,以保证实验按时完成。
-
结合实验七、实验八的学习体验,对比陈述结构化软件分析与设计、面向对象分析与设计两类软件开发技术的异同
-
结构化分析方法强调弄清楚用户信息需求, 事实上很多场合下这种需求是难以弄清的, 特别是比较大型的系统。如果系统的目的又牵涉到解决某些非结构化的决策问题, 其中的不确定因素太多, 周围的环境不定, 加之用户本身并不熟悉计算机系统, 一开始也难以提出清晰准确的信息需求。外来的系统分析人员和本单位的用户一起工作数月, 但得出的用户信息需求仍然模凌两可, 并不能为第一阶段的系统设计提供太多的有价值的意见, 因而系统分析工作可能会成为一种令人沮丧的工作。
-
结构化分析方法是面向过程的, 形成的信息系统模型实际是对现实世界信息过程的一种抽取, 这同人们认识世界 、分析世界 、形成决策的实际情形并不吻合。结构化分析方法中的数据流程图着重强调的是数据的流动及每一个处理过程, 这样不便于系统分析员和用户之间的沟通, 而且当用户信息需求发生变化或外界条件改变时, 人们无法直观地去改变系统, 必须映象为信息流动及过程后才有可能实现。
-
面向对象的分析方法:需求分析阶段首先要给出UML图中的用例图与类图。用例图是由系统之外的执行者( 称为主角或角色) 与执行者感受到的一系列动作( 称为用例) 所构成, 用例图包括主角、用例以及主角与用例之间的联系。类图则要从问题域的研究 、描述中抽象提取。在初步的用例图与类图的基础上可根据需要分析给出 UML的其他图, 比如状态图、顺序图 、活动图、协作图等。进入设计阶段后需进一步规划 、设计类的属性与方法, 给出方法体的实现流程 。
-
从上面的分析设计过程可以看出, 结构化方法是对系统功能建模, 基于功能分解设计系统结构, 从内部功能上模拟客观世界.面向对象方法则是从行为的角度进行建模, 基于行为分析法认定对象及它们之间的关系, 从内部结构上模拟客观世界, 它采用了新概念 、新方法 、新的表示形式, 有助于软件开发人员加深对系统的理解, 给软件开发带来很大益处 .但在实际应用中, 开发的大型软件系统通常是混合型系统, 即需要处理实时信息、又需要数据库的支持, 同时还涉及大量的事务性操作请求, 在这种情况下, 在选用面向对象方法的同时在局部处理上可以结合使用结构化方法 。
-
结构化分析方法图文讲解
-
面向对象的分析方法图文讲解
-
-
学习活动的心得
-
*泽浩
Visio建模工具学习:首先Visio软件的学习是我们每一个人的任务,所以大家都进行了学习。开始学习用Visio软件画图,软件的功能还是很强的,目前还有N多的功能没有用过,画图的时候需要找一会,有的会要找很久还不一定能找到。因为软件版本不尽相同,有的功能在不同的版本中处在不同的地方,Visio软件中有的功能不太方便使用,可以用在线的一些建模工具作为辅助设计,如处理上次所学的ProcessOn,我还会使用艾莫脑图等在线软件。
项目需求分析建模:对于这个任务,我们团队是分工协作的,其中主要有贾傲羊和杨子豪来主要引领完成,期间我们四人也会参与讨论,如我们之前一起分析档案馆的需求,从老师学生的角度多方面考虑,绘制前期的E-R图等。
软件系统设计:通过再一次的对软件系统的设计,我们几人对自己的项目加深了理解,在设计中完善了我们最常的普通设计,对每一个小的环节功能进行了再一次的探讨确认。在本次任务中通过团队成员的讲解帮助让我本来对于软件系统理解不透彻的我,对此有了新的认识,帮助我更好的完成后面的学习。
补:本次实验发生一件让我感到愧疚与温暖,愧疚是由于自己的事物耽搁,导致团队博文差一点就没有交上使我感到愧疚;温暖是当我在9:13告诉团队成员我在接待专家没有及时提交作业时团队成员及时回应交上了作业,也对我表示关心。这件事让我感受到团队在一起分工协作学习的优势
-
*文婷
软件使用方面:本次实验运用了visio绘图软件,在此之前也接触过类似软件,visio软件与ProcessOn的区别在于ProcessOn是在线软件,很方便,visio的好处在于功能齐全,但是在之后的学习中我会选择ProcessOn,因为很方便,快捷。
团队协作方面:我作为团队的PM在几次实验中确实体会到了团队协作的重要性,也感受到了作为团队PM的压力。虽然我们团队内部人人都有分工,而且分工很明确,没有出现任何问题。但是出现的问题有,成员之间的接触不密切,这是值得反思的地方,在之后的协作过程中我会努力改正这一点,争取带领团队做的更好。
学习方面:在完成软件需求设计书时我感觉自己对于UML用例图的了解更加的深入。在观看了mooc视频后再反复修改,这是我觉得很好的一个自我习惯,在经过几次编写设计书,需求文档后,我对格式的要求更加的严格,看了其他团队的文档后也找出了我们与他们的差异,这也让我明白我们需要改正的地方,希望在以后的学习中我们可以更加努力向前,学习好的方面,摒弃差的方面!
-
*傲羊
团队精神和团队氛围会产生强大的动力。古语说近朱者赤,近墨者黑,一个好的氛围对人的影响是巨大的,好的团队氛围可以使每个成员都心甘情愿尽自己最大的努力去完成好工作,工作效率成倍增长。 对于本次实验中使用visio画图的部分,我们不仅需要正确,也要美感易于阅读和理解,画好图也体现作者对工具的驾驭水平,体现作者的美感审美能力,这也是学习中需要不断修炼的一个方面。
在对项目进行需求分析建模的过程中明白了正确的需求的重要性,还注意到就是把握软件在开发过程中应该有的功能性需求和非功能性需求。采用合理化的需求分析模型,能够快速让我们的工作开动,让我们的合作密切起来,有助于我们快速完成工作。
软件的设计实际上是一个很复杂的事情,一个高超的软件更为复杂,因为你要考虑太多的情况,一个人是极其复杂的。但正如所有的物质都是由简单的原子组成的,所有的复杂性都能划分成最简单最基本的东西。拿软件设计来说,对于基于窗口的程序设计,我们有多种技术方案可以选择,在windows下有mfc,.net, wpf,在linux下有gtk, qt, wxWidgets,在mac下有cocoa, 但核心思想差不多,大多用到了mvc思想,但mvc思想本身也是一个组合思想,它组合了策略模式,观察者模式等。对于这样的一个设计思想来说,它其实是一个对设计的高度抽象。我甚至可以做这样一个奇怪的思考:如果将mvc模式套用到人身上,那么人所看到的就是view,人所想到的就是controller,人所使用的便是model了,那么针对一个人来说,他的基本动作可能如下:看到东西->产生需求->寻找工具来实现自己的需求。得益于此,我们完成系统设计说明书的过程虽然有少许挫折,但还是顺利的完成了。
-
*子豪
团队实施Visio建模工具学习:在之前的课程实验过程中,已经接触到了各式各样的建模工具,此次实验,我们要学习的是Visio,这是微软Office的产品,为创建复杂软件系统的面向对象模型提供了全面的支持。为了完成本次的实验目标,添加用例图和功能分析的四个象限以及UML模型,我们组内进行了较长时间的学习与讨论,原因是大家毕竟都第一次接触Visio,好在换汤不换料,明白了这个软件的用法之后,意识到和别的建模软件相比都是大同小异的,最后顺利地完成了实验目标。
项目需求分析建模:需求分析是在之前的实验过程中已经分析与处理过的,此次实验涉及到需求分析建模,所做的是对之前学习成果的一个梳理与完善,通过建模更直观地呈现出各方对项目的需求,因此这一项任务比较快速地就完成了。
软件系统设计:撰写软件系统说明书需要对整个项目有一个宏观的理解与把握,需要了解软件的各个功能,软件的模块划分,软件的数据流动,软件的异常过程处理,还有各类内部外部接口,数据库的数据结构,实体之间的联系,实体的属性等,在此基础上,总结,梳理,最后绘制出清晰直观的项目整体架构,经过讨论和分享项目的信息与对项目的理解,最后也顺利地撰写出了项目软件系统设计说明书
-