文章目录
软件设计原则的分类
开闭原则
依赖倒置原则
单一职责原则
接口隔离原则
迪米特法则（最少知道原则）
里氏替换原则
合成/复用原则（组合/复用原则）

软件设计原则的分类

开闭原则
依赖倒置原则
单一职责原则
接口隔离原则
迪米特法则（最少知道原则）
里氏替换原则
合成/复用原则（组合/复用原则）


在设计模式中会有这7中软件设计原则的体现，但是值得注意的是这7钟设计原则在设计模式中的使用是有取舍的，有的可能是完整的体现，也可能是部分地体现设计原则；有的可能使用了，有的可能没有使用等。

软件设计原则的学习应为软件设计模式的学习打好基础

开闭原则
定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
核心思想：用抽象构建框架，用实现扩展细节
优点：提高软件系统的可复用性及可维护性
开闭原则是面向对象最基础的设计原则，它能够帮助我们开发稳定灵活的系统



下面来演示一下:

场景描述：现在要卖“雪花酥”小蛋糕大礼包，雪花酥小蛋糕大礼包的属性有编号，价格，口味。
首先定义一个接口：
package softwaredesign;

public interface ICake {
    Integer getID();
    String getTaste();
    Double getPrice();
}

实现类
package softwaredesign;

public class SnowCake implements ICake {
    private Integer id;
    private String taste;
    private Double price;

    public SnowCake(Integer id, String taste, Double price) {
        this.id = id;
        this.taste = taste;
        this.price = price;
    }

    @Override
    public Integer getID() {
        return this.id;
    }

    @Override
    public String getTaste() {
        return this.taste;
    }

    @Override
    public Double getPrice() {
        return this.price;
    }

    @Override
    public String toString() {
        return "SnowCake{" +
                "id=" + id +
                ", taste='" + taste + '\'' +
                ", price=" + price +
                '}';
    }
}

测试：
package softwaredesign;

public class Test {
    public static void main(String[] args) {
        SnowCake sc = new SnowCake(100,"原味",55.0);
        System.out.println(sc);
    }
}

结果是正常的

转换成UML图：





从类结构图中 很容易类结构的信息
最近618 淘宝也搞活动了雪花酥要进行打8折了。
这个时候的开发要注意了 不要动接口 不要动接口  接口作为契约应该是可靠的，稳定的。
添加一个类
package softwaredesign;

public class SnowCakeDiscount extends SnowCake {
    public SnowCakeDiscount(Integer id, String taste, Double price) {
        super(id, taste, price);
    }

    @Override
    public Integer getID() {
        return super.getID();
    }

    @Override
    public String getTaste() {
        return super.getTaste();
    }

    @Override
    public Double getPrice() {
        return super.getPrice()*0.8;
    }

    @Override
    public String toString() {
        return "SnowCake{" +
                "id=" + super.getID() +
                ", taste='" + super.getTaste()+ '\'' +
                ", price=" + super.getPrice()*0.8 +
                '}';
    }
}

测试
package softwaredesign;

public class Test {
    public static void main(String[] args) {
        SnowCake sc = new SnowCakeDiscount(100,"原味",55.0);
        System.out.println(sc);
    }
}





上述是UML图
依赖倒置原则
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象
抽象不应该依赖细节；细节应该依赖抽象
针对接口编程，不要针对实现编程

注意

每个类都尽量继承自接口或者抽象类(可以继承抽象类实现接口方法)

尽量不要从具体的类派生

尽量不要覆盖其基类的方法

优点：

可以减少类间的耦合性、提高系统稳定性，提高代码可读性和可维护性，可降低修改程序所造成的风险
下面来演示一下:

小明对淘宝上卖的鼠标 和 键盘都比较感兴趣
首先演示一个面向实现编程的例子

Buy类
package softwaredesign;

public class Buy {
    public void buyMouse(){
        System.out.println("小明在买鼠标");
    }
    public void buyKeyboard(){
        System.out.println("小明在买键盘");
    }
}

Test
package softwaredesign;

public class Test {
    public static void main(String[] args) {
       Buy buy = new Buy();
       buy.buyMouse();
       buy.buyKeyboard();
    }
}

假如小明又想买 鼠标垫

在Buy类中添加
public void buyMousePad(){
	System.out.println("小明在买键盘垫");
}

就是妥妥的面向实现编程

这个是与 依赖倒置 原则 是背道而驰的
高层次的模块不应该依赖低层次的模块
下面演示 满足依赖倒置原则的情况

