下载文档原格式
面向对象软件工程面向对象方法学的提出•结构化软件工程方法学•面向过程、以算法为核心、把数据和过程作为相对独立的部分•对早期只重视编程、不重视用户需求和开发过程,只重视代码、不重视文档来说,是一个巨大的进步•给软件产业带来了巨大的进步,部分缓解了软件危机•在许多中小型软件项目中获得了很大的成功•但是，它存在着明显的缺点•当把这种方法学应用于大型软件产品的开发时，似乎很少取得成功面向对象方法学概述•面向对象方法学的出发点和原则•尽可能模仿人类习惯的思维方式,使软件开发的方法与过程尽可能接近人类认识世界、解决问题的方法与过程•面向对象方法的特点•与人类习惯的思维方法一致：按照人们习惯的思维方式建立模型，模拟客观世界•稳定性好：实体是相对稳定的，以对象为中心构建的软件系统必然是相对稳定的•可重用性好：对象类提供了比较理想的模块化机制和可重用机制•易于开发大型软件：把大型产品看作一系列本质上相互独立的小产品来处理•可维护性好：容易理解、容易修改、易于测试四个要点：对象+类+继承+通信•面向对象软件是由对象组成•软件中的任何元素都是对象•对象是把静态属性的数据和动态属性的操作封装在一起而形成的统一体•复杂对象由简单对象组成•把所有对象都划分成若干类•每个类都定义了一组数据和方法（即施加于对象的操作）；•按照子类与父类的关系，把若干个对象类组成一个层次结构的系统（即继承）；•对象彼此之间仅能通过传递消息相互联系（对象的私有信息都被封装在对象类中）。
Coad和Yourdon给出了一个定义：面向对象＝对象＋类＋继承＋通信基本概念（1）•类(Class)•是对具有相同属性和行为的一(多)个对象的描述•是一个支持继承的抽象数据类型•实例(Instance)•就是由某个特定的类所描述的一个具体的对象•消息(Message)•是要求某个对象执行类中所定义的某个操作的规格说明•其组成为:接收消息的对象、消息名和变元•方法(Method)•就是对象所能执行的操作(类中定义的服务)•属性(Attribute)•就是类中所定义的数据,是对客观世界实体所具有的性质的抽象基本概念（2）•封装•是把数据和实现操作的代码集中起来放在对象内部，不能从外部进行访问和修改。
面向对象程序设计中的架构设计研究在现代软件开发中，架构设计是非常重要的一部分。
它是整个软件系统的基础，决定了软件的可扩展性、可维护性、可重用性、可靠性等各方面的质量。
而面向对象程序设计则是现代软件开发的核心思想。
面向对象的程序设计充分利用了面向对象思想的优势，使得程序更易于开发、管理和维护。
本文将分析面向对象程序设计中的架构设计研究。
一、架构设计的定义架构设计是指在软件设计阶段确定软件系统整体结构的过程。
它包括设计软件系统的各个组件之间的关系、功能划分、预估性能等。
软件系统的架构设计贯穿了软件开发的始终，除了决定软件系统的基础架构外，还针对非功能性需求，如可维护性、可扩展性、可移植性、性能等对软件系统进行设计，以达到整体性能的最优化。
二、面向对象程序设计的特点面向对象程序设计的特点在于将整个软件系统看做相互协作的对象集合，各个对象各自负责某个动作，而这些动作组成相互协作的业务逻辑。
面向对象程序设计充分利用了面向对象的优势，让整个软件系统的开发更加易于管理和维护。
其主要特点如下：1. 抽象面向对象程序设计中有一个很重要的概念——抽象。
抽象是指忽略某些细节，只保留重要的信息的过程。
在面向对象程序设计中，我们将不同的对象看做是客观世界中的不同事物，我们只关注事物和事物之间的互动过程，而不需要过多关注每一个细节。
2. 继承继承是面向对象程序设计中的常见特性之一。
继承是指在一个类的基础上创建一个新的子类，子类具有被父类继承的属性和方法。
这样的话，我们可以大大减少重复代码的编写，同时也提高了程序的可重用性和可维护性。
3. 封装封装是面向对象程序设计的一个非常重要的特点。
封装是指数据和方法被封装在一个类中，外部代码只能通过定义好的接口来访问这些内容。
封装可以提高程序的安全性，避免不必要的访问或修改内存内容，同时也提高了程序的可维护性。
4. 多态多态是面向对象程序设计中非常重要的一种特性。
多态是指同一种方法在不同的表现形式下实现不同的操作，这样的话可以用一种通用的类型来操纵不同的对象。
软件体系结构设计方法的特点软件体系结构设计方法是指在软件开发过程中，通过对软件系统的结构和组织方式进行规划和设计的方法。
它是软件工程中的重要环节，直接影响软件系统的稳定性、可维护性和可扩展性。
软件体系结构设计方法具有以下特点：1.模块化设计：软件体系结构设计方法注重对软件系统的模块化划分。
将系统划分为多个模块，每个模块负责特定的功能或任务。
模块化设计可以提高开发效率、降低开发难度和维护成本。
同时，模块之间的接口定义清晰，便于模块之间的协作与集成。
2.分层设计：软件体系结构设计方法通过分层设计将系统划分为若干层次。
每一层次负责不同的功能或服务，并通过明确定义的接口与其他层次进行通信。
分层设计可以提高系统的可扩展性和可重用性。
同时，各层次之间的依赖关系清晰，每一层次的实现对上层是透明的，便于功能的修改和扩展。
3.面向对象设计：软件体系结构设计方法倾向于采用面向对象的设计方法。
面向对象设计将系统划分为多个简单的对象，并通过对象间的继承、组合和关联等关系来描述系统的结构和行为。
面向对象设计具有易于理解、易于维护、易于扩展等优点，适用于复杂系统的设计和实现。
4.客户与服务的解耦：软件体系结构设计方法注重将客户端与服务端解耦。
客户端只需要关注所需的服务，而不需要关心服务的具体实现。
服务端负责提供服务并处理客户端的请求。
这种解耦可以提高系统的灵活性和可扩展性，允许系统的不同部分以不同的速度进行开发和演化。
5.弹性设计：软件体系结构设计方法强调系统的弹性设计。
系统应该具有适应性和容错性，能够在面对不同的环境和需求变化时进行调整和自适应。
弹性设计可以提高系统的稳定性和可靠性，降低系统运行的风险。
6.可视化设计：软件体系结构设计方法倾向于采用可视化的设计方法。
通过绘制各种图表、图形和图示，将系统的结构、组织和功能可视化，便于设计人员和开发人员之间的沟通和理解，促进团队的合作和协作。
7.迭代与重构：软件体系结构设计方法倡导迭代与重构。
面向对象与面向服务架构的比较研究在计算机技术不断发展的今天，软件开发也不断出现新的方法和架构，其中两种比较流行的架构是面向对象和面向服务。
本文将对这两种架构进行比较研究。
一、面向对象面向对象是一种计算机编程的思维方式和方法，其核心是将数据和操作数据的方法封装在一起，形成一个对象。
面向对象的思维方式强调把客观世界中的事物抽象成为程序世界中的类和对象，从而实现软件系统的模块化、复用和扩展性。
面向对象的优点在于：1. 模块化：面向对象的方法可以将庞大的软件系统分解成相互独立的模块，每个模块都是一个对象，可以单独开发、测试、维护和修改。
2. 复用性：面向对象可以将类和对象作为基本的构建元素，通过继承和多态等机制实现代码的复用性，提高软件开发效率和质量。
3. 扩展性：面向对象可以在不修改原有代码的情况下新增功能，只要通过继承和重写等机制，就可以扩展出新的类和对象。
二、面向服务面向服务是一种分布式系统的架构模式，它强调将软件系统中的功能模块封装为独立的服务，通过网络进行通信，从而实现各个服务之间的协同工作。
面向服务的架构主要包括：服务提供者、服务注册中心、服务消费者和服务调用者等组件。
面向服务的优点在于：1. 松散耦合：面向服务的架构是基于服务的，服务之间是通过接口通信，可以随时替换、扩展和移植，各个服务之间是松散耦合的，提高了系统的稳定性和灵活性。
2. 重用和组合：面向服务的架构是可以进行组装和重用的，系统中的每个服务都是独立的模块，可以进行拆分和组合，提高了软件的可重用性。
3. 分布式：面向服务的架构可以将系统的不同部分分别部署在不同的服务器上，实现了分布式的部署和管理，可以提高系统的性能和可伸缩性。
三、比较分析面向对象和面向服务是两种不同的思维方式和架构模式，它们都有自己的优点和适用场景，具体比较如下：1. 技术复杂度：面向对象的技术复杂度相对面向服务来说较低，能够适应不同的项目和开发人员的能力需求；而面向服务的技术复杂度较高，需要对分布式系统和SOA等理念有较深的理解和掌握。
⾯向服务的架构设计⼀．什么是SOA SOA 是⼀种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的⽅法。
SOA 并不是⼀个新鲜事物，⽽只是⾯向对象模型的⼀种替代。
虽然基于 SOA 的系统并不排除使⽤ OOD 来构建单个服务，但是其整体设计却是⾯向服务的。
由于 SOA 考虑到了系统内的对象，所以虽然SOA 是基于对象的，但是作为⼀个整体，它却不是⾯向对象的。
SOA 系统原型的⼀个典型例⼦是 CORBA，它已经出现很长时间，其定义的概念与 SOA 相似。
SOA 建⽴在 XML 等新技术的基础上，通过使⽤基于 XML 的语⾔来描述接⼝，服务已经转到更动态且更灵活的接⼝系统中，CORBA 中的 IDL ⽆法与之相⽐。
⼆．基本结构 服务模型的表⽰层从逻辑层分离出来，中间增加了服务对外的接⼝层。
通过服务接⼝的标准化描述，使得服务可以提供给在任何异构平台和任何⽤户接⼝使⽤。
这允许并⽀持基于服务的系统成为松散耦合、⾯向构件和跨技术实现，服务请求者很可能根本不知道服务在哪⾥运⾏、是由哪种语⾔编写的，以及消息的传输路径，⽽是只需要提出服务请求，然后就会得到答案。
三．SOA设计原理 在 SOA 架构中，继承了来⾃对象和构件设计的各种原则，例如，封装和⾃我包含等。
那些保证服务的灵活性、松散耦合和复⽤能⼒的设计原则，对 SOA 架构来说同样是⾮常重要的。
关于服务，⼀些常见的设计原则如下：（1）明确定义的接⼝。
服务请求者依赖于服务规约来调⽤服务，因此，服务定义必须长时间稳定，⼀旦公布，不能随意更改；服务的定义应尽可能明确，减少请求者的不适当使⽤；不要让请求者看到服务内部的私有数据。
（2）⾃包含和模块化。
服务封装了那些在业务上稳定、重复出现的活动和构件，实现服务的功能实体是完全独⽴⾃主的，独⽴进⾏部署、版本控制、⾃我管理和恢复。
（3）粗粒度。
服务数量不应该太多，依靠消息交互⽽不是远程过程调⽤，通常消息量⽐较⼤，但是服务之间的交互频度较低。
引言以服务为中心的业务活动管理与监控是最近出现的一种热门的IT技术，它的目的在于帮助企业管理人员实时获悉企业运营状况，了解企业的战略实施进展。
《SOA 快速指南 1 2 3》系列文章是笔者近年来在 SOA 项目实施中的经验结晶。
该系列文章结合一个汽车贷款流程，介绍了在 SOA 的环境下如何基于 IBM 的现有产品构造业务活动管理解决方案，详细阐述了每个实施步骤中使用的 IBM 的方法学、技术和产品。
希望通过本文的介绍，能够帮助读者理清业务流程管理所包含的基本概念，并了解构建解决方案所需要的基本步骤。
1. 服务建模方法论介绍众所周知，面向对象的应用构建在类和对象之上。
随后发展起来的建模技术将相关的对象按照业务功能进行分组，就形成了组件的概念；对于跨组件的功能调用，则采用接口的形式暴露出来。
进一步的将接口的定义与接口的具体实现进行解耦，就催生了SOA。
而作为业务和IT之间的契约的服务，是SOA最重要的概念。
因此面向对象、基于组件、面向服务是三个递进的抽象层次。
现在我们有OOAD（Object Oriented Analysis Design）和CBD（Component Based Development）来进行面向对象和基于组件的建模与开发。
但是没有一个好的方法来进行SOA的分析、设计和开发。
SOMA（Service Oriented Modeling Architecture）就是在这个背景下诞生的，其主要目的就是填补OOAD和CBD在建模领域留下的空白，为SOA实施提供一个方法学的指导。
需要特别指出的是，SOMA的出现并不是要替代OOAD或者CBD，正如CBD需要借助OOAD一样，SOMA也要借助OOAD和CBD进行实现层面的建模。
与OOAD和CBD相比较而言，SOMA贯穿整个IT建设的生命周期，在项目规划、设计、实施、运行中都起到重要的作用。
本文就不展开阐述了，相关信息可见参考资料。
SOMA另外一个显著的特点就是将IT与业务对齐。
面向过程、面向对象、面向组件、面向服务软件架构的分析与比较摘要：软件开发从汇编语言、过程式语言、面向对象、面向组件发展到面向服务，每一步都体现了不断抽象、更加贴近业务实际的发展趋势。
当前软件发展正处于从面向组件思想向面向服务思想的跨越阶段。
本文深入分析了面向过程、面向对象、面向组件、面向服务架构，得出相关的优缺点。
关键字：面向过程，面向对象，面向组件，面向服务1 背景当前，信息系统的发展越来越明显地呈现出以下特征：软件系统越来越庞大，但是软件系统内部组成模块的规模却越来越小；软件系统的功能越来越复杂，但是系统的开放性却越来越好。
信息系统软件正向着不依赖于特定的硬件和操作系统以及具有高度可重用性的方向发展。
在这种情况下，人们对这种大型复杂软件产品的质量和开发速度都有了更严格的要求，传统的开发方法已经难以满足这种需求。
首先，我们来分析一下几种传统的系统开发方法。
1）自底向上法自底向上法出现于早期的计算机管理应用系统，即在进行系统分析和设计时自下而上，先从底层模块做起，然后逐步完成整个系统。
自底向上法使得系统的开发易于适应组织机构真正的需要；有助于发现系统的增长需要，所获得的经验有助于下一阶段的开发，易于控制和管理。
但由于方法的演变性质，自底向上法使系统难以实现其整体性；同时由于系统未进行全局规划，数据一致性和完整性难以保证；而且为了保证系统性能的需求，往往要重新调整，甚至重新设计系统。
2）自顶向下法随着信息系统规划的扩大和对开发经验的总结与归纳，自顶向下的系统分析方法论逐步得到了发展和完善。
自顶向下法要求开发者首先制定系统的总体规划，然后逐步分离出高度结构化的子系统，从上至下实现整个系统。
运用这类方法可以为企业或机构MIS的中期或长期发展规划奠定基础，同时支持信息系统的整体性，为系统的总体规划、子系统的协调和通信提供保证。
但它同样也存在缺点：对系统分析、设计人员要求较高，在大系统中，对下层系统的实施往往缺乏约束力，开发的周期长，系统复杂，成本较高。
面向对象分析与设计ATM系统分析与设计ATM系统是一种常见的自动银行服务设备，可以方便用户进行存款、取款、余额查询、转账等银行业务操作。
本文将对ATM系统进行面向对象分析与设计。
一、分析1.系统需求分析ATM系统的主要需求包括：用户认证、账户管理、取款、存款、查询、转账等功能。
用户通过银行卡和密码进行认证，认证后可以进行不同业务的操作。
2.系统角色分析在ATM系统中，主要涉及到三个角色：用户、ATM和银行。
用户通过ATM设备进行业务操作，ATM设备与银行之间通过网络进行信息传递和交互。
3.系统功能分析根据需求分析，ATM系统的主要功能包括：-用户认证：用户通过输入银行卡和密码进行认证。
-取款：用户可以选择取款金额，并从账户余额中扣除相应金额。
-存款：用户可以选择存款金额，并将金额存入账户余额中。
-查询：用户可以查询账户余额和交易记录等信息。
-转账：用户可以选择转账金额和收款方账户，并将金额从自己账户扣除，转入收款方账户。
二、设计1.类的设计根据分析，可以定义以下类：- User（用户）：包括属性银行卡号和密码。
- Account（账户）：包括属性账户余额和交易记录。
-ATM（自动柜员机）：包括属性ATM编号和位置。
具有用户认证、取款、存款、查询、转账等方法。
2.类之间的关系- User与Account之间是一对一的关系，一个用户只能对应一个账户。
- ATM与User之间是一对一的关系，一个ATM设备只能为一个用户提供服务。
- ATM与Account之间是一对一的关系，一个ATM设备只能为一个账户提供操作。
3.系统流程设计ATM系统的流程设计如下：-用户插入银行卡，并输入密码。
-ATM设备进行用户认证，验证银行卡号和密码的正确性。
-用户选择需要进行的业务操作，如取款、存款、查询、转账等。
-ATM设备根据用户的选择进行相应的业务操作，并更新账户余额和交易记录。
-用户完成业务操作后，选择退出并取出银行卡。
面向对象设计与面向服务架构（SOA）在软件开发领域，面向对象设计（Object-Oriented Design，简称OOD）和面向服务架构（Service-Oriented Architecture，简称SOA）是两种不同的软件开发方法论。
本文将就这两种方法进行解析，并讨论它们在不同场景下的应用。
一、面向对象设计（OOD）面向对象设计是一种软件开发方法，它以对象为基本单元，通过封装、继承和多态等机制来实现代码的复用性、扩展性和可维护性。
在面向对象设计中，开发人员将问题拆分为多个对象，根据对象之间的关系和行为来设计类和接口。
面向对象设计强调模块化和抽象，以便更好地组织和管理大型软件系统。
面向对象设计的主要特点包括：1. 封装（Encapsulation）：将数据和相关的操作封装在类内部，隐藏内部实现细节，提供公共接口供外部使用。
2. 继承（Inheritance）：通过继承机制实现代码的复用性和扩展性，子类可以继承父类的属性和方法。
3. 多态（Polymorphism）：通过多态机制，同一个接口可以表现出不同的行为，提高代码的灵活性。
4. 抽象（Abstraction）：根据实际需求定义抽象类和接口，隐藏复杂的实现细节，简化问题的复杂度。
1. 可维护性：模块化设计和高内聚性使得代码更易于理解和修改。
2. 可扩展性：通过继承和接口，可以方便地添加新的功能和特性。
3. 可复用性：面向对象的设计思想使得代码更加模块化和可复用。
4. 可测试性：面向对象的设计使得单元测试更容易进行。
二、面向服务架构（SOA）面向服务架构是一种软件架构风格，通过将功能划分为服务并将这些服务通过网络进行通信，实现松耦合的分布式系统。
在面向服务架构中，服务是独立的实体，可以被其他系统或者服务调用，提供特定的功能或者数据。
面向服务架构强调服务的自治性、互相合作和可组合性，以实现灵活、可伸缩的系统。
面向服务架构的主要特点包括：1. 服务（Service）：将系统的功能划分为独立的服务，每个服务提供特定的功能或者数据。
前言N层的应用软件系统，由于其众多的优点，已经成为典型的软件系统架构，也已经为广大开发人员所熟知。
在一个典型的三层应用软件系统中，应用系统通常被划分成以下三个层次：数据库层、应用服务层和用户界面层。
如下图所示：其中，应用服务层集中了系统的业务逻辑的处理，因此，可以说是应用软件系统中的核心部分。
软件系统的健壮性、灵活性、可重用性、可升级性和可维护性，在很大程度上取决于应用服务层的设计。
因此，如何构建一个良好架构的应用服务层，是应用软件开发者需要着重解决的问题。
为了使应用服务层的设计达到最好的效果，我们通常还需要对应用服务层作进一步的职能分析和层次细分。
很多开发者在构建应用服务层的时候，把数据库操纵、业务逻辑处理甚至界面显示夹杂在一起，或者，把业务逻辑处理等同于数据库操纵，等等，这些，都是有缺陷的做法。
本文，就在这个方面进行设计时可采用的方案进行一些探讨。
为了使讨论更具有针对性，本文会讨论一些比较流行的系统架构，例如J2EE架构，以及JDO。
在微软的.Net平台上，将以Websharp中间件为例。
Websharp中间件是笔者开发的一个构建在微软.Net平台之上的一个中间件系统，也是实现文章所述的系统架构的支撑系统。
选用这些架构做例子，也是因为.Net出现的时间比较短，目前在这个平台上没有成熟统一的架构，而J2EE是目前最成熟的构建企业应用的平台。
自本人的《利用.Net框架开发应用系统》和《实战揭秘：开发.Net平台应用系统框架》两篇文章发表以来，收到很多反馈和来信，提出了很多问题。
因为时间的关系，不能一一回复，因此，也借本文给大家一些解答。
需要说明的是，原来的Jobsinfo现在已经做了升级，名称变更为Websha rp。
设计的原则和评判标准同软件工程的原则一样，应用服务层的设计，必须遵循的最重要的原则就是高内聚和低耦合。
软件分层的本来目的，就是提高软件的可维护性和可重用性，而高内聚和低耦合正是达成这一目标必须遵循的原则。
尽量降低系统各个部分之间的耦合度，是应用服务层设计中需要重点考虑的问题。
内聚和耦合，包含了横向和纵向的关系。
功能内聚和数据耦合，是我们需要达成的目标。
横向的内聚和耦合，通常体现在系统的各个模块、类之间的关系，而纵向的耦合，体现在系统的各个层次之间的关系。
系统的框架，通常包含了一系列规范、约定和支撑类库、服务。
对于如何判断一个软件的系统框架的优劣，笔者认为，可以从以下几个方面来评判：◆系统的内聚和耦合度这是保证一个系统的架构是否符合软件工程原则的首要标准。
◆层次的清晰和简洁性系统每个部分完成功能和目标必须是明确的，同样的功能，应该只在一个地方实现。
如果某个功能可以在系统不同的地方实现，那么，将会给后来的开发和维护带来问题。
系统应该简单明了，过于复杂的系统架构，会带来不必要的成本和维护难度。
在尽可能的情况下，一个部分应该完成一个单独并且完整的功能。
◆易于实现性如果系统架构的实现非常困难，甚至超出团队现有的技术能力，那么，团队不得不花很多的精力用于架构的开发，这对于整个项目来说，可能会得不偿失。
简单就是美。
◆可升级和可扩充性一个系统框架，受设计时技术条件的限制，或者设计者本人对系统认识的局限，可能不会考虑到今后所有的变化。
但是，系统必须为将来可能的变化做好准备，能够在今后，在目前已有的基础上进行演进，但不会影响原有的应用。
接口技术，是在这个方面普遍应用的技巧。
◆是否有利于团队合作开发一个好的系统架构，不仅仅只是从技术的角度来看，而且，它还应该适用于团队开发模型，可以方便一个开发团队中各个不同角色的互相协作。
例如，将Web页面和业务逻辑组件分开，可是使页面设计人员和程序员的工作分开来同步进行而不会互相影响。
◆性能性能对于软件系统来说是很重要的，但是，有的时候，为了能让系统得到更大的灵活性，可能不得不在性能和其他方面取得平衡。
另外一个方面，由于硬件技术的飞速发展和价格的下降，性能的问题往往可以通过使用使用更好的硬件来获得提升。
应用服务层的内容应用服务层，通常也被称为业务逻辑层，因为这一层，是应用软件系统业务逻辑处理集中的部分。
然而，我将这一层称为应用服务层，而不称业务逻辑层，因为，这一层需要处理的不仅仅是业务逻辑，还包含了其他方面的内容。
从完整的角度来说，应用服务层需要处理以下内容：◆数据的表示方式数据，是软件处理的对象。
从某种程度上来说，"软件，就是数据结构加算法"的说法，是有一定意义的。
在面向对象的系统中，数据是用类来表示的，代表了现实世界实体对象在软件系统中的抽象。
考虑所谓的MVC模式，这个部分的类属于M--实体类的范畴。
由于应用软件通常会使用数据库，数据库中的数据，可以看成是对象的持久化保存。
由于数据库一般是关系型的，因此，这个部分，还需要考虑类（对象）同关系型数据的映射，即通常所说的O-R MAP问题。
◆数据的存取方式如同上述所说，软件系统处理的实体对象数据需要持久化保存数据库中，因此，我们必须处理系统同数据库的交互，以及数据的存取和转换方式的问题。
◆业务逻辑的组织方式在面向对象的系统中，业务逻辑表现为对象之间的交互。
有了上述的实体对象，以及对象的保存策略，就可以将这些对象组合起来，编写我们的业务逻辑处理程序。
在业务逻辑的处理中，必须保证处理的正确性和完整性，这将会涉及到事务处理。
通常，我们也会把业务逻辑封装成组件的形式，以得到最大的可重用性。
◆业务服务的提供方式在我们完成系统的功能后，如何向客户提供服务，是我们需要考虑的问题。
这里的客户，不仅仅是指软件的使用者，也包括调用的界面、其他程序等。
例如，在一个基于Web的或JSP系统中，业务逻辑功能的客户便是这些页面或JSP页面。
业务逻辑组件应该通过什么方式，直接的，或间接的，向这些客户提供服务,是这一层需要完成的任务。
◆层的部署和层间交互对于一个多层的应用软件系统来说，尤其是大型的应用软件系统，通常需要把不同的部分部署在不同的逻辑或物理设备上。
特别是一些基于Web的应用软件系统，其部署工作将涉及到Web服务器、组件服务器、数据库服务器等不同的服务设备。
在进行应用软件架构的设计的时候，必须考虑各种不同的部署方案。
综上所述，一个完整的基于Web的应用软件系统，其架构可以用下图来表示（Websharp推荐的应用软件系统架构）：对于以上各个方面来说，每个问题都可以有很多种策略和方案，但是，在一个系统中，应该尽可能的统一这些策略和方案。
也就是说，在一个系统，或者一个项目中，应该统一每个解决每个问题所采用的方法。
软件的开发方法是灵活的，可以用不同的方法解决相同的问题，这会诱使开发人员采用他们认为能够表现自己的方法，但是，从整个系统来看，这将会是灾难性的。
我们应该尽可能统一，就是，采用统一的数据表示方式、统一的数据存取方式、统一的业务逻辑处理方式等。
下面，将就这些部分的设计策略和可用方案进行一些比较详细的论述。
数据实体的表示应用软件系统，从本质上来说，是计算机对现实世界的模拟。
现实世界中的实体对象，在软件系统中，表现为需要处理的数据。
在面向对象的系统中，这是通过"类"和"对象"来表示的。
参考著名的"MVC"模式，类可以分成实体类（M）、控制类（C）、和边界类（V），分别代表了实体对象、控制和界面显示。
系统中需要处理的数据，在面向对象的系统中，属于实体类部分。
在考虑数据实体层的设计策略的时候，需要把握以下要点：◆一致的数据表示方式。
在一个系统中，数据的表示方式必须尽可能统一，同时，在处理单个数据和多个数据的时候，处理方式尽可能一致。
◆因为数据通常是需要存储到数据库中，因此，良好的映射方法是必需的。
◆处理好对象的粒度，即所谓的粗粒度对象、细粒度对象。
一般例子考虑一个现实的例子，一个仓库中的产品（Product），在系统中可以使用如下定义：public class Product{public string Name; //名称public decimal Price;//价格public int Count;//数量}可以按照如下方法使用Product类：Product p=new Product();//……处理Product这是一个包含了三个属性的Product类的定义。
为了便于说明，在这里，我们尽量将问题简化了。
又例如，一张入库单可以使用如下定义：public class Form{public string ID; //入库单编号public DateTime AddTime; //入库时间public FormDetail[] FormDetails; //入库单明细}public class FormDetail{public Product InProduct; //入库产品public int Count; //入库数量}对于处理单个对象，通常采用上述的方法，但是，当我们需要处理相同类的一组对象，也就是处理一个对象集合的时候，就会有一些小小的麻烦。
如前所述，我们希望在处理单个对象和对象集合的时候，处理的方式尽量统一，这对于软件开发的意义是很大的。
常用的处理对象集合的方法有：◆数组表示的方法例如，上面的例子中当一张入库单包含多条入库单明细的时候采用的方法。
为了灵活性，也可以使用容器来，如Java中的Vector或C#的ArrayList(C#)。
只是，在处理对象的时候，需要一个类型转换的操作。
这个问题，在支持泛型的语言中不会存在，如使用C++的标准库的容器类。
◆ObjectCollection方法。
这个方法同上面的方法类似，不同之处在于，为每个实体类设计一个Collection类。
例如，可以为FormDetail设计一个FormDetailsCollection类(C#)：public class FormDetailsCollection: ArrayList{public void Add(FormDetail detail){base.Add(detail);}public new FormDetail this[int nIndex]{get{ return (FormDetail)base[nIndex];}}}这么做的好处在于，在操作集合中的对象时，不必进行类型转换的操作。
◆数据集的表示方法。
采用这种方法，通常是直接把从数据库查询中获取的数据集(Recordset)作为数据处理对象。
这种方法在ASP应用程序中是非常常见的做法。
这种做法简单，初学者很容易掌握，但是弊病也很多。
EJB的方法在J2EE体系中，对实体对象的处理的典型方法是Entity Bean。
J2EE中使用Entity Bean来表示数据，以及封装数据的持久化储存（同数据库的交互）。
