欢迎来到我的范文网!

spring,mvc,uml

个人简历表格 时间:2019-07-11

【www.myl5520.com--个人简历表格】

UML分析
篇一:spring,mvc,uml

画图不要解释不要过程,只要结果

第一个作图题:用例图

用例是主要参与者与系统之间的交互(一系列动作),来完成他的目标。

用例:谁,想干什么事。

要给系统定义一个边界范围。

可能还需要一些外部的系统和设备来支持,在右边画出支持性参与者。

会给一个表格,说明参与者是谁,目标是什么,这个目标有什么子功能,有哪些场景,需要的外部设备有哪些。只需要按照这个表去做就行了。

举例:课程网站上面那份酒店预订的文档,给你附上链接吧:

1、 明确是什么系统(系统边界的标题),大概是从文档第一段找吧

2、 为了获得目标,有经验的作者都是把目标写在段落的第一行或者最后一行,告诉你

使用者的意图是什么,找到这一句的动词和名词即可,如:

The Search button allows to submit the request to the system to find available hotels on the dates specified.

这个功能的目标就是为了find hotel,hotel不要加s,也不要把形容词留下,做需求的时候要简洁,要把冠词、复数等去掉,只留下动词和名词

如果有特殊情况,遇到这种特殊情况,系统会增加一个功能,这个是属于extend的(目标同样是查找酒店,只是查找的方式不同而已): If the City/Town location does not exist in the database, the application offers the traveler to find the location by browsing through the selections, as shown in Screenshot 2.

后面就没有什么跟find hotel有关的了,所以这个功能到此提取结束。

3、 接下来讲找到酒店之后,给了一个工作流告诉你怎样去下一个订单:

workflow that informs that making a reservation consists of four steps: (1) search,

(2) choose hotel, (3) choose room type, and (4) confirm reservation

这个功能是make reservation。

这里是一个功能包含多个子功能,第一个(search)我们前面已经做了,所以这里的功能包含了后面3个子功能,是include,要注意include与extend的区别。

(老师在黑板上写的3个子功能分别是:choose hotel, choose room, confirm reservation,大概原则是尽可能简洁吧)

虽然说这3个子功能可能可以继续细分,但是考试时间有限,老师说最多考三层,正常情况下写两层你就可以得到满分了。(老师特别提醒女生不要太追求细节,太追求细节不但不加分,反而要扣分,然后他就开始继续拿起他那独特的吹水功夫了…)

4、 他说然后剩下的就是check out功能了,于是乎我在文档里面搜了一下,这个check

out好像不像他说的那么好找啊…于是我仔细听一下他是怎么找出来的:“下面就要做check out,check out 干嘛呢,这你一看check out hotel,所以说这个东西呢,就是你的直觉也会告诉你的,这样划分为3个用例是非常合理的”

好的…直觉,恩,记住了!请练好你的直觉…

但是他最后画出来的图check out是放在make payment里面的…所以最后我画图是按照四个功能来画的,这个check out放到pay里面去了

5、 接下来还有管理basket、pay,老师说漏掉不会扣分,不要太追求细节。

整体地从参与者的角度去看这个系统,而不是从系统功能的角度去研究系统,我为

什么要用它,用它来干嘛。

注意pay这里用到了支持性参与者,如信用卡等

扣分标准(一个图才10分啊!):

1、 在图里面有“什么什么界面”“什么什么菜单”“什么什么功能”“什么什么按钮”

之类的字眼,扣10分,哦,后来又改成一分都不给了

2、 画得像流程图,不给分

其他情况下,画得想流程图就有分。

3、 没有系统边界,扣1分

4、 没有系统名称,扣1分

5、 只出现名词却没有出现动词,扣1分

6、 一定要有一个include或者一个extend,不需要两种都有,搞不清楚二者的区别全

都写include就好了。如果是extend,一定是虚线箭头指向父用例,代表从父用例扩展出来,如果是include,一定是虚线箭头指向子用例,代表包含子用例。

如果不满足上面条件,扣分,扣多少就不知道了…

7、 所有的用例都必须和actor关联,如果没有关联线或者关联线有箭头,扣分,关联

线一定是没有箭头的。

