SAP系统架构是什么

SAP系统架构是什么

创新互联主要从事成都网站建设、网站建设、网页设计、企业做网站、公司建网站等业务。立足成都服务屏边,十余年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:028-86922220

SAP是英文“Systems,Applications and Products in Data Processing”的缩写,其开发公司SAP公司是目前全球应用最广的企业管理和协同化商务解决方案供应商。下面让我们一起来看看什么是SAP系统架构。

1 SAP系统的三层架构

SAP是一个基于客户/服务机结构和开放系统的、集成的企业资源计划系统[3]。其功能覆盖企业的财务、后勤(工程设计、采购、库存、生产销售和质量等)和人力资源管理、SAP业务工作流系统以及因特网应用链接功能等各个方面。SAP系统的运行环境是该系统的核心部分,其主体是由C及C++语言编写,也有一部分有SAP自身开发到程序语言ABAP编写。

SAP系统的核心执行以下几个任务:

1)运行SAP程序:所有的SAP程序都在一个软件处理器(虚拟机)中运行。

2)提供数据库读写服务:SAP程序并不直接对数据库进行操作,而是通过自身的Database Interface,使用SAP Open SQL(Structured Query Language)对底层数据库进行读写。

3)通讯服务:SAP程序可与其他SAP程序进行通信,同时也可与非SAP程序通过BAPI接口进行通信。

4)系统监控:用户可对SAP程序的运行进行监控及改变运行环境参数。

SAP系统是一个典型的Three-Tier系统架构,由表现层,应用层及数据库构成(图1):

1)SAP系统架构表现层(Presentation Layer):这是SAP用户图形界面(SAP GUI),是SAP用户和SAP系统交流的接口,用户登录后对SAP系统进行操作。通过这图形界面用户可对SAP发出指令或递交数据给应用层,应用层接收到指令或数据后,会进行相应的计算操作,之后底层将处理后把数据返还给表现层。

2)SAP系统架构应用层(Application layer)这层包括一个或者多个应用服务器(ABAP Programm)和一个消息服务器(ABAP Dispatcher)。每一个应用服务器包括一系列服务以便运行应用程序。Dispatcher是系统应用层的核心,所有从客户端传递进来的请求都将首先传递到消息服务器中,消息服务器首先按照First in First out的原则将所有请求排序,然后将用户请求依次传递给空闲的工作进程(Work Process)中,每个工作进程在某一时刻只能处理一个用户请求。工作进程会根据具体的要求通过Open SQL到数据层中读取对应的数据。

3)SAP系统架构数据库层(Database layer):这里存放了所有SAP系统的数据。SAP系统通过自身的标准语言Open SQL对数据库进行管理,同时实现了上层应用于底层数据库类型的不相关性。SAP支持很多数据库系统,包括:Microsoft SQL Server,ORACLE,INFORMIX,DB2等。

2 SAP系统的数据库接口

SAP系统支持多种数据库,SAP程序可通过SAP Open SQL对数据库进行读写,SAP Open SQL的编写不依赖于数据库的类型。在图2中所示的数据库接口是SAP应用层中一个重要的组成部分,它将Open SQL指令转换成与数据库类型相应的SQL语句(Native SQL)。这样使得在SAP开发时无需考虑底层数据库的类型。在数据库接口对Open SQL进行转换时会先对验证其语法,并自动最大限度使用本的'缓存来优化数据库的操作。人们也可在SAP程序中直接定义与数据库类型相应的SQL指令(Native SQL)来读写数据库中数据。

3 总结

任何ERP软件都不可能覆盖企业的多样性和复杂性的所有方面,对于企业的特殊要求用户可自行进行必要的二次开发,并要求同其他应用软件也可方便地集成。这就要求供应商提供的软件都能具有很强的开放性,而充分利用这种开放性的前提就是必须熟知其系统的基本架构。本文通过对SAP系统的三层结构和数据库接口的分析使大家更能深层次的了解SAP系统的系统框架,能够更好的使用SAP系统。

;

一文读懂 UML 用例图

当你脑子里有一个商业案例时，你该怎么向老板介绍呢？一大段文字，或是动手写个 Demo？老板很忙，老板也不见得懂你所说的“高大上”技术，有没有那种实现成本较低但又包含较多信息的表现方式呢？有，画张图呗！

今天起再开个专题，谈谈我们开发中常用到的一些图形建模手段。前言结束，我们从 UML 视图启航。

UML——Unified Modeling Language——统一建模语言，是业务建模阶段最常用和最重要的一种视图。由于它简单易懂，常常用于跨组织的文档或演示的说明中；这里所谓的跨组织指的不仅仅是开发部门间，而是指跨产品、设计、测试、运维等等部门的业务交流中。UML 设计中，第一张图一般都是用例图：是的，就是那个有“小人”的图。

用例图主要有三个部分组成：用例（Use Case）、参与者（Actor），以及它们互相间的关系（Relationship）；形式上就是用椭圆、小人，以及箭头的连线组合。

