一、项目需求
-
模拟实现一个ATM + 购物商城程序
实现功能如下：
-
额度 15000或自定义
-
实现购物商城，买东西加入 购物车，调用信用卡接口结账
-
可以提现，手续费5%
-
支持多账户登录
-
支持账户间转账
-
记录每月日常消费流水
-
提供还款接口
-
ATM记录操作日志
-
提供管理接口，包括添加账户、用户额度，冻结账户等。
-
用户认证用装饰器
二、开发软件的公司, 客户, 用户三者之间的关系
-
开发软件的公司: 帮甲方开发软件.
-
客户: 指的是某些服务行业的客户, 需要找人开发某些软件(甲方)
-
用户: 甲方的软件已经开始上线，提供给我们(用户)使用。
三、 一个项目是如何从无到有的？
1.需求分析
1-1.需求分析流程
-
拿到项目。会先在客户那里一起讨论需求商量项目的功能是否实现。周期与价格得到一个需求文档。
-
最后在公司的内部需要开一次会议，最终得到一个开发文档，交给不同岗位的程序员进行开发。 python: 后端开发, 爬虫 不同的岗位:
-
UI界面设计: 设计软件的布局会分布软件的外观，切成一张张图片交给前端。
-
前端: 拿到ui交给他的图片，然后去搭建网页，设计一些页面中哪些位置需要接收数据进行，需要进行数据交互。
-
后端: 直接核心的业务逻辑调度数据库进行数据的增删查改。
-
测试: 会给代码进行全面测试，比如压力测试界面测试。
-
运维: 部署项目。
-
1-2 需求文档分析示例
-
额度15000或自定义
-
注册功能。(注册完毕以后用户有15000默认的额度): 用户只有注册了以后才有额度，用户注册了以后，我们还可以给用户设定默认的额度15000.
-
-
实现购物商城，买东西加入 购物车，调用信用卡接口结账
-
购物功能: 用户进入购物功能, 首先要打印购物的列表，清单，有什么东西可以购物，还有物品的价格, 以及物品的个数。用户需要买东西。用户选择完东西。对比用户的余额，用户可以可不可以买? 余额够不够？用户购买成功以后放入购物车并保存到用户的个人信息中。 支付功能: 用户购完物需要付钱，付款的钱要从用户的余额里面去扣。
-
-
可以提现，手续费5%
-
提现功能: 用户可以提现，但是会收取手续费这里涉及到了计算用户提现手续费.
-
-
支持多账户登录
-
登录功能: 支持多账户，由注册功能体现，因为注册所以会有多个用户的账户信息。当用户登录以后，我们保存用户当前的状态。就是说用户暂时登陆以后不需要再输入验证。
-
-
支持账户间转账
-
转账功能: 用户提供转账, 首先看用户有没有这个人, 如果没有那不能转，如果有那么得看用户的余额，用户的余额够不够用用户的余额不够。那么他转就不能转。用户转账成功, 接着我们要跑到收钱的那个用户，我们要定位到收钱的用户，然后对收钱的用户进行加钱。对转钱的当前自己进行减钱。
-
-
记录每月日常消费流水
-
记录消费流水功能(设置金额): 记录用户每个月的消费流水, 以月为单位时间进行划分。统计用户购物支付的钱, 购物的清单, 个数, 统计用户提现, 转账的钱.
-
-
提供还款接口
-
还款功能: 对当前用户的余额, 进行增加操作。
-
-
ATM记录操作日志
-
日志功能: 对用户登录以后的所有的操作进行记录。
-
-
提供管理接口，包括添加账户、用户额度，冻结账户等
-
管理员功能: 管理员可以添加账户。管理员可以设置用户的信用额度。管理员可以可以冻结用户账户。
-
-
用户认证用装饰器
-
登录认证装置器: 控制对于用户没有登录之前，操作功能都不能执行。
-
1-3. 提取功能
提取出来的功能
-
注册功能
-
登录功能
-
购物功能
-
支付功能
-
提现功能
-
转账功能
-
还款功能
-
日志功能
-
管理员功能 (添加账户、用户额度，冻结账户)
-
登录认证装饰器
-
记录消费流水功能
提供给用户“选择与操作”的功能
-
注册
-
登录
-
购物
-
提现
-
还款
-
转账
-
查看金额
-
查看购物车
-
查看消费流水
-
管理员功能
提供给”管理员”的功能
-
修改用户额度
-
添加账户
-
冻结账户(以时间作为冻结的依据)
2.软件架构的设计
2-1. 程序设计的好处。
-
思路清晰
-
不会出现写一半代码是推翻重写。
-
方便自己或以后的同事更好维护。
2-2. 三层架构设计的好处
-
把每个功能都分成三部分，逻辑清晰。
-
如果用户更换不同的用户界面或不同的数据存储机制都不会影响接口层的核心逻辑代码。扩展性强。
-
可以在接口层，准确的记录日志与流水。
2-3. 三层架构
注意: 如果没有软件的架构时期到了后期你想进行维护或者扩展功能可能会很难扩展和维护
三层架构:
-
用户视图层: 用户视图层是展示给用户看的，用户视图层展示相关功能给用户看的，接收用户输入的内容，比如用户通过注册功能，输入用户名和密码，用户视图层也可以校验简单的逻辑，比如用户注册时两次输入的密码是否一致；(前端)
-
逻辑接口层: 所有核心逻辑都放在接口中。提供给用户视图层来使用的。接收视图层传过来的用户名拿到第三层去做校验。
-
数据处理层: 接收接口层。传过来的参数。返回相应的数据给接口层或者保存数据。主要做一些数据的增删查改。
1.用户注册时，用户视图层接收用户输入的内容并传给逻辑接口层，接口层接收到数据传递给数据处理层，如果用户已存在，则返回该用户对应的信息，否则返回 None，逻辑接口层拿到数据处理返回的数据，进行 判断，如果接收到的是用户信息已存在，则告诉视图层，该用户已存在，否则继续注册。 2.用户登录时，用户视图层接收用户输入的内容并传给逻辑接口层，接口层接收到数据传递给数据处理层，如果用户已存在，则返回该用户对应的信息，否则返回 None，逻辑接口层拿到数据处理返回的数据，进行判断，如果接收到的是用户信息，则进行比对用户密码是否一致，然后将结果返回用户视图层 # 接受接口层传递过来的参数，做数据的 - 保存数据 save() - 查看数据 select() - 更新数据 - 删除数据
三层架构图：
3.分任务开发
分任务开发: 多个同步协同去开发项目, 实现高效开发项目。
4.测试
手动测试. 自动化测试。(使用自动化脚本测试)
5.上线运行
四、目录结构
ATM/
|
├── bin
| |
│ └──start.py (提示: 这里的start.py有两种放置的方法，一种是放到bin目录下。一种放到ATM这个文件夹下面。放到ATM这个文件夹下面。好处是不需要在当前文件中处理添加环境变量的问题, 也就是当我们调用别的目录下的模块功能的时候不会发生找不到到模块路径的问题。)
├── conf
│ └── settings.py
├── view
│ ├── main.py
| └── admin_file.py
├── db
│ ├── user_data(用户与管理员之间的差距就在于"is_admin"是否为True, 普通用户默认为False)
│ ├── shop_date(用于存放商品, 每个不同类别的商品都是一个单独的文件)
| └── db_hanlder.py
├── api
│ ├── admin.py
│ ├── user.py
│ ├── shop.py
│ ├── bank.py
├── lib
│ ├── common.py
├── log
│ ├── ATM.log
├── README.md