精华内容
下载资源
问答
  • 架构设计 例子和实践 系统设计说明书(架构、概要、详细)目录结构演进架构中的领域驱动设计Web架构设计经验分享软件架构设计从MVC框架看MVC架构的设计领域驱动设计(Domain Driven Design)参考架构详解关于垂直切分...

    架构设计 例子和实践 系统设计说明书(架构、概要、详细)目录结构演进架构中的领域驱动设计Web架构设计经验分享软件架构设计从MVC框架看MVC架构的设计领域驱动设计(Domain Driven Design)参考架构详解关于垂直切分Vertical Sharding的粒度企业应用集成与开源ESB产品ServiceMix和Mule介绍论基于数据访问的集合类(Data Access Based Collection)和领域事件(Domain Event)模式关于系统异常设计的再思考前车之覆,后车之鉴——开源项目经验谈软件的架构与设计模式之什么是架构OO系统设计师之路–设计模型系列(1)–软件架构和软件框架

    系统设计说明书(架构、概要、详细)目录结构

    虽然这些文档一般来说公司都是有模板的,但我写这些文档以来基本上是每写一次就把目录结构给改一次,应该说这是因为自己对这些文档的理解开始加深,慢慢的越来越明白这些文档的作用和其中需要阐述的东西,觉得这三份文档主要阐述了一个系统的设计和实现过程,从系统分解为层次、层次内的模块以及相互的接口、模块分解为对象以及对象的接口、实现这些对象接口的方法。这次又整了一份,^_^,欢迎大家指正。

    XXX架构设计说明书

    (架构设计重点在于将系统分层并产生层次内的模块、阐明模块之间的关系)

    一.  概述

    描述本文的参考依据、资料以及大概内容。

    二.  目的

    描述本文编写的目的。

    三.  架构设计

    阐明进行架构设计的总体原则,如对问题域的分析方法。

    3.1.       架构分析

    对场景以及问题域进行分析,构成系统的架构级设计,阐明对于系统的分层思想。

    3.2.       设计思想

    阐明进行架构设计的思想,可参考一些架构设计的模式,需结合当前系统的实际情况而定。

    3.3.       架构体系

    根据架构分析和设计思想产生系统的架构图,并对架构图进行描述,说明分层的原因、层次的职责,并根据架构图绘制系统的物理部署图,描述系统的部署体系。

    3.4.       模块划分

    根据架构图进行模块的划分并阐明模块划分的理由,绘制模块物理图以及模块依赖图。

    3.4.1.       模块描述

    根据模块物理图描述各模块的职责,并声明其对其他模块的接口要求。。

    3.4.2.       模块接口设计

    对模块接口进行设计,并提供一定的伪代码。

    XXX概要设计说明书

    (概要设计重点在于将模块分解为对象并阐明对象之间的关系)

    一.  概述

    描述本文的参考依据、资料以及大概内容。

    二.  目的

    描述本文的编写目的。

    三.  模块概要设计

    引用架构设计说明书中的模块图,并阐述对于模块进行设计的大致思路。

    3.1.       设计思想

    阐明概要设计的思想,概要设计的思想通常是涉及设计模式的。

    3.2.       模块A

    3.2.1.       概要设计

    根据该模块的职责对模块进行概要设计(分解模块为对象、描述对象的职责以及声明对象之间的接口),绘制模块的对象图、对象间的依赖图以及模块主要功能的序列图,分别加以描述并相应的描述模块异常的处理方法。

    3.2.2.       模块接口实现

    阐明对于架构设计中定义的模块接口的实现的设计。

    XXX详细设计说明书

    (详细设计重点在于对模块进行实现,将模块的对象分解为属性和方法,并阐述如何实现)

    一.  概述

    阐述本文的参考依据、资料以及大概内容。

    二.  目的

    阐述本文的编写目的。

    三.  模块详细设计

    3.1.       设计思想

    阐述对模块进行详细设计的思想。

    3.2.       模块A

    3.2.1.       详细设计

    根据模块概要设计详细描述对于模块内对象的实现,包括对象的职责、属性、方法、对象内功能的流程图、对象关联的类、对象的异常。(需要绘制的主要为类图)

    在大型的项目中是有必要分开的…. 
    架构解决系统核心用例以及关键性需求的设计,形成抽象的基础结构,划分模块、形成模块接口. 
    概要解决模块以及模块接口的实现,形成模块中核心对象以及对象的接口定义..

    详细解决模块中具体对象的实现以及对象接口的实现

    演进架构中的领域驱动设计

    原文链接:http://www.infoq.com/cn/articles/ddd-evolving-architecture

    作者Mat Wall and Nik Silver译者王丽娟发布于2009年9月21日
    上午11时9分

    社区
    Architecture,
    Java
    主题
    设计,
    面向对象设计,
    建模
    标签
    Hibernate,
    领域驱动设计

    领域驱动设计能非常容易地应用于稳定领域,其中的关键活动适合开发人员对用户脑海中的内容进行记录和建模。但在领域本身不断变化和发展的情况下,领域驱动设计变得更具有挑战性。这在敏捷项目中很普遍,在业务本身试图演进的时候也会发生。本文分析了在反思、重建guardian.co.uk这一为期两年的计划背景下我们是如何利用DDD的。我们展示了如何确保在软件架构中反映最终用户演变的认知,以及怎样实现该架构来保证以后的变化。我们提供了模型中重要项目过程、具体演进步骤的细节。

    顶层标题:

    1. 计划背景
    2. 从DDD开始
    3. 增量计划中的DDD过程
    4. 进化的领域模型
    5. 代码级别的演进
    6. 演进架构中DDD的一些教训
    7. 附录:具体示例

    1. 计划背景

    Guardian.co.uk有相当长的新闻、评论、特性历史记录,目前已拥有超过1800万的独立用户和每月1.8亿的页面访问量。在此期间的大部分时间,网站都运行在原始的Java技术之上,但在2006年2月开始了一项重要的工作计划——将网站移植到一个更现代的平台上去,计划的最初阶段于2006年11月推出,当时推出了具有新外观的旅游网站,接着在2007年5月推出新的主页,之后相继推出了更多内容。尽管在2006年2月仅有少数几个人在做这项工作,但后来团队最多曾达到了104人。

    然而,计划的动机远不止是要一个新外观。多年的经验告诉我们有更好的办法来组织我们的内容,有更好的方式将我们的内容商业化,以及在此背后,还有更先进的开发方法——这才是关键之所在。

    其实,我们考虑工作的方式已超越了我们软件可以处理的内容。这就是为什么DDD对我们来说如此有价值。

    遗留软件中阻碍我们的概念不匹配有两个方面,我们先简单看一下这两方面问题,首先是我们的内部使用者,其次是我们的开发人员。这些问题都需要借助DDD予以解决。

    1.1. 内部使用者的问题

    新闻业是一个古老的行业,有既定的培训、资格和职制,但对新闻方面训练有素的新编辑来说,加入我们的行列并使用Web工具有效地工作是不可能的,尤其在刚来的几个月里。要成为一个高效的使用者,了解我们CMS和网站的关键概念还远远不够,还需要了解它们是如何实现的。

    比如说,将缓存内容的概念(这应该完全是系统内部的技术优化)暴露给编辑人员;编辑们要将内容放置在缓存中以确保内容已准备好,还需要理解缓存工作流以用CMS工具诊断和解决问题。这显然是对编辑人员不合理的要求。

    1.2. 开发人员的问题

    概念上的不匹配也体现在技术方面。举例来说,CMS有一个概念是“制品”,这完全是所有开发人员每天工作的核心。以前团队中的一个人坦言,在足足九个月之后他才认识到这些“制品”其实就是网页。围绕“制品”形成的含义模糊的语言和软件越来越多,这些东西让他工作的真正性质变得晦涩难懂。

    再举一个例子,生成我们内容的RSS订阅特别耗时。尽管各个版块的主页都包含一个清晰的列表,里面有主要内容和附加内容,但底层软件并不能对两者予以区分。因此,从页面抽取RSS订阅的逻辑是混乱的,比如“在页面上获取每个条目,如果它的布局宽大约一半儿、长度比平均长度长一些,那它可能是主要内容,这样我们就能抽取链接、将其作为一个订阅”。

    很显然,对我们来说,人们对他们工作(开始、网页和RSS订阅)及其如何实现(缓存工作流、“制品”、混乱逻辑)的认识之间的分歧给我们的效益造成了明显而惨重的影响。

    2. 从DDD开始

    本部分阐述了我们使用DDD的场景:为什么选择它,它在系统架构中所处的位置,还有最初的领域模型。在后面的章节中,我们会看一下如何把最初的领域知识传播给扩充的团队,如何演进模型,以及如何以此为中心来演进我们的编码技术。

    2.1. 选择DDD

    DDD所倡导的首要方面就是统一一致的语言,以及在代码中直接体现用户自己的概念。这能有效地解决前面提及的概念上的不匹配问题。单独看来,这是一个有价值的见解,但其本身价值或许并不比“正确使用面向对象技术”多很多。

    使其深入的是DDD引入的技术语言和概念:实体、值对象、服务、资源库等。这确保了在处理非常大的项目时,我们的大型开发团队有可能一致地进行开发——长远来看,这对维护质量是必不可少的。甚至在废弃我们更底层的代码时(我们稍后会进行演示),统一的技术语言能让我们恢复到过去、改进代码质量。

    2.2. 在系统中嵌入领域模型

    本节显示了DDD在整个系统架构中的地位。

    我们的系统逐渐建立了三个主要的组件:渲染应用的用户界面网站;面向编辑、用于创建和管理内容的应用程序;跟系统交互数据的供稿系统。这些应用都是基于Spring和Hibernate构建的Java Web应用,并使用Velocity作为我们的模板语言。

    我们可以看下这些应用的布局:

    Hibernate层提供数据访问,使用EHCache作为Hibernate的二级缓存。模型层包含领域对象和资源库,服务则处于其上一层。在此之上,我们有Velocity模板层,它提供页面渲染逻辑。最顶层则包含控制器,是应用的入口点。

    看一下这个应用的分层架构,仅仅将模型当做是应用的一个自包含的层是很有意思的。这个想法大致正确,但模型层和其它层之间还是有一些细微的差别:由于我们使用领域驱动设计,所以我们需要统一语言,不仅要在我们谈论领域时使用,还要在应用的任何地方使用。模型层的存在不仅是为了从渲染逻辑中分离业务逻辑,还要为使用的其它层提供词汇表。

    另外,模型层可作为代码的独立单元进行构建,而且可以作为JAR包导入到依赖于它的许多应用中。其它任何层则不是这样。对构建和发布应用来说,这意味着:在我们基础设施的模型层改变代码一定是跨所有应用的全局变化。我们可以在前端的网站中改变Velocity模板,只用部署前端应用就可以,管理系统或供稿系统则不用。如果我们在领域模型中改变了一个对象的逻辑,我们必须更新所有依赖于模型的应用,因为我们只有(而且期望只有)一个领域视图。

    这有一种危害,就是领域建模的这种方法可能会导致单一模型,如果业务领域非常庞大,改变起来的代价会非常昂贵。我们认识到了这一点,因此随着领域不断增长,我们必须确保该层没有变得太过笨重。目前,虽然领域层也是相当庞大和复杂的,但是这还没有带来什么问题。在敏捷环境中工作,我们希望无论如何每两周都要推出所有系统的最新变化。但我们持续关注着该层代码改变的成本。如果成本上升到不能接受的程度,我们可能会考虑将单一模型细分成多个更小的模型,并在每个子模型之间给出适配层。但是我们在项目开始时没有这样做,我们更偏向于单一模型的简单性,而不是用多个模型时必须解决的更为复杂的依赖管理问题。

    2.3. 早期的领域建模

    在项目初期,大家在键盘上动手开始编写代码之前,我们就决定让开发人员、QA、BA、业务人员在同一个房间里一起工作,以便项目能够持续。在这个阶段我们有一个由业务人员和技术人员组成的小型团队,而且我们只要求有一个稳妥的初次发布。这确保了我们的模型和过程都相当简单。

    我们的首要目标是让编辑(我们业务代表的关键组成部分)就项目最初迭代的期望有一个清楚的认识。我们跟编辑们坐在一起,就像一个整体团队一样,用英语与他们交流想法,允许各个功能的代表对这些想法提出质疑和澄清,直到他们认为我们正确理解了编辑需要的内容。

    我们的编辑认为,项目初期优先级最高的功能是系统能生成网页,这些网页能显示文章和文章分类系统。

    他们最初的需求可归纳为:

    • 我们应该能将一篇文章和任何给定的URL关联起来。
    • 我们要能改变选定的不同模板渲染结果页面的方式。
    • 为了管理,我们要将内容纳入宽泛的版面,也就是新闻、体育、旅游。
    • 系统必须能显示一个页面,该页面包含指向特定分类中所有文章的链接。

    我们的编辑需要一种非常灵活的方式来对文章进行分类。他们采用了基于关键字的方法。每个关键字定义了一个与内容相关的主题。每篇文章可以和很多关键字关联,因为一篇文章可以有很多主题。

    我们网站有很多编辑,每个人负责不同版块的内容。每个版块都要求有自己导航和特有关键字的所有权。

    从编辑使用的语言来看,我们似乎在领域中引入了一些关键实体:

    • 页面 URL的拥有者。负责选择模板来渲染内容。
    • 模板 页面布局,任何时候都有可能改变。技术人员将每个模板实现为磁盘上的一个Velocity文件。
    • 版块 页面更宽泛的分类。每个版块有一个编辑,还有对其中页面共同的感官。新闻、旅游和商业都是版块的例子。
    • 关键字 描述存在于版块中主题的方式。关键字过去用于文章分类,现在则驱动自动导航。这样它们将与某个页面关联,关于给定主题所有文章的自动页面也能生成。
    • 文章 我们能发布给用户的一段文本内容。

    提取这些信息后,我们开始对领域建模。项目早期做出的一个决定:编辑拥有领域模型并负责设计,技术团队则提供协助。对过去不习惯这种技术设计的编辑来说,这是相当大的转变。我们发现,通过召开由编辑、开发人员、技术架构师组成的研习会,我们能用简单、技术含量较低的方法勾画出领域模型,并对它持续演进。讨论模型的范围,使用钢笔、档案卡和Blu-Tak绘制备选解决方案。每个候选模型都会进行讨论,技术团队把设计中的每个细节含义告诉给编辑。

    尽管过程在最初相当缓慢,但很有趣。编辑发现这非常容易上手;他们能信手拈来、提出对象,然后及时从开发人员那里获得反馈,以知道生成的模型是否满足了他们的需求。对于编辑们能在过程中迅速掌握技术的要领,技术人员都感到很惊喜,而且所有人都对生成的系统是否能满足客户需求很有信心。

    观察领域语言的演变也很有趣。有时文章对象会被说成是“故事”。显然对于同一实体的多个名称,我们并没有一种统一语言,这是一个问题。是我们的编辑发现他们描述事物时没有使用统一的语言,也是他们决心称该对象为文章。后来,任何时间有人说“故事”,就会有人说:“你的意思不是文章吗?”在设计统一语言时,持续、公共的改进过程是种很强大的力量。

    我们的编辑最初设计生成的模型是这样的:

    [网页及其版块之间的关系由应用于文章的关键字导出,文章是网页中的核心内容。网页的版块由应用于文章的首个关键字的版块确定。]

    由于并非所有的团队成员都参与了该过程的所有阶段,所以我们需要向他们介绍工作进展,并将这些全部展现在了墙上。然后开发人员开始了敏捷开发之旅,而且由于编辑和开发人员、BA、QA都在一起工作,任何有关模型及其意图的问题都能在开发过程的任何时候获得第一手的可靠信息。

    经过几次迭代之后系统初具形态,我们还建立工具来创建和管理关键字、文章和页面。随着这些内容的创建,编辑们很快掌握了它们,并且给出了一些修改建议。大家普遍认为这一简单的关键模型能正常运行,而且可以继续下去、形成网站初次发布的基础。

    3. 增量计划中的DDD过程

    首次发布之后,我们的项目团队伴随着技术人员和业务代表们的成长,一起取得了进步,打算演进领域模型。很显然,我们需要一种有组织的方式来为领域模型引入新的内容、进行系统的演进。

    3.1. 新员工入门

    DDD是入门过程中的核心部分。非技术人员在整个项目生命周期内都会加入项目,因为工作计划是横跨各个编辑领域的,反过来,在恰当的时机我们也会引入版面编辑。技术人员很容易就能加入项目,因为我们持续不断地雇用新员工。

    我们的入门过程包括针对这两类人的DDD讲习,尽管细节不同,但高层次的议题涵盖两个相同的部分:DDD是什么,它为什么重要;领域模型本身的特定范围。

    描述DDD时我们强调的最重要的内容有:

    • 领域模型归业务代表所有。这就要从业务代表的头脑里抽象概念,并将这些概念嵌入到软件中,而不能从软件的角度思考,并试图影响业务代表。
    • 技术团队是关键的利益相关者。我们将围绕具体细节据理力争。

    覆盖领域模型的特定范围本身就很重要,因为它予以就任者处理项目中特定问题的真正工具。我们的领域模型中有几十个对象,所以我们只关注于高级别和更为明显的少数几个,在我们的情况中就是本文所讨论的各种内容和关键字概念。在这里我们做了三件事:

    • 我们在白板上画出了概念及其关系,因此我们能给出系统如何工作的一个有形的表示。
    • 我们确保每位编辑当场解释大量的领域模型,以强调领域模型不属于技术团队所有这一事实。
    • 我们解释一些为了达到这一点而做出的历史变迁,所以就任者可以理解(a)这不是一成不变的,而是多变的,(b)为了进一步开发模型,他们可以在即将进行的对话中扮演什么样的角色。

    3.2. 规划中的DDD

    入门是必不可少的,不过在开始计划每次迭代的时候,知识才真正得以实践。

    3.2.1 使用统一语言

    DDD强制使用的统一语言使得业务人员、技术人员和设计师能围坐在一起规划并确定具体任务的优先次序。这意味着有很多会议与业务人员有关,他们更接近技术人员,也更加了解技术过程。有一位同事,她先担任项目的编辑助理,然后成长为关键的决策者;她解释说,在迭代启动会议上她亲自去看技术人员怎样判断和(激烈地)评估任务,开始更多地意识到功能和努力之间的平衡。如果她不和技术团队共用一种语言,她就不会一直出席会议,也不会收获那些认识。

    在规划阶段利用DDD时我们使用的两个重要原则是:

    1. 领域模型归属于业务;
    2. 领域模型需要一个权威的业务源。

    领域模型的业务所有权在入门中就进行了解释,但在这里才发挥作用。这意味着技术团队的关键角色是聆听并理解,而不是解释什么可能、什么不可能。需求抽象要求将概念性的领域模型映射到具体的功能需求上,并在存在不匹配的地方对业务代表提出异议或进行询问。接着,存在不匹配的地方要么改变领域模型,要么在更高层次上解决功能需求(“你想用此功能达成什么效果?”)。

    对领域模型来说,权威的业务源是我们组织的性质所明确需要的。我们正在构建一个独立的软件平台,它需要满足很多编辑团队的需求,编辑团队不一定以同样的方式来看世界。Guardian不实行许多公司实行的“命令和控制”结构;编辑台则有很多自由,也能以他们认为合适的方式去开发自己的网站版面,并设定预期的读者。因此,不同的编辑对领域模型会有略微不同的理解和观点,这有可能会破坏单一的统一语言。我们的解决办法是确定并加入业务代表,他们在整个编辑台都有责任。对我们来说,这是生产团队,是那些处理日常构建版面、指定布局等技术细节的人。他们是文字编辑依赖的超级用户,作为专家工具建议,因此技术团队认为他们是领域模型的持有者,而且他们保证软件中大部分的一致性。他们当然不是唯一的业务代表,但他们是与技术人员保持一致的人员。

    3.2.2 与DDD一起计划的问题

    不幸的是,我们发现了在计划过程中应用DDD特有的挑战,尤其是在持续计划的敏捷环境中。这些问题是:

    1. 本质上讲,我们正在将软件写入新的、不确定商业模式中;
    2. 绑定到一个旧模型;
    3. 业务人员“入乡随俗”。

    我们反过来讨论下这些问题……

    EricEvans撰写关于创建领域模型的文章时,观点是业务代表的脑海中存在着一个模型,该模型需要提取出来;即便他们的模型不明确,他们也明白核心概念,而且这些概念基本上能解释给技术人员。然而在我们的情况中,我们正在改变我们的模型——事实上是在改变我们的业务——但并不知道我们目标的确切细节。(马上我们就会看到这一点的具体例子。)某些想法显而易见,也很早就建立起来了(比如我们会有文章和关键字),但很多并不是这样(引入页面的想法还有一些阻力;关键字如何关联到其它内容则完全是各有各的想法)。我们的教科书并没有提供解决这些问题的指南。不过,敏捷开发原则则可以:

    • 构建最简单的东西。尽管我们无法在早期解决所有的细节,但通常能对构建下一个有用的功能有足够的理解。
    • 频繁发布。通过发布此功能,我们能看到功能如何实际地运转。进一步的调整和进化步骤因此变得最为明显(不可避免,它们往往不是我们所预期的)。
    • 降低变化的成本。利用这些不可避免的调整和进化步骤,减少变化的成本很有必要。对我们来说这包括自动化构建过程和自动化测试等。
    • 经常重构。经过几个演进步骤,我们会看到技术债务累积,这需要予以解决。

    与此相关的是第二个问题:与旧模型有太多的精神联系。比如说,我们的遗留系统要求编辑和制作人员单独安排页面布局,而新系统的愿景则是基于关键字自动生成页面。在新系统里,Guantánamo Bay页面无需任何人工干预,许多内容会给出GuantánamoBay关键字,仅简单地凭借这一事实就能显示出来。但结果却是,这只是由技术团队持有的过度机械化的愿景,技术团队希望减少体力劳动和所有页面的持续管理。相比之下,编辑人员高度重视人的洞察力,他们带入过程的不仅有记述新闻,还有展现新闻;对他们来说,为了突出最重要的故事(而不仅仅是最新的),为了用不同的方法和灵敏性(比如9·11和Web
    2.0报导)区别对待不同的主题,个人的布局是很有必要的。

    对这类问题没有放之四海而皆准的解决办法,但我们发现了两个成功的关键:专注于业务问题,而不是技术问题;铭记“创造性冲突”这句话。在这里的例子里,见解有分歧,但双方表达了他们在商业上的动机后,我们就开始在同一个环境里面工作了。该解决方案是创造性的,源于对每个人动机的理解,也因此解决了大家了疑虑。在这种情况下,我们构建了大量的模板,每个都有不同的感觉和影响等,编辑可以从中选择并切换。此外,每个模板的关键区域允许手动选择显示的故事、页面的其余部分自动生成内容(小心不要重复内容),对于该手动区域,如果管理变得繁重,就可以随时关闭,从而使网页完全自动化。

    我们发现的第三个挑战是随着业务人员“入乡随俗”,也就是说他们已深深融入技术且牵涉到了要点,以至于他们会忘记对新使用系统的内部用户来说,系统该是什么样。当业务代表发现跟他们的同事很难沟通事情如何运转,或者很难指出价值有限的功能时,就有危险的信号了。KentBeck在《解析极限编程》第一版中说,现场客户与技术团队直接交互绝不会占用他们很多的时间,通过强调这一点,就可以保证在现场的客户。但我们在与有几十个开发人员、多名BA、多名QA的团队一起工作时,我们发现即使有三个全职的业务代表,有时也是不够的。由于业务人员花费了太多的时间与技术人员在一起,以至他们与同事失去联系成为真正的问题。这些都是人力解决方案带来的人力问题。解决方案是要提供个人备份和支持,让新的业务人员轮流加入团队(可能从助理开始着手进行,逐步成长为关键决策角色),允许代表有时间回归他们自己的核心工作,比如一天、一周等。事实上,这还有一个附加的好处,就是能让更多的业务代表接触到软件开发,还可以传播技巧和经验。

    4. 进化的领域模型

    在本章中,我们看看模型在方案的后期是如何演进的。

    4.1. 演进第一步:超越文章

    首次发布后不久,编辑要求系统能处理更多的内容类型,而非只有文章一类。尽管这对我们来说毫不稀奇,但在我们构建模型的第一个版本时,我们还是明确决定对此不予考虑太多。

    这是个关键点:我们关注整个团队能很好地理解小规模、可管理块中的模型和建模过程,而不是试图预先对整个系统进行架构设计。随着理解的深入或变化,稍后再改变模型并不是个错误。这种做法符合YAGNI编码原则(你不会需要它),因为该做法防止开发人员引入额外的复杂度,因而也能阻止Bug的引入。它还能让整个团队安排时间去对系统中很小的一块达成共识。我们认为,今天产出一个可工作的无Bug系统要比明天产出一个完美的、包括所有模型的系统更为重要。

    我们的编辑在下一个迭代中要求的内容类型有音频和视频。我们的技术团队和编辑再次坐在一起讨论了领域建模过程。编辑先跟技术团队谈道,音频和视频很显然与文章相似:应该可以将视频或音频放在一个页面上。每个页面只允许有一种内容。视频和音频可以通过关键字分类。关键字可以属于版面。编辑还指明,在以后的迭代中他们会添加更多类型的内容,他们认为现在该是时候去理解我们应该如何随着时间的推移去演进内容模型。

    对我们的开发人员来说,很显然编辑想在语言中明确引入两个新条目:音频和视频。音频、视频和文章有一些共同点:它们都是内容类型,这一点也很明确。我们的编辑并不熟悉继承的概念,所以技术团队可以给编辑讲解继承,以便技术团队能正确表述编辑所看到的模型。

    这里有一个明显的经验:通过利用敏捷开发技术将软件开发过程细分为小的块,我们还能使业务人员的学习曲线变得平滑。久而久之他们能加深对领域建模过程的理解,而不用预先花费大量的时间去学习面向对象设计所有的组件。

    这是我们的编辑根据添加的新内容类型设计的模型。

    这个单一的模型演变是大量更细微的通用语言演进的结果。现在我们有三个外加的词:音频、视频和内容;我们的编辑已经了解了继承,并能在以后的模型迭代中加以利用;对添加新的内容类型,我们也有了以后的扩展策略,并使其对我们的编辑来说是简单的。如果编辑需要一个新的内容类型,而这一新的内容类型与我们已有的内容类型相同、在页面和关键字之间有大致相同的关系,那编辑就能要求开发团队产出一个新的内容类型。作为一个团队,我们正通过逐步生成模型来提高效率,因为我们的编辑不会再详细检查漫长的领域建模过程去添加新的内容类型。

    4.2. 演进第二步:

    由于我们的模型要扩展到包括更多的内容类型,它需要更灵活地去分类。我们开始在领域模型中添加额外的元数据,但编辑的最终意图是什么还不是非常清楚。然而这并不让我们太过担忧,因为我们对元数据进行建模的方法与处理内容的方法一样,将需求细分为可管理的块,将每个添加到我们的领域中。

    我们的编辑想添加的第一个元数据类型是系列这一概念。系列是一组相关的内容,内容则有一个基于时间的隐含顺序。在报纸中有很多系列的例子,也需要将这一概念解释为适用于Web的说法。

    我们对此的初步想法非常简单。我们将系列添加为一个领域对象,它要关联到内容和页面。这个对象将用来聚集与系列关联的内容。如果读者访问了一种内容,该内容属于某个系列,我们就能从页面链接到同一系列中的前一条和后一条内容。我们还能链接到并生成系列索引页面,该页面可以显示系列中的所有内容。

    这里是编辑所设计的系列模型:

    与此同时,我们的编辑正在考虑更多的元数据,他们想让这些元数据与内容关联。目前关键字描述了内容是关于什么的。编辑还要求系统能根据内容的基调对内容进行不同的处理。不同基调的例子有评论、讣告、读者供稿、来信。通过引入基调,我们就可以将其显示给读者,让他们找到类似的内容(其它讣告、评论等)。这像是除关键字或系列外另一种类型的关系。跟系列一样,基调可以附加到一条内容上,也能和页面有关系。

    这里是编辑针对基调设计的模型:

    完成开发后,我们有了一个能根据关键字、系列或基调对内容进行分类的系统。但编辑对达到这一点所需的技术工作量还有一些关注点。他们在我们下次演进模型时向技术团队提出了这些关注点,并能提出解决方案。

    4.3. 演进第三步:重构元数据

    模型的下一步演进是我们的编辑想接着添加类似于系列和基调的内容。我们的编辑想添加带有贡献者的内容这一概念。贡献者是创建内容的人,可能是文章的作者,或者是视频的制作人。跟系列一样,贡献者在系统中有一个页面,该页面会自动聚集贡献者制作的所有内容。

    编辑还看到了另一个问题。他们认为随着系列和基调的引入,他们已经向开发人员指明了大量非常相似的细节。他们要求构建一个工具去创建系列,构建另一个工具去创建基调。他们不得不指明这些对象如何关联到内容和页面上。每次他们都发现,他们在为这两种类型的领域对象指定非常相似的开发任务;这很浪费时间,还是重复的。编辑更加关注于贡献者,还有更多的元数据类型会加入进来。这看起来又要让编辑再次指明、处理大量昂贵的开发工作,所有这些都非常相似。

    这显然成为一个问题。我们的编辑似乎已经发现了模型的一些错误,而开发人员还没有。为什么添加新的元数据对象会如此昂贵呢?为什么他们不得不一遍又一遍地去指定相同的工作呢?我们的编辑问了一个问题,该问题是“这仅仅是‘软件开发如何工作’,还是模型有问题?”技术团队认为编辑熟悉一些事情,因为很显然,他们理解模型的方式与编辑不同。我们与编辑一起召开了另一个领域建模会议,试图找出问题所在。

    在会议上我们的编辑建议,所有已有的元数据类型实际上源于相同的基本思想。所有的元数据对象(关键字、系列、基调和贡献者)可以和内容有多对多的关系,而且它们都需要它们自己的页面。(在先前的模型版本中,我们不得不知道对象和页面之间的关系)。我们重构了模型,引入了一个新的超类——Tag(标签),并作为其它元数据的超类。编辑们很喜欢使用“超类”这一技术术语,将整个重构称为“Super-Tag”,尽管最终也回到了现实。

    由于标签的引入,添加贡献者和其它预期的新元数据类型变得很简单,因为我们能够利用已有的工具功能和框架。

    我们修订后的模型现在看起来是这样的:

    我们的业务代表在以这种方式考虑开发过程和领域模型,发现这一点非常好,还发现领域驱动设计有能力促进在两个方向都起作用的共同理解:我们发现技术团队对我们正努力解决的业务问题有良好且持续的理解,而且出乎意料,业务代表能“洞察”开发过程,还能改变这一过程以更好地满足他们的需求。编辑们现在不仅能将他们的需求翻译为领域模型,还能设计、检查领域模型的重构,以确保重构能与我们目前对业务问题的理解保持同步。

    编辑规划领域模型重构并成功执行它们的能力是我们领域驱动设计guardian.co.uk成功的一个关键点。

    5. 代码级别的演进

    前面我们看了领域模型方面的进化。但DDD在代码级别也有影响,不断变化的业务需求也意味着代码要有变化。现在我们来看看这些变化。

    5.1. 构建模型

    在构建领域模型时,要确认的第一件事就是领域中出现的聚集。聚集可认为是相关对象的集合,这些对象彼此相互引用。这些对象不应该直接引用其它聚集中的其它对象;不同聚集之间的引用应该由根聚集来完成。

    看一下我们在上面定义的模型示例,我们开始看到对象成形。我们有Page和Template对象,它们结合起来能给Web页面提供URL和观感。由于Page是系统的入口点,所以在这里Page就是根聚集。

    我们还有一个聚集Content,它也是根聚集。我们看到Content有Article、Video、Audio等子类型,我们认为这些都是内容的子聚集,核心的Content对象则是根聚集。

    我们还看到形成了另一个聚集。它是元数据对象的集合:Tag、Series、Tone等。这些对象组成了标签聚集,Tag是根聚集。

    Java编程语言提供了理想的方式来对这些聚集进行建模。我们可以使用Java包来对每个聚集进行建模,使用标准的POJO对每个领域对象进行建模。那些不是根聚集、且只在聚集中使用的领域对象可以有包范围内使用的构造函数,以防它们在聚集外被构造。

    上述模型的包结构如下所示(“r2”是我们应用套件的名称):

     com.gu.r2.model.page 
    
     com.gu.r2.model.tag 
    
     com.gu.r2.model.content 
    
     com.gu.r2.model.content.article
    
     com.gu.r2.model.content.video
    
     com.gu.r2.model.content.audio 

    我们将内容聚集细分为多个子包,因为内容对象往往有很多聚集特定的支持类(这里的简化图中没有显示)。所有以标签为基础的对象往往要更为简单,所以我们将它们放在了一个包里,而没有引入额外的复杂性。

    不过不久之后,我们认识到上述包结构会给我们带来问题,我们打算修改它。看看我们前端应用的包结构示例,了解一下我们如何组织控制器,就能阐述清楚这一问题:

     com.gu.r2.frontend.controller.page
    
     com.gu.r2.frontend.controller.articl

    这里看到我们的代码集要开始细分为片段。我们提取了所有的聚集,将其放入包中,但我们没有单独的包去包含与聚集相关的所有对象。这意味着,如果以后领域变得太大而不能作为一个单独的单元来管理,我们希望将应用分解,处理依赖就会有困难。目前这还没有真正带来什么问题,但我们要重构应用,以便不会有太多的跨包依赖。经过改进的结构如下:

     com.gu.r2.page.model   (domain objects in the page aggregate)
    
     com.gu.r2.page.controller (controllers providing access to aggregate)
    
     com.gu.r2.content.article.model
    
     com.gu.r2.content.article.controller
    
     ...
    
     etc

    除了约定,我们在代码集中没有其它任何的领域驱动设计实施原则。创建注解或标记接口来标记聚集根是有可能的,实际上是争取在模型包锁定开发,减少开发人员建模时出错的几率。但实际上并不是用这些机械的强制来保证在整个代码集中都遵循标准约定,而是我们更多地依赖了人力技术,比如结对编程和测试驱动开发。如果我们确实发现已创建的一些内容违反了我们的设计原则(这相当少见),那我们会告诉开发人员并让他完善设计。我们还是喜欢这个轻量级的方法,因为它很少在代码集中引入混乱,反而提升了代码的简单性和可读性。这也意味着我们的开发人员更好地理解了为什么一些内容是按这种方式组织,而不是被迫去简单地做这些事情。

    5.2. 核心DDD概念的演进

    根据领域驱动设计原则创建的应用会具有四种明显的对象类型:实体、值对象、资源库和服务。在本节中,我们将看看应用中的这些例子。

    5.2.1 实体

    实体是那些存在于聚集中并具有标识的对象。并不是所有的实体都是聚集根,但只有实体才能成为聚集根。

    开发人员,尤其是那些使用关系型数据库的开发人员,都很熟悉实体的概念。不过,我们发现这个看似很好理解的概念却有可能引起一些误解。

    这一误解似乎跟使用Hibernate持久化实体有点儿关系。由于我们使用Hibernate,我们一般将实体建模为简单的POJO。每个实体具有属性,这些属性可以利用setter和getter方法进行存取。每个属性都映射到一个XML文件中,定义该属性如何持久化到数据库中。为了创建一个新的持久化实体,开发人员需要创建用于存储的数据库表,创建适当的Hibernate映射文件,还要创建有相关属性的领域对象。由于开发人员要花费一些时间处理持久化机制,他们有时似乎认为实体对象的目的仅仅只是数据的持久化,而不是业务逻辑的执行。等他们后来开始实现业务逻辑时,他们往往在服务对象中实现,而不是在实体对象本身中。

    在下面(简化)的代码片段中可以看出此类错误。我们用一个简单的实体对象来表示一场足球赛:

     public class FootballMatch extends IdBasedDomainObject
    
     { 
    
         private final FootballTeam homeTeam;
    
         private final FootballTeam awayTeam;
    
         private int homeTeamGoalsScored;
    
         private int awayTeamGoalsScored;
    
     
    
         FootballMatch(FootballTeam homeTeam, FootballTeam awayTeam) { 
    
             this.homeTeam = homeTeam; 
    
             this.awayTeam = awayTeam; 
    
         } 
    
     
    
         public FootballTeam getHomeTeam() { 
    
             return homeTeam; 
    
         } 
    
     
    
         public FootballTeam getAwayTeam() { 
    
             return awayTeam; 
    
         } 
    
         public int getHomeTeamScore() { 
    
             return homeTeamScore; 
    
         } 
    
     
    
         public void setHomeTeamScore(int score) { 
    
             this.homeTeamScore = score; 
    
         } 
    
     
    
         public void setAwayTeamScore(int score) { 
    
             this.awayTeamScore = score; 
    
         } 
    
     }

    该实体对象使用FootballTeam实体去对球队进行建模,看起来很像使用Hibernate的开发人员所熟悉的对象类型。该实体的每个属性都持久化到数据库中,尽管从领域驱动设计的角度来说这个细节并不真的重要,我们的开发人员还是将持久化的属性提升到一个高于它们应该在的水平上去。在我们试图从FootballTeam对象计算出谁赢得了比赛的时候这一点就可以显露出来。我们的开发人员要做的事情就是造出另一种所谓的领域对象,就像下面所示:

     public class FootballMatchSummary { 
    
    
    
         public FootballTeam getWinningTeam(FootballMatch footballMatch) { 
    
             if(footballMatch.getHomeTeamScore() >  footballMatch.getAwayTeamScore()) { 
    
                 return footballMatch.getHomeTeam(); 
    
             } 
    
             return footballMatch.getAwayTeam(); 
    
         } 
    
     }

    片刻的思考应该表明已经出现了错误。我们已经创建了一个FootballMatchSummary类,该类存在于领域模型中,但对业务来说它并不意味着什么。它看起来是充当了FootballMatch对象的服务对象,提供了实际上应该存在于FootballMatch领域对象中的功能。引起这一误解的原因好像是开发人员将FootballMatch实体对象简单地看成了是反映数据库中持久化信息,而不是解决所有的业务问题。我们的开发人员将实体考虑为了传统ORM意义上的实体,而不是业务所有和业务定义的领域对象。

    不愿意在领域对象中加入业务逻辑会导致贫血的领域模型,如果不加以制止还会使混乱的服务对象激增——就像我们等会儿看到的一样。作为一个团队,现在我们来检视一下创建的服务对象,看看它们实际上是否包含业务逻辑。我们还有一个严格的规则,就是开发人员不能在模型中创建新的对象类型,这对业务来说并不意味着什么。

    作为团队,我们在项目开始时还被实体对象给弄糊涂了,而且这种困惑也与持久化有关。在我们的应用中,大部分实体与内容有关,而且大部分都被持久化了。但当实体不被持久化,而是在运行时由工厂或资源库创建的话,有时候还是会混淆。

    一个很好的此类例子就是“标签合成的页面”。我们在数据库中持久化了编辑创建的所有页面的外观,但我们可以自动生成从标记组合(比如USA+Economics或Technology+China)聚集内容的页面。由于所有可能的标记组合总数是个天文数字,我们不可能持久化所有的这些页面,但系统还必须能生成页面。在渲染标记组合页面时,我们必须在运行时实例化尚未持久化的新Page实例。项目初期我们倾向于认为这些非持久化对象与“真正的”持久化领域对象不同,也不像在对它们建模时那么认真。从业务观点看,这些自动生成的实体与持久化实体实际上并没有什么不同,因此从领域驱动设计观点来看也是如此。不论它们是否被持久化,对业务来说它们都有同样的定义,都不过是领域对象;没有“真正的”和“不是真正的”领域对象概念。

    5.2.2 值对象

    值对象是实体的属性,它们没有特性标识去指明领域中的内容,但表达了领域中有含义的概念。这些对象很重要,因为它们阐明了统一语言。

    值对象阐述能力的一个例子可以从我们的Page类更详细地看出。系统中任何Page都有两个可能的URLs。一个URL是读者键入Web浏览器以访问内容的公开URL。另一个则是从应用服务器直接提供服务时内容依存的内部URL。我们的Web服务器处理从用户那里传入的URL,并将它转换为适合后端CMS服务器的内部URL。

    一种简化的观点是,在Page类中两个可能的URL都被建模为字符串对象:

     public String getUrl(); 
    
     public String getCmsUrl(); 

    不过,这并没有什么特别的表现力。除了这些方法返回字符串这一事实之外,只看这些方法的签名很难确切地知道它们会返回什么。另外想象一下这种情况,我们想基于页面的URL从一个数据访问对象中加载页面。我们可能会有如下的方法签名:

    public Page loadPage(String url);

    这里需要的URL是哪一个呢?是公开的那个还是CMS URL?不检查该方法的代码是不可能识别出来的。这也很难与业务人员谈论页面的URL。我们指的到底是哪一个呢?在我们的模型中没有表示每种类型URL的对象,因此在我们的词汇里面也就没有相关条目。

    这里还含有更多的问题。我们对内部URL和外部URL可能有不同的验证规则,也希望对它们执行不同的操作。如果我们没有地方放置这个逻辑,那我们怎么正确地封装该逻辑呢?控制URLs的逻辑一定不属于Page,我们也不希望引入更多不必要的服务对象。

    领域驱动设计建议的演进方案是明确地对这些值对象进行建模。我们应该创建表示值对象的简单包装类,以对它们进行分类。如果我们这样做,Page里面的签名就如下所示:

     public Url getUrl();
    
     public CmsPath getCmsPath();

    现在我们可以在应用中安全地传递CmsPath或Url对象,也能用业务代表理解的语言与他们谈论代码。

    5.2.3 资源库

    资源库是存在于聚集中的对象,在抽象任何持久化机制时提供对聚集根对象实体的访问。这些对象由业务问题请求,与领域对象一起响应。

    将资源库看成是类似于有关数据库持久化功能的数据访问对象,而非存在于领域中的业务对象,这一点很不错。但资源库是领域对象:他们响应业务请求。资源库始终与聚集关联,并返回聚集根的实例。如果我们请求一个页面对象,我们会去页面资源库。如果我们请求一个页面对象列表来响应特定的业务问题,我们也会去页面资源库。

    我们发现一个很好的思考资源库的方式,就是把它们看成是数据访问对象集合之上的外观。然后它们就成为业务问题和数据传输对象的结合点,业务问题需要访问特定的聚集,而数据传输对象提供底层功能。

    这里举一小段页面资源库的代码例子,我们来实际看下这个问题:

     private final PageDAO<Page> pageDAO; 
    
     private final PagesRelatedBySectionDAO pagesRelatedBySectionDAO; 
    
    
    
     public PageRepository(PageDAO<Page> pageDAO,
    
             EditorialPagesInThisSectionDAO pagesInThisSectionDAO, 
    
             PagesRelatedBySectionDAO pagesRelatedBySectionDAO) { 
    
         this.pageDAO = pageDAO; 
    
         this.pagesRelatedBySectionDAO = pagesRelatedBySectionDAO;
    
     } 
    
    
    
     public List<Page> getAudioPagesForPodcastSeriesOrderedByPublicationDate(Series series, int maxNumberOfPages) { 
    
         return pageDAO.getAudioPagesForPodcastSeriesOrderedByPublicationDate(series, maxNumberOfPages); 
    
     } 
    
    
    
     public List<Page> getLatestPagesForSection(Section section, int maxResults) {
    
         return pagesRelatedBySectionDAO.getLatestPagesForSection(section, maxResults); 
    
     }

    我们的资源库有业务请求:获取PublicationDate请求的特定播客系列的页面。获取特定版面的最新页面。我们可以看看这里使用的业务领域语言。它不仅仅是一个数据访问对象,它本身就是一个领域对象,跟页面或文章是领域对象一样。

    我们花了一段时间才明白,把资源库看成是领域对象有助于我们克服实现领域模型的技术问题。我们可以在模型中看到,标签和内容是一种双向的多对多关系。我们使用Hibernate作为ORM工具,所以我们对其进行了映射,Tag有如下方法:

    public List<Content> getContent();

    Content有如下方法:

     public List<Tag>  getTags(); 

    尽管这一实现跟我们的编辑看到的一样,是模型的正确表达,但我们有了自己的问题。对开发人员来说,代码可能会编写成下面这样:

     if(someTag.getContent().size() == 0){
    
         ... do some stuff
    
     }

    这里的问题是,如果标签关联有大量的内容(比如“新闻”),我们最终可能会往内存中加载几十万的内容条目,而只是为了看看标记是否包含内容。这显然会引起巨大的网站性能和稳定性问题。

    随着我们演进模型、理解了领域驱动设计,我们意识到有时候我们必须要注重实效:模型的某些遍历可能是危险的,应该予以避免。在这种情况下,我们使用资源库来用安全的方式解决问题,会为系统的性能和稳定性牺牲模型个别的清晰性和纯洁性。

    5.2.4. 服务

    服务是通过编排领域对象交互来处理业务问题执行的对象。我们所理解的服务是随着我们过程演进而演进最多的东西。

    首要问题是,对开发人员来说创建不应该存在的服务相当容易;他们要么在服务中包含了本应存在于领域对象中的领域逻辑,要么扮演了缺失的领域对象角色,而这些领域对象并没有作为模型的一部分去创建。

    项目初期我们开始发现服务开始突然涌现,带着类似于ArticleService的名字。这是什么呀?我们有一个领域对象叫Article;那文章服务的目的是什么?检查代码时,我们发现该类似乎步了前面讨论的FootballMatchSummary的后尘,有类似的模式,包含了本该属于核心领域对象的领域逻辑。

    为了对付这一行为,我们对应用中的所有服务进行了代码评审,并进行重构,将逻辑移到适当的领域对象中。我们还制定了一个新的规则:任何服务对象在其名称中必须包含一个动词。这一简单的规则阻止了开发人员去创建类似于ArticleService的类。取而代之,我们创建ArticlePublishingService和ArticleDeletionService这样的类。推动这一简单的命名规范的确帮助我们将领域逻辑移到了正确的地方,但我们仍要求对服务进行定期的代码评审,以确保我们在正轨上,以及对领域的建模接近于实际的业务观点。

    6. 演进架构中DDD的一些教训

    尽管面临挑战,但我们发现了在不断演进和敏捷的环境中利用DDD的显著优势,此外我们还总结了一些经验教训:

    • 你不必理解整个领域来增加商业价值。你甚至不需要全面的领域驱动设计知识。团队的所有成员差不多都能在他们需要的任何时间内对模型达成一个共同的理解。
    • 随着时间的推移,演进模型和过程是可能的,随着共同理解的提高,纠正以前的错误也是可能的。

    我们系统的完整领域模型要比这里描述的简化版本大很多,而且随着我们业务的扩展在不断变化。在一个大型网站的动态世界里,创新永远发生着;我们始终要保持领先地位并有新的突破,对我们来说,有时很难在第一次就得到正确的模型。事实上,我们的业务代表往往想尝试新的想法和方法。有些人会取得成果,其他人则会失败。是逐步扩展现有领域模型——甚至在现有领域模型不再满足需求时进行重构——的业务能力为guardian.co.uk开发过程中遇到的大部分创新提供了基础。

    7. 附录:具体示例

    为了了解我们的领域模型如何生成真实的结果,这里给出了一个例子,先看单独的内容……

    8. 关于作者

    Nik Silver是Guardian News & Media软件开发总监。他于2003年在公司引入敏捷软件开发,负责软件开发、前端开发和质量保证。Nik偶尔会在blogs.guardian.co.uk/inside上写Guardian技术工作相关的内容,并在他自己的站点niksilver.com上写更宽泛的软件问题。

    Matthew Wall是Guardian News & Media的软件架构师,深入研究敏捷环境下大型Web应用的开发。他目前最关心的是为guardian.co.uk开发下一代的Web平台。他在JAOO、ServerSide、QCon、XTech和OpenTech上做过关于此及相关主题的各种演讲。

    Web架构设计经验分享

    作者:朱燚
    来源:http://www.cnblogs.com/yizhu2000/archive/2007/12/04/982142.html

     

    本人作为一位web工程师,着眼最多之处莫过于 性能与架构,本次幸得参与sd2.0大会,得以与同行广泛交流,于此二方面,有些心得,不敢独享,与众博友分享,本文是这次参会与众同撩交流的心得,有兴趣者可以查看视频

    架构设计的几个心得:


    一,不要过设计:never over design

    这是一个常常被提及的话题,但是只要想想你的架构里有多少功能是根本没有用到,或者最后废弃的,就能明白其重要性了,初涉架构设计,往往倾向于设计大而化一的架构,希望设计出具有无比扩展性,能适应一切需求的增加架构,web开发领域是个非常动态的过程,我们很难预测下个星期的变化,而又需要对变化做出最快最有效的响应。。

    ebay的工程师说过,他们的架构设计从来都不能满足系统的增长,所以他们的系统永远都在推翻重做。请注意,不是ebay架构师的能力有问题,他们设计的架构总是建立旧版本的瓶颈上,希望通过新的架构带来突破,然而新架构带来的突破总是在很短的时间内就被新增需求淹没,于是他们不得不又使用新的架构
    web开发,是个非常敏捷的过程,变化随时都在产生,用户需求千变万化,许多方面偶然性非常高,较之软件开发,希望用一个架构规划以后的所有设计,是不现实的

    二,web架构生命周期:web architecture‘s life cycle

    既然要杜绝过设计,又要保证一定的前瞻性,那么怎么才能找到其中的平衡呢?希望下面的web架构生命周期能够帮到你

    architecture_life_cycle

    所设计的架构需要在1-10倍的增长下,通过简单的增加硬件容量就能够胜任,而在5-10倍的增长期间,请着手下一个版本的架构设计,使之能承受下一个10倍间的增长

    google之所以能够称霸,不完全是因为搜索技术和排序技术有多先进,其实包括baidu和yahoo,所使用的技术现在也已经大同小异,然而,google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的


    三,缓存:Cache

    空间换取时间,缓存永远计算机设计的重中之重,从cpu到io,到处都可以看到缓存的身影,web架构设计重,缓存设计必不可少,关于怎样设计合理的缓存,jbosscache的创始人,淘宝的创始人是这样说的:其实设计web缓存和企业级缓存是非常不同的,企业级缓存偏重于逻辑,而web缓存,简单快速为好。。

    缓存带来的问题是什么?是程序的复杂度上升,因为数据散布在多个进程,所以同步就是一个麻烦的问题,加上集群,复杂度会进一步提高,在实际运用中,采用怎样的同步策略常常需要和业务绑定

    老钱为搜狐设计的帖子设计了链表缓存,这样既可以满足灵活插入的需要,又能够快速阅读,而其他一些大型社区也经常采用类此的结构来优化帖子列表,memcache也是一个常常用到的工具

    钱宏武谈架构设计视频 http://211.100.26.82/CSDN_Live/140/qhw.flv

    Cache的常用的策略是:让数据在内存中,而不是在比较耗时的磁盘上。从这个角度讲,mysql提供的heap引擎(存储方式)也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢?

    我们这里只说到了读缓存,其实还有一种写缓存,在以内容为主的社区里比较少用到,因为这样的社区最主要需要解决的问题是读问题,但是在处理能力低于请求能力时,或者单个希望请求先被缓存形成块,然后批量处理时,写缓存就出现了,在交互性很强的社区设计里我们很容易找到这样的缓存

    四,核心模块一定要自己开发:DIY your core module

    这点我们是深有体会,钱宏武和云风也都有谈到,我们经常倾向于使用一些开源模块,如果不涉及核心模块,确实是可以的,如果涉及,那么就要小心了,因为当访问量达到一定的程度,这些模块往往都有这样那样的问题,当然我们可以把问题归结为对开源的模块不熟悉,但是不管怎样,核心出现问题的时候,不能完全掌握其代码是非常可怕的


    五,合理选择数据存储方式:reasonable data storage

    我们一定要使用数据库吗,不一定,雷鸣告诉我们搜索不一定需要数据库,云风告诉我们,游戏不一定需要数据库,那么什么时候我们才需要数据库呢,为什么不干脆用文件来代替他呢?
    首先我们需要先承认,数据库也是对文件进行操作。我们需要数据库,主要是使用

    展开全文
  • 销售管理系统数据库设计说明书

    千次阅读 2014-11-12 16:58:32
    本文档为北大青鸟ACCP软件工程师培训无锡培训中心 SI50B 班学员,第一学期毕业设计项目(《销售管理系统》)的数据库设计说明书,具体描述《销售管理系统》的数据库的设计,用于指导该系统在数据库存储各方面的内容...

    一、概述

    (一)、数据库设计文档概述

    本文档为北大青鸟ACCP软件工程师培训无锡培训中心 SI50B 班学员,第一学期毕业设计项目(《销售管理系统》)的数据库设计说明书,具体描述《销售管理系统》的数据库的设计,用于指导该系统在数据库存储各方面的内容,作为系统代码设计的基准文档。

    (二)、项目简要介绍

    项目目标软件系统名称:销售管理系统

    项目提出:自命题

    项目目标:利用计算机技术和信息技术实现销售管理的信息化,达到客户管理、合同管理、业务管理的规范有序、信息查阅快速准确、事务处理方便高效的要求,及时跟踪企业营销目标并适时进行结构化分析,为营销策略的修正以及新的营销策略的制定提供依据,通过对提高营销效率与降低营销成本的有效支持,从而改善企业宏观运营,提高企业的经济效益。

    系统模式:采用客户端/服务器模式

    系统开发环境:Visual Basic 6.0

    数据库管理系统:Microsoft SQL Server 2000

    软件开发者:北大青鸟无锡培训中心 SI50B 班学员王章圣

    软件应用范围:中小型企业(生产类)

    (三)、参考资料:

    A、北大青鸟第一学期教材;

    B、《基于软件开发项目的毕业设计》;

    (C、《销售管理系统》需求说明书)

    D、项目指导教师提供的毕业设计案例

    二、数据库外部设计

    (一)本数据库的应用软件及其与数据库的接口

    数据库软件:Microsoft SQL Server 2000

    系统要求建立的数据库名称:Sales

    使用该数据库的应用软件:销售管理系统

    该应用软件在Visual Basic 6.0编程环境下设计,采用Visual Basic 6.0基于Active Data Objects的数据库访问接口技术,建立与数据库的通讯连接、执行T-SQL。应用程序对数据库的操作,在通过执行T-SQL查询语句生成的结果集上执行。

    (二)数据库管理系统

    Microsoft® SQL Server? 2000 扩展了 Microsoft SQL Server 7.0 版的性能、可靠性、质量和易用性。Microsoft SQL Server 2000 增加了几种新的功能,由此成为大规模联机事务处理 (OLTP)、数据仓库和电子商务应用程序的优秀数据库平台。本数据库采取SQL Server 2000作为系统平台。以下是需要使用到SQL Server 2000的几个组件,包括:

    A、企业管理器:提供了数据管理和数据库操作的集成平台;

    B、查询分析器:T-SQL调试、优化、性能检测的工具;

    C、事件探查器:提供了对SQL Server执行操作的检测,并以T-SQL的形式记录;

    D、服务管理器:提供SQL Server停止、启动的控制工具;

    此外,还包括可能会使用到的数据导入和导出工具,为数据库提供数据的输入。

    三、数据库结构设计

    (一)表结构设计

    本数据库包括五类二十三张数据表,清单如下:

    类别

    表索引

    表名

    说明

    产品类

    表一

    Product

    存储公司所有产品目录

    表二

    product_type

    产品类类别:对表一的产品进行分类,并以其进行约束(字典库)

    表三

    Store

    产品出/入库:指检验合同的成品/退货产品,生产过程中的待检品、半成品以及材料等不纳入本系统

    表四

    store_reason

    出/入库理由:字典库

    表五

    product_ qulity

    产品质量:字典库

    表六

    product_Periods

    产品生产周期:主要用于合同评审(字典库)

    表七

    product_profit

    产品利润:通过表九与表一跟踪签约产品的利润实现情况

    客户类

    表八

    client

    客户表:一般指企业(即法人)

    合 同

    订单类

    表九

    Orders

    订单:即将合同细化的产品订单

    表十

    Contract

    合同:即以合同为单位的订单,也可称之为销售记录

    表十一

    contract_mode

    履行方式:字典库

    表十二

    contract_cancel

    已废止/取消的合同:在本库中起字典库作用

    表十三

    contract_talk

    合同评估:字典库

    表十四

    Suddenness

    合同意外处置:当不能完全按照合同的约定履行时,需在此登记,以便对合同与客户进行有效的管理

    表十五

    deal_mode

    意外处置方式:字典库

    表十六

    contract_profit

    合同利润:以合同为统计单位,并扣除各种折扣

    表十七

    contract_verify

    合同评审记录:主体部分

    表十八

    contract_perverify

    合同评审记录:产品细分清单

    营销目标与

    营销人员

    表十九

    Target

    销售目标:企业整体的营销目标,并按产品分解

    表二十

    Seller

    销售员:字典库

    表二一

    Seller_target

    个人目标分解:按产品将企业营销目标分解到业务员,以便跟踪个人业绩

    系统

    用户

    表二二

    userlist

    用户表:用于数据库的操作人员,业务员、客户可通过其口令登录查询

    表二三

    Operate_recorders

    用户操作记录表:写入操作员针对数据库的任何更改,建立责任制,同时也可以用作对操作员考核的原始依据

    以下是各数据表的具体结构及约束等说明:

    表一:Product(产品)

    字段

    类型(长度)

    约束

    说明

    产品编号

    product_id

    Char(10)

    主键

     

    产品名称

    product_name

    Char(20)

    非空

     

    产品大类

    product_type

    tinyint

    外键

    引用表二:type_id

    单位成本

    product_cost

    smallmoney

    根据用户类型决定可否查看

    备  注

    product_menu

    text

     

    相关表:订单、库存(出/入库)、销售计划、销售记录、产品利润、产品生产周期(编号)

    说 明:所有字段均由用户输入(选择产品大类,用户输入不存在的类别时提示添加。)

    (严格地讲,单位成本是变动的,最好单独成表并标注日期,以保存不同时期的“版本”,同时,还需建立报价表,此二表可考虑合并,为减轻项目负担,没有分开。)

    表二:product_type(产品大类)

    字段

    类型(长度)

    约束

    说明

    序号

    type_id

    tinyint

    标识列,主键

     

    产品大类

    type_name

    Char(20)

    非空

    将数据写入产品输入界面的组合框

    相关表:产品(对其实施约束)

    说 明:type_name由用户输入(一般通过修改产品时提示添加)

    表三:Store(产品出/入库)

    字段

    类型(长度)

    约束

    说明

    序  号

    store_id

    int

    标识列,主键

     

    产品编号

    product_id

    char(10)

    外键

    引用表一:product_id

    产品批号

    product_code

    char(10)

    非空

     

    登记方式

    enter _statu

    bit

    非空

    “1”为入存,“0”为出库

    登记数量

    chang_number

    int

    非空/正数

    可与前项合并,以正负区别,但考虑到统计需要,分开。

    质量等级

    store_qulity

    tinyint

    外键

    引用表四:qulity_type

    出/入库日期

    store_date

    datetime

    非空

     

    来源/去向

    store_frorto

    char(20)

    非空

     

    出/入库理由

    store_reason

    char(20)

    非空

    参引表 :reason_type

    库存数量

    store_number

    int

    非空/非负

     

    相关表:产品(产品编号)、产品质量

    说 明:除“序号”、“库存状态”、“库存数量”外均由用户输入(选择日期、理由、质量等级);reason_id不作为本表的外键,从而允许用户输入其他原因,并提示用户规范该字典库(“库存数量”在用户登记时由系统计算并自动填写)。

    表四:product_qulity(产品质量)

    字段

    类型(长度)

    约束

    说明

    序号

    qulity_id

    tinyint

    标识列,主键

    有关属性与产品类别表相似。

    质量等级

    qulity_type

    Char(6)

    非空

    相关表:产品出/入库、定单

    表五:store_reason(出/入库理由)

    字段

    类型(长度)

    约束

    说明

    序号

    reason_id

    tinyint

    标识列,主键

    相关表:产品出/入库

    有关属性与产品类别表相似。

    理由描述

    reason_type

    Char(20)

    非空

    表六:product_Periods(产品生产周期)

    字段

    类型(长度)

    约束

    说明

    序    号

    periods_id

    Tinyint

    标识列,主键

     

    产 品 编 号

    product_id

    Char(10)

    外键

     

    数    量

    product_number

    Int

    非空/正数

     

    一般生产周期

    periods

    smallint

    非空/正数

    以天计

    相关表:产品(编号)

    说 明:均由用户输入,所有在产品都必须在此登记,并作为在产的标志。

    表七:product_profit(产品利润)

    字段

    类型(长度)

    约束

    说明

    产品编号

    product_id

    Char(10)

    外键

    主键

    合同编号

    contract_id

    Char(10)

    外键

    利 润 额

    profit

    Money

     

    利 润 率

    profit_margin

    decimal

     

    相关表:产品(产品编号)、合同(合同编号)

    说 明:根据订单表作相应更新,由系统建立,便于统计。

    表八:client(客户)

    字段

    类型(长度)

    约束

    说明

    客户编号

    client_id

    Char(8)

    主键

     

    客户名

    client_name

    Char(30)

    非空

     

    联系人

    client_person

    Char(10)

    非空

    或称代表人

    联系方式

    client_tel

    Char(15)

    非空

     

    住址

    client_ad

    Varchar(50)

    非空

     

    相关表:合同(客户编号)(通过合同表与产品表建立间接联系,查看客户感兴趣的产品)

    说 明:全部由用户输入(客户编号可考虑由系统建立)

    表九:Orders(订单)

    字段

    类型(长度)

    约束

    说明

    合同编号

    product_id

    Char(10)

    外键

    主键

    产品编号

    contract_id

    Char(10)

    外键

    数  量

    sells_number

    int

    非空/正数

     

    质  量

    contract_ qulity

    tinyint

    外键

    引用表四:qulity_type

    单  价

    per_price

    smallmoney

    非空/正数

     

    相关表:产品(产品编号)、合同(合同编号)、产品质量

    说 明:均由用户输入(多数情况下,与合同表一同更新)

     

    表十:Contract(合同)

    字段

    类型(长度)

    约束

    说明

    合同编号

    contract_id

    Char(10)

    主键

     

    客户编号

    client_id

    Char(8)

    外键

     

    标的额

    sells_totall

    Money

    非空

    >0

    签约折扣

    sign_ discount

    Money

    非空

    非负/默认为“0”

    销售人员编号

    seller_id

    Char(8)

    非空

     

    订立日期

    sign_date

    datetime

    非空

     

    履行日期

    carry_date

    datetime

    非空

     

    履行方式

    carry_mode

    Char(20)

    非空

    参引表 :carry_type

    履行状态

    contract_statu

    Bit

    非空

    “1”为履行完毕,“0”为未完毕(默认)

    履约评估

    contract_talk

    Char(30)

    参引表 :talk_type

    相关表:订单(合同编号)、客户(客户编号)、个人销售记录(销售人员编号)、合同意外处理(合同编号)、履行方式、履约评估

    说 明:合同编号及标的额在订单的输入由系统生成,履行方式可作为本表的一个小备注,如具体时间、地点、提货或是送货等;销售人员项由程序提供名单,供用户选择,用户亦可输入,但不能是数据库之外的——可以以公司名义而不划入任何个人,故此处不将其作为外键,仅查询出来供用户选择;不再履行的合同也视为已经履行(即不再将此合同列入待履行之列)。

    表十一:contract_mode(履行方式)

    字段

    类型(长度)

    约束

    说明

    序号

    carry_id

    tinyint

    标识列,主键

    相关表:合同

    有关属性与产品类别表相似。

    理由描述

    carry_type

    Char(20)

    非空

    表十二:contract_talk(合同评估)

    字段

    类型(长度)

    约束

    说明

    序号

    talk_id

    tinyint

    标识列,主键

    相关表:合同

    有关属性与产品类别表相似。

    具体描述

    talk_type

    Char(20)

    非空

    表十三:contract_cancel(已废止/取消的合同)

    字段

    类型(长度)

    约束

    说明

    合同编号

    contractl_id

    Char(10)

    外键/主键

    相关表:合同

    有关属性与产品类别表相似。

    废止理由

    cancel_type

    Char(20)

    非空

    废止日期

    cancel_date

    datetime

    非空

    表十四:Suddenness(合同意外处置)

    字段

    类型(长度)

    约束

    说明

    合同编号

    contract_id

    Char(10)

    外键

    未使用主键

    日  期

    treatdate

    datetime

    非空

    处置方式

    treatment

    Varchar(50)

    非空/参引十五:deal_mode

    相关表:合同(合同编号)

    说 明:均由用户输入(处置方式如提前、推迟、取消等,通过程序修改合同及相关表格)

    表十五:deal_mode(意外处置方式)

    字段

    类型(长度)

    约束

    说明

    序号

    deal_id

    tinyint

    标识列,主键

    相关表:合同

    有关属性与产品类别表相似。

    处置方式

    deal_mode

    Char(30)

    非空

    表十六:contract_profit(合同利润)

    字段

    类型(长度)

    约束

    说明

    合同编号

    contract_id

    Char(10)

    外键,主键

    在“折扣”项中,如用户以比例形式提交,则在程序中先行计算

    标的总成本

    totall_cost

    money

    非空

    折 扣

    discount

    money

    非空

    利润额

    contract_profit

    money

    利润率

    profit_margin

    decimal

    相关表:合同(合同编号)

    说 明:折扣由用户输入,其余由系统建立。

    表十七:contract_verify(合同评审记录/主体评审)

    字段

    类型(长度)

    约束

    说明

    评审号

    verify_id

    Char(10)

    主  键

    由系统建立

    评审日期

    verify_date

    datetime

    非空

     

    有关评审人员

    verify_persons

    varchar(50)

    非空

     

    客户编号

    client_id

    Char(8)

    非空/外键

     

    业务员编号

    seller_id

    Char(8)

    非空

     

    最低利润率需求

    verify_forprofit

    decimal

    非空/非负

     

    拟履行日期

    verify_carry

    datetime

    非空

     

    标的总额

    verify_allprice

    money

    非空/“0”

    由系统建立

    可能的折扣

    verify_allowdis

    money

    非空/“0”

    可实现的利润总额

    verify_profit

    money

    非空/“0”

    可实现的利润率

    verify_margin

    decimal

    非空/“0”

    生产能力评估

    verify_capacity

    varchar(50)

    系统建议结论

    verify_sysadvice

    varchar(50)

    评审结论

    verify_conclusion

    varchar(50)

    可先登记,再评审

    相关表:产品细分评审(评审号)

    说 明:由于评审并不是一次完成,故允许有关的判断项暂允许为空。

    表十八:contract_perverify(合同评审记录/产品细分评审)

    字段

    类型(长度)

    约束

    说明

    评审号

    verify_id

    Char(10)

    外键

    主键

    产品编号

    product_id

    Char(10)

    外键

    数  量

    verify_number

    int

    非空/正数

     

    单  价

    perverify_price

    smallmoney

    非空/正数

     

    最低利润率需求

    perverify_forprofit

    decimal

    非空/非负

     

    可启动日期

    perverify_ondate

    datetime

    非空

     

    可实现利润

    perverify_profit

    money

    非空/非负

    由系统建立

    可实现利润率

    perverify_margin

    decimal

    非空/非负

    生产能力评估

    perverify_capacity

    varchar(30)

    非空

    系统建议结论

    perverify_syadice

    varchar(30)

    非空

    评审意见

    perverify_conclusion

    varchar(30)

    可先登记,再评审

    相关表:产品(产品编号)、主体评审(评审号)

    说 明:暂不考虑产品质量;新时期产品的数据输入需一次完成,故除“评审意见”外,均不允许为空;

    表十九:Target(销售目标)

    字段

    类型(长度)

    约束

    说明

    产品编号

    product_id

    Char(10)

    外键,主键

     

    本年度销售目标

    target

    money

    非空/正数

     

    相关表:产品(产品编号)

    说 明:产品编号可选择,也可直接输入;工作界面增加产品大类,以方便用户。

    表二十:Seller(销售员)

    字段

    类型(长度)

    约束

    说明

    销售人员编号

    seller_id

    Char(4)

    主键

    新注册时由系统给出提示,超级用户可修改之。

    姓  名

    seller_name

    Char(15)

    非空

     

    登录口令

    seller_pwd

    Char(6)

    非空

     

    状  态

    seller _statu

    bit

    非空

    “1”为有效(默认),“0”为失效

    相关表:个人目标分解表(编号)

    说 明:均由用户输入,口令为标准的六位,不足由系统补足(用户表同)。

    表二一:Seller_target(个人目标分解表)

    字段

    类型(长度)

    约束

    说明

    销售人员编号

    seller_id,

    Char(4)

    外键,主键

     

    产品编号

    product_id

    Char(10)

    外键

     

    个人目标

    per_target

    money

    非空/正数

     

    相关表:销售员(编号)、产品(产品编号)

    说 明:工作界面可增加产品大类,以方便用户

    表二二:userlist(用户表)

    字段

    类型(长度)

    约束

    说明

    用户编号

    user_id

    Char(4)

    主键

    在申请用户时,程序中要求提交用于申请用户的密码,代替管理员的确认(销售人员表同)

    用 户 名

    user_name

    Char(15)

    非空

    密  码

    user_pwd

    Char(6)

    非空

    状  态

    user_statu

    bit

    非空

    “1”为有效(默认),“0”为失效

    相关表:用户操作(编号)

    说 明:均由用户输入(可以考虑增加一张表,对业务员及用户状态中的“失效”作出说明,但这应该属于人力资源管理的范畴,放在此处 可能不太合适!)。

    表二三:Operate_recorders(用户操作记录表)

    字段

    类型(长度)

    约束

    说明

    操作序号

    operate_id

    int

    标识列,主键

     

    用户编号

    user_id

    Char(4)

    外键

     

    记录日期

    operate_date

    datetime

    非空

     

    操作记录

    operate_text

    Char(20)

    非空

     

    相关表:用户表(编号)

    说 明:均由系统(以模块函数方式)建立,以实际变更数据库中的值为标准(即单纯的查看不计)。

    (二)、视图对象设计

    为方便查询与维护,本数据库设计了十六个视图,具体描述如下:

    视图一:produce_view(在产品目录)

    字段名

    来源字段

    来源表

    连接关系及条件、聚合等

    产品编号

    productid

    product_id

    Product

    product_type .type_id = Product.product_type

     

    Product .product_statu = 1

    产品名称

    productname

    product_name

    Product

    产品大类

    typename

    type_name

    product_type

    单位成本

    productcost

    product_cost

    Product

    备  注

    productmenu

    product_menu

    Product

    说 明:以“产品”表为基础,为查询提供方便;对于成本的查看同样需要权限。

    视图二:contract_view(合同)

    字段名

    来源字段

    来源表

    连接关系及条件、聚合等

    合同编号

    contractid

    contract_id

    Contract

    Client. client_id= Contract. client_id

     

    Seller.seller_id= Contract. seller_id

     

    Suddenness.contract_id= Contract.contract_id

    客户编号

    clientid

    contract_id

    Contract

    客户名称

    clientname

    client_name

    client

    标 的 额

    sellstotall

    sells_totall

    Contract

    签约折扣

    signdiscount

    sign_discount

    Contract

    业务员编号

    sellerid

    seller_id

    Contract

    业务员姓名

    sellername

    seller_name

    Seller

    订立日期

    signdate

    sign_date

    Contract

    履行日期

    carrydate

    carry_date

    Contract

    履行方式

    carrymode

    carry_mode

    Contract

    履行状态

    contractstatu

    contract_statu

    Contract

    履约评估

    contracttalk

    contract_talk

    Contract

    日期/意外

    dealdate

    treatdate

    Suddenness

    意外情况

    deal

    treatment

    Suddenness

    说 明:以“合同”表为基础,通过“客户”、“销售员”、“合同意外处置”补充数据。

    视图三:product_sales_view(产品销售情况)

    字段名

    来源字段

    来源表/视图

    连接关系及条件、聚合等

    产品编号

    productid

    product_id

    orders

    orders.contract_id= contract_view.contractid

     

    orders.product_id= product_view.product_id

     

    产品名称

    productname

    product_name

    product_view

    产品类别

    typename

    typename

    product_view

    销售数量

    sellsnumber

    sells_number

    orders

    签约价格

    perprice

    per_price

    orders

    签约质量

    contractqulity

    contract_qulity

    orders

    产品成本

    productcost

    productcost

    product_view

    合同状态

    contractstatu

    contractstatu

    contract_view

    签约日期

    signdate

    sign_date

    product_view

    客户编号

    clientid

    clientid

    product_view

    客户名称

    clientname

    client_name

    product_view

    业务员编号

    sellerid

    sellerid

    product_view

    业务员姓名

    sellername

    seller_name

    product_view

    说 明:以“订单”表为基础,通过“合同”视图与“在产品”视图补充数据。

    视图四:sales_target_view1(销售目标完成情况/宏观、签约、产品)

    字段名

    来源字段

    来源表/视图

    连接关系及条件、聚合等

    产品编号

    productid

    product_id

    target

    produce_view . productid=target.product_id

    product_sales_view . productid = target.product_id

    group by productid,…, contractstatu

    (注:在来源中已能表明关系的,此处不再重复,下同)

    产品名称

    productname

    productname

    produce_view

    产品类别

    typename

    typename

    produce_view

    销售目标

    target

    target

    target

    销售总额

    totallprice

    sellsnumber*perprice

    product_sales_view

    销售数量

    sumnumber

    sum (sellsnumber)

    product_sales_view

    产品均价

    avgprice

    SUM(sellsnumber*perprice)/ SUM(sellsnumber)

    合同份数

    contractnumber

    COUNT(contractid)

    product_sales_view

    合同状态

    contractstatu

    contractstatu

    product_sales_view

    说 明:按产品分组,有汇总;以“营销目标”表为基础,通过“产品销售情况”视图和“在产品”视图补充 数据;“合同状态”作为以后查询的条件依据。

    视图五:sales_target_view2(销售目标完成情况/产品、履行)

    字段名

    来源字段

    来源表/视图

    连接关系及条件、聚合等

    产品编号

    productid

    product_id

    sales_target_view1

    contractstatu=1

     

     

    group by productid,…

    产品名称

    productname

    productname

    产品类别

    typename

    typename

    销售目标

    target

    target

    销售总额

    totallfinish

    SUM(totallprice)

    销售数量

    numberfinish

    SUM(sumnumber)

    合同份数

    contractfinish

    SUM(contractnumber)

    产品均价

    avgfinish

    SUM(totallprice) / SUM(sumnumber)

    视图六:sales_pertarget1_view1(销售目标完成情况/业务员、产品、签约)

    字段名

    来源字段

    来源表/视图

    连接关系及条件、聚合等

    业务员编号

    sellerid

    seller_id

    Seller_target

    produce_view . productid=Seller_target.product_id

     

     product_sales_view . sellerid = Seller_target. seller_id 

     

    group by seller_id,  productid,…, contractstatu

    业务员姓名

    sellername

    sellername

    product_sales_view

    产品编号

    productid

    product_id

    Seller_target

    产品名称

    productname

    productname

    produce_view

    产品类别

    typename

    typename

    produce_view

    个人目标

    pertarget

    per_target

    Seller_target

    销售总额

    sumprice

    sellsnumber*perprice

    product_sales_view

    销售数量

    sumnumber

    sum (sellsnumber)

    product_sales_view

    产品均价

    avgprice

    sum(sellsnumber*perprice)/ sum(sellsnumber)

    合同份数

    contractnumber

    count(contractid)

    product_sales_view

    合同状态

    contractstatu

    contractstatu

    product_sales_view

    说 明:按业务员,产品分组,有汇总;以“个人目标分解”表为基础,按业务员及订单产品分类,以签约为 标准,通过“产品销售情况”视图和“在产品”视图补充数据;“合同状态”作为以后查询的条件依据。

    视图七:sales_pertarget1_view2(销售目标完成情况/业务员、产品、履行)

    字段名

    来源字段

    来源表/视图

    连接关系及条件、聚合等

    业务员编号

    sellerid

    sellerid

    sales_pertarget1_view1

    contractstatu=1

     

     

    group by sellerid ,productid,…

    业务员姓名

    sellername

    sellername

    产品编号

    productid

    product_id

    产品名称

    productname

    productname

    产品类别

    typename

    typename

    个人目标

    pertarget

    pertarget

    销售总额

    totallfinish

    sum(totallprice)

    销售数量

    numberfinish

    sum(sumnumber)

    产品均价

    avgfinish

    sum (totallprice) / sum (sumnumber)

    合同份数

    contractfinish

    sum (contractnumber)

    sales_pertarget1_view1

    视图八:product_view(产品利润视图)

    字段名

    来源字段

    来源表/视图

    连接关系及条件、聚合等

    产品编号

    productid

    product_id

    product_profit

    produce_view.product_id= product_profit.product_id

     

    Orders.product_id= product_profit.product_id

    产品名称

    productname

    productname

    produce_view

    产品类别

    producttype

    producttype

    produce_view

    合同编号

    contractid

    contract_id

    product_profit

    销售数量

    sellsnumber

    sells_numbe

    Orders

    销售价格

    perprice

    perprice

    Orders

    产品成本

    productcost

    product_cost

    produce_view

    产品毛利

    profit

    profit

    product_profit

    利 润 率

    rpofitmargin

    profit_margin

    product_profit

    说明:以“产品利润”表为基础,通过“在产品视图”和“定单”表补充数据;此处计算的是每一份合同的每 一种产品的毛利,没有判断合同是否已经履行,在组织用户查询时,可能会附带条件,此时则需另行附加条件并组织联接进行查询。

    视图九:sales_pertarget2_view1(销售目标完成情况/业务员、合同、签约细目)

    字段名

    来源字段

    来源表/视图

    连接关系及条件、聚合等

    业务员编号

    sellerid

    seller_id

    Seller_target

    Contract.seller_id=seller_target.seller_id

    seller.seller_id=seller_target.seller_id

    业务员姓名

    sellername

    seller_name

    Seller

    合同编号

    contractid

    contract_id

    Contract

    标的总额

    sellstotall

    sells_totall

    Contract

    签约日期

    signdate

    sign_date

    Contract

    履行日期

    carrydate

    carry_date

    Contract

    合同状态

    contractstatu

    contract_statu

    Contract

    说 明:以“个人目标分解”表和“合同”表为基础,通过“销售员”表补充数据。

    视图十:sales_pertarget2_view2(销售目标完成情况/业务员、履行细目)

    字段名

    来源字段

    来源表/视图

    连接关系及条件、聚合等

    业务员编号

    sellerid

    sellerid

    sales_pertarget2_view1

    contractstatu=1

    业务员姓名

    sellername

    sellername

    合同编号

    contractid

    contractid

    标的总额

    sellstotall

    sellstotall

    签约日期

    signdate

    signdate

    履行日期

    carrydate

    carrydate

    说 明:为了使用户可以确定的期间进行查询,故不对数据进行处理,根据用户的查询要求在具体查询时进行 处理(分类汇总)。

    视图十一:store_ view(产品库存)

    字段名

    来源字段

    来源表/视图

    连接关系及条件、聚合等

    截止日期

    toDate

    max(store_date)

    Store

    Produc_viewt.product_id= Store. product_id

    产品编号

    Productid

    Product_id

    Store

    产品名称

    productname

    productname

    Produce_view

    产品类别

    typename

    typename

    Produce_view

    库存数量

    storenumber

    store_number

    Store

    质量等级

    storequlity

    store_qulity

    Store

    产品批号

    productcode

    product_code

    Store

    说 明:以“产品出/入库表”为基础;以最后一次登记日期作为截止日期。

    视图十二:signcontract_view(签约客户/全部客户的查询直接操作表,不再建立视图)

    字段名

    来源字段

    来源表/视图

    连接关系及条件、聚合等

    客户编号

    clientid

    client_id

    client

    Client. Client_id= contract.Client_id

    客户名称

    clientname

    client_name

    client

    签约总额

    signtotall

    sum(sells_totall)

    Contract

    联系人

    linkperson

    client_person

    client

    联系方式

    clienttel

    client_tel

    client

    住址

    Address

    client_ad

    client

    说 明:以“客户”表为基础,通过“合同”表补充数据。

    视图十三:store_contract_view(现有库存占在履合同标的之比重)

    字段名

    来源字段

    来源表/视图

    连接关系及条件、聚合等

    产品编号

    productid

    productid

    store_ view

    product_sales_view.productid= store_view.productid

     

    contractstatu=0

    产品名称

    productname

    productname

    store_ view

    产品类别

    typename

    typename

    store_ view

    截止日期

    todate

    todate

    store_ view

    库存数量

    benumber

    sum(storenumber)

    store_ view

    需求数量

    needsnumber

    Sum(sells_number)

    product_sales_view

    质量等级

    qulity

    storequlity

    store_ view

    在履合同标的总额

    totallprice

    sum(sellsnumber * perprice)

    product_sales_view

    库存所占比重

    porpotion

    sum(storenumber)/sum(sellsnumber)* 100

    说 明:以“产品库存”视图为基础,通过“产品销售情况”视图补充数据。

    视图十四:(产品签约焦点)

    字段

    来源字段

    来源表/视图

    连接关系及条件、聚合等

    客户编号

    clientid

    client_id

    client

    client .client_id = product_sales_view.clientid

     

    GROUP BY client.client_id, product_sales_view.productid,…

    客户名称

    clientname

    client_name

    产品编号

    productid

    productid

    product_sales_view

    产品名称

    productname

    productname

    产品类别

    typename

    typename

    合同编号

    contractid

    contractid

    总  价

    totallprice

    sum(sellsnumber * perprice)

    均  价

    avgprice

    sum (sellsnumber *perprice)       / sum (sellsnumber)

    总 成 本

    totallcost

    sum (sellsnumber *productcost)

    说 明:以“客户”表为基础,通过“产品销售情况”视图补充数据。

    视图十五:contract_verify_view(合同评审/主体)

    字段

    来源字段

    来源表/视图

    连接关系及条件、聚合等

    评审号

    verifyid

    verify_id

    contract_verify

    client. client_id= contract_verify.client_id

    Seller. seller_id= contract_verify. seller_id

    评审日期

    verifydate

    verify_date

    有关评审人员

    verifypersons

    verify_persons

    客户编号

    clientid

    client_id

    客户名称

    clientname

    client_name

    client

    联系人/代表人

    clientperson

    client_person

    client

    业务员编号

    sellerid

    seller_id

    contract_verify

    业务员姓名

    sellername

    seller_name

    Seller

    拟履行日期

    verifycarry

    verify_carry

    contract_verify

    最低利润率需求

    verifyforprofit

    verify_forprofit

    标的总额

    verifyallprice

    verify_allprice

    可能的折扣

    verifyallowdis

    verify_allowdis

    可实现利润总额

    verifyprofit

    verify_profit

    可实现的利润率

    verifymargin

    verify_margin

    生产能力评估

    verifycapacity

    verify_capacity

    系统建议结论

    verifysysadvice

    verify_sysadvice

    评审结论

    verifyconclusion

    verify_conclusion

    说明;以“合同评审记录/主体评审”表为基础,通过“客户”、“业务员”表补充数据;用户界面添加成本总 额项(从在产品视图与产品细分视图中查询、计算)、最长需求期限、最短实现期限(产品细分评审相应的最大值,忽略需累加情形)。

    视图十六:contract_perverify_view(合同评审/产品细分)

    字段

    来源字段

    来源表/视图

    连接关系及条件、聚合等

    评审号

    verifyid

    verify_id

    contract_perverify

    produce_view. Productid= contract_perverify. product_id

     

    产品编号

    productid

    product_id

    产品名称

    productname

    productname

    produce_view

    产品类别

    typename

    typename

    数  量

    verifynumber

    verify_number

    contract_perverify

    单  价

    perverifyprice

    perverify_price

    最低利润率需求

    perverifyforprofit

    perverify_forprofit

    成  本

    productcost

    productcost

    produce_view

    可启动日期

    perverifyondate

    perverify_ondate

    contract_perverify

    可实现利润

    perverifyprofit

    perverify_profit

    contract_perverify

    可实现利润率

    perverifymargin

    perverify_margin

    生产能力评估

    perverifycapacity

    perverify_capacity

    系统建议结论

    perverifysyadice

    perverify_syadice

    评审意见

    perverifyconclusion

    perverify_conclusion

    说明;以“合同评审记录/产品细分评审”表为基础,通过“在产品视图”补充数据;用户界面添加成本总额项(从在产品视图与产品细分视图中查询、计算)、最长期限、最短实现期限(查询“合同评审记录/主体评审”与“产品生产周期”通过计算获得)。

    (三)、数据库报表设计

    本数据库暂未设计报表(拟将有关统计信息组织成报表)。

    (四)、数据库逻辑结构设计

    本数据库的逻辑结构如下图:

    销售管理系统数据库设计说明书 - saint - 不放弃不强求

    (五)、索引设计

    每个表的主键都是聚集索引,SQL Server自动为这些主键设置索引和索引结构。

    (六)、存储过程设计:

    无存储过程。

    (七)、触发器设计:

    无触发器设计

    (八)、其它逻辑设计

    不适用。 

     (九)、数据库物理结构设计

    本数据库的物理结构的部分符合SQL Server 2000关于数据文件、卷、页的分配和分配规则。

    数据库初始大小为(20MB),按照超过最大容量后(20%)的增长速率进行增长。

    数据库分配日志文件大小为(20M),自动增长。应用程序中自动截断事务日志。

    数据库的物理文件、主要数据文件、次要数据文件、文件组等都按照系统的默认设置进行。物理文件的存储位置为SQL Server 2000默认的位置。

    四、完成数据库设计,按以上设计要求创建数据库和表。

    (一)、完成的数据库设计:

    数据库名称:sales

    中文名称或意义:营销

    创建日期:2005.12.12

    创建人:王章聖

    数据文件初始大小:(20MB)

    数据文件物理位置:(C:\SQL Server\Data\ Library_data.MDF)

    日志文件初始大小:(20MB)

    日志文件物理位置:(C:\SQL Server\Data\ Library_log.LDF)

    文件组名称:sales

    特性列表:

    只读:False

    限制访问:False

    故障还原模型:简单

    自动关闭:False;

    自动收缩:True;

    兼容性级别:数据库兼容性80

    (二)、完成的数据表设计:

    数据库表及结构参见本文档前面第三部分数据库结构设计。

    (三)、完成其他数据库相关设计

    数据库逻辑关系、检查、约束等设计参见本文档前面第三部分,此处略。

    (四)、安全保密设计

    数据库只被少数授权用户修改,其他受限用户有权查看,但均必须提供用户名和正确的密码。存储数据库的服务器也只能让系统管理员或少数高级管理人员登录。

    数据库的安全策略,遵从SQL Server 2000的安全策略事项。


    转载自:  http://blog.163.com/saint998@126/blog/static/4306292920077293647361/



    展开全文
  • 酒店管理系统数据库设计说明书

    万次阅读 2017-12-06 11:18:40
    本文档为**酒店管理系统需求分析报告,为**酒店管理系统设计的主要依据,主要针对**酒店管理系统的概要设计和详细设计人员,作为项目验收的主要依据。 1.2背景 本软件全称为**酒店管理系统。 软件适用于普通二...

    转自:http://blog.csdn.net/chenzhanhai/article/details/6055409

    1.1编写目的

    本文档为**酒店管理系统需求分析报告,为**酒店管理系统的设计的主要依据,主要针对**酒店管理系统的概要设计和详细设计人员,作为项目验收的主要依据。

    1.2背景

    本软件全称为**酒店管理系统。

    软件适用于普通二星级酒店、宾馆。

    1.3参考资料

    美萍酒店管理系统

    2结构设计

    本软件的数据库名称为:**hotel,结构设计如下:

    房间类型表  [roomtype]

    字段名

    类型

    允许为空

    默认值

    说明

    pk

    decimal

    ×

     

    主键

    id

    varchar

    ×

     

    房间类型编号

    r_type

    varchar

    ×

     

    房间类型

    bed

    int

    ×

     

    床位数

    price

    float

    ×

     

    单价

    foregift

    float

    ×

     

    押金

    cl_room

    varchar

    ×

    N

    是否钟点房

    cl_price

    float

    ×

     

    钟点房价

    remark

    varchar

     

    备注

    sysmark

    int

    ×

    0

    系统级标志

    delmark

    Int

    ×

    0

    删除标记

    other1

    varchar

     

    保留1

    other2

    varchar

     

    保留2

     

    房间信息表  [roominfo]

    字段名

    类型

    允许为空

    默认值

    说明

    pk

    decimal

    ×

     

    主键

    id

    varchar

    ×

     

    房间号

    r_type_id

    varchar

    ×

     

    房间类型编号

    state

    varchar

    ×

     

    房间状态

    location

    varchar

    ×

     

    所处位置

    r_tel

    varchar

    ×

     

    房间电话

    remark

    varchar

     

    备注

    statetime

    int

    ×

    0

    状态计时

    delmark

    int

    ×

    0

    删除标记

    other1

    varchar

     

    保留1

    other2

    varchar

     

    保留2

     

    客户类型表  [customertype]

    字段名

    类型

    允许为空

    默认值

    说明

    pk

    decimal

    ×

     

    主键

    id

    varchar

    ×

     

    客户类型编号

    c_type

    varchar

    ×

     

    客户类型

    dis_attr

    varchar

    ×

     

    折扣属性

    discount

    int

    ×

     

    折扣比例

    price

    float

    ×

     

    原价格

    dis_price

    varchar

    ×

     

    折扣价格

    remark

    varchar

     

    备注

    delmark

    int

    ×

    0

    删除标记

    other1

    varchar

     

    保留1

    other2

    varchar

     

    保留2

     

    入住信息表[livein]

    字段名

    类型

    允许为空

    默认值

    说明

    pk

    decimal

    ×

     

    主键

    In_no

    varchar

    ×

     

    入住单号

    r_no

    varchar

    ×

     

    房间号

    r_type_id

    varchar

    ×

     

    房间类型编号

    Main_room

    varchar

    ×

     

    主房间号

    Main_pk

    decimal

    ×

     

    主PK

    c_type_id

    varchar

    ×

     

    客户类型编号

    m_id

    varchar

    ×

    *

    客户编号

    c_name

    varchar

    ×

     

    客户名称

    c_jp

    varchar

     

    客户名称简拼

    sex

    varchar

    ×

     

    性别

    zj_type

    varchar

    ×

     

    证件类型

    zj_no

    varchar

    ×

     

    证件编号

    address

    varchar

    ×

    *

    地址

    renshu

    int

    ×

     

    人数

    in_time

    varchar

    ×

     

    入住时间

    days

    int

    ×

     

    预注天数

    account

    float

    ×

     

    消费数量

    foregift

    float

    ×

     

    押金

    chk_no

    varchar

    ×

    *

    结算单号

    chk_time

    varchar

    ×

    *

    结算时间

    remark

    varchar

     

    备注

    userid

    varchar

    ×

     

    操作员

    cluemark

    int

    ×

    0

    提醒标志

    statemark

    varchar

    ×

    0

    状态标志

    delmark

    int

    ×

    0

    删除标记

    other1

    ]

     

     

     

    varchar

     

    保留1

    other2

    varchar

     

    保留2

     

    预定信息表[engage]

    字段名

    类型

    允许为空

    默认值

    说明

    pk

    decimal

    ×

     

    主键

    c_name

    varchar

    ×

     

    客户名称

    c_jp

    varchar

    ×

     

    客户名称简拼

    c_tel

    varchar

    ×

     

    客户电话

    r_type_id

    varchar

    ×

     

    房间类型编号

    r_no

    varchar

    ×

     

    房间号

    pa_time

    varchar

    ×

     

    预抵时间

    keep_time

    int

    ×

     

    保留时间

    eng_time

    varchar

    ×

     

    预定时间

    remark

    varchar

     

    备注

    engagemark

    int

    ×

    0

    预定状态标志

    cluemark

    int

    ×

    0

    提醒标志

    delmark

    int

    ×

    0

    删除标记

    other1

    varchar

     

    保留1

    other2

    varchar

     

    保留2

     

    结算表[checkout]

    字段名

    类型

    允许为空

    默认值

    说明

    pk

    decimal

    ×

     

    主键

    chk_no

    varchar

    ×

     

    结帐单号

    in_no

    varchar

    ×

     

    入住单号

    days

    int

    ×

     

    实住天数

    money

    float

    ×

     

    金额

    chk_time

    varchar

    ×

     

    结算时间

    remark

    varchar

     

    备注

    delmark

    int

    ×

    0

    删除标记

    other1

    varchar

     

    保留1

    other2

    varchar

     

    保留2

     

    日志表[record]

    字段名

    类型

    允许为空

    默认值

    说明

    pk

    decimal

    ×

     

    主键

    time

    datetime

    ×

     

    操作时间

    operator

    varchar

    ×

     

    操作员

    brief

    varchar

    ×

     

    内容摘要

    content

    varchar

    ×

     

    内容

    delmark

    int

    ×

    0

    删除标记

    other1

    varchar

     

    保留1

    操作员信息表[pwd]

    字段名

    类型

    允许为空

    默认值

    说明

    pk

    decimal

    ×

     

    主键

    userid

    varchar

    ×

     

    用户登录ID

    pwd

    varchar

    ×

     

    登录密码

    puis

    int

    ×

     

    用户权限

    delmark

    int

    ×

    0

    删除标记

    other1

    varchar

     

    保留1

    other2

    varchar

     

    保留2

     

    会员信息表[member]

    字段名

    类型

    允许为空

    默认值

    说明

    pk

    decimal

    ×

     

    主键

    m_id

    varchar

    ×

     

    会员编号

    m_name

    varchar

    ×

     

    会员名称

    sex

    varchar

    ×

     

    性别

    zj_no

    varchar

    ×

     

    证件编号

    address

    varchar

    ×

     

    详细地址

    m_tel

    varchar

    ×

     

    联系电话

    remark

    varchar

    ×

     

    备注

    delmark

    int

    ×

    0

    删除标记

    other1

    vrchar

     

    保留1

    other2

    varchar

     

    保留2

     

    散客开单中间表[roomnum]

    字段名

    类型

    允许为空

    默认值

    说明

    roomid

    varchar

     

    房间编号

     

     

    团体开单中间表[roomnums]

    字段名

    类型

    允许为空

    默认值

    说明

    rr_type

    varchar

     

    房间类型

    roomid

    varchar

     

    房间编号

    price

    float

     

    单价

     

    预订信息中间表

    字段名

    类型

    允许为空

    默认值

    说明

    pk

    decimal

     

    主键

    c_name

    varchar

     

    客户名称

    c_jp

    varchar

     

    客户名称简拼

    c_tel

    varchar

     

    客户电话

    r_type_id

    varchar

     

    房间类型编号

    r_no

    varchar

     

    房间号

    pa_time

    varchar

     

    预抵时间

    keep_time

    int

     

    保留时间

    eng_time

    varchar

     

    预定时间

    remark

    varchar

     

    备注

    engagemark

    int

    0

    预定状态标志

    cluemark

    int

    0

    提醒标志

    delmark

    int

    0

    删除标记

    other1

    varchar

     

    保留1

    other2

    varchar

     

    保留2


    展开全文
  • 05详细设计说明书(机房收费系统

    千次阅读 2015-02-09 11:22:57
    本详细设计说明书是在概要设计说明书的基础上进一步明确系统的结构和程序,针对各个模块的编程给出详细设计,为以后的编程,测试和维护工作做准备,本详细设计说明书的读者为程序员、测试人员和维护人员。...


    详细设计说明书

    1引言

    1.1编写目的

    本详细设计说明书是在概要设计说明书的基础上进一步明确系统的结构和程序,针对各个模块的编程给出详细设计,为以后的编程,测试和维护工作做准备,本详细设计说明书的读者为程序员、测试人员和维护人员。

    1.2背景

    说明:
    A. 所建议开发的软件系统的名称:机房管理系统
    B. 本项目的任务提出者:米新江教授
    开发者:张翼彪
    用户:教师、学生、职工、机房管理员等
    实现该软件的计算中心或计算机网络:个人笔记本电脑、学校机房
    C. 该软件系统同其他系统或其他机构的基本的相互来往关系:可访问学生学籍系统的数据库

    1.3定义

    注册 消费金额 充值 值班 退卡
    Landing Consume Recharge On work Cancel
    结账 基本数据 购卡 上机 下机
    SettleAccount Basicdata Buycard Login logout
    1.4参考资料
    列出有关的参考资料,如:
    [1]、《软件工程导论(第五版)》张海藩 编著 清华大学出版社
    [2]、可行性研究报告(GB8567——88)概要设计说明书(GB8567——88)、软件需求说明书(GB8567——88)
    [3]、软件开发标准:Microsoft Windows XP Professional,Microsoft SQL Server 2008,Microsoft Visual Basic 6.0
    [4]、《软件工程基础与案例分析》 王阿川 主编 机械工业出版社
    2程序系统的结构
    用一系列图表列出本程序系统内的每个程序(包括每个模块和子程序)的名称、标识符和它们之间 的层次结构关系。



    权限分配图:

    下面以高权限中的各个模块为划分标准继续一下描述,中低权限只是高权限的部分功能。

    3上、下机管理设计说明

    3.1程序描述

    上下机实现刷卡上机自动计费的功能,非常驻内存,是可重入的,只要登录该系统即可经行该操作。

    3.2功能

    采用IPO图(即输入一处理一输出图)的形式说明其功能:

    系统名称:学生管理

    模块名称:上、下机管理

    调用:学生注册表

    输入:学生卡号   输出:提示信息

    3.3性能

    金额精确到0.5元,时间精确到分钟,其他数字精确到小数点后两位小数。

    3.4输入项

    名称

    标识

    数据类型

    有效范围

    输入方式

    卡号

    CardNo

    Char

    10

    刷卡输入

    学号

    studentNo

    Char

    11

    自动输入

    姓名

    studentName

    Char

    10

    自动输入

    系别

    Department

    Char

    10

    自动输入

    性别

    Sex

    Char

    6

    自动输入

    年级

    Grade

    Char

    10

    自动输入

    班级

    Class

    Char

    10

    自动输入

    金额

    Cash

    Money

    10

    自动输入

    备注

    Remarks

    Varchar

    20

    自动输入

    状态

    Status

    Char

    8

    自动输入

    用户ID

    UserID

    Char

    10

    自动输入

    注册时间

    LoginTime

    datetime

    10

    自动输入


    3.5输出项

    名称

    标识

    数据类型

    有效范围

    卡号

    cardNo

    Char

    10

    上机时间

    Ontime

    Datetime

    精确到秒

    下机时间

    Offtime

    Datetime

    精确到秒

    备注

    Status

    Char

    20

    消费金额

    ConsumeMoney

    Money

    精确到0.5元

    剩余金额

    RemainCash

    Money

    精确到0.5元

    姓名

    StudentName

    Char

    10

    用户

    UserID

    Char

    10

    3.6算法

    该模块通过读卡器读取的卡号,从数据库中提取相关的信息,如:姓名、性别、账户余额等。并且取系统当前时间为上机时间,并记录。若用户输入信息错误,则弹出提示框。

    3.7流程逻辑


    3.8接口

    与本模块直接关联的数据结构:学生注册表和学生上机记录表

    3.9存储分配

    对数据库采用日志记录技术和海量转存技术,并定期进行数据备份。

    3.10注释设计

    本程序中安排的注释,如:
    A.模块首部注释说明本模块开始编写的时间,编写人员,及其基本功能;
    B.加在各分枝点的注释说明学生上机所要具备的条件;
    C.对时间和费用变量进行说明,指出学生上机所用的时间和所消费的金额;
    D.注释说明不同的情况对学生上机费用的收取规则不同,指出具体的计算方法。

    3.11限制条件

    必须保证程序正常的连接到服务器。

    3.12测试计划

    经行上机和下机测试,保证数据的正确性。

    3.13尚未解决的问题

    对不同类别的卡收费标准不同。

    4查询功能设计说明

    4.1程序叙述

    查询程序可以查询到学生消费卡的余额、充值记录,学生的上机记录和上机状态等,还可以做到收取金额查询,金额退还信息查询,学生上机统计信息查询,工作记录查询。它是可重入的。

    4.2功能

    采用IPO图(即输入一处理一输出图)的形式,说明程序的功能

    系统名称:学生管理

    模块名称:查询卡上余额

    调用:学生注册表

    输出:学号,班级,姓名,状态,性别,备注,年级,系别,余额

     

    输入:学生卡号  



    系统名称:学生管理

    模块名称:查询充值记录

    调用:充值表

    输入:学生卡号   输出:卡号,充值金额,充值时间,充值老师


    系统名称:学生管理

    模块名称:查询学生上机记录

    调用:上下机表

    输出:卡号,上机时间,下机时间,消费金额,余额,备注

     

    输入:学生卡号   


    4.3性能

    金钱精确到0.5元,时间精确到分钟,其他数字均精确到整数位

    4.4输入项

    名称

    标识

    数据类型

    有效范围

    输入方式

    卡号

    cardNo

    Char

    10字符以内

    手动输入

    姓名

    studentName

    Char

    10字符以内

    手动输入

    日期

    Date

    DateTime

    精确到日

    手动输入

    时间

    Time

    Datetime

    精确到秒

    手动输入

    金额

    Cash

    Money

    精确到0.5元

    手动输入


    4.5输出项

    名称

    标识

    数据类型

    有效范围

    卡号

    CardNo

    Char

    10

    学号

    StudentNo

    Char

    11

    姓名

    StudentName

    Char

    10

    性别

    Sex

    Char

    6

    年级

    Grade

    Char

    10

    班级

    Class

    Char

    10

    系别

    Department

    Char

    10

    余额

    Remain

    Money

    精确到0.5

    日期

    Date

    Datetime

    精确到日

    时间

    Time

    Datetime

    精确到秒

    级别

    Level

    Char

    10

    状态

    Status

    Char

    10

    备注

    Remarks

    Char

    10

    机房号

    RoomNo

    Char

    10

    机器号

    ComputerNo

    Char

    10


    4.6算法

    实现查询功能主要就是查询语句:select … from … where …

    4.7流程逻辑


    4.8接口

    与本程序关联的数据结构有:学生注册表,充值表,学生上机记录表,上机状态表,退卡表,工作员记录表。

    4.9存储分配

    4.10注释设计

    说明准备在本程序中安排的注释,如:
    A.模块首部注释说明本模块开始编写的时间,编写人员,及其基本功能;
    B.加在各分枝点的注释说明查询的条件;

    4.11限制条件

    暂无。

    4.12测试计划

    说明对本程序进行单体测试的计划,包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。

    4.13尚未解决的问题

    暂无

    5修改密码设计说明

    5.1程序描述

    本程序主要是实现了用户自主修改密码的功能。

    5.2功能

    说明该程序应具有的功能,可采用IPO图(即输入一处理一输出图)的形式。

    5.3性能
    5.4输入项

     名称

    标识

    数据类型

    有效范围

    输入方式

    密码

    PWD

    Char

    20位字符以内

    手动输入


    5.5输出项

    提示信息。

    5.6算法


    5.7流程逻辑


    5.8接口

    与本程序有关的上一层模块为:学生信息管理层,没有下层模块。

    5.9存储分配

    根据需要,说明本程序的存储分配。

    5.10注释设计

    说明准备在本程序中安排的注释,如:
    A.模块首部注释说明本模块开始编写的时间,编写人员,及其基本功能;
    B.加在各分枝点的注释说明各种验证条件。

    5.11限制条件

    说明本程序运行中所受到的限制条件。

    5.12测试计划

    说明对本程序进行单体测试的计划,包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。

    5.13尚未解决的问题

    无。

    6添加/删除用户设计说明

    6.1程序描述

    该程序的主要功能是添加用户或删除用户。

    6.2功能


    6.3性能

    6.4输入项

    名称

    标识

    数据类型

    有效范围

    输入方式

    用户名

    UserID

    Char

    10位字符以内

    手动输入

    用户级别

    Level

    Char

    10位字符以内

    手动输入/选择添加

    用户姓名

    UserName

    Char

    10位字符以内

    手动输入

    用户密码

    PWD

    Char

    10位字符以内

    手动输入


    6.5输出项

    名称 标识 数据类型 有效范围
    用户名 UserID Char 10位字符以内
    姓名 UserName Char 10位字符以内

    6.6算法


    6.7流程逻辑


    6.8接口

    与本程序相直接关联的数据结构是用户信息表。

    6.9存储分配

    根据需要,说明本程序的存储分配。

    6.10注释设计

    A.模块首部注释说明本模块开始编写的时间,编写人员,及其基本功能;
    B.加在各分枝点的注释说明各种条件。

    6.11限制条件

    说明本程序运行中所受到的限制条件。

    6.12测试计划

    说明对本程序进行单体测试的计划,包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。

    6.13尚未解决的问题


    7注册设计说明

    7.1程序描述

    该程序的功能主要是给学生注册卡号和相关信息,以便上下机的管理。

    7.2功能


    7.3性能
    7.4输入项

    名称

    标识

    数据类型

    有效范围

    输入方式

    卡号

    CardNo

    Char

    10位数字以内

    刷卡输入

    学号

    StudentNo

    Char

    11位数字以内

    手动输入

    姓名

    StudentName

    Char

    10位字符以内

    手动输入

    系别

    Department

    Char

    10位字符以内

    手动输入

    性别

    Sex

    Char

    6位字符

    手动输入

    年级

    Grade

    Char

    10位字符以内

    手动输入

    班级

    Class

    Char

    10位字符以内

    手动输入

    金额

    Cash

    Money

    >5元

    手动输入

    备注

    Remarks

    Varchar

    20位字符以内

    手动输入

    状态

    Status

    Char

    10位字符以内

    手动输入

    7.5输出项

    提示信息。

    7.6算法

    无。

    7.7流程逻辑


    7.8接口

    本程序无下一层模块,相关联的数据结构是学生注册表。

    7.9存储分配

    根据需要,说明本程序的存储分配。

    7.10注释设计

    说明准备在本程序中安排的注释,如:
    A.模块首部注释说明本模块开始编写的时间,编写人员,及其基本功能;
    B.加在各分枝点的注释说明各种条件。

    7.11限制条件


    7.12测试计划

    说明对本程序进行单体测试的计划,包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。

    7.13尚未解决的问题


    8充值设计说明

    8.1程序描述

    本程序的主要功能是给学生的消费卡里进行充值管理。

    8.2功能


    8.3性能

    8.4输入项

    名称

    标识

    数据类型

    有效范围

    输入方式

    卡号

    CardNo

    Char

    10位数字以内

    手动输入

    充值金额

    Cash

    Money

    >5元

    手动输入

    8.5输出项

    名称

    标识

    数据类型

    有效范围

    上次卡上余额

    LastRemaincash

    Money

    >5元

    现在卡内余额

    NowRemaincash

    Money

    >5元

    充值日期

    Date

    Datetime

    精确到日

    充值时间

    Time

    Datetime

    精确到秒

    充值老师

    teacher

    Char

    10位字符以内


    8.6算法

    无。

    8.7流程逻辑


    8.8接口

    该程序的无下一层模块
    本程序的相关联的数据结构是学生注册表和充值表。

    8.9存储分配

    根据需要,说明本程序的存储分配。

    8.10注释设计

    说明准备在本程序中安排的注释,如:
    A.模块首部注释说明本模块开始编写的时间,编写人员,及其基本功能;
    B.加在各分枝点的注释说明各种条件。

    8.11限制条件


    8.12测试计划

    说明对本程序进行单体测试的计划,包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。

    8.13尚未解决的问题

    无。

    9退卡设计说明

    9.1程序描述

    该程序的主要实现学生退卡功能。

    9.2功能


    9.3性能

    9.4输入项

    名称

    标识

    数据类型

    有效范围

    输入方式

    卡号

    CardNo

    Char

    10位数字以内

    手动输入


    9.5输出项

    名称

    标识

    数据类型

    有效范围

    退卡金额

    CancelCash

    Money

    精确到小数点后两位

    退卡日期

    CancelDate

    DateTime

    精确到日

    退卡时间

    CancelTime

    DateTime

    精确到秒

    办理教师

    OperateTeacher

    Char

    10个字符内

    9.6算法


    9.7流程逻辑


    9.8接口

    本程序无下一层模块;与程序直接相关的数据结构:退卡表和学生注册表。

    9.9存储分配

    根据需要,说明本程序的存储分配。

    9.10注释设计

    说明准备在本程序中安排的注释,如:
    A.模块首部注释说明本模块开始编写的时间,编写人员,及其基本功能;
    B.加在各分枝点的注释说明各种条件。

    9.11限制条件

    无。

    9.12测试计划

    说明对本程序进行单体测试的计划,包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。

    9.13尚未解决的问题

    无。

    10结账设计说明

    10.1程序描述

    本程序主要实现对学生上机收入的结算功能,包括:日结和周结。

    10.2功能


    10.3性能

    10.4输入项

    名称

    标识

    数据类型

    有效范围

    输入方式

    日期

    Date

    Datetime

     10个数字以内

    自动/手动


    10.5输出项

    名称

    标识

    数据类型

    有效范围

    上期充值卡金额

    RemainCash

    Money

    精确到0.01元

    当日充值金额

    RechargeCash

    money

    精确到0.01元

    当日消费金额

    ConsumeCash

    Money

    精确到0.01元

    当日退款金额

    CancelCash

    Money

    精确到0.01元

    本期充值卡金额

    AllCash

    money

    精确到0.01元

    日期

    Date

    datetime

    精确到0.01元


    10.6算法

    通过当日的工作员结账表计算日结。使用循环语句将每个工作员的结账记录累加起来。上期充值卡余额通过前一天的本期充值卡金额得到,今天的本期充值卡金额则通过算式得到:本期充值卡金额=上期充值卡金额+当日充值金额—当日消费金额—当日退卡金额。对于周结的算法同日结的大同小异。

    10.7流程逻辑

    暂无

    10.8接口

    本程序无下一层模块;与程序直接相关的数据结构:退卡表和学生注册表。

    10.9存储分配

    根据需要,说明本程序的存储分配。

    10.10注释设计

    说明准备在本程序中安排的注释,如:
    A.模块首部注释说明本模块开始编写的时间,编写人员,及其基本功能;
    B.加在各分枝点的注释说明各种条件。

    10.11限制条件

    无。

    10.12测试计划

    说明对本程序进行单体测试的计划,包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。

    10.13尚未解决的问题

    无。

    11登录设计说明

    11.1程序描述

    该程序的功能主要是实现了辨别用户身份,非三类管理者不能随意进入,确保了系统的安全性.

    11.2功能


    11.3性能
    11.4输入项

    名称

    标识

    数据类型

    有效范围

    输入方式

    用户名

    UserID

    Char

    20位字符以内

    手动输入

    密码

    UserPWD

    Char

    20位字符以内

    手动输入


    11.5输出项

    提示信息.

    11.6算法

    无。

    11.7流程逻辑


    11.8接口

    无上一层模块,下一层模块连接主模块。

    11.9存储分配

    根据需要,说明本程序的存储分配。

    11.10注释设计

    说明准备在本程序中安排的注释,如:
    A.模块首部注释说明本模块开始编写的时间,编写人员,及其基本功能;
    B.加在各分枝点的注释说明各种条件。

    11.11限制条件

    无。

    11.12测试计划

    说明对本程序进行单体测试的计划,包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。

    11.13尚未解决的问题

    无。
    展开全文
  • 但是怎样在实际中有效地使用UML使之发挥应有的作用,怎样捕捉用户心中的需求并转换成明确的UML图形,怎样把自己心中的设计意图通过UML图形准确地表达出来,以及各职责人员如何通过UML图形进行有效沟通,关于这些,却...
  • 概要设计说明书

    万次阅读 2016-01-06 00:45:46
    04概要设计说明书 1引言 1.1编写目的 本阶段完成系统的大致设计并明确系统的数据结构与软件结构。本概要设计说明书的目的就是进一步细化软件设计阶段得出的软件概貌,把它加工成在程序细节上非常接近与源...
  • 详细设计说明书部分样例

    千次阅读 2008-10-07 10:55:00
    XX系统详细设计说明书目录第一章 引言 11.1 概述 11.2 背景 11.3 定义 11.4 参考资料 11.5 术语与缩写解释 12. 程序结构 22.1 模块汇总表 23. 程序设计说明 23.1 终端通讯子系统 23.1.1 子系统功能说明 23.1.2 子...
  • 接口设计说明书模板

    万次阅读 2016-07-28 20:23:25
    接口设计说明书   (版本号 VX.X)                     杭州朗新信息科技有限公司  二〇XX年XX月   更改履历 版本号 修改编号 更改时间 更改的 图表和章节号 更改简要描述 更改人 ...
  • 概要设计说明书实例

    千次阅读 2009-01-05 11:19:18
    概要设计说明书 一. 引言 1. 编写目的 从 该阶段开发正式进入软件的实际开发阶段,本阶段完成系统的大致设计并明确系统的数据结构与软件结构。在软件设计阶段主要是把一个软件需求转化为软件表示的 ...
  • 正确编写概要设计说明书

    千次阅读 2017-03-19 21:40:44
    正确编写概要设计说明书   在需求明确、准备开始编码之前,要做概要设计,而详细设计可能大部分公司没有做,有做的也大部分是和编码同步进行,或者在编码之后。因此,对大部分的公司来说,概要设计文档是唯一的...
  • 软件详细设计说明书

    千次阅读 2009-05-31 09:28:00
    1 引言 1.1 编写目的:阐明编写详细设计说明书的目的,指明读者对象。 1.2 项目背景:应包括项目的来源和主管部门等。 1.3 定义:列出本文档中所用到的专门术语的定义和缩写词的愿意。 1.4 参考资料: ● 列出有关...
  • 到底该如何书写概要设计说明书

    千次阅读 热门讨论 2013-12-28 21:51:26
    将软件系统需求转换为未来系统设计;  2.逐步开发强壮的系统构架;  3.使设计适合于实施环境,为提高性能而进行设计;  4.结构应该被分解为模块和库。 二、概要设计的任务  1.制定规范:代码体系、接口规约、...
  • oo软件设计说明书结构

    千次阅读 2012-04-10 16:05:21
    oo软件设计说明书结构 1 概述 系统简述、软件设计目标、参考资料、修订版本记录 这部分论述整个系统的设计目标,明确地说明哪些功能是系统决定实现而哪些时不准备实现的。同时,对于非功能性的需求例如性能、可用...
  • 数据库系统设计大作业:图书馆管理系统

    千次阅读 多人点赞 2020-12-04 09:12:45
    数据库系统设计大作业:图书馆管理系统 参考https://blog.csdn.net/dimo__/article/details/84936685中的设计思路,设计了本系统 1 需求分析 针对图书馆的图书管理系统数据库设计,分别对图书馆的读者、一般工作人员...
  • 【软件工程】——详细设计说明书

    万次阅读 多人点赞 2018-11-19 12:38:12
    该文档在概要设计的基础上,进一步的细化系统结构,展示了软件结构的图标,物理设计、数据结构设计、及算法设计、详细的介绍了系统各个模块是如何实现的,包括涉及到的算法,逻辑流程等。 预期的读者:程序员 1.2...
  • 面向对象软件设计说明书模板

    千次阅读 2007-08-08 10:50:00
    面向对象软件设计说明书模板blueski推荐 [2007-7-31]出处:http://www.sawin.cn/doc/Document/DocPattern/blueski1402.htm作者:不详 1 概述 1.1 系统简述 对系统要完成什么,所面向的用户以及系统运行的环境的...
  • 机器人系统设计与控制技术作业和考核说明主要分为以下2个方面:平时作业和研究型学习报告。平时作业共4次,包括如下内容:1 写一篇关于机器人和人工智能的小论文,题目不限,600字;(1次)(1)...
  • 概要设计说明书(实例)

    万次阅读 2007-02-07 11:15:00
    概要设计说明书 一. 引言 1. 编写目的 500){this.resized=
  • 软件设计文档说明书(IEEE标准)

    千次阅读 2018-01-25 20:43:30
    软件设计文档说明书    1 概述  1.1 系统简述  对系统要完成什么,所面向的用户以及系统运行的环境的简短描述,这部分主要来源于需求说明书的开始部分。  1.2 软件设计目标  这部分论述整个系统设计...
  • G.1 引言 ...为了合理地组织和高效率地存取数据,目前最好的方式,就是建立数据库系统,因此在系统的总体设计阶段,数据库的建立与设计是一项十分重要的内容。由于数据库应用系统的复杂性,为了...
  • java常用设计模式应用案例

    万次阅读 2012-10-12 16:15:08
    设计模式; 一个程序员对设计模式的理解: “不懂”为什么要把很简单的东西搞得那么复杂。后来随着软件开发经验的增加才开始明白我所看到的“复杂”恰恰就是设计模式的精髓所在,我所理解的“简单”就是一把钥匙开...
  • 本章介绍该案例实现的业务逻辑与系统结构设计。   业务逻辑 Tiny Library的业务逻辑非常简单,主要就是如下两条: 任何用户可以添加Library中的图书(简化起见,图书不能修改也不能删除),也可以查看图书...
  • 系统架构设计师考试说明(2015)

    千次阅读 2016-02-05 20:24:54
    地位高级资格考试要求: 掌握计算机硬软件与网络的基础知识; 熟悉信息系统开发过程;...了解用户的行业特点,并根据行业特点架构合适的系统设计; 掌握应用数学基础知识; 熟练阅读和正确理解相关
  • 图书管理数据库系统

    万次阅读 多人点赞 2020-01-29 19:22:44
    发本文的原因:本文是一个很经典的图书管理系统设计,大学本科实验,用例图,流程图真香!包含全部设计架构和源代码 ,可直接使用。 链接:https://pan.baidu.com/s/16Wda96TQ_4MWHj5cXNhZaA 提取码:ug6z 1 系统...
  • 软件开发详细设计说明书(转载)

    千次阅读 2010-03-30 22:59:23
    【阐明编写详细设计说明书的目的,指明读者对象。】   1.2项目背景 【应包括项目的来源和主管部门等。】 1.3定义 【列出文档中所用到的专门术语的定义和缩写词的原文。】 1.4参考资料 【列出有关资料的作者...
  • 概要设计说明书(GB8567——88)

    千次阅读 2016-06-21 22:50:16
    1引言 1.1编写目的 1.2背景 1.3定义 1.4参考资料 2总体设计 2.1需求规定 2.2运行环境 2.3基本设计概念和处理流程 2.4结构 2.5功能器求与程序的关系 ...3接口设计 ...4运行设计
  • 数据库设计案例分析

    万次阅读 2016-06-30 09:39:02
    一、树型关系的数据表  不少程序员在进行数据库设计的时候都遇到过树型关系的数据,例如常见的类别表,即一个大类,下面有若干个...按照教科上的教导,第二类程序员大概会设计出类似这样的数据表结构: 类别表

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 41,774
精华内容 16,709
关键字:

系统设计说明书案例