业务对象层次结构树（ 适用于不会编程或设计的人）

引言

在业务应用程序中识别对象和类通常是一项繁琐的任务，它始于对给定需求的分析。需求往往不完整、不清晰且不断变化。在分析过程中，可能会出现误解需求、文档混乱、新想法涌现以及对拟议设计的局限性等问题。因此，在最终确定应用程序的对象及其对象之间的关系之前，需要花费大量的时间和精力。即使在良好的条件下，设计对象也是一个繁琐且迭代的过程。本文旨在通过为应用程序中的所有业务对象创建一个层级树来简化设计工作。

背景

dotnet 框架中有一个广为人知的类是 System.Object 类，它是 dotnet 中所有类的最终基类。该类提供基本功能，以便所有 dotnet 对象都具有一些共同的强制行为。同样，我们也可以为业务应用程序中的所有业务对象设置一个最终的基类，以便所有业务对象都具有共同的业务功能和属性。我将这个类命名为 System.BObject。这里的“System”是正在开发的软件应用程序的别名，而不是 dotnet 框架中使用的 System 命名空间。

为什么要设置基业务类？

业务对象用于实现工作流、业务规则，或在应用程序中表示现实世界的对象。非业务对象通常是应用程序框架的一部分，它们提供数据访问、异常处理、事件处理、日志记录等功能。非业务对象有时可以在应用程序之间重用，而业务对象则特定于应用程序。

给定业务应用程序中的所有业务对象彼此相关，因为它们是同一业务应用程序的成员。因此，它们可以有一个最终的基类，提供跨业务对象的一些通用行为。通过从基对象派生对象，我们创建了一个对象层级树。尝试将对象拟合到层级树中，可以更容易地理解它们的用途，并有助于证明应用程序设计的合理性。如果一个对象无法拟合到层级树中，则表明对该对象的需求理解不当，或者设计在某些方面存在缺陷。

创建层级树的优点

每个类都可以从层级中更高级别的类继承现成的方法和属性。在需要时，子类可以重写或覆盖其基类中的方法。

可选地，我们可以使用接口创建层级树。通过使用接口，我们可以轻松地在应用程序内的组件之间移动类。实现接口的类必须有自己的接口方法和属性的实现。

在这个设计阶段，无论是使用类还是接口，都没有太大关系，因为这里的主要目的是识别对象及其属性、属性和方法。

通过将所有业务对象放置在层级树中，我们还可以进行向上转型和向下转型。这意味着我们可以根据对象可以向下转型到的类型来动态处理基对象。它还允许将父类型分配给子对象，类似于使用 dotnet 框架对象所做的。

例如 System.Object o = new System.OutOfMemoryException();

在上面的行中，System.Object 类的任何派生类都可以被赋值给 System.Object 类型。

一旦创建了层级树，就更容易识别对象之间可能存在的关联。如果我们只是定义对象而不将它们放入层级树中，那么即使是想象到某些对象之间可能存在关系都会很困难。

例如，如果我们创建了 company、services、customers、users、offers、policies 和 departments 等对象，而不将它们放入层级树中，那么就不清楚这些对象是如何（或者是否）相互关联的。层级树也不会显示关联，但通过研究树，可以更容易地识别可能的关联。

构建树的另一个好处是，它有助于最终确定需求。如果业务分析师在编写工作流和用例的同时进行这项练习，这将有助于他们理解要开发的应用程序的范围，并识别其文档中的不足之处。

应用程序的估算也会变得更容易。通过研究每个对象类或接口中的公共方法数量，还可以计算出树中每个对象要开发的人工小时数。有关估算的更多信息，请阅读文章《如何估算软件项目》和估算人工小时。

如何构建树？

下面展示的几个简单步骤应该能帮助你开始。

· 首先，在分析需求后，为你的应用程序提出业务对象。

· 然后将这些对象放置在你的树中，并让它们都直接派生自一个名为 BObject 的基对象。

· 尽可能多地识别对象，无论它们看起来多么微不足道。

· 一旦你有了十几个或更多的对象，就尝试看看它们是否有共同的属性或相似的功能。

· 然后将共同的功能放入一个中间基对象中，该对象放置在 BObject 和你的特定业务对象之间。