创建一个Things接口
package softwaredesign;

public interface Things {
    void buyThins();
}


继承接口的类:
package softwaredesign;

public class BuyMouse implements Things {
    @Override
    public void buyThins() {
        System.out.println("小明正在买鼠标");
    }
}

package softwaredesign;

public class BuyKeyboard implements Things {
    @Override
    public void buyThins() {
        System.out.println("小明正在买键盘");
    }
}

将继承接口的类联系起来
package softwaredesign;

public class Buy {
    public void buy(Things things){
        things.buyThins();
    }
}

测试
package softwaredesign;

public class Test {
    public static void main(String[] args) {
       Buy b = new Buy();
       b.buy(new BuyMouse());
       b.buy(new BuyKeyboard());
    }
}

打印结果与前面面向实现的结果是一样的
我们看一下类图:



如果有拓展的要买的东西 都和BuyMouse和BuyKeyboard平级了
具体的实现类 Buy类是不需要动的
也就是说我们面向接口编程, 不需要变动实现类
这里的Test测试类 和 Buy类是解耦的




当然也可以通过构造器注入 来进行Buy的实现

没有改动的
package softwaredesign;

public class Buy {
    public void buy(Things things){
        things.buyThins();
    }
}

改动后
package softwaredesign;

public class Buy {
    private Things things;

    public Buy(Things things){
        this.things = things;
    }

    public void buy(){
        things.buyThins();
    }
}


具体的测试
package softwaredesign;

public class Test {
    public static void main(String[] args) {
       Buy b = new Buy(new BuyMouse());
       b.buy();
    }
}

构造器使用方式并不是非常方便  需要拓展的时候 还有new一个出来Buy实现类

在Spring框架中默认的设计模式是 单例模式


之前是构造器方式

现在取消构造器方式 改用Setter方法

修改Buy类
package softwaredesign;

public class Buy {

    private Things things;

    public void setThings(Things things) {
        this.things = things;
    }

    public void buy(){
        things.buyThins();
    }
}


测试
package softwaredesign;

public class Test {
    public static void main(String[] args) {
       Buy b = new Buy();
       b.setThings(new BuyMouse());
       b.buy();
    }
}


看看现在的类图



Buy类不依赖与任何继承Things的类
单一职责原则
定义：不要存在多于一个导致类变更的原因
一个类/接口/方法只负责一项职责
优点：降低类的复杂度、提高类的可读性，提高系统的可维护性、降低变更引起的风险
下面进行演示:

创建一个鸟类  违反单一原则
package softwareDesign;

public class Bird {
    public void mainMoveMode(String birdName){
        if ("变色龙".equals(birdName)){
            System.out.println("变色龙用四肢走");
        }else {
            System.out.println(birdName+"用翅膀飞");
        }
    }
}


测试
package softwareDesign;

public class Test {
    public static void main(String[] args) {
        Bird bird = new Bird();
        bird.mainMoveMode("猫头鹰");
        bird.mainMoveMode("变色龙");
    }
}

假如又要添加新的东西 又要去动Bird类了(因为Bird类负责的职责较多),随着代码的复杂,越动出错的风险越大
改变:
package softwareDesign;

public class FlyBird {
    public void mainMoveMode(String birdName) {
        System.out.println(birdName + "用翅膀飞");
    }
}

package softwareDesign;

public class WalkAnimal {
    public void mainMoveMode(String Name) {
        System.out.println(Name + "用四肢走");
    }
}

package softwareDesign;

public class Test {
    public static void main(String[] args) {
        FlyBird flyBird = new FlyBird();
        WalkAnimal walkAnimal = new WalkAnimal();
        //应用层判断
        flyBird.mainMoveMode("猫头鹰");
        walkAnimal.mainMoveMode("变色龙");
    }
}

我们来看一下类图



当然还有接口 以及 方法的情况

结合上面的示例  这个都很好理解的
接口隔离原则
定义：用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口
一个类对一个类的依赖应该建立在最小的接口上
建立单一接口，不要建立庞大臃肿的接口尽量细化接口，接口中的方法尽量少
尽量细化接口，接口中的方法尽量少
注意适度原则，一定要适度
优点：符合我们常说的高内聚低耦合的设计思想从而使得类具有很好的可读性、可扩展性和可维护性。
比如说 一个接口中定义了eat() fly() swim()

狗继承了这个接口 但是多了一个fly()

猫头鹰记录了这个接口 但是多一个swim()