8、 actor和actor之间作为角色可以存在泛化,但是不能存在管理,因为整个文档没有

出现“管理”这个字样。

9、 如果是手机的APP,右边的支持性参与者常用的有device或传感器,GPS,加速传

感器,支持性参与者不能写在左边,写在左边要扣分

spring,mvc,uml。

10、 画用例是画有用的用例,不能出现“登陆”或者“login”这种对系统没有贡

献的字眼

11、 一个用例就是一个基本业务流程:做事过程中间是不能停顿的。比如在下订单

的过程中,是不能中断的,如果下一半就关掉系统则没有成功下订单。

如果你把所有功能堆积到一个用例里面,说明你认为所有功能必须一次性完成,不能中断,这个是错误的,直接是0分

12、 size原则:用例不是操作,不要把每一个操作都拿出来做一个单独的用例,比

如输入地点等等。

如何判断是否符合size原则:这个功能是否有一个单独的界面

这意味着每一个用例都有一个单独的交互过程

第二个图:活动图

1、 首先画好起点(一定要有起点终点,起点只有一个,终点可以有多个)

2、 画活动

填写以下表单的活动:

1) 输入地点

2) 输入check in日期和天数

3) 输入check out日期

4) 点击search按钮

以上写得很详细,写得详细不扣分,但是考试时间有限啊!!!

遇到这种情况,考试时就写成下面这样就好了:

1) 输入查询条件

至于查询条件是什么,那一般是在系统说明里面详细说明的。

2) 提交查询表单

活动图一般是画一个用例或者一个子用例,一定要看清楚它要你画哪个用例。

假设这里是要画find hotel的活动图,那么就是:

1) 输入查询条件

2) 提交查询表单

3) 如果city存在,则这个用例就结束了

4) 如果city不存在,则调用find location子用例,不用研究怎么find的,文字细节以

后进一步改进,这样的图一看就很清晰了

注意事项:

有箭头的线,如果有循环一定有归并节点,如果有条件的话,一定要写guard(写在guard里面会自动加上左右中括号[ ]的,guard在constraint选项卡里面)。

可能会考什么是活动状态Activity:

活动状态用于表达状态机中的非原子的运行,特点如下:

1) 活动状态可以分解成其他子活动或者动作状态

2) 活动状态的内部活动可以用另一个活动图来表示

3) 和动作状态不同,活动状态可以有入口动作和出口动作,也可以有内部转移

4) 动作状态(Action)是活动状态的一个特例,如果某个活动状态只包括一个动作,那

么它就是一个动作状态。

第三个图:状态图(最好自己百度怎么画)

状态图的对象是什么,可能是一个system,也可能是一个用例,也可能是一个对象,一定要看清楚题目要求画什么东西的状态图。

画系统和用例的状态图一般是画它的过程,而画对象的状态图是画它的生命周期。 然后就是找状态了,一定要知道状态变量是什么,一定要能枚举状态有哪些情况。 接下来是操作。

1、 识别状态图的对象

2、 识别状态

考试是有组合状态的。

3、 转换边

格式:触发事件 [监护条件] / 动作

触发事件:触发转换的事件,包括调用、触发信号、时间等spring,mvc,uml。

监护条件(guard):决定是否能转换的条件,监护条件为true才能转换

动作:转换被激活时会发生的操作

事件一般用被动语态写出来(用被动语态写出来的叫做触发,如onKeyPressed,一般是与代码对应的函数名相同的)。

如果程序显式告诉你,“如果什么,怎么样”,则一定要写guard,否则要扣分

动作可以不写,写错了要扣分

对例子进行状态建模:

1) 起始状态

2) Choose hotel状态

3) 经历Hotel selected事件(不要写成continue事件)之后进入submit状态

4) Confirm状态

5) 终止状态

第四个图:领域模型

名词法:找一堆名词,然后把这堆名词之间的关系给建立起来

名词里面有属性。要判断名词是不是概念类,是不是属性。

考试的时候是针对一个用例来画领域模型,一定要看清楚是要对哪个用例建模,没有那么多时间对整个系统建模。

1、 先找到所有名词,判断它是类还是属性

找名词的原则(下面不要的名词标红):

1) 跟UI相关的名词不要