· 继续执行上述步骤，你应该能在几个小时内得到一个可接受的层级树。

· 如果树变得太大，可以将其拆分成几个图。第一个图只包含那些在层级中较高的业务对象。派生的对象可以显示在单独的较低层级的树中。

不适合此树的对象可能是框架对象，例如用于异常处理、数据库访问、电子邮件等的对象。这些对象通常继承自某个 dotnet 框架类或接口，而业务对象则不会。如果无法将所有业务对象都纳入树中，则将这些对象视为实用对象或通用对象。

一个虚构的业务应用程序

在上图中，我们有一个顶层类（最终基类），即 BObject 类。大多数业务对象通常会有一个唯一的标识号或代码、名称、描述和一个激活状态。让我们将相应的属性命名为 ID、Name、Desc 和 ActivatedStatus。因此，这些属性可以放置在 BObject 类中，并且由于继承，BObject 的所有派生类也将具有这些属性。

继承

接下来，让我们识别 Registration 类的一些属性，除了 BObject 类已提供的属性。要注册用户，我们通常需要用户名、密码、名字、姓氏、电子邮件、地址、州、国家和电话。要注册业务咨询，我们可以有客户姓名、联系人姓名、电子邮件、地址、州、国家、电话和需求详情。需求详情可以是另一个业务对象，它有自己的类（包括派生类）。要注册销售，我们可以有客户姓名、联系人姓名、电子邮件、地址、州、国家、电话、发票/订单号、账单号和收据号。通过观察，我们可以发现电子邮件、地址、州、国家、电话是 Registration 类中的通用属性。由于（个人/联系人/用户）姓名属性在各个类中都是通用的，我们可以创建一个名为 Name 的新类来处理不同类型的姓名。Name 类可以具有名为 username、firstname、lastname、customername、contactname、companyname 等属性。这将有助于防止基类 Registration 类充斥过多属性，并避免在派生类中命名一组单独的属性。同样，我们可以继续识别和放置一组相关类的通用功能。

但是，关键问题是，如果没有对象层级树，要弄清楚要创建哪些对象以及这些对象如何融入设计将会是一项更艰巨的任务。通过首先使用 System.Business.Object 作为最终基类来创建树，我们可以派生业务类/对象并创建层级树。这使得理解和证明它们的位置合理性以及如何区分父类和子类变得更加容易。

关联

创建层级树的另一个有用之处在于，我们可以更轻松地识别类之间可能的关系。再次查看上图，以下关系是可能的：

Class BObject.Organisation.Division.Department.Team.Member 和 BObject.User.Staff [Operator, Visitor, Admin] 之间是一对一的关系。即，一个团队成员只能映射到一种类型的用户。

Class BObject.Report.Internal.Sales 和 BObject.Registration.RegisterSale 之间可能是一对多的关系。即，销售报告可能使用多个 RegisterSale 对象实例来收集报告的详细信息。

Class BObject.Registration.RegisterSale 和 BObject.Report.Enternal.Bill 之间可能是一对多的关系。在这种情况下，一次销售可能涉及多个账单，因为如果客户在第一组商品确定后需要更多商品，销售可能会延长。

Class BObject.Report.Internal 和 BObject.Organisation 之间可能存在多对多关系。内部报告可能涉及组织的多个方面，而一个组织也可能需要多种类型的内部报告。

RegisterEnquiry 类在功能上可能更适合用户或组织，但它的实际父类将是 Registration 类。RegisterEnquiry 为 Registration 类添加了更多定义，并与其他派生自 Registration 类的类相关。但它并没有为 Organization 类增加更多意义。相反，它将成为 Organization 类或其派生类的属性。

Services 和 User 类可以是 Organization 类的属性。

得益于层级树，更容易理解和最终确定对象之间的关系。

结论

对于给定的系统，每个业务对象都与其他业务对象相关。一旦为系统的业务对象创建了层级树，就更容易理解业务对象如何在系统中发挥作用以及它们之间如何交互。

层级树以对象格式表示了整个业务应用程序的结构。

链接

数据层级树

http://www.dotnetspider.com/technology/kb/ShowSample.aspx?SampleId=589

发送电子邮件至：diontrish@sify.com