项目需求不断地变
6月12日老板的新想法，真的妙，我要把它发扬光大！商品库存预警的智能分析
顾客好坏的自动判断
界面操作的原则：简单、直观、易用、功能强（要用微软那套"猴子实验系统"了^_^）。
报警系统，类似闹钟一样，要联系整个系统各个环节，包括：进销存，会员管理。。。。。，另外还可以个性化。
posted @ 2006-08-08 11:07 何维雍 阅读(100) 评论(1) 编辑
公告
商品库存预警的智能分析
我们的新项目，美容院管理
2006年4月初定需求一、基本设计思路：
经过了解，心意美容院连锁管理软件是要达成以现有的单店的基础上，加开一家店面，实现客户消费的同步管理的目标
根据目前在广州市能提供的网络接入方式和整体费用的考量，基本是考虑采用以下思路：
使用一台公网服务器为数据端
每个店面使用MODEM或者宽带连接数据端，达到数据共享和同步操作
会员持有注册会员卡，采用预付费方式
二、基本功能设计：
1、 会员系统
实现所有会员的持卡管理，以及忘记带会员卡时可以根据基本注册资料实现临时的无卡管理；
会员卡的冲值管理；
遗失会员卡时可以补办、锁定等安全管理；
持会员卡随时可以查询消费记录和修改相关资料等。
2、 商品管理
实现实物商品和服务项目的分别管理和整合管理；
商品的库存管理；
商品的定价管理；
商品缺货报警功能，可以定义按数量、时间间隔等初始化条件的库存报警。
3、 员工管理
员工卡的注册和注销；
根据单一店面的员工考勤管理；
与销售系统整合的员工业绩统计。
4、 销售管理
根据商品原始定价和会员定价整合的销售系统；
持卡销售和现金消费整合；
数据流的整合。
5、汇总统计
公司销售记录（按各种方式查询和统计）；
打印系统；
员工管理整合的业绩统计。
6、 系统设置
公司或店面资料的设置；
系统本身的各项设置；
会员和员工的安全和级别管理；
整体安全系统。
三、关键流程基本描述
1、 销售流程
购买产品或服务→销售→员工刷卡开启销售→是否会员判定→销售记录→出单→销售完毕
2、 商品管理
商品入库：
判定商品类别→分类入库→数量判别与输入→详细信息或照片等资料输入→多项商品重复输入→操作人刷卡记录→入库完毕
商品定价：
按商品类别定义商品原始定价
3、 会员管理
会员登记管理：
按会员卡设定登记定义商品折扣等信息
会员注册：
填写会员资料→设定会员登记→开卡→会员输入密码→冲值→注册完毕
会员注销：
会员刷卡→输入密码→选择注销→是否退款→取消会员卡记录→注销完毕
4、 软件安装和设置
软件安装→定义数据库信息→输入初始激活密码→定义公司或店面资料→基本安装完毕
posted @ 2006-08-08 10:57 何维雍 阅读(292) 评论(2) 编辑
高薪聘请UI软件美工
公司：广州方华企业管理咨询公司网站：www.gzFanghua.com
|
工作地点: |
广州 | 月薪： | 面议 |
| 学历要求： | 大专及以上 | 外语语种要求： | 英语 |
| 专业要求： | 工艺美术类 | 性别要求： | 不限 |
| 工作经验： | 一年以上 | 年龄要求： | 22岁至40岁 |
招聘要求：
1、具有优秀的策划创意思维、较强的审美观和美术设计功底，善于色彩搭配并精通相关工具软件，如Photoshop, Illustrator,CorelDRAW ,flash等各类设计软件；
2、美工设计、艺术设计或广告设计等专业院校毕业，具有一年以上软件界面设计相关工作经验。
注：无软件界面设计经验者，请勿投简历。
3、个性积极，沟通能力良好；能够承受工作压力，动作迅速；能够按时完成设计项目；
4、面试请携带近期作品，或提供自己制作的网站链接；
5、请注明薪酬要求。
6、能够理解软件原型设计原理；
7、对产品功能，用户需求等有良好理念，对软件界面的色彩，整体风格，图标设计有良好的感觉；对不同需求、应用有灵活的艺术表现力；
8：有编程经验优先考虑。
9：兼职或全职
工作职责：
(1)负责软件或网站产品的视觉规划和视觉风格设计，美工、图片制作等工作
(2)规划用户体验，编写用户体验文档；
(3)设计产品说明书
(4)产品包装设计
有意者，可先将个人详细简历以及部分可具代表性的相关应聘作品发到公司邮箱: mail@gzfanghua.cn
请注明应聘职位.
posted @ 2006-07-19 15:48 何维雍 阅读(189) 评论(0) 编辑
类设计原则
1. 开闭原则（the Open Closed Principle OCP）一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向对象设计的方法，是软件工程设计方法的重要原则之一。
我们以收音机的例子为例，讲述面向对象的开闭原则。我们收听节目时需要打开收音机电源，对准电台频率和进行音量调节。但是对于不同的收音机，实现这三个步骤的细节往往有所不同。比如自动收缩电台的收音机和按钮式收缩在操作细节上并不相同。因此，我们不太可能针对每种不同类型的收音机通过一个收音机类来实现（通过重载）这些不同的操作方式。但是我们可以定义一个收音机接口，提供开机、关机、增加频率、降低频率、增加音量、降低音量六个抽象方法。不同的收音机继承并实现这六个抽象方法。这样新增收音机类型不会影响其它原有的收音机类型，收音机类型扩展极为方便。此外，已存在的收音机类型在修改其操作方法时也不会影响到其它类型的收音机。
2. 替换原则 (the Liskov Substitution Principle LSP)
子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC (Design by Contract) 的概念推出。
我们以学生为例，夜校生为学生的子类，因此在任何学生可以出现的地方，夜校生均可出现。这个例子有些牵强，一个能够反映这个原则的例子时圆和椭圆，圆是椭圆的一个特殊子类。因此任何出现椭圆的地方，圆均可以出现。但反过来就可能行不通。
3. 依赖原则 (the Dependency Inversion Principle DIP)
在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。
在结构化设计中，我们可以看到底层的模块是对高层抽象模块的实现（高层抽象模块通过调用底层模块），这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化方法的一个"硬伤"。
面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。
为此，我们在进行业务设计时，应尽量在接口或抽象类中定义业务方法的原型，并通过具体的实现类（子类）来实现该业务方法，业务方法内容的修改将不会影响到运行时业务方法的调用。
4. 接口分离原则（the Interface Segregation Principle ISP）
采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。
ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植性将大打折扣。
这个原则的本质相当简单。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。
posted @ 2006-05-03 12:57 何维雍 阅读(620) 评论(2) 编辑