2) 跟database相关的名词不要

3) 跟业务流程没有关系的名词不要,如技术相关的术语,如下面的workflow,list

4) 任何计算出来的结果,不参与业务运算,不要,如果留下了这个会扣分

5) 模糊的术语一定要过滤掉

2、 如果出现动词,扣分

3、 没有名词,扣分

4、 多重性(关联的一对多,一对一等)没有,扣分

5、 漏掉一两个类,不扣分

6、 属性,假如每一个类有七八个属性,只写一两个典型的代表即可,考试没有那么多

时间

7、 领域模型的类不能有操作(也就是类的函数),如果写出来要扣分。

8、 如果有描述类,一定要画出来。

描述类是包含其他事物的信息的类。命名方式:被描述类名Description

被描述的事物存在,并且描述独立于事物的实例

比如酒店的每一个同类型的房间价格都是一样的,它并不随着房间号的变化而变化,所以把房间描述独立出来会比较好

对下面这段话(make reservation用例)进行领域模型建模: Screenshot 3 shows a web page resulting from a successful search. The page shows:

workflow that informs that making a reservation consists of four steps: (1) search, (2) choose hotel, (3) choose roomtype, and (4) confirm reservation summary that displays the original search criteria search again option, which returns the customer to Screenshot 1

option to sort results by: (1) our favourites, (2) lowest price, (3) highest star rating, and

(4) alphabetical

search results listing the hotels and basic information about them, as well as the continue option to proceed with the reservation

1) 首先看它是什么用例:make reservation,就先把reservation提取出来,这一定是

重要的,把它放在最中间,其他的都围着它转,因为大部分会与它有关系

2) 看描述文档里面的单词,哪些单词与它联系比较紧密,出现次数比较多

3) search criteria是前面输入的搜索条件,是已经存在内存里面的,表示方法为在前

面加个m,表示为mSearch Criteria,要注意以m开头的东西,一般不要与其他类发生关联,除了mBasket(购物车)可能要与item发生关联,其他都不要

4) 找到所有的名词后,建立它们的关联

include, own, has等等

第五个图:SSD 操作协议(系统顺序图)

什么是SSD?

通常用这个图来画一个用例场景(例如主场景或复杂的常用的场景)。

1、 首先要画一个system,前面要加个冒号,不写system,扣全部分,不写冒号扣1

分,位置放错扣1分。

因为要画的是系统事件,没有系统还画什么

2、 最左边是actor(前面也要加冒号),然后是system,然后就是用例的外部实体

3、 主场景是按照最理想的情况把事情做完就可以了,不需要考虑细节

4、 系统顺序图通常只有3-5个事件,如果某个事件操作很多,直接忽略后面那些细节 5、

make reservation的系统事件:

事件不能写什么continue之类的,要写具体的意图,对应代码里面的函数名

1) findHotel(mSearchForm)

2) chooseHotel(hotel)

3) chooseRoomType(room)

4) confirm(reservation)

5) addBasket()

后置条件只能写这3句话中的一句或几句:

创建什么对象或删除什么对象,修改什么属性,生成什么关联

这是整个画图考试唯一需要文字的地方

第六个图:包图

我想实现这一个场景,请使用MVC模式生成一个层次架构,请你用一个包图来表示这个层次架构,并把场景里面的元素填到包里面去。

有3个包,一个叫M(模型),一个叫V(视图),一个叫C(控制器)。

把每个包里面涉及到的东西添加到包里面。

findHotel领域模型里面包括:city, hotel,这个是在M里面的,包图的M里面的元素全都来自领域模型里面。

findHotelAction, mSearchCriteria属于C,临时变量都属于控制层,动作的命名规则是在动作后面加个Action或者Controller,一个用例就一个控制器。

searchForm属于V

对一个用例画包图就是把这个用例的领域模型里面的元素填到M和C包里面,然后给界面起个名字,然后写在V包里面即可。(老师没说要画包之间的关系,他自己画的图也没有画关系,所以干脆还是不要画了吧)

开题报告
篇二:spring,mvc,uml

重庆工商大学

毕业论文(设计)开题报告

计算机科学与信息工程 院(系) 计算机 专业2011级 软件2 班

课题名称: 校家电维修社团报修品管理系统