我们先不细说椭圆或是箭头的具体含义。我觉得讲用例图最好还是从具体的 Use case 入手为好。我们试着设计一款简单的银行 APP，它包含注册、登陆、交易等等操作。我们一步步拆解挥着用例图的过程。

画用例图的第一步通常是拖出一个巨大的矩形块，并将其命名为我们的目标系统——Banking App。一个用例图一般只会有一个 System，之后我们会把所有该系统相关的是功能（“用例”）放置在系统内部，系统的相关方（“参与者”）放置在系统的左右两侧。

第二个绘制元素就是参与者，即系统相关方，可以是人、组织、外部设备，或是其他系统。在我们这个银行案例里，该 App 的相关方有两个：就是客户（Customer）和银行（Bank）。

通常来说，一个用例图中会有两三个参与者，我们会把主要参与者放在系统左侧，次要参与者（主要参与者的回应方）放在右侧；显然我们的 App 主要是面向客户的，所以把客户放在了左边。

第三步就是在系统内添加具体的用例，也就是该系统所提供的功能或是业务块。我们的银行 APP 比较简单，只提供如下业务：

第四步，我们再把参与者与用例串联起来，就是我们所说的关系（Relationships）。用例图中，关系还可以继续细分：

最后，所有 UML 视图事实上都可以加注释，专业术语叫延伸（Extension points）和批注（Note）；这两种注释性质形同，都是起说明作用：

好了，UML 用例图大体就讲完了。我们再回顾一下用例图的使用场景，在产品设计阶段，我们可以使用用例图为用户、系统和功能服务建立起抽象关系，以便描述产品所呈现的外部动态特征。在一些大厂中，通常由产品经理或是设计师来首先绘制 UML 用例图，再交于开发团队实现。

我们举了一个银行 App 的例子，事实上有点大了；现实开发中，一个 Use Case 图通常只对应的一个简单的业务流而已。我们自己在写用例图时，也要注意在宏观层面将联系紧密的功能模块抽象为一个简单的 Case，然后逐步地为这些较大的功能模块画出细分 Case 的用例图。

UML设计中分析类图和设计类图的区别

UML类图的概念

一、概述

UML类图（Class Diagram）是描述类、接口、协作以及它们之间关系的图，用来显示系统中各个类的静态结构。UML类图是定义其他图的基础，在UML类图基础上，可以使用状态图、协作图、组件图和配置图等进一步描述系统其他方面的特性。

UML类图包括7个元素：类（Class）、接口（Interface）、协作（collaboration）、依赖关系（Dependency）、泛化关系（Generalization）、关联关系（Association）以及实现关系（Realization）。

二、类

类定义了一组有着状态和行为的对象。其中，属性和关联用来描述状态。属性通常用没有身份的数据值表示，如数字和字符串。关联则用有身份的对象之间的关系表示。行为由操作来描述，方法是操作的实现。对象的生命期则由附加给类的状态机来描述。

1、 名称：类的名称是每个类中所必有的构成元素。

2、 属性（Attribute）

（1） 可见性：类中属性的可见性主要包括公有（public）、私有（Private）和受保护（Protected）。在UML中，公有类型的用“+”表达，私有类型用“-”表达，而受保护类型则用“#”表达。UML的类中不存在默认的可见性，如果没有显示任何一种符号，就表示没有定义该属性的可见性。

（2） 属性名：按照UML的约定，单字属性名小写。如果属性名包含多个单词，这些单词要合并，且除了第一个单词外其余单词的首字母要大写。

（3） 属性字符串。属性字符串用来指定关于属性的其他信息，例如某个属性应该是永久的。任何希望添加在属性定义字符串值但又没有合适地方可以加入的规则，都可以放在属性字符串里。

（4） 类属性。属性也可以作为一个类属属性来定义，这就意味着此属性被该类的所有对象共享。在UML类图中，类属性带有一条下划线。

3、 操作。类的操作是对类的对象所能做的事务的抽象，相当于一个服务的实现。

4、 职责：在操作部分下面的区域，可以用来说明类的职责。职责是类或其他元素的契约或义务。类的职责是是自由形式的文本，写一个短语，一个句子等。在UML中，把职责列在UML类图底部的分隔栏中。

5、 约束。说明类的职责是消除二义性的一种非形式化的方法，形式化的方法是使用约束。约束指定了该类所要满足的一个或多个规则。在UML中，约束是用一个花括号括起来的自由文本。

三、接口

接口包含操作但不包含属性，且它没有对外界可见的关联。

四、类之间的关系

类之间的关系最常见的有四种：依赖关系、泛化关系、管理关系、实现关系。

UML对象图

一、概述

UML对象图(Object Diagram)描述的是参与交互的各个对象在交互过程中某一时刻的状态。对象图可以被看作是UML类图在某一时刻的实例。

在UML中，对象图使用的是与UML类图相同的符号和关系，因为对象就是类的实例。下图显示了对象图的模型。其中节点可以是对象也可以是类，连线表示对象之间的关系：

二、UML类图和对象图的区别

标题名称：关于SAP系统uml设计图的信息
标题来源：http://kswjz.com/article/dojcicc.html