首页 > 代码库 > 《软件工程》课程报告 —国土资源执法监察管理信息系统建模
《软件工程》课程报告 —国土资源执法监察管理信息系统建模
一、问题描述与需求分析
国土资源执法监察管理信息系统的用户需求以及面向对象建模。
分析题目，可知软件的的重点不是国土资源的执法本身，而是对执法进行监察， 主要工作有各级各部门开展核查、整改查处、督查、验收和存档，另外还应能处理群众即投诉人的举报投诉。涉及的有关部门总的有投诉人、国土资源局、政府、监察局；而国土资源局里的分工比较明确，可以进一步划分为地籍科、规划科、用地科（利用科）、耕保科、监察科（在国土资源局内部也有相应的监察科）；政府也可以按等级进行细分，大体有市政府、省厅。
经过查阅相关资料后明确了有关部门的职责，归纳如下：
1.投诉人
此部门是该系统中很重要的部门，主要职责为核查。关于核查又可以细分为不同具体工作。
2.1地籍科：负责对卫片图斑涉及地块的外业核查和测量结果进行审核
2.2、规划科：负责对卫片图斑涉及地块的审批权及使用是否符合土地利用总体规划和土地利用年度计划进行审核；
2.3、耕保科：负责基本农田和一般耕地的认定；
2.4、用地科（利用科）：负责对用地是否经过依法批准和依法供地进行审核，并负责合法用地档案的整理；
2.5、监察科：负责对新增建设用地的合法性进行审核，以及对土地违法行为进行查处，负责各种表格的综合统计上报，并对此项工作进行总协调。
3.政府
不同级别政府的工作有所不同。
3.1、市政府：在核查下属单位的提供的信息后，汇总上报；
3.2、省厅：负责抽查统计。
4.监察局
监察局是对国土资源执法的整个流程进行监察，对合格的存档，不合格的依法追究相关责任人的责任。
二、用例图
用例是对系统功能的描述。用例图则从用户的角度描述系统功能，并指出各个功能的操作者。
三、活动图
活动图是描述动作以及动作之间关系的。活动图和状态图有着很多相似之处：状态图描述的是一个特定对象的所有可能状态以及引起状态转换的事件；活动图是状态图的变种，活动图主要描述的是动作及动作的结果。活动图的动作转换代表信息的流动。
从上面的两幅活动图中，可以看出这个系统动作及动作之间的关系。
一个初态：表示动作的起点。可以由投诉人举报投诉发起，也可以由国土资源局相关部门自查发起。
两个终态：验收不通过进而依法追究相关责任人责任对应一个终态；验收通过进而存档对应一个终态。
四、小结
这次课程报告遇到的最大问题就是对整个国土资源执法监察流程非常陌生，感觉以后在职场中程序员会经常碰到这种问题，即对开发软件所处的行业背景不了解，这是就需要不断学习，通过不同渠道获取信息增长知识。这次报告我在网上查找了些资料，但很多都不切合题意，于是我对现有资料进行归纳总结，然后结合自己的理解完成了需求分析。
建立用例模型是很关键的，在这个环节上我首先是寻找行为者：投诉人、国土资源局、政府、监察局；然后确定各个行为者对系统功能的要求，从而寻找到用例；最后确定各个用例之间的关系，由于系统较为复杂，我就没有细分用例。
建立用例图之后，感觉建立活动图就有方向了。只需找出一个对象所处的状态以及引起状态变换的事件，准确的说是描述动作及动作的结果，给出信息流动的方向。
下面谈谈我对《软件工程》这门课的总结。大学前三年主要做的就是编程，准确说是拿到问题后选择算法直接动手编程，由于程序总的规模较小（实际自己编写的代码没有超过2000行的），所以还是能完成题目的要求。步入职场后，我们遇到的问题往往是一个大型软件的研发，这时盲目动手编程很可能顾此失彼、事倍功半。软件是程序、数据及相关文档的完整集合。其中文档编写是现阶段我比较忽略的环节，文档是开发、使用、维护程序的重要图文资料，对于理解用户需求、设计软件很重要。软件是有生命周期的，大体可分为软件定义、软件开发、运行维护3个阶段，每个阶段又可以细分。软件研发是有法可循的：结构化设计方法学与面向对象方法学，其中面向对象的思想比较适合大型软件的研发。UML是其中书写软件蓝图的标准语言，具有可视化、规范化、文档化的特点。UML设计遵循模块化、分层化、分区话、可扩展、可重用的原则。
国土资源执法监察管理信息系统的用户需求以及面向对象建模。
分析题目，可知软件的的重点不是国土资源的执法本身，而是对执法进行监察， 主要工作有各级各部门开展核查、整改查处、督查、验收和存档，另外还应能处理群众即投诉人的举报投诉。涉及的有关部门总的有投诉人、国土资源局、政府、监察局；而国土资源局里的分工比较明确，可以进一步划分为地籍科、规划科、用地科（利用科）、耕保科、监察科（在国土资源局内部也有相应的监察科）；政府也可以按等级进行细分，大体有市政府、省厅。
经过查阅相关资料后明确了有关部门的职责，归纳如下：
1.投诉人
举报投诉
此部门是该系统中很重要的部门，主要职责为核查。关于核查又可以细分为不同具体工作。
2.1地籍科：负责对卫片图斑涉及地块的外业核查和测量结果进行审核
2.2、规划科：负责对卫片图斑涉及地块的审批权及使用是否符合土地利用总体规划和土地利用年度计划进行审核；
2.3、耕保科：负责基本农田和一般耕地的认定；
2.4、用地科（利用科）：负责对用地是否经过依法批准和依法供地进行审核，并负责合法用地档案的整理；
2.5、监察科：负责对新增建设用地的合法性进行审核，以及对土地违法行为进行查处，负责各种表格的综合统计上报，并对此项工作进行总协调。
3.政府
不同级别政府的工作有所不同。
3.1、市政府：在核查下属单位的提供的信息后，汇总上报；
3.2、省厅：负责抽查统计。
4.监察局
监察局是对国土资源执法的整个流程进行监察，对合格的存档，不合格的依法追究相关责任人的责任。
二、用例图
用例是对系统功能的描述。用例图则从用户的角度描述系统功能，并指出各个功能的操作者。
在上面的需求分析中，不同部门人员对系统的理解是不一样的，他们都只能站在自己的角度使用系统提供给他们的功能，屏蔽相关技术实现，且其他部门的功能对他们来说是透明的。
上面是整个国土资源执法监察管理信息系统总的用例图，在国土资源局、政府这块没有细分。
上面是细分各级国土资源局、政府职责后的用例图，但在国土资源局这块还是没有细分，但系统提供给各部门的功能是显而易见的。
三、活动图
活动图是描述动作以及动作之间关系的。活动图和状态图有着很多相似之处：状态图描述的是一个特定对象的所有可能状态以及引起状态转换的事件；活动图是状态图的变种，活动图主要描述的是动作及动作的结果。活动图的动作转换代表信息的流动。
上面是国土资源执法监察管理信息系统的简化版活动图，从中可以看出动作的起点、终点、泳道等信息。
从上面的两幅活动图中，可以看出这个系统动作及动作之间的关系。
一个初态：表示动作的起点。可以由投诉人举报投诉发起，也可以由国土资源局相关部门自查发起。
两个终态：验收不通过进而依法追究相关责任人责任对应一个终态；验收通过进而存档对应一个终态。
四、小结
这次课程报告遇到的最大问题就是对整个国土资源执法监察流程非常陌生，感觉以后在职场中程序员会经常碰到这种问题，即对开发软件所处的行业背景不了解，这是就需要不断学习，通过不同渠道获取信息增长知识。这次报告我在网上查找了些资料，但很多都不切合题意，于是我对现有资料进行归纳总结，然后结合自己的理解完成了需求分析。
建立用例模型是很关键的，在这个环节上我首先是寻找行为者：投诉人、国土资源局、政府、监察局；然后确定各个行为者对系统功能的要求，从而寻找到用例；最后确定各个用例之间的关系，由于系统较为复杂，我就没有细分用例。
建立用例图之后，感觉建立活动图就有方向了。只需找出一个对象所处的状态以及引起状态变换的事件，准确的说是描述动作及动作的结果，给出信息流动的方向。
下面谈谈我对《软件工程》这门课的总结。大学前三年主要做的就是编程，准确说是拿到问题后选择算法直接动手编程，由于程序总的规模较小（实际自己编写的代码没有超过2000行的），所以还是能完成题目的要求。步入职场后，我们遇到的问题往往是一个大型软件的研发，这时盲目动手编程很可能顾此失彼、事倍功半。软件是程序、数据及相关文档的完整集合。其中文档编写是现阶段我比较忽略的环节，文档是开发、使用、维护程序的重要图文资料，对于理解用户需求、设计软件很重要。软件是有生命周期的，大体可分为软件定义、软件开发、运行维护3个阶段，每个阶段又可以细分。软件研发是有法可循的：结构化设计方法学与面向对象方法学，其中面向对象的思想比较适合大型软件的研发。UML是其中书写软件蓝图的标准语言，具有可视化、规范化、文档化的特点。UML设计遵循模块化、分层化、分区话、可扩展、可重用的原则。
总之，学习了软件工程，对软件开发与运行维护有了新的理解，尤其意识到软件研发不仅仅局限在编码层面。
在次声明，以上是我的软件工程课程设计报告，其中部分参考其他文献，在此表示感谢！
《软件工程》课程报告 —国土资源执法监察管理信息系统建模
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。