毕业论文(设计)起止时间:

2015年2月25 日~ 5 月 14 日(共 12 周)

学号:

指导教师: 赖涵

报告日期: 2015年3月8日

说明:

1. 本报告必须由承担毕业论文(设计)课题任务的学生在接到“毕业论文(设计)任务书”、正式开始做毕业论文(设计)的第2周或第3周末之前独立撰写完成,并交指导教师审阅。

2. 每个毕业论文(设计)课题撰写本报告一份,作为指导教师、毕业论文(设计)指导小组审查学生能否承担该毕业设计(论文)课题任务的依据,并接受学校的抽查。

系统分析及UML建模
篇三:spring,mvc,uml

系统分析及UML建模

软件开发的阶段:包括可行性研究、需求分析、系统设计、编码、测试、部署、运行、维护等。

一、 可行性研究spring,mvc,uml。

1.全国会计专业技术资格考试网上集中评卷可行性报告介绍

2.全国会计专业技术资格无纸化考试可行性报告介绍

二、 需求分析

需求(Requirement)是系统必须满足的条件或必须实现的性能,是用户对目标软件系统在功能、行为、性能、约束等方面的期望。

系统分析(Analysis)的目的是将系统需求转化为能更好地将需求映射到软件设计师所关心的实现领域的形式,如通过分解将系统转化为一系列的类和子系统。

良好的需求分析活动有助于避免或修正软件的早期错误,提高软件生产率,降低开发成本,改进软件质量。

注意事项:

①改进不合理的、或不合实际的需求

②当需求不明确时,可以利用快速原型,引导用户提出需求。

可以将系统的需求划分为以下几个方面:

1、 功能性需求:

是指系统需要完成的功能,它通过详细说明系统的输入和输出条件来描述系统的行为。

2、 非功能性需求,主要有:

①使用性(Usability):如易学性、易用性、用户界面、用户文档等

②可靠性(Reliability):是指系统能正常运行的概率,如系统的失败程度、系统的可恢复性、可预测性和准确性。 ③性能(Performance):如事件的响应时间、内存占有量等。

④可支持性(Supportability):指易测试性、可维护性等。如测试工具:LoadRunner、APP Scan、 Fortify SCA等。

3、 设计约束:

如对操作系统的要求、硬件网络的要求等。

三、以一个《简单的图书管理系统》为例进行系统建模。

1、 创建系统的用例模型

进行系统分析和设计的第一步就是创建系统的用例模型,整个开发过程都是围绕系统的需求用例表述的问题和问题模型进行的。

⑴创建系统用例的第一步是确定系统的参与者,各自的任务、工作流程等。

图书管理系统的参与者一般包含以下几种:

借阅者:能够借阅图书、查询图书信息、预定图书和归还图书操作。

图书管理员:处理借阅者借阅图书和归还图书。

系统管理员:负责图书、借阅者、图书管理员等的信息维护。 在Use Case View中建立3个

Actor

可以为每个参与者建立一个活动图,因为活动图能够反映出参与者的工作流程,例如,以下是图书管理员的活动图。

如图:

⑵建立顶层用例图,由于系统比较简单在此可以省略。 ⑶分别建立每个参与者的用例图

如图1:

UML实验报告
篇四:spring,mvc,uml

个人项目报告

(2014 年)

课题名称专业名称 信息与计算科学(嵌入式) 学生姓名 吕佳培,倪佳良,马凡贺,沈程晨

南京工业大学理学院spring,mvc,uml。

目 录

第一章 引言 ................................................................. 3

1.1编写目的 ............................................................. 3

1.2背景 ................................................................. 3

1.3定义 ................................................................. 4

1.4参考资料 ............................................................. 4

第二章 总体设计(系统架构设计) .............................................. 5

2.1需求规定 ............................................................. 5

2.2运行环境 ............................................................. 5

2.3基本设计概念和处理流程 ................................................ 6

2.3.5总体架构设计2.4 系统结构(系统各个组件设计) ....................... 10

2.4 系统结构(系统各个组件设计) ........................................ 11

第三章 系统数据结构设计 ..................................................... 17

3.1数据库逻辑结构设计 ................................................... 17