它们都要空实现
如果要符合接口隔离原则,需要为fly(0 eat()

和 swim() eat() 或者 为fly() eat() swim()分别定义一个接口
但是一定要适度适度  差不多细化就行了 否则会导致接口过多 反而增大开发难度
迪米特法则（最少知道原则）
定义：一个对象应该对其他对象保持最少的了解。又叫最少知道原则
尽量降低类与类之间的耦合
优点：降低类之间的耦合、
这个也是需要适度的!!!
强调只和朋友交流，不和陌生人说话
朋友：

出现在成员变量、方法的输入、输出参数中的类称为成员朋友类，而出现在方法体内部的类不属于朋友类。
演示

不符合迪米特法则的情形:
package softwareDesign;

import java.util.ArrayList;
import java.util.List;

public class Boss {
    public void commandCheckNumber(TeamLeader teamLeader){
        List<Project> list = new ArrayList<>();
        for (int i = 0; i <3 ; i++) {
            list.add(new Project());
        }
        teamLeader.checkNumberOfProject(list);
    }
}

package softwareDesign;

import java.util.List;

public class TeamLeader {
    public void checkNumberOfProject(List<Project> projectList){
        System.out.println("项目数量是: "+projectList.size());
    }
}


package softwareDesign;

public class Project {
}


测试
package softwareDesign;

public class Test {
    public static void main(String[] args) {
        Boss boss = new Boss();
        TeamLeader teamLeader = new TeamLeader();
        boss.commandCheckNumber(teamLeader);
    }
}


我们看看它的类图



从代码中可以分析出

Boss类中 可以跟Project类没有关系的 直接调用TeamLeader就行了
修改:
package softwareDesign;

public class Boss {
    public void commandCheckNumber(TeamLeader teamLeader){
        teamLeader.checkNumberOfProject();
    }
}


package softwareDesign;

import java.util.ArrayList;
import java.util.List;

public class TeamLeader {
    public void checkNumberOfProject(){
        List<Project> list = new ArrayList<>();
        for (int i = 0; i <3 ; i++) {
            list.add(new Project());
        }
        System.out.println("项目数量是: "+list.size());
    }
}


package softwareDesign;

public class Project {
}


测试
package softwareDesign;

public class Test {
    public static void main(String[] args) {
        Boss boss = new Boss();
        TeamLeader teamLeader = new TeamLeader();
        boss.commandCheckNumber(teamLeader);
    }
}


只有 Boss和TeamLeader类 做了改动

下面是类图:


里氏替换原则
定义：

如果对每一个类型为T1的对象o1，都有类型为T2的对象02，使得以T1定义的所有程序P在所有的对象o1都替换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。
定义扩展：

一个软件实体如果适用一个父类的话，那一定适用于其子类，所有引用父类的地方必须能透明地使用其子类的对象，子类对象能够替换父类对象，而程序逻辑不变。
引申意义：子类可以扩展父类的功能，但不能改变父类原有的功能。

◆含义1：子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

◆含义2：子类中可以增加自己特有的方法。
结合"开闭原则"举的例子  可以很容易看出来 前两条的出入
◆含义3：当子类的方法重载父类的方法时，方法的前置条件（即方法的输入/入参）要比父类方法的输入参数更宽松。

◆含义4：当子类的方法实现父类的方法时（重写/重载或实现抽象方法）方法的后置条件（即方法的输出/返回值）要比父类更严格或相等。
它的优点:

◆优点1：约束继承泛滥，开闭原则的一种体现。

◆优点2：加强程序的健壮性，同时变更时也可以做到非常好的兼容性提高程序的维护性、扩展性。降低需求变更时引入的风险。
演示:

Rectangle.java
package softwareDesign;

public class Rectangle {
    private long length;
    private long width;

    public long getLength() {
        return length;
    }

    public long getWidth() {
        return width;
    }

    public void setLength(long length) {
        this.length = length;
    }

    public void setWidth(long width) {
        this.width = width;
    }
}


Squre.java
package softwareDesign;

public class Square extends Rectangle{
    private long sideLength;

    public long getSideLength() {
        return sideLength;
    }

    public void setSideLength(long sideLength) {
        this.sideLength = sideLength;
    }

    @Override
    public long getLength() {
        return getSideLength();
    }

    @Override
    public long getWidth() {
        return getLength();
    }

    @Override
    public void setLength(long length) {
       setSideLength(length);
    }

    @Override
    public void setWidth(long width) {
        setSideLength(width);
    }
}


Test.java
package softwareDesign;

public class Test {
    public static void resize(Rectangle rectangle) {
        while (rectangle.getWidth()<=rectangle.getLength()){
            rectangle.setWidth(rectangle.getWidth()+1);
            System.out.println("width:"+rectangle.getWidth()+" length:"+rectangle.getLength());
        }
        System.out.println("方法结束：width:"+rectangle.getWidth()+" length:"+rectangle.getLength());
    }

    public static void main(String[] args){
        Rectangle rectangle = new Rectangle();
        rectangle.setWidth(10);
        rectangle.setLength(20);
        resize(rectangle);
    }
}

注意测试的是 长方形的实例

如果换成了正方形 那么这个程序将会永久的执行下去 直到溢出

不符合 里氏替换原则
我们可以改进一下:

我们可以创建一个基于长方形和正方形的父类:
package softwareDesign;

public interface QRangle {
    long getWidth();
    long getLength();
}


package softwareDesign;

public class Rectangle implements QRangle{
    private long length;
    private long width;

    public long getLength() {
        return length;
    }

    public long getWidth() {
        return width;
    }

    public void setLength(long length) {
        this.length = length;
    }

    public void setWidth(long width) {
        this.width = width;
    }
}

package softwareDesign;

public class Square implements QRangle{
    private long sideLength;

    public long getSideLength() {
        return sideLength;
    }

    public void setSideLength(long sideLength) {
        this.sideLength = sideLength;
    }

    public long getWidth() {
        return sideLength;
    }

    public long getLength() {
        return sideLength;
    }
}


这样子在测试中 使用之前的方式 会报错 因为他不满足里氏替换原则
合成/复用原则（组合/复用原则）
定义：尽量使用对象组合/聚合，而不是继承关系达到软件复用的目的
聚合has-A和组合contains-A
优点：可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少
不满足的设计
package softwareDesign;

public class DBConnection {
    public String getConnection(){
        return "MySQL数据库连接";
    }
}


package softwareDesign;

public class ProductDao extends DBConnection {
    public void addProduct(){
        String conn = super.getConnection();
        System.out.println("使用"+conn+"增加产品");
    }
}


Test
package softwareDesign;

public class Test {

    public static void main(String[] args){
        ProductDao productDao = new ProductDao();
        productDao.addProduct();
    }
}

UML类图



如果又接入了别的数据库

我们能够直接修改DBConnection类

但是这样违反开闭原则
我们重构一下它 让它在具备扩展能力且不违反开闭原则,还遵守合成/复用原则

抽象类
package softwareDesign;

public abstract class DBConnection {
    public abstract String getConnection();
}


package softwareDesign;

public class MySQLConnection extends DBConnection{
    @Override
    public String getConnection() {
        return "MySQL数据库连接";
    }
}


package softwareDesign;

public class PostgreSQLConnection extends DBConnection {
    @Override
    public String getConnection() {
        return " PostgreSQL数据库连接";
    }
}


package softwareDesign;

public class ProductDao  {
    private DBConnection dbConnection;

    public void setDbConnection(DBConnection dbConnection) {
        this.dbConnection = dbConnection;
    }

    public void addProduct(){
        //通过组合的方式
        String conn =dbConnection.getConnection();
        System.out.println("使用"+conn+"增加产品");
    }
}


测试
package softwareDesign;

public class Test {

    public static void main(String[] args){
        ProductDao productDao = new ProductDao();
        productDao.setDbConnection(new MySQLConnection());
        productDao.addProduct();
    }
}


查看UML图



凡是拓展的都是第二层的平级

软件的需求分析阶段知道系统要“做什么”，而软件设计阶段我们明白的是“怎么做”。
软件的设计分为：总体设计&&详细设计
设计基本原理:


总体设计的任务和过程
总体设计分为：面向数据，面向功能，面向对象的分析


设计原则：独立性，规模，深，宽，入，出。作用域。接口。单入单出。预测（黑盒子）
总体设计图形工具
1.层次图：描述层次结构。
2.HIPO图：在层次图的基础上，把图中除了顶层的方框外都加上编号****基本形式：输入，处理，输出。
3.结构图（SC）：表达程序结构图形的表示方法，反映程序模块间的层次关系和联系。
成分：模块，模块间调用关系，通信，辅助控制符号。
结构图的四中类型：传入，传出，变换，协调
结构图VS数据流图
数据流图反映的是程序中数据流的情况
结构图反映的是程序中控制流的情况
结构图VS程序流程图
Battle1：
结构图着重反映模块间的隶属关系，即调用关系和层次关系。
程序流程图表达程序执行的顺序及执行顺序依赖的条件。
Battle2：
结构图着眼于软件系统的总体结构，不涉及内部细节，只考虑模块作用，以及上下级模块关系
程序流程图表达执行程序的具体算法

面向数据流的设计方法
目标：给出设计软件结构的一个系统化途径。
作用：信息流映射成软件结构。
映射的方法由信息流的类型决定
    信息流的类型分为两类
 1.变换流：信息-->系统-->外换内-->加工-->内换外-->离开。
    变换型系统结构图：输入，变换中心，输出。
 2.事务流：信息-->输入-->处理-->输入类型选动作-->执行
    根据信息流类型，进行不同的分析。
       变换分析：把具有变换流特点的数据流图按预先确定的模式映射成软件结构
       事务分析：设计步骤跟变换分析类似，不同之处是数据流图到软件结构的映射方式不同。事务流映射的软件结构包括一个接收分支和一个发送分支。

软件设计是需求工程的后续阶段，他根据项目所描述的需求（功能需求、性能需求、领域需求、数据需求等）的定义，进行数据设计、体系结构设计、界面设计和过程设计。
软件设计主要解决“如何做”的问题，设计的方案最终会影响软件实现的成败。
一般把软件设计分为概要设计和详细设计两个阶段，包括体系结构设计、界面设计、数据设计和过程设计。
1.概要设计：
也称总体设计，主要任务是基于数据流图和数据字典，确定系统的整体软件结构，划分软件的各个子模块，确定他们之间的关系。概要设计是要完成体系结构设计、数据设计和界面设计。
体系结构设计：
确定各子系统模块间的数据传递与调用关系；
界面设计：
包括与系统交互的人机界面设计，以及模块间、系统与外部系统的接口关系；
数据设计：
包括数据库、数据文件和全局数据结构的定义。
2.详细设计
详细设计的任务就是在概要设计的基础上，具体实现各部分的细节，直至系统的所有的内容都有足够详细的过程描述，使得编码的任务就是将详细设计的内容翻译成代码就可以了。详细设计就是完成过程设计。
3.软件设计的原则
a.分而治之
分而治之用于解决大型、复杂度高的问题时所采用的策略。把大问题划分成若干个小问题，把对一个大问题的求解转换为对若干个小问题的解答，这样极大地降低了问题的复杂度；
b.重用设计模式
重用是指同一事物不做修改或者稍作改动就能多次使用的机制，重用的内容是软件的设计模式；
c.可跟踪性
软甲设计的任务之一就是确定软件各部分间的关系。设计系统结构，就是要确定系统各部分、个模块间的相互调用和控制关系，以便在需要修改模块的时，能掌握与修改模块有关的部分，并正确追溯问题的根源；
d.灵活性
设计的灵活性是指设计具有易修改性。会发生修改是因为：一是用户需求发生改变，二是设计存在缺陷，三是设计需要进化，四是设计利用重用。软件设计的灵活性主要是通过系统描述问题的抽象来实现。
e.一致性
一致性在软件设计方法和过程总都有体现。界面试图的一致性保证了用户体验和对系统的忠诚度。用统一的规则和约束规范模块接口定义，确保编码阶段对接口和数据结构的统一操作，减少数据理解的歧义。
aaa

一.软件设计的定义

定义：对需求分析阶段提出的系统要求，给出具体的软件设计方案，即如何去做。
	
软件设计的概述(1)目标：根据SRS提出的目标，设计出软件的体系结构，接口，数据结构和处理流程并撰写SDS。(2)软件的设计模型
数据设计 ——> 体系结构设计 ——> 接口设计 ——> 过程流程

数据设计：指内部的数据结构，数据存储（数据库或文件）

体系结构设计：物理架构，逻辑架构

接口设计：内部模块之间的接口，外部与人机，其他系统的接口

过程流程：处理流程和算法，并发控制

       3.软件设计的两个阶段

总体设计

详细设计

体系结构具有多样性

(1)模块化

高层模块 ——> 复杂问题 ——> 较小问题

(2)模块化的重要特征：

抽象化：抽出事物的本质特征不考虑细节

信息隐藏：模块所包含的信息不允许其他不需要这些信息的模块访问，独立的模块间仅交流为完成系统功能必须交换的信息。

信息隐藏的作用：提高模块的独立性，便于修改维护

4.设计描述与建模

(1)类图：表示系统中类及类 和类之间的关系，用于对系统的静态结构进行描述。

(2)一个系统中通常有若干个类图：一个类图不一定包含系统中的所有类，一个类也可以出现在多个类图中。

​​​​​​​

UML中属性的语法：[可见性][属性名][：类型][=初值]

类之间的关系
关联：两个类对象之间存在某种语义上的关联
	
聚集：聚合，表示类与类之间是整体与部分的关系
	
泛化：继承
	
依赖和细化
状态图
是一个类对象可能经历的所有历程的模型图

包图
UML为复杂系统建模所提供的模型元素组与管的机制。

包 定义 个名字空 包用于定义一个名字空 间或容器（Container) ，通过包可以把类、用例、组 件等语义联系紧密元素聚集在一起，从而实现从不同 抽象层次、不同角度对系统或子系统进行建模描述， 将对包中的元素作为一个整体对待，并且控制它们的 可视性和存取。

