广告管理系统
软件工程与UML
大作业
课题:广告管理系统
学号:3158126157
姓名:徐先森
专业班级:网络工程
指导老师:杨财英
【大作业名称】 广告管理系统UML设计
【大作业目的】1.掌握UML建模的基础知识和其应用；
2.熟悉Rational Rose 或Staruml环境及功能,能够设计出完整系统。
【大作业要求】1.对系统功能进行必要的描述；
2.绘制系统的主要模型图；
3.模型图要有说明性文字解释。
【大作业内容】1.广告管理系统的需求分析；
2.广告管理系统UML建模。
【大作业步骤】
功能 |
用例名称 |
概述 |
登录 |
登录 |
根据用户填写的用户名和密码发送连接请求。连接成功后登录数据库，服务器对用户的身份进行验证 |
|
广告管理 |
上架广告 |
填写新增广告信息，向服务器发送上架广告请求，更新数据库广告 |
下架广告 |
向服务器发送删除广告请求，数据库更新广告 |
|
查看推广效果 |
服务器返回推广效果表 |
|
业务管理 |
查看推广效果 |
服务器返回推广效果表 |
筛选广告 |
向服务器发送广告类型进行筛选，返回数据 |
广告管理系统是基于C2C模式的平台，可以理解为目前流行的广告联盟。参与者主要包括广告提供商、站长、app所有者、平台管理员等。
广告提供商主要提供广告、此广告不同于商品，它放在平台上，站长、app所有者会获取广告信息并在自己的网站或者软件上进行推广，推广效果是公开的。平台管理者拥有平台所有权，能对平台进行最高权限管理。
说明:系统参与者主要是广告提供者和用户，广告提供者登录平台后通过平台选择提供、删除广告和查看推广效果。用户则是筛选广告、查看广告推广效果。用户包括了站长和app所有者，这两者分别绑定他们各自的网站或app。平台管理员拥有最高所有权，可对系统进行任何功能性操作。
用例名称：广告管理 |
ID:01 |
简单描述：广告提供者对广告进行管理操作 |
参与者：广告提供者 |
前置条件：登录成功 |
基本事件流：提供者对选择管理操作 |
后置条件：进入上架或下架广告界面 |
附加：无 |
用例名称：上架广告 |
ID:02 |
简单描述：提供者上架广告 |
参与者：广告提供者 |
前置条件：进入广告管理界面 |
基本事件流：提供者上传广告到平台 |
后置条件：更新数据库 |
附加：上架失败 |
用例名称：下架广告 |
ID:03 |
简单描述：广告提供者下架广告 |
参与者：广告提供者 |
前置条件：进入广告管理界面 |
基本事件流：广告提供者删除之前提供的广告 |
后置条件：更新数据库 |
附加：下架失败 |
用例名称：登录 |
ID:004 |
简单描述：用户登录平台 |
参与者：平台管理员、广告提供者、用户、站长、app所有者 |
前置条件：无 |
基本事件流：登录系统 |
后置条件：系统登录成功 |
附加：登录失败 |
用例名称：业务管理 |
ID:05 |
简单描述：用户管理业务 |
参与者：站长或app所有者 |
前置条件：站长或app所有者登录成功 |
基本事件流：站长或app所有者选择查看广告推广效果或筛选广告 |
后置条件：进入广告推广效果或筛选广告界面 |
附加：无 |
用例名称：查看广告推广效果 |
ID:06 |
简单描述：用户查看广告推广效果 |
参与者：用户 |
前置条件：进入业务管理界面 |
基本事件流：显示推广效果 |
后置条件：显示推广效果 |
附加：无 |
用例名称：筛选广告 |
ID:07 |
简单描述：用户筛选广告 |
参与者：用户 |
前置条件：进入业务管理界面 |
基本事件流：从数据库中选择广告 |
后置条件：显示信息 |
附加：筛选信息中未找到 |
说明：用户登录系统输入用户名和密码，用户名和密码传输到数据库和数据库中的数据进行匹配，返回密码正确或错误，正确则进入系统或选择功能，错误重新输入。
说明：广告提供者登录系统后选择上架广告进入上架广告界面，输入广告数据后提交到数据库。
说明：广告提供者登录系统后选择下架广告进入下架广告界面，选择下架的广告后提交到数据库。
说明：广告提供者/用户登录系统后选择查看推广效果，数据库返回数据系统分析后显示推广效果。
说明：用户登录系统后选择筛选广告进入筛选广告界面，用户输入关键字后提交到数据库，数据库返回数据。
说明：开始登录状态，密码和用户名正确则进入登录成功状态后结束，否则登录三次失败结束。
说明：由于上架广告和下架广告是同一种方式进行的，于是把上架和下架广告整合到同一幅图中，
登录成功后选择是上架还是下架广告，上下架广告后选择继续上下架广告或者结束。
说明：用户/广告提供商进入登录界面，系统返回输入用户名和密码，用户输入用户名和密码，提交到系统，系统和数据库匹配，正确则进入下一界面，提示登录成功。
说明：上架广告和下架广告是同一种流程进行的，于是把上架和下架广告整合到同一幅图中，
登录验证成功后选择是上架还是下架广告，提交数据库后返回上下架成功消息。
说明：广告提供者提供登录系统成功后选择查看推广效果，数据库返回数据，系统根据算法生成效果表，反回表到广告提供者。
说明：系统中实体包括平台管理员、广告提供者、用户、app所有者、站长、广告。
平台管理者可以登录、上下架广告、查看推广效果、筛选广告等操作。
用户包括appuser\webuser可以登录、查看推广效果、筛选广告操作。
广告提供者可以执行登录、上下架广告操作。
Appuser、webuser和user是泛化关系
User、AD提供者和平台管理员是泛化关系。
AD提供者对AD是一对多的关系，一个AD提供者可以提供多种广告。
User对AD是多对多的关系，每个User都可以选择多个广告进行推广。
推广效果表和user、广告提供者是一对一的关系，一张表对应一个用户或一个广告提供者。
意外是一种美好的邂逅，本来选者系统时候自信满满以为网上的资料一大堆，没想到网上资料都是千篇一律你copy我的而我是复制别人的。找了好久最后没办法只能自己构思。
最先的想法是流量提供商提供流量接口，用户上系统进行选择各大用户提供的流量接口。用户申请流量接口，流量提供商同意，然后生成账单。等等
不过后来觉得太过抽象有些无法下手有的图没法子画，我实在没有哪个经验和阅历，貌似从来没有过这种系统。
第二个想法是从第一个想法中衍生过来的，简单来说就是关系互相换了一下，流量提供商变成了广告提供者，广告提供者提供广告，用户者是做筛选广告并把广告投放到自己的流量接口。虽然第二个想法和第一个没多大差别，但是我在想到这个系统时候察觉到了这个系统就是一个C2C模式，类似于百度联盟。这样我有了资料可查，有了平台可以借鉴。
在做图过程中因为对许多概念忘了只能参考其他的系统和，因此我还特意去参考了超市管理系统UML图、教务管理系统UML图还有书上的案例。但是由于系统比较简单学生我又并不是十分优秀，因而并不能把这学期所学的东西都尽善尽美的表现出来。比如UML建模关系中组合和聚合关系以及实现关系我都未能表现出来，配置图和组件图也没有画出。
通过此次实验，我对系统的设计有了更清晰的了解：“系统是有许多模块组成的，模块与模块之间存在各种关系”。相信不管以后在学习和生活中这种模块化思想会帮助我完成许多困难的事情。