1. 怎样进行设计？
首先，我们要明确设计要做什么？大家都知道需求分析是问题域的定义（WHAT），而设计是解决域的定义（HOW），他们之间的关系应该是继承的，所有HOW的定义必须是针对相应的WHAT来的，使用软件开发领域的概念解决WHAT提出的问题，譬如需求分析中分析出客户对GUI的要求是：能够随时改变界面显示的样式，那么在设计中就要针对这个问题提出解决方案：采用WEB 开发语言HTML中CSS来解决。譬如客户需求：多个异地用户可以同时使用，并且能简易安装，那么设计中提出的解决方案就是采取B/S 框架，使用中间件解决。所以大家在此一定要明白：第一，设计是有的放矢的，那个的就是需求；第二，需求是唯一的，而设计不是唯一的，也就是同一个问题可能有多个解决方案，我们只要选取其中一个有效方案就可以；第三，有些需求的定义可能就是使用HOW的方法来定义的，这时必须遵循需求的定义；第四，设计的目的最终是为了用计算机领域概念实现（也就是代码或者工程），必需并且只需做到实现者能明白设计的解决方案就可以，设计细化的粒度完全依赖前者和计划分配的时间。
      下面，我们讲设计的具体实现方法。
      设计一般分为概要设计（TOP DESIGN）和详细设计（DETAIL DESIGN），他们之间是
继承和并列的。
      概要设计主要针对需求分析中的步骤一的项（全景描述）和步骤三的项（接口定义），而详细设计主要针对需求分析中的步骤二和步骤四，当然步骤四也可以放在概要设计中，这些没有明确的界限，根据你项目的计划和资源进行调整。
  概要设计主要是设计整个系统采取什么样的框架来完成，经常拿软件设计和建筑设计类比，概要设计就是整个建筑的框架，它是针对外部视图的，从系统外部者来看，整个系统是怎样的；而详细设计则是针对内部视图的，从系统内部来看，每个框架中的布局是怎么实现的。
    概要设计以系统本身作为一个对象进行分析，研究这个对象和其它对象的关系以及这个对象内部的组成，包括系统架构设计（组件图 Component Diagram），接口设计（外部接口和内部接口），概念模型设计以及数据定义
      系统架构设计是指系统包含了哪些子系统，他们是怎么组成这个系统的（系统框架），以及每个子系统采取了什么框架。（子系统框架）
      在需求分析中我们讲到子系统之间的划分和关系，他们是独立（左右结构）或者依赖（上下结构）的，因此整个系统框架也就是这样建立起来，这可以类比成建设一个城堡，城堡东西部分（左右结构），每部分都有N层（上下结构），而且我们要定义城堡的建筑风格，这样大致的一个城堡图纸就设计出来了。
  这些子系统的划分最终原则还是基于客户的需求。
  在这里我们先熟悉和应用一些软件的标准框架，就像建筑设计者要了解建筑中比较通用的框架设计一样，这些标准框架是前辈们总结出来的，是可以解决很多框架问题的，如果你要在框架上有什么创新的话，那当然受欢迎，但前提是你已经非常熟练的应用过很多框架。
    软件领域中每天都提出新的框架，如JAVA 的MVC框架，J2EE框架（其中小的一些框架EJB,SPRING+HIBERNATE,STRUSTS框架等），如MS的MFC架构(Document/View架构)，.NET Framework，还有一些ACE的架构，中间件架构等，大家都要去了解和掌握，他们这些框架是解决什么问题的，有什么优缺点，实际应用怎样配置等。现在大家都在谈的SOA，面向服务的架构(WEB SERVICE)，实际上就是N-Tire架构的具体化。
参照《OOAD & UML V2.ppt》的P43
      架构的设计还是需要根据具体业务领域来架设的，多去了解业务领域的知识以及软件领域的架构，看是否能匹配到一起。
    接口设计包括外部接口设计和内部接口设计，外部接口设计包括系统和外在一切使用者的接口，常有的是GUI，系统软件接口和系统硬件接口。内部接口就是定义各个子系统之间的接口
    GUI的设计包括页面的美工布局和内容的设计，美工的设计就不在讨论，它也有自身的规律，对于内容的设计可以用面向对象的方法来完成，每个界面实际就是一个对象，它和其它界面（对象）的接口是什么（譬如采取POST,GET还是SESSION,TRANSACTION传递参数），每个对象的元素有哪些（实际上是每个对象的数据），设计的原则为客户操作直观，简便和美观。
  系统硬件接口在这里不讨论，因为公司目前还未涉及。
  系统软件接口的设计主要包括接口通讯的协议，之间传递的消息，以及这些消息组成的命令原语。
  外部软件接口设计建议：1）采用业内比较通用的通讯协议，这样系统的可扩展性比较强 2）消息的设计要考虑到计算机通讯接口处理的能力，包括网络带宽，接口处理能力以及网络丢包异常情况 3）原语的设计要易于扩展和修改
  内部子系统的接口设计参照外部软件接口设计，由于是内部的接口，因此考虑复用性更多一些
  概念模型设计实际上为详细设计中类图的设计打下基础，同时也是为后面的spring framework是什么框架的数据模型设计打下基础，把系统中重要的概念组建起来形成一个基本模型，并且定义概念之间的关系，这个关系一旦建立，则大的类图以及协作图就基本形成。概念模型设计是基于需求分析中的所有USE CASE的概念，定义USECASE的涉及的概念的总关系图。
  数据定义系统中所有相关的数据模型，也就是我们经常说的数据字典的定义。它是从概念模型（E-R）转化而来，一般遵循下面的原则：（请参照数据库设计资料）