包的表示（1）



包的表示（2）

不同包中的元素可以同名，但是同一包中的模 型元素不能同名。

包的模型元素前可以有可视性标志，其表示方法与 类中的属性和操作的可视性表示 类中的属性和操作的可视性表示一样。

F ＋，对于输入该包的任何包的模型元素都可见 F

－，对于外包不可见 F

＃，只对其子包可见

包的联系：

依赖，输入依赖

输入和输出，泛化

构件图
构件图用来描述代码构件的物理结构及各个构件之间的物理关系。

构件的作用：

构件是定义了良好接口的物理实现单元，它是系统中可替换的部分。每个构件体现了系统设计中特定类的实现。良好定义的构件不直接依赖于其他构件而依赖于构件所支持的接口。

 

部署图
部署视图描述位于节点实例上的运行构件实例的安排。

 

体系结构设计
体系结构：一个系统的高层次的组织结构，表现为系统的组件、组件之间的相互关系、组件与环境之间的相互关系以及设计和进化的原理。

 

体系结构模式：根据软件设计开发经验总结出来，且命名的，针对某类型软件具有通用性和推广价值的设计方案某一类型软件具有通用性和推广价值的设计方案。

UML架构：“4+1”视图

包括4种架构：

逻辑：软件逻辑单元（函数、类）的组成及其关系。