3.2数据库物理结构设计 ................................................... 25

第一章 引言

1.1编写目的

本文档作为BBS的概要设计说明文档,用于与用户确定最终的目标,并成为协议文本的一部分,同时也是本系统设计人员的基础文档。

1.1.1 概要设计说明书目的

本概要设计说明书说明了BBS论坛系统设计的整体结构。

1.1.2 预期读者

本系统开发人员及维护人员。

1.2背景

BBS论坛,或者称为社区,是电子商务网站中一种常见功能,也是互联网上一种极为常见的互动交流服务。它为上网用户提供了也各自由的讨论区。通过论坛可以向用户提供开放性的分类专题讨论区服务,同时注册的用户可以根据需要在论坛上发表文章,交流技术经验,或者提出问题并表达自己的观点。不仅如此,上网的用户还可以在论坛中看到他人发表的文章,并且能够对该文章进行评论。

一般情况下,BBS按不同主题分为多个布告栏,其设立多是依据使用者的要求和喜好,但多具有信件交流、软件交流、信息发布等功能。

目前,大部分BBS由教育机构、研究机构或商业机构管理,大多有自己的拨入电话号码,用户只需电脑、调制解调器和电话线就可通过电话拨号登录BBS站点。

1.2.1 待开发软件系统的名称

BBS论坛系统

1.2.2 项目的任务提出者

1.2.3 项目的任务开发者

1.3定义

1.3.1 本文档中涉及的专业词汇

1、GB:中华人民共和国国家标准的英文缩写字母

2、构件:具有某种功能的可重用的软件模版单元,表示了系统中主要的计算元素和数据存储。

3、逻辑视图:描述支持系统的功能需求的视图。

4、开发视图:也称模块视图,主要侧重于软件模块的组织和管理描述。

1.3.2 名词说明

1、BBS:Bulletin Board Service

2、JSP(JavaServer Pages)

JSP技术使用Java编程语言编写类XML的tags和scriptlets,来封装产生动态网页的处理逻辑。网页还能通过tags和scriptlets访问存在于服务端的资源的应用逻辑。JSP将网页逻辑与网页设计和显示分离,支持可重用的基于组件的设计,使基于Web的应用程序的开发变得迅速和容易

3、Struts只是一个MVC框架(Framework)

它用于快速开发Java Web应用。Struts实现的重点在C(Controller),包括ActionServlet/RequestProcessor和我们定制的Action,也为V(View)提供了一系列定制标签(Custom Tag)。但Struts几乎没有涉及M(Model),所以Struts可以采用JAVA实现的任何形式的商业逻辑。

1.4参考资料

1、本软件项目规划依据标准为国家表准:GB856T——88;

2、技术参考资料

(1)J2EE项目实训Hibernate框架技术(21世纪高等学校实用软件工程教育规划教材)

杨少波 等编著 清华大学出版社 2008 年5月

(2)J2EE项目实训Spring框架技术(21世纪高等学校实用软件工程教育规划教材)

杨少波 等编著 清华大学出版社 2008 年5月

(3)J2EE项目实训UML及设计模式(21世纪高等学校实用软件工程教育规划教材)

杨少波 等编著 清华大学出版社 2008 年5月

(4)J2EE项目实训Struts框架技术(21世纪高等学校实用软件工程教育规划教材)

杨少波 等编著 清华大学出版社 2008 年10月

第二章 总体设计(系统架构设计)

2.1需求规定

2.1.1输入输出要求

界面风格:要求整体界面美观,有清晰的层次感,布局简洁、合理。同时保证后台的管理页面和前台的服务页面保持风格的一致。

2.1.2时间要求

时间需求:在软件方面,响应时间,更新处理时间都比较快且迅速,系统响应时间不能超过20秒。

2.1.3灵活性要求

灵活性:当用户需求,如操作方式,运行环境,结果精度,数据结构等其他软件接口等发生变化时,设计的软件能做出适当调整,灵活性非常大。

2.2运行环境

2.2.1设备

1、主机类型如表2-1

表2-1 主机类型

2、网络类型:百兆高速局域网

3、存贮器容量:大容量存贮器

本文来源:http://www.myl5520.com/gerenjianli/97508.html

推荐内容