1） 一个实体集转换为关系模型中的一个关系，实体的属性就是关系的属性，实体的码就是关系的码，关系的结构时关系模式。
2）一个1：1联系可以转换为一个独立的关系，也可以与任意一端实体集所对应的关系合并。如果将1：1联系转换为一个独立的关系，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，且每个实体的码均是该关系的候选码。如果将1：1联系与某一端实体所对应的关系合并，则需要在被合并关系中增加属性，其新增的属性为联系本身的属性和与联系相关的另一个实体的码。
3）实体间的1：n联系可以有两种转换方法：一种方法是将联系转换为一个独立的关系，其关系的属性由与该联系相连的各实体集的码一击联系本身的属性组成，而该关系的码为n端实体的码；另一种方法是在n端实体集中增加新属性，新属性由联系对应的1端实体集的码和联系自身的属性构成，新增属性后原关系的码不变。
4）一个m：n联系转换为一个关系：与该联系相连的各实体集的码以及联系本省的属性均转换为关系的属性，新关系的码为两个相连实体码的组合
概要设计就完成了。概要设计的各个步骤是可以并发完成。
详细设计是针对每个功能，转化成具体的类图，时序图等，让代码书写者能够使用具体的语
言表达。 在详细设计中最为困难的就是分配任务到具体的对象，在这之前我们实际上已经完成了大的框架设计，具体的概念模型设计（大致的类图），而详细设计就是把具体的每个功能让具体的类去实现，在分配过程中有很多具体的方法。这在《OOAD & UML V2.ppt》中P53-P85有详细的描述。
建议大家在书写详细设计时，按照子系统，分配到USE CASE一个个分析，对于重复覆盖的USECASE只要设计一次。这样详细设计的任务是可以并发完成的。
在详细设计中我们必须定义出具体的类以及它的属性和方法，那么详细设计就是围绕怎么分析类，定义类的操作（分配任务）和属性，而且这些类本身有什么特点（持久性,安全性）。
我们系统的类有三种：实体类（Entity），控制类（事务类Session），边界类（消息类 Message），在PPT里就是围绕如何创建这三种类展开的，并且讲述了一些需要注意的细节，大家在做详细设计的时候可以不断参考。
相对来讲，我们拿到系统需求分析和概要设计之后，可以定义80％左右的对象了，还有20％就是我们在详细设计中要发现的，譬如实体类的不断分解和组合，控制类的细化（使架构更
加合理），边界类的细化等。只有在每个子系统功能的详细设计中才能不断修改。（修改的原因是让系统更加容易修改和扩展）
有了这些类之后，我们就要定义类的操作（方法）和属性。
同样，80％的任务分配还是比较明显的，我们明确的知道哪些操作应该分配给谁，还有一些是不明确的，希望大家参考《APPLYING UML AND PATTERNS》 Craig larman，这本书详细的描述了GRAP(general responsibility assignment software patterns) 慢慢体会分配比较好的原则。也可以参照《OOAD & UML V1.ppt》里面有一些重要说明
总之，一个完美的设计是要花费很多心思的，建议参照23Patterns，它可以覆盖一般的应用了，但是不要强硬的套用，以系统简洁易修改，代码开发人员能简单开发为原则，避免认为的把系统复杂化。
在设计中还需要强调复用和减少代码人员的重复工作，如果一个设计让代码人员经常做一些重复的事情，那设计可以说是失败的。如果一旦发现类似的代码要进行Copy & Paste操作，设计人员就要对系统设计进行优化。
分析和设计是让实现更加简单，更加富有直观和逻辑性，但是同时它肯定是大大的提高效率的，否则分析和设计就变得毫无意义。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。