MVC架构

进程：系统运行时进程(线程)的构成及其控制。与系统性能有关。

开发：软件物理单元（动态库、文件、可执行程序、程序包）的成组及其关系。与软件开发管理及程序员有关。

物理：系统的网络拓扑结构系统的网络拓扑结构、硬件构成以及软件的部署方案。与系统工程师规划部署方案有 关。该架构又称为系统架构(System Arch.)

人机交互设计
1.交互设计是关于创建新的用户体验的问题，目的 在于增强和扩充人们的工作、通信及交互方式， 使他们能够更加有效地进行日常工作和学习。

2.设计流程

交互设计： 生成产品原型 线框图——>视觉设计： 生成产品模型 效果图——>

SS/HTML： 生成产品DEMO

界面设计原则
合理组织内容

简化表单，突出重点

清晰的浏览线

考虑用户场景 ，保证主流程顺畅

选择合适的标签对齐方式

提供必要的帮助

智能默认

帮助用户探索和尝试

允许用户犯错误

使界面符合用户的使用习惯

减少用户在使用软件时出现错误...

界面开发
典型事件：窗口创建、打开、关闭、销毁，以及其他界面 元素触发的事件。

业务逻辑层设计
领域模型：领域模型是对真实世界中概念类的表示，而不是软 件对象的表示。它不是用来描述软件类、软件架构领 域 有责件象 层或 职责软件对象的一组图。
	
领域模型用一套类图来表示，这些类没有操作。
领域模型可以显示：领域对象或者概念类；概念类之间的关联；概念类的属性。

数据存储设计
1.设计范围： l

业务数据在内存中的管理组织；业务数据在外存中的存储结构。

内存数据管理与组织：
自定义数据结构； l

开发语言内建的数据结构：

外存数据管理组织
存储方案：文件 VS. 数据库

文件优缺点 ：l

安装部署不需要其他软件支持； l

易于作为网络数据交换格式； l

不利于数据的并发访问与共享

数据库 l

实现数据共享 ；减少数据的冗余度 ；数据的独立性：独立于具体应用。数据实现集中控制：数据安全性、一致性和可靠性：①安全性控制；②完整性控制：③并发控制。故障恢复：备份恢复机制。