oracleobject设计毕业设计论文完整版设计论文

（此文档为word格式，下载后您可任意编辑修改！）根据上文OracleObject定义，也就是说，会有一张Trade表，一张Product表，一张Account表。其中通过Trade_ID的关联实现了数据层级表现这样做目的是不希望数据库的表设计与OracleObject太过紧密绑定，以免将来有数据库更换的需求或数据迁移的过程中，遇到不可估计的难度。虽然说没有完全用到OracleObject提供优势，可以在列上使用自定义的数据类型，方便存储和查询，但这里使用了一种折中的方案，放弃了一些性能上和编码上的便利，换来了系统今后升级的空间，而且性能的表现也完全在可接受范围内在V2版本中，所有Datasheet的保存都是在保存过程的基础上完成的，而OracleObject特性中允许用户自定义类型，因此我们运用OracleObject来保存和访问Datasheet。理由很简单，既然定义和使用了OracleObject，就可以在存储过程中充分使用其面向对象的特性，可以轻易的使用其属性和各种方法。举个例子来看，假设我们定义了INSERT_TRADE，即“插入一笔交易”这个类的保存过程，该类的参数是Trade_Object即交易数据，我们用该类的返回参数替代了返回列表。而操纵Trade_Object就和使用Java对象一样。例如需要使用Trade_id，只需要调用OracleObjectPOB_TRADE中的属性Trade_id就可以了，如POB_TRADE.Trade_id。而对于一个有层级结构对象的查修也非常方便，只需要把相应的表做关联，并把关联表中的属性作为参数传入与之对应的OracleObject的构造器内，就可以构建出Oracle对象。但是对于数组形式的属性，却不能像以上的方法设置，如ACCOUNT_LIST。对于数组我们只有重新定义其保存过程一种方法，如PKG_ACCOUNT.GET_ACCOUNT_LIST(POB_LIST_ID)这个类，其返回值是一个数组，我们必须定义一个外部数组变量作为过渡的变量，利用给该变量赋值将数组中的元素移出，将该变量与ACCOUNT_LIST建立连接。接着根据ACCOUNT_LIST的返回值，将外部数组变量里的元素按顺序逐一复制进ACCOUNT_LIST里的对象，最后移除该外部变量，释放空间，就完成了操作在完成了数据库方面设计和实现后，需要在Java端进行调用。首先需要利用OracleJPublisher生成相应Java类TradeObject，TradeObjectRef等与数据库对象一一对应的类后，就可以使用JavaJDBC的操纵这些类以OracleObject的方式进行调用了。首先定义ParamValuePairList，是传入SQL语句或者存储过程的参数的集合包括SqlInParameter，SqlOutParameter。如果没有OracleObject，当需要将数据插入到数据表中，特别当表的字段比较多时，SQL语句会变得非常长难以维护并且需要非常仔细的定义每个列顺序和保证每个数据类型是否一致；如果使用存储过程，将会有定义一系列参数，一般而言参数数量将会和表字段数一致。当数据表需要增加新字段或修改原有字段时，SQL或存储过程的维护都会变得非常困难。在引入OracleObject后，存储过程参数就一目了然，当插入数据到Trade表中，只需要传入TradeObject这个由JPublisher生成出来的Java对象。同时在完成插入操作后，需要通过查询数据表返回最新TradeObject，用来确保数据一致性。所以在ParamValuePairList里定义了SqlOutParameter是TradeObject.class，而SqlInParameter则是TradeObject对象，轻易的就把Trade_Object传递给了存储过程。（这里的存储过程INSERT_TRADE_OBJECT就是上文代码中提及的PROCEDUREINSERT_TRADE）当然为了支持OracleObject，还需要在原生的存储过程调用方法上进行一些改进。当存储过程的返回值是OracleObject时，原生的JDBC方法是不支持的。所以首先判断ParamValuePairList是否定义ORASqlOutParameter，如果存在，说明存储过程返回值是一个OracleObject。这样就需要返回值Class类型，调用其create方法去创建出这个OracleObject对象以上代码就是在V2版本中使用OracleObject主要流程。其主要作用是取代了Hibernate在V1版本中对于自定义数据存储实现，利用OracleObject面向对象特性，构建出与真实世界业务对象类似结构，类似于JavaPOJO操作，在存储过程中用OracleObject，这样在数据操纵和查询过程中利用Oracle自身优化引擎对存储过程中使用SQL优化，抛弃了由Hibernate生成HSQL，提高效率。根据测试结果，在20000条数据情况下，性能基本可提升一倍。不仅如此，在实际开发过程中，从某种程度上讲，它的开发效率并不比Hibernate差，甚至更好。但是不可否认，使用OracleObject后，也就意味系统和Oracle数据库有着紧耦合，并不利于将来有可能的重构，所以在系统中，多增加一个数据转换层。简单说就是业务数据模型还是使用JavaPOJO对象，而不直接使用OracleObject，仅仅数据存储层使用OracleObject，这样就需要增加个JavaPOJO和OracleObject数据存储间数据转换，带来好处就是若将来不在使用Oracle数据库，将不需要重构业务代码，只要替换相对应数据存储层即可4.3设计根据上文提及V1版本主要问题之一是大数据量查询以及数据在网络上传输问题，这样在V2版本系统中需要一种可以作为Cache存储空间以及有类似数据存储功能策略，这样就可减少数据库查询次数，从而加快速度。在解决这个问题上，考虑使用技术是Gemfire和ApacheCassandra。Gemfire可提供高度可扩展，弹性数据管理解决方案，确保企业和云解决方案的快速和可靠的数据访问，是种NoSQL基于Key-Value的技术。而ApacheCassandra则是基于列Key-Value第二代分布式数据库技术，而底层实现也是用JAVA实现。虽然二者可提供类似技术功能，但Gemfire是要付费，而Cassandra则是基于Apachelicense免费。而且由于系统都是基于JAVA语言设计实现，所以这里就选择ApacheCassandra作为系统解决大数据查询与传输问题主要技术。系统数据查询及数据通信都会使用Cassandra作中间媒介，当前数据更改不仅保存在数据库中，在Cassandra中也会保存。这种结构的优点在于系统主要对当前数据进行查询和操作，如果数据仅保存在数据库内，就会造成系统中各个模块会频繁查询数据库，进行多表查询及网络传输。由于各计算模块对于数据格式要求不同，需要对数据进行处理，造成性能瓶颈。而Cassandra多节点部署可及时响应各模块请求。若其中一个节点故障，其他有着相同数据备份节点可以继续为系统服务，而对于数据库来说如果数据库的连接被全部占有或是网络出现故障，系统将不得不停止服务。不仅如此，Cassandra可以部署在任何的机器上,当然也可在系统运行机器上,这样从某种程度上将减少了网络传输增加系统运行速度风险估值计算模块主要对用户提交风险计算请求作出业务处理，用户在客户端做任何风险计算业务操作请求，提交到后台风险估值计算模块对应方法中，后台服务会根据接收到的数据及相关的度量方法参数配置，会调用数据验证模块做相关联的数据验证，然后将交易数据传输到Cassandra里，而仅仅把运算唯一标示符和相关计算参数发送给计算引擎，最后把计算结果进行数据转化保存在Cassandra内,为系统的报表模块服务4.3.1查询对于Cassandra使用，首先需要定义Cassandra服务端信息，如名字，节点信息。接着需要通过Cassandra的命令行预先定义KeySpace和ColumnFamily，或者通过客户端在运行时动态的创建KeySpace和ColumnFamily。接下来就可以使用客户端去连接Cassandra其中的某一个节点然后存放读取数据了首先需要定义Cassandra的服务端信息（只列出一些比较关键属性）例如cluster_name：Cassandra集群名字。主要用于防止在一个逻辑集群里的机器在加入其他的集群Partitioner：分区的机制。在一个集群里，负责把行根据Key分配到节点上。其中RandomPartitioner是根据MD5的形式进行分配的，也是Cassandra建议的一种分配方式seed_provider：提供一个节点列表的接口。默认类是SimpleSeedProvider，需要以逗号为分隔的节点信息Seeds:节点IP地址，作为Cassandra与外界交互的连接点。该选项可以设置多个值，即Cassandra集群中有多个种子节点。集群中所有的服务器在启动的时候，都将于seed节点进行通信，从而获取集群的相关信息。如果某一台服务器被设置为seed节点，那么在启动的时候，将自动加入集群，并且不会执行Bootstrap的操作，即无法从集群的其他节点中获取相应数据在完成定义Cassandra的集群名字，节点信息后，需要在Cassandra服务端预先定义KeySpace和ColumnFamily的配置信息和其他一些辅助信息（类似于TableSchema和Table），本系统中是通过系统运行时动态加载其中分别使用CreateKey_Space和CreateColumnFamily去创建KeySpace和定义ColumnFamily后，就可使用KeySpace进行操作。就如第二章介绍，KeySpace有点类似于数据库Schema,而Cassandra里所有操作都是基于KeySpace，不同KeySpace数据也是不同的。这里使用Astyanax1.56.37作为客户端工具根据上述代码，可以清晰的看到客户端将会使用Cassandra的配置建立一个上下文，接着调用start方法启动Cassandra。当Cassandra启动后，就可以利用上下文获取KeySpace的，这样就可以使用这个KeySpace而获取数据了。如果希望使用其他的KeySpace下的数据，需要使用相同的逻辑与这个KeySpace建立连接从Cassandra内取出数据则是利用KeySpace的prepareQuery预定义好查询语句，然后真正去执行execute方法从Cassandra内取出数据。逻辑和JavaJDBC非常接近这样，当后台数据处理管理器收集完数据后，会把数据保存到数据库中，同时会把那些使用比较频繁的数据保存到Cassandra中去，为了加快系统的查询速度，建立了不同ColumnFamily。例如系统中最常用的是根据客户的唯一账号查询其名下的所有交易数据或者根据产品类型进行查询。根据以上代码，Cassandra主要根据KeySpace和ColumnFamily中的Key进行查询。就是说这里的queryKey就是客户唯一账号或产品类型。如果系统中需要重新实现一个新的查询，只需简单创建一个ColumnFamily，并用唯一Key去标示就可以系统会构建出一个基于客户账号ID查询，其中客户账号ID为Key，而ColumnFamily则是其所有的不同产品交易信息。与此同时，系统也会构建出一个局域产品类型的查询，其中产品类型作为Key,而ColumnFamily则是所有属于这种类型的产品。这样，系统在查询生产数据的时候不必每次都从数据库中查询在使用Cassandra过程中，为加快系统查询速度，往往会建立很多冗余数据，其实很多数据都是类似甚至一样的。换句话说，就是用空间换速度。所以，在系统的开发中，一般会根据以下原则去决定是否需要建立新的查询呢（ColumnFamily）。首先必须知道系统中有哪些经常使用的大数据量查询，一般而言这样的查询不会很多，而且不会经常变动。这种做法是把查询的压力转换到了更新的操作上了，因为当数据变动时，Cassandra内的数据也必须更新。而Cassandra的更新操作是经过优化的，作为一款可靠的大规模的分布式存储系统，其在更新速度上是非常快的。这样Cassandra就解决了系统中大数据量频繁查询问题4.3.2传输在用户查询完数据后，对交易数据的传输是系统中又一比较重要的功能。在系统V1版本中主要的问题有二个，一是交易数据信息量太大，在频繁的操作下，造成性能低下；二是模块的紧耦合，系统计算必须等待计算引擎返回计算结果，并多次访问数据库。在引入Cassandra后，当系统接收到计算请求后，只需要把数据信息传输到Cassandra里并生成唯一的运算标示符传递给计算引擎，计算引擎会根据这个标示符从Cassandra中读取需要的数据，同样在结果的处理和报表服务中也只需要从Cassandra中读取就可以了。这样做的好处是减少了数据库的频繁访问；实现了系统和计算引擎之间的松耦合，实现了真正的分布式。这样Cassandra的存在着实解决了前文所描述的系统V1版本中问题如4.3.1所描述，首先需要使用Cassandra服务器并建立连接，然后可以简单实现把数据保存在Cassandra里，实现数据的传输示例代码会将数据保存到Cassandra的KeySpace里这里首先根据KeySpace准备好一个类似与Connection的客户端，然后使用withRow()定位一行，其中columnFamilyDefinition是ColumnFamily的定义，domainQueryCacheKey是ColumnFamily的Key,最后使用putColumn把一条数据放入Cassandra内这样就实现了使用Cassandra作为中间的媒介进行数据传输。系统会整合所有的需要计算的数据，然后生成一个专门的ID作为Key，数据的具体属性作为Column，保存在Cassandra的Context上，然后仅仅传递给后台一个ID。最后后台计算引擎会根据这个ID从Cassandra中取出相关的数据，然后进行计算，随后把计算出来的结果也保存在Cassandra中。这样，系统就不需要与计算引擎紧紧依赖，也不会由于数据量大而造成网络的阻塞在风险估值计算模块，除了使用Cassandra提高了系统的容错性和运行速度，也是用了多线程技术提高了系统对于计算请求的吞吐量。通过线程池的原理接受不同的计算请求然后发送给不同的接收者，不仅如此依然采用多线程Future处理返回的结果集，进一步提高了计算速度4.4设计验证模块的输入是用户自定义的模拟交易数据，经过不同验证规则的验证，输出则是验证报表。在V1版本中，由于支持的金融产品种类不多，在验证模块实现的过程中，更多的是使用硬编码的形式进行逻辑处理。代码中存在着过多的if-else。随着系统支持的产品和业务需求的不断增加，使得目前的验证模块难以编码和维护，而且其结构也不适于目前需求。目前验证模块的主要需求是基于以下几点1验证的级别。其中包括Hard警告和Soft警告。Hard警告表示数据的错误致命的,用户必须对数据进行相应的修改，否则无法进行下一步操作。而Soft警告是告诉用户有些数据的输入不太正确，但这些数据不会影响下一步的操作。这些警告将以报表形式通知用户2产品的多样化。随着产品的增加，验证规则也呈几何式递增，如果继续使用硬编码的形式，不仅难以开发，而且将来也难以维护，不适合系统的发展空间3设计更灵活。将来有可能需要提供给用户自定义验证规则的页面。也就是说验证规则处理除了需要支持正常的验证处理，还需要支持动态的修改。这些将来的需求都要在目前的设计中加以考虑，其中有一个难点，就是如何保存这些动态修改的数据以及如何同步修改后的数据根据对V1版本的研究，目前的结构已然不适合目前的需求和将来的变动，所以验证模块的重构势在必行。在V1版本中，主要使用了ApachecommandChain来实现验证模块，根据不同的条件，遍历不同的CommandChain(命令链)。VaREligibleService是验证的接口，在实现中定义了某个产品类型和相关命令链的映射VaRCommandMap，每一条命令链都会服务于某一个特定的产品并将验证的结果返回给接口并放到一个结果映射集中，最终解析这个结果映射集生成验证报告。其中验证规则都是硬编码在系统里的，而且需要遍历数据源同步的进行验证。这里可以得出，验证需要遍历输入数据源然后等待每一笔数据的结果，时间比较长；因为硬编码的问题，使得产品验证的规则难以维护，无法抽象出通用的验证规则，基本无法实现数据验证规则的动态修改根据系统要求和业务需求，对系统中验证模块进行了重构。主要是基于SpringSPEL表达式语言的一种验证。Spring表达式语言是一个功能强大的表达式语言，它支持在运行时查询和操纵的对象图。验证模块所有的验证最后将解析成SpringSPEL表达式进行验证。首先会定义一个模板类（FilterTemplate）,把所有产品验证规则抽象出来，做集中处理。这些验证规则会全部保存在数据库并在系统启动的时候加载到Cassandra内。Build类，每一个产品都会有一个Build类，里面会定义其需要的所有验证规则，有效值以及错误提示消息，规则的定义必须与Template里定义的互相匹配。这些针对每个产品的验证规则会通过JavaAnnotation解析成XML保存在数据库内，并加载到Cassandra内。这里的思路基本是在Annotation基础上，定义一套验证机制，针对不同验证建立一系列内置的验证规则，通过JAXBAnnotation转成XML格式保存在数据库中，同时针对不同产品的有效值、验证值也根据产品对象上的Annotation，通过JAXBAnnotation转成产品的样板。这样根据验证规则和产品样板有效地解决了验证多样化、验证规则多的情况。在进行验证处理的时候，会把每一个产品的验证规则（XML）和模板进行匹配，最终解析成SpringSPEL表达式进行处理。因为每一个产品的验证没有依赖关系，使用了线程池来调用验证服务来验证每一种产品，并通过线程的返回值组装成可读报表。对于动态修改验证规则，则是通过直接修改数据库值并放到Cassandra内来做到的，在引入Cassandra后，Cassandra会根据不同的策略进行数据同步。所以在同步机制上不会存在问题，同时由于Cassandra节点获取不同策略，使得系统在获取数据可以实现一致性上。这样设计的好处在于：验证规则集中化，便于管理；产品特定的规则逻辑独立，互相没有依赖；规则命名规范统一；数据规则最终保存在数据库内，抛弃了代码级别的规则定义，便于动态更改；Cassandra的使用则加快了运行速度，以及正常验证处理和动态改动之间的隔离重构后的验证模块，ValidationService是验证逻辑的入口，主要负责对输入交易数据进行分类，根据交易产品的类型，将交易数据放置在一个Map对象内。不同产品之间的验证没有直接关系或者依赖，所以说每一个产品的验证相对独立。使用了一个线程池概念，线程池大小目前定义为产品种类的数量，线程定义为实现Callable接口,目的是为获取返回值。ExecutorCompletionService可以将已完成任务与未完成的任务分离出来,ExecutorCompletionService会把那些已经完成的任务的结果放在LinkedBlockQueue队列上，并使用take方法获取LinkedBlockQueue队列上任务结果。调用submit方法提交验证任务，其中使用ValidationProcess根据Build和FilterTemplate互相协作生成出最终的返回值。完成的任务会把返回值以Future类的形式保存在队列上，通过take方法可以获取到这个Future对象，如果take方法获取返回的结果与提交请求的数量不一致，说明还有线程正在执行，继续等待。在验证过程中把不同的产品放置在不同的线程中运行，每一个线程会根据产品类型获取相关的验证服务，并最终把验证结果保存到数据库中并通过Future类把结果返回给ValidationService。ValidationService最后对数据进行整合，生成相关验证报告具体的多线程调用核心代码如下验证规则定义设计是验证模块值得推荐的一种设计方案。首先定义规则类规则,包括domain,calculationType，filter三个字段。Domain是最高层级分类，是为了将来扩展预留字段，目前系统只有一个Domain。calculationType表明是不同计算方法，如VaR,CCP,Stress,不同计算方法对于产品有着不同验证规则，而filter则是针对特定的calculationType定义包括所有产品验证模板。FilterTemplate以SpringSPEL的语言定义着所有需要验证字段的验证规则，并把同种业务逻辑的验证归类，例如组名ProductFilter表明只针对产品特性，而组名AccountFilter则是针对帐号验证；而CUSIP则是属于需要验证的字段，其值是类似于SPEL表达式语言，同时它属于产品特性验证，所以属于ProductFilter组。当系统启动，会通过Hibernate先去数据表中查询是否有最新FilterTemplate，如果存在则在加载它并放入Cassandra验证KeySpace下，如果不存在则会读取代码中编写的默认模板并保存在数据库内。FilterTemplate参数列表为Domain,组名，属性名，验证表达式。(Cassandra代码示例不在此处列举。)这里数据库将保存所有验证规则历史数据，以便将来的代码追溯接下来需要定义每个产品的验证规则，使用Build类进行构建。Build类会构建出针对一个产品所需要的验证。Filter类是用来设置每个验证规则，就是说Filter就是定义验证规范的类，例如简单非空验证，使用SimpleFilter；属性值是否在列表中，使用PreconditionFilter等。不仅如此，在Build类里还需要定义与FilterTemplate模板中相对应组名和属性名以及产品对象中真正属性字段值和验证结果信息根据上述代码，Filter参数列表序列是组名（与FilterTemplate组名匹配），属性名（与FilterTemplate属性名匹配），真实需要验证属性,验证规则（这里NonNullValue表明验证字段是否为空），错误提示消息。这样产品验证规则就可以与Template匹配，根据先前定义的不同Filter类，最终转换成SpringSPEL表达式语言，做最终的验证。利用Filter生成SPEL语言。以SimpleFilter为例，其中resultExpression是从template里获取的定义的验证规则，如上文提到Notional规则里的第三个参数：notional。SimpleFilter一般用于判断是否为空验证，根据inNot()的值，最后生成Spring可识别的语言最后利用SpringValitionframework里的API构建出expression并使用getValue方法对数据进行验证通过上述代码的共同合作，不仅从业务逻辑上实现了验证模块的业务需求，而且在扩展性上都为以后的设计预留了空间，例如抛开动态规则的修改功能，如果将来有新的验证需求，只需要在Template里定义一个新的验证模板，同时在产品验证的规则类Build里新加一条验证就足够了。至于定义真正规则实现的Filter类，如果说验证的方法超出了目前的支持度，只需要新创建一个类并继承Filter类就可以了。从性能上来看，引入Cassandra后，首先验证数据可以直接从Cassandra中获取，而不必从数据库内获取，虽然说在数据量小的时候，性能并没有太大的提升，但是当数据量大时和数据验证比较频繁时，性能提升还是非常明显最后，简单介绍一下动态验证规则修改的处理逻辑。根据V1版本的设计，因为所有的代码都是硬编码在代码中的，实现这部分功能基本是不可能的。而根据V2版本的设计，动态验证规则的接口只需要直接操作数据库就可以了，并把最新的规则推送到Cassandra内去就可以了，原理就在于系统都启动的时候都是先从数据库加载的，而系统运行时都是从Cassandra内获取的，从而解决了动态修改的逻辑。这块功能还在实现过程中，这里省略了代码实现部分综上所述，验证模块最新的设计是V2版本的一个重点，目前的设计基本覆盖功能和扩展的要求4.5比较从业务上讲,银行保证金风险管理系统版本V2实现了跨产品的风险估值计算，极大程度上加强了对客户整个资产组合的风险监控，降低了公司运营的风险，对金融机构技术支持平台来说，是一种创新；从技术上讲，基于多线程技术，JavaAnnotation,双数据库引擎的架构重新设计系统，通过数据统一，模块之间的业务独立，松耦合大大缩短设计、开发的时间，降低企业的成本；通过模块的优化和缓存机制的使用，解决了V1版本中的不足之处，实现了数据的共享和性能的提升。银行保证金风险管理系统版本V2在系统设计思想和采用的技术上具有明显的自身特点。银行保证金风险管理系统版本V2与版本V1相比较，组要体现在系统的体系结构、开发框架以及开发技术等与V1相比较，V2版本中采用了目前主流的多层架构体系，结合B/S结构以及Spring框架技术。多层架构更加方便模块化和标准化、项目结构比较清晰、各层次之间分工明确、耦合度低、可复用，有利于开发维护和系统日后需求扩展和功能升级。银行保证金风险管理系统V2采用双数据库引擎多线程的设计思想及方法。与V1相比较，V2版本可以任意存储需要的数据，同时利用其多节点的特性增加系统的可容性，提供运行速度，使系统以最大程度地实现现有资源共享、避免重复建设为目标，利用先进的信息和网络技术手段，通过对业务需求和功能的梳理，轻松实现了交易数据和计算结果的共享以及业务上的需求；同时利用多线程技术线程池的概念和Java新特性Callable支持有返回值的特性，提高了系统的业务处理能力，从而使得客户能及时得到数据响应，提升用户体验；同时利用JavaAnnotation实现了部分可配置的业务逻辑，使得系统可以快速适应业务流程变化，并且具备更好的健壮性，可维护性4.6效果保证金风险管理系统在使用了基于OracleObject技术和Cassandra作为缓存区的双数据库引擎以及多线程池的适当使用，JavaAnnotation的灵活配置等技术等特点后，得到了来自外部客户和内部业务操作员广泛的好评。系统可以将来自其他交易平台交易数据相对快速的保存到数据库，相对于V1版本的保存速度，提升了接近五倍。当业务操作员进行数据查询的时候，很少再会因为页面超时或者数据展示慢而抱怨了。同时在业务员进行风险计算时，系统提供了及时，可靠的验证回馈信息，和原来的V1版本相比，性能得到了明显的提升，是原来验证处理速度的五倍，用户体验良好。系统的稳定性的提升也使客户的使用感受更佳对系统的核心模块进行重新设计后，提高了系统的可扩展性和兼容性，提高了系统的服务质量。因为在系统开发中，重用了V1版本中的一些模块，节约了整体的开发成本和时间，同时重新设计的模块更加独立，抽象，极大程度上实现了模块的松耦合，当新业务增加时，节约了开发时间，从而加快了开发过程，以较短的时间实现了系统的基本功能，展现给用户，提高了系统的可信度，留给了客户更深的印象，给企业带来了直接的经济收益银行保证金风险管理系统的设计和实现 第5章总结与展望第5章5.1总结截止到目前银行保证金风险管理系统发布的版本，已然广泛的被公司内部使用，根据每天最新的市场数据和历史数据得出最新的保证金计算，可以清晰的得到公司客户的资产情况，从而决定是否需要一个保证金电话(Margincall)。同时因为系统出色的理念和较为正确先进的计算方法以及实实在在的商业价值，所以被很多外部用户认可，主要外有香港、伦敦、德国、澳大利亚等地的客户。外部客户会在系统中设定账号，然后可以每天从系统中了解自己和本公司所有交易的风险估值，用来监控账户的金融风险。以目前银行保证金风险管理系统应用表现来说，具体结论如下：1、方便了客户了解其整体或投资组合的风险状况和通过计入抵押品向交易公司以抵消损失的初始保证金要求银行保证金风险管理系统不仅每天会收集客户在不同系统中的不同金融产品交易的数据而且会收集基于这些交易的历史数据，然后计算出对于客户整个公司的风险状况和每一笔交易的风险状况，同时提供不同层面和不同角度的报表，提供给客户更加直观的风险度量。同时由于对不同的金融产品做了整合，使得客户不需要到不同系统中去了解其不同的风险状况，节省了时间，而且也不用给每个系统支付相应的保证金，因为保证金将会通过银行保证金风险管理系统被整合在一起，这样就减少了客户的流动资金的压力2、电子化合约，定制化合约以前如果客户需要和公司签约使用系统，可能需要准备大量的文件，然后一份份签字。现在通过银行保证金风险管理系统，可以在几分钟内和公司完成电子化合约，达成合作协议。不仅如此，还可以个性化定制合约内容，比如需要哪些风险估算或报表。这也是吸引客户的重要功能之一3、不仅提供客户真实数据的报表，也可以通过实时计算提供给客户对于将来某笔交易提前预测的风险估值客户不仅可以通过系统后台的批处理模块生成不同报表，也可以通过系统模拟那些将来可能成交的交易，并把这笔交易加入到当前的资产组合中，主要通过多线程和网络技术实时的发送请求进行计算，返回给用户增加了新的交易后的资产组合的风险评估，使得客户可以了解到这笔交易对于目前公司资产组合情况的影响，提供了很大的便利度，成为了吸引客户的又一把利器4、系统设计人性化，使用方便本系统提供了很多人性化设计的表现，例如不同级别的验证信息可以让用户一目了然的知道错误、报警图片的延时加载、不同级别的报表系统，功能清晰的菜单功能等等。这些功能上细节的设计方便了用户的操作，使用户使用本系统感觉更加方便易用5.2展望目前在金融市场上的产品多种多样，金融创新也不断出现，同时由于银行内部对于不同金融产品的支持有着不同的系统，而系统需要从这些系统中收集金融产品的信息，这样就给项目中实现的银行保证金风险管理系统带来了一定的难度。具体来说，现阶段基于Java开发的银行保证金风险管理系统在未来可以在功能性上和技术上，二个层面做不同的完善1.接入更多的业务平台，支持更多的金融产品在本软件系统中，金融产品的覆盖率是整个软件被客户接受的重要指标之一。越多的金融产品被集成到系统中，意味着对于客户来说不需要到不同系统中去估算不同产品的风险估值，从而可以在本软件系统中得到整个资产组合更加精确的风险估值。因为不同金融产品的风险估值得到了整合，所以减少了流动资金的压力。随着不同的金融产品集成到系统中来，对于系统的挑战是与不同的金融系统交互获取数据以及对数据的处理和呈现2.风险种类的扩展，例如信用风险估算如前文介绍，目前银行保证金风险管理系统可以支持VaR(ValueatRisk),CCP(结算中心的风险估值),Stress(压力测试)，虽然已经可以覆盖了行业内流行的风险计算方式，但是从另一方面看，这些风险价值估算是基于一个公司所拥有的所有交易根据历史数据和当前的金融环境，利率市场的估算，并没有考虑到公司本身或者交易涉及到的公司的信用状况。在金融危机后，信用风险变的尤为关键。比如，A公司目前在市场是的评级为AA,那么它所发行的债券的成交价格在98元。如果说到了第二年，A公司的评级为BB，那么它所发行的债券在市场中成交价格可能只有78元。那么其实对于持有A公司债券的公司是有风险的。所以说如果可以增加信用风险的评估，会对银行内部或者外部客户提供更为全面的风险管理。那么对于系统相应的就提出了挑战，如何搭建新的业务流程去支持新的需求3.用户界面设计的优化在目前实现的系统中，因为金融产品的多样性和不同的风险价值估算方法，导致对于同一种产品，要求的数据属性也是不一致的，使得页面表述不够清晰，这样对于用户来说在页面定制一个交易比较困难和复杂。同时由于不断的有新的金融产品加入到系统中来，导致页面很难维护。与此同时，前台页面是基于EXTJS搭建的，在显示大数据量的时候，由于EXTJS需要构建自己的数据格式，往往导致数据响应时间长的问题4.系统功能上细分依然不够完善举例来看，就如1、2两点提到的将来可能会有新的业务增加的需求，所以说系统的功能并不完善。不仅如此，就系统功能上来看，还有