DR-PrologA System for Reasoning with Rules and Ontologies on the Semantic Web

DR-PrologA System for Reasoning with Rules and Ontologies on the Semantic Web
DR-PrologA System for Reasoning with Rules and Ontologies on the Semantic Web

Abstract

Defeasible reasoning is a rule-based approach for

efficient reasoning with incomplete and inconsis-

tent information. Such reasoning is, among others,

useful for ontology integration, where conflicting

information arises naturally; and for the modeling

of business rules and policies, where rules with ex-

ceptions are often used. This paper describes these

scenarios in more detail, and reports on the imple-

mentation of a system for defeasible reasoning on

the Web. The system (a) is syntactically compati-

ble with RuleML; (b) features strict and defeasible

rules, priorities and two kinds of negation; (c) is

based on a translation to logic programming with

declarative semantics; (d) is flexible and adaptable

to different intuitions within defeasible reasoning;

and (e) can reason with rules, RDF, RDF Schema

and (parts of) OWL ontologies.

1 Introduction

The development of the Semantic Web [Berners Lee et al., 2001] proceeds in layers, each layer being on top of other layers. At present, the highest layer that has reached suffi-cient maturity is the ontology layer in the form of the de-scription logic based languages of DAML+OIL [Connolly et al., 2001] and OWL [Dean and Schreiber, 2004].

The next step in the development of the Semantic Web will be the logic and proof layers that will offer enhanced representation and reasoning capabilities. Rule systems ap-pear to lie in the mainstream of such activities. Moreover, rule systems can also be utilized in ontology languages. So, in general rule systems can play a twofold role in the Se-mantic Web initiative: (a) they can serve as extensions of, or alternatives to, description logic based ontology languages; and (b) they can be used to develop declarative systems on top (using) ontologies. Reasons why rule systems are ex-pected to play a key role in the further development of the Semantic Web include the following:

Seen as subsets of predicate logic, monotonic rule sys-tems (Horn logic) and description logics are orthogo-nal; thus they provide additional expressive power to ontology languages.

Efficient reasoning support exists to support rule lan-

guages.

Rules are well known in practice, and are reasonably well integrated in mainstream information technology. Possible interactions between description logics and monotonic rule systems were studied in [Grosof et al.,

2003]. Based on that work and on previous work on hybrid reasoning [Levy and Rousset, 1998] it appears that the best one can do at present is to take the intersection of the ex-pressive power of Horn logic and description logics; one way to view this intersection is the Horn-definable subset of OWL.

This paper is devoted to a different problem, namely con-flicts among rules. Here we just mention the main sources of such conflicts, which are further expanded in section 2. At the ontology layer:

Default inheritance within ontologies

Ontology merging

And at the logic and reasoning layers:

Rules with exceptions as a natural representation of business rules

Reasoning with incomplete information

Defeasible reasoning is a simple rule-based approach to reasoning with incomplete and inconsistent information. It can represent facts, rules, and priorities among rules. This reasoning family comprises defeasible logics [Nute, 1994; Antoniou et al., 2001] and Courteous Logic Programs [Gro-sof 1999]. The main advantage of this approach is the com-bination of two desirable features: enhanced representa-tional capabilities allowing one to reason with incomplete and contradictory information, coupled with low computa-tional complexity compared to mainstream nonmonotonic reasoning.

In this paper we report on the implementation of a defea-sible reasoning system for reasoning on the Web. Its main characteristics are the following:

Its user interface is compatible with RuleML [RuleML], the main standardization effort for rules on the Semantic Web.

DR-Prolog:A System for Reasoning with Rules and Ontologies on the Semantic Web

Grigoris Antoniou and Antonis Bikakis

Computer Science Department, University of Crete, Greece

Institute of Computer Science, FORTH, Greece

{antoniou,bikakis}@ics.forth.gr

It is based on Prolog. The core of the system consists of a well-studied translation [Antoniou et. al., 2001] of defeasible knowledge into logic programs under Well-Founded Semantics [van Gelder et al., 1991]. This de-clarative translation distinguishes our work from other implementations [Grosof et al., 2002; Maher et al., 2001].

The main focus is on flexibility. Strict and defeasible rules and priorities are part of the interface and the im-plementation. Also, a number of variants were imple-mented (ambiguity blocking, ambiguity propagating, conflicting literals; see below for further details).

The system can reason with rules and ontological knowledge written in RDF Schema (RDFS) or OWL.

The latter happens through the transformation of the RDFS constructs and many OWL constructs into rules.

Note, however, that a number of OWL constructs can-not be captured by the expressive power of rule lan-guages.

As a result of the above, DR-Prolog is a powerful de-clarative system supporting

rules, facts and ontologies

all major Semantic Web standards: RDF, RDFS, OWL, RuleML

monotonic and nonmonotonic rules, open and closed world assumption, reasoning with inconsistencies. The paper is organized as follows. Section 2 describes the main motivations for conflicting rules on the Semantic Web. Section 3 describes the basic ideas of defeasible reasoning. Sections 4 describes the translation of defeasible logic, and of RDF, RDFS and (parts of) OWL into logic programs. Section 5 reports on the implemented system. Section 6 dis-cusses related work, and section 7 concludes with a sum-mary and some ideas for future work.

2 Motivation for Nonmonotonic Rules on the

Semantic Web

We believe that we have to distinguish between two types of knowledge on the Semantic Web. One is static knowledge, such as factual and ontological knowledge which contains general truths that do not change often. And the other is dynamic knowledge, such as business rules, security poli-cies etc. that change often according to business and strate-gic needs. The first type of knowledge requires monotonic reasoning based on an open world assumption to guarantee correct propagation of truths. But for dynamic knowledge flexible, context-dependent and inconsistency tolerant non-monotonic reasoning is more appropriate for drawing prac-tical conclusions.

Obviously, a combination of both types of knowledge is required for practical systems. Defeasible logic, as described in section 3, supports both kinds of knowledge. Before pre-senting its technical details, we motivate the use of non-monotonic rules in more detail.

Reasoning with Incomplete Information:Antoniou and Arief[2002] describe a scenario where business rules have to deal with incomplete information: in the absence of cer-tain information some assumptions have to be made which lead to conclusions not supported by classical predicate logic. In many applications on the Web such assumptions must be made because other players may not be able (e.g. due to communication problems) or willing (e.g. because of privacy or security concerns) to provide information. This is the classical case for the use of nonmonotonic knowledge representation and reasoning [Marek and Truszczynski, 1993].

Rules with Exceptions: Rules with exceptions are a natu-ral representation for policies and business rules [Antoniou et. al, 1999]. And priority information is often implicitly or explicitly available to resolve conflicts among rules. Poten-tial applications include security policies [Ashri et al., 2004; Li et al., 2003], business rules [Antoniou and Arief 2002], personalization, brokering, bargaining, and automated agent negotiations [Governatori et al., 2001].

Default Inheritance in Ontologies: Default inheritance is a well-known feature of certain knowledge representation formalisms. Thus it may play a role in ontology languages, which currently do not support this feature. Grosof and Poon [2003] present some ideas for possible uses of default inheritance in ontologies. A natural way of representing default inheritance is rules with exceptions, plus priority information. Thus, nonmonotonic rule systems can be util-ized in ontology languages.

Ontology Merging: When ontologies from different au-thors and/or sources are merged, contradictions arise natu-rally. Predicate logic based formalisms, including all current Semantic Web languages, cannot cope with inconsistencies. If rule-based ontology languages are used and if rules are interpreted as defeasible (that is, they may be prevented from being applied even if they can fire) then we arrive at nonmonotonic rule systems. A skeptical approach, as adopted by defeasible reasoning, is sensible because it does not allow for contradictory conclusions to be drawn. More-over, priorities may be used to resolve some conflicts among rules, based on knowledge about the reliability of sources or on user input. Thus, nonmonotonic rule systems can support ontology integration.

3 Defeasible Logics

3.1 Basic Characteristics

The root of defeasible logics lies on research in knowledge representation, and in particular on inheritance networks. Defeasible logics can be seen as inheritance networks ex-pressed in a logical rules language. In fact, they are the first nonmonotonic reasoning approach designed from its begin-ning to be implementable.

Being nonmonotonic, defeasible logics deal with poten-tial conflicts (inconsistencies) among knowledge items.

Thus they contain classical negation, contrary to usual logic programming systems. They can also deal with negation as failure (NAF), the other type of negation typical of non-monotonic logic programming systems; in fact, Wagner [2003] argues that the Semantic Web requires both types of negation. In defeasible logics, often it is assumed that NAF is not included in the object language. However, as Anto-niou et al. [2000a] show, it can be easily simulated when necessary. Thus, we may use NAF in the object language and transform the original knowledge to logical rules with-out NAF exhibiting the same behavior.

Conflicts among rules are indicated by a conflict between their conclusions. These conflicts are of local nature. The simpler case is that one conclusion is the negation of the other. The more complex case arises when the conclusions have been declared to be mutually exclusive, a very useful representation feature in practical applications. Defeasible logics are skeptical in the sense that conflict-ing rules do not fire. Thus consistency of drawn conclusions is preserved.

Priorities on rules may be used to resolve some conflicts among rules. Priority information is often found in practice, and constitutes another representational feature of defeasible logics.

The logics take a pragmatic view and have low computa-tional complexity. This is, among others, achieved through the absence of disjunction and the local nature of priorities: only priorities between conflicting rules are used, as op-posed to systems of formal argumentation where often more complex kinds of priorities (e.g. comparing the strength of reasoning chains) are incorporated.

Generally speaking, defeasible logics are closely related to Courteous Logic Programs [Grosof, 1997]; the latter were developed much later than defeasible logics. DLs have the following advantages:

They have more general semantic capabilities, e.g. in terms of loops, ambiguity propagation etc.

They have been studied much more deeply, with strong results in terms of proof theory [Antoniou et al., 2001], semantics [Maher, 2002] and computational complexity [Maher, 2001]. As a consequence, its translation into logic programs, a cornerstone of DR-Prolog, has also been studied thoroughly [Maher et al., 2001; Antoniou and Maher, 2002].

However, Courteous Logic Programs have also had some advantages:

They were the first to adopt the idea of mutually ex-clusive literals, an idea incorporated in DR-Prolog.

They allow access to procedural attachments, some-thing we have chosen not to follow in our work so far. In the following we discuss in more detail some of the ideas and concepts mentioned here. 3.2 Syntax

A defeasible theory D is a couple (F,R,>) where F is a finite set of facts, R a finite set of rules, and > a superiority rela-tion on R. In expressing the proof theory we consider only propositional rules. Rules containing free variables are in-terpreted as the set of their variable-free instances.

There are two kinds of rules (fuller versions of defeasible logics include also defeaters): Strict rules are denoted by A p, and are interpreted in the classical sense: whenever the premises are indisputable then so is the conclusion. An ex-ample of a strict rule is “Professors are faculty members”. Written formally: professor(X) faculty(X). Inference from strict rules only is called definite inference. Strict rules are intended to define relationships that are definitional in na-ture, for example ontological knowledge.

Defeasible rules are denoted by A p, and can be de-feated by contrary evidence. An example of such a rule is faculty(X) tenured(X)which reads as follows: “Profes-sors are typically tenured”.

A superiority relation on R is an acyclic relation > on R (that is, the transitive closure of > is irreflexive). When r1 > r2, then r1 is called superior to r2, and r2inferior to r1. This expresses that r1may override r2. For example,given the defeasible rules

r: professor(X) tenured(X)

r’: visiting(X) ?tenured(X)

which contradict one another: no conclusive decision can be made about whether a visiting professor is tenured. But if we introduce a superiority relation > with r’ > r, then we can indeed conclude that a visiting professor cannot be ten-ured.

A formal definition of the proof theory is found in [Anto-niou et al., 2001].

3.3 Simulation of Negation As Failure in the Ob-ject Language

We follow a technique based on auxiliary predicates first presented in [Antoniou et al., 2000a], but which is often used in logic programming. According to this technique, a defeasible theory with NAF can be modularly transformed into an equivalent one without NAF. Every rule

r: L1,…,Ln, ?M1,…, ?Mk L

can be replaced by the rules:

r: L1,…,Ln, neg(M1),…,neg(Mk) L

neg(M1)

neg(Mk)

M1 ?neg(M1)

Mk ?neg(Mk)

where neg(M1),…,neg(Mk)are new auxiliary atoms. If we restrict attention to the original language, the set of conclu-sions remains the same.

3.4 Ambiguity Blocking and Ambiguity Propagat-ing Behavior

A literal is ambiguous if there is a chain of reasoning that supports a conclusion that p is true, another that supports that ?p is true, and the superiority relation does not resolve this conflict. We can illustrate the concept of ambiguity propagation through the following example.

r1: quaker(X) pacifist(X)

r2: republican(X) ?pacifist(X)

r3: pacifist(X) ?hasGun(X)

r4: livesInChicago(X) hasGun(X)

quaker(a)

republican(a)

livesInChicago(a)

r3 > r4

Here pacifist(a)is ambiguous. The question is whether this ambiguity should be propagated to the dependent literal hasGun(a). In one defeasible logic variant it is detected that rule r3cannot fire, so rule r4is unopposed and gives the defeasible conclusion hasGun(a). This behavior is called ambiguity blocking, since the ambiguity of pacifist(a)has been used to block r3 and resulted in the unambiguous con-clusion hasGun(a).

On the other hand, in the ambiguity propagation variant, although rule r3cannot lead to the conclusion hasGun(a) (as pacifist(a) is not provable), it opposes rule r4and the con-clusion hasGun(a) cannot also be drawn.

This question has been extensively studied in artificial in-telligence, and in particular in the theory of inheritance net-works. A preference for ambiguity blocking or ambiguity propagating behavior is one of the properties of non-monotonic inheritance nets over which intuitions can clash. Ambiguity propagation results in fewer conclusions being drawn, which might make it preferable when the cost of an incorrect conclusion is high. For these reasons an ambiguity propagating variant of DL is of interest.

3.4 Conflicting Literals

Usually in Defeasible Logics only conflicts among rules with complementary heads are detected and used; all rules with head L are considered as supportive of L, and all rules with head ?L as conflicting. However, in applications often literals are considered to be conflicting, and at most one of a certain set should be derived. For example, the risk an in-vestor is willing to accept may be classified in one of the categories low, medium, and high. The way to solve this problem is to use a constraint rule of the form

conflict :: low, medium, high

Now if we try to derive the conclusion high, the conflict-ing rules are not just those with head ?high, but also those with head low and medium. Similarly, if we are trying to prove ?high, the supportive rules include those with head low or medium.

In general, given a conflict :: L, M, we augment the de-feasible theory by:

r i: q1,q2,…,q n ?L for all rules r i: q1,q2,…,q n M

r i: q1,q2,…,q n ?M for all rules r i: q1,q2,…,q n L

r i: q1,q2,…,q n ?L for all rules r i: q1,q2,…,q n M

r i: q1,q2,…,q n ?M for all rules r i: q1,q2,…,q n L The superiority relation among the rules of the defeasible theory is propagated to the “new” rules.

4 Translation into Logic Programs

4.1 Translation of Defeasible Theories

The translation of a defeasible theory D into a logic program P(D) has a certain goal: to show that

p is defeasibly provable in D

p is included in the Well-Founded Model of P(D) Two different translations have so far been proposed, sharing the same basic structure:

The translation of [Antoniou et al., 2000b; Maher et al., 2001] where a meta-program was used.

The translation of [Antoniou and Maher, 2002], which makes use of control literals.

It is an open question which is better in terms of compu-tational efficiency, although we conjecture that for large theories the meta-program approach is better, since in the other approach a large number of concrete program clauses is generated. Therefore, we have adopted this approach in our implementation.

Translation of Ambiguity Blocking Behavior

The metaprogram which corresponds to the ambiguity blocking behavior of the defeasible theories consists of the following program clauses:

The first three clauses define the class of rules used in a defeasible theory.

supportive_rule(Name,Head,Body):-

strict(Name,Head,Body).

supportive_rule(Name,Head,Body):-

defeasible(Name,Head,Body).

rule(Name,Head,Body):-

supportive_rule (Name,Head,Body).

The following clauses define the definite provability: a literal is definitely provable if it is a fact or is supported by a strict rule, the premises of which are definitely provable. definitely(X):- fact(X).

definitely(X):- strict(R,X,L), definitely_provable(L). definitely_provable([]).

definitely_provable(X):- definitely(X).

definitely_provable([X1|X2]):- definitely_provable(X1), definitely_provable(X2).

The next clauses define the defeasible provability: a lit-eral is defeasibly provable, either if it is definitely provable, or if its complemetary is not definitely provable, and it is supported by a defeasible rule, the premises of which are defeasibly provable, and which is not overruled. defeasibly(X):- definitely(X).

defeasibly(X):- negation(X,X1), supportive_rule(R,X,L), defeasibly_provable(L), sk_not(definitely(X1)),

sk_not(overruled(R,X)).

defeasibly_provable([]).

defeasibly_provable(X):- defeasibly(X).

Figure 1: The overall architecture of DR-Prolog

defeasibly_provable([X1|X2]):- defeasibly_provable(X1), defeasibly_provable(X2).

The next clause defines that a rule is overruled when there is a conflicting rule, the premises of which are defea-sible provable, and which is not defeated. overruled(R,X):- negation(X,X1),

supportive_rule(S,X1,U), defeasibly_provable(U), sk_not(defeated(S,X1)).

The next clause defines that a rule is defeated when there is a superior conflict rule, the premises of which are defea-sibly provable. The last two clauses are used to define the negation of a literal.

defeated(S,X):- sup(T,S), negation(X,X1),

supportive_rule(T,X1,V), defeasibly_provable(V). negation(~(X),X):- !. negation(X,~(X)).

For a defeasible theory D = (F,R,>), where F is the set of the facts, R is the set of the rules, and > is the set of the su-periority relations between the rules of the theory, we add facts according to the following guidelines: fact(p). for each p F

strict(r i ,p,[q 1,…,q n ]). for each rule r: q 1,q 2,…,q n p R defeasible(r i ,p,[q 1,…,q n ]). for each r: q 1,q 2,…,q n p R sup(r,s). for each pair of rules such that r>s Translation of Ambiguity Propagating Behavior

In order to support the ambiguity propagation behavior of a defeasible theory, we only have to modify the program clauses which define when a rule is overruled. In particular, in this variant a rule is overruled when there is a conflicting rule, the premises of which are supported, and which is not defeated.

overruled(R,X):- negation(X,X1),

supportive_rule(S,X1,U), supported_list(U), sk_not(defeated(S,X1)).

The next clauses define that a literal is supported, either if it is definitely provable, or if there is a supportive rule, the premises of which are supported, and which is not defeated. supported(X):- definitely(X).

supported(X):- supportive_rule(R,X,L), supported_list(L), sk_not(defeated(R,X)). supported_list([]).

supported_list(X):- supported(X).

supported_list([X1|X2]):- supported_list(X1), supported_list(X2).

4.2 Translation of RDF(S) and parts of OWL on-tologies

In order to support reasoning with RDF/S and OWL ontolo-gies, we translate RDF data into logical facts, and RDFS and OWL statements into logical facts and rules.

For RDF data, the SWI-Prolog RDF parser [SWI] is used to transform it into an intermediate format, representing triples as rdf(Subject, Predicate, Object). Some additional processing (i) transforms the facts further into the format Predicate(Subject, Object); (ii) cuts the namespaces and the “comment” elements of the RDF files, except for resources which refer to the RDF or OWL Schema, for which name-space information is retained.

In addition, for processing RDF Schema information, the following rules capturing the semantics of RDF Schema constructs are created: a : C(X):- rdf:type(X,C).

b : C(X):- rdfs:subClassOf(Sc,C),Sc(X).

c : P(X,Y):- rdfs:subPropertyOf(Sp,P),Sp(X,Y).

d : D(X):- rdfs:domain(P,D),P(X,Z).

e : R(Z):- rdfs:range(P,R),P(X,Z).

Parts of OWL ontologies can also be translated using logical rules, which capture the semantics of some of the OWL constructs. For example the following rules are used to capture the semantics of transitive, symmetric and inverse properties respectively.

o1: P(X,Z):- P(X,Y), P(Y,Z),

rdf:type(P,owl:TransitiveProperty).

o2: P(X,Y):- P(Y,X), rdf:type(P,owl:SymmetricProperty). o3: P(X,Y):- Q(Y,X),owl:Inverseof(P,Q). o4: Q(X,Y):- P(Y,X),owl:Inverseof(P,Q).

Other OWL constructs which are also supported by our sys-tem are: owl:equivalentClass, owl:equivalentProperty, owl:sameIndividualAs, owl:sameAs, property restrictions (owl:allValuesFrom, owl:hasValue), owl collections etc. All the above rules are created at compile-time, i.e. before the actual querying takes place. Therefore, although at first they seem second-order, because they contain variables in place of predicate names, they are actually first-order rules, i.e. predicate names are constant at run-time.

5 Implementation

DR-Prolog, in accordance with the general philosophy of logic programming, is designed to answer queries. In fact, there are two kinds of queries, depending on which strength of proof we are interested in: definite or defeasible provabil-ity.

In Figure 1 we present the overall architecture of our sys-tem. The system works in the following way: The user im-ports defeasible theories, either using the syntax of defeasi-ble logic, or in the RuleML syntax, that we describe below.

The former theories are checked by the DL Parser, and if they are syntactically correct, they are passed to the Logic Translator, which translates them into logic programs. The RuleML defeasible theories are checked by the RuleML Parser and translated into defeasible theories, which are also passed to the Logic Translator and transformed into logic programs. The Reasoning Engine compiles the logic pro-grams and the metaprogram which corresponds to the user’s choice of the defeasible theory variants (ambiguity blocking / propagating), and evalutes the answers to the user’s que-ries. The logic programming system that we use as the Rea-soning Engine is XSB. The advantages of this system are basically two: (a) it supports the well-founded semantics of logic programs through the use of tabled predicates, and its sk_not negation operator; and (b) it offers an easy and effi-cient way to communicate with the other parts of the sys-tem.The RDF&OWL Translator is used to translate the RDF/S and OWL information into logical facts and rules, which can be processed by the rules, provided by the user. The DTD that we have developed to represent defeasible theories in XML format, is in fact an extension of the RuleML DTDs [RuleML]. The elements that we add / mod-ify to support the defeasible theories are:

The “rulebase” root element which uses strict and de-feasible rules, fact assertions and superiority relations.

The “imp” and “def” elements, which consist of a “_head” and a “_body” element, accept a “name” at-tribute, and refer to the strict and defeasible rules.

The “superiority” empty element, which accepts the name of two rules as its attributes (“sup” & “inf”), and refers to the superity relation between these two rules.

6 Related Work

There exist several previous implementations of defeasible logics. Conington et al. [2002] give the historically first implementation, D-Prolog, a Prolog-based implementation. It was not declarative in certain aspects (because it did not use a declarative semantic for the not operator), therefore it did not correspond fully to the abstract definition of the logic. Also, D-Prolog supported only one variation thus it lacked the flexibility of the implementation we report on. Finally it did not provide any means of integration with Se-mantic Web layers and concepts, a central objective of our work.

Deimos [Maher et al.,2001] is a flexible, query process-ing system based on Haskell. It implements several variants, but not conflicting literals. Also, it does not integrate with Semantic Web (for example, there is no way to treat RDF data and RDFS/OWL ontologies; nor does it use an XML-based or RDF-based syntax for syntactic interoperability). Thus it is an isolated solution. Finally, it is propositional and does not support variables.

Delores[Maher et al.,2001] is another implementation, which computes all conclusions from a defeasible theory. It is very efficient, exhibiting linear computational complex-ity. Delores only supports ambiguity blocking propositional defeasible logic; so, it does support ambiguity propagation, nor conflicting literals and variables. Also, it does integrate with other Semantic Web languages and systems, and is thus an isolated solution.

DR-DEVICE [Bassiliades, 2004] is another effort on im-plementing defeasible reasoning, albeit with a different ap-proach. DR-DEVICE is implemented in Jess, and integrates well with RuleML and RDF. It is a system for query an-swering. Compared to the work of this paper, DR-DEVICE supports only one variant, ambiguity blocking, thus it does not offer the flexibility of this implementation. At present, it does not support RDFS and OWL ontologies. SweetJess [Grosof et al., 2002] is another implementation of a defeasible reasoning system (situated courteous logic programs) based on Jess. It integrates well with RuleML. Also, it allows for procedural attachments, a feature not supported by any of the above implementations, not by the system of this paper. However, SweetJess is more limited in flexibility, in that it implements only one reasoning variant (it corresponds to ambiguity blocking defeasible logic). Moreover, it imposes a number of restrictions on the pro-grams it can map on Jess. In comparison, our system im-plements the full version of defeasible logic.

7 Conclusion

In this paper we described reasons why conflicts among rules arise naturally on the Semantic Web. To address this problem, we proposed to use defeasible reasoning which is known from the area of knowledge representation. And we reported on the implementation of a system for defeasible reasoning on the Web. It is Prolog-based, supports RuleML syntax, and can reason with monotonic and nonmonotonic rules, RDF facts and RDFS and OWL ontologies.. Planned future work includes:

Adding arithmetic capabilities to the rule language, and using appropriate constraint solvers in conjunction with logic programs.

Implementing load/upload functionality in conjunction with an RDF repository, such as RDF Suite [Alexaki et al., 2001] and Sesame [Broekstra et al., 2003].

Applications of defeasible reasoning and the devel-oped implementation for brokering, bargaining, auto-mated agent negotiation, and security policies.

References

[Alexaki et al., 2001] S. Alexaki, V. Christophides, G.

Karvounarakis, D. Plexousakis and K. Tolle (2001). The ICS-FORTH RDFSuite: Managing Voluminous RDF Description Bases. In Proc. 2nd International Workshop on the Semantic Web, Hongkong, May 1, 2001. [Antoniou and Arief, 2002] G. Antoniou and M. Arief (2002). Executable Declarative Business rules and their use in Electronic Commerce. In Proc. ACM Symposium on Applied Computing

[Antoniou et al., 1999] G. Antoniou, D. Billington and M.J.

Maher (1999). On the analysis of regulations using de-feasible rules. In Proc. 32nd Hawaii International Con-ference on Systems Science

[Antoniou et al., 2001] G. Antoniou, D. Billington, G. Gov-ernatori and M.J. Maher (2001). Representation results for defeasible logic. ACM Transactions on Computa-tional Logic 2, 2 (2001): 255 - 287

[Antoniou et al., 2000a] G. Antoniou, M. J. Maher and D.

Billington (2000). Defeasible Logic versus Logic Pro-gramming without Negation as Failure. Journal of Logic Programming 41,1 (2000): 45-57

[Antoniou et al., 2000b] G. Antoniou, D. Billington, G.

Governatori, M. J. Maher: A Flexible Framework for Defeasible Logics. In Proc. AAAI’ 2000, 405-410 [Antoniou and Maher, 2002] G. Antoniou, M.J. Maher (2002). Embedding Defeasible Logic into Logic Pro-grams. In Proc. ICLP 2002, 393-404

[Ashri et al., 2004] R. Ashri, T. Payne, D. Marvin, M. Sur-ridge and S. Taylor (2004). Towards a Semantic Web Security Infrastructure. In Proc. of Semantic Web Ser-vices 2004 Spring Symposium Series, Stanford Univer-sity, California

[Bassiliades et al., 2004] N. Bassiliades, G. Antoniou and I.

Vlahavas (2004). DR-DEVICE: A Defeasible Logic Sys-tem for the Semantic Web. In Proc. 2nd Workshop on Principles and Practice of Semantic Web Reasoning (PPSWR04), LNCS, Springer 2004 (accepted) [Berners-Lee et al., 2001]T. Berners-Lee, J. Hendler, and O.

Lassila (2001). The Semantic Web. Scientific American, 284, 5 (2001): 34-43

[Broekstra et al., 2003] J. Broekstra, A. Kampman and F.

van Harmelen (2003) Sesame: An Architecture for Storin gand Querying RDF Data and Schema Informa-tion. In: D. Fensel, J. A. Hendler, H. Lieberman and W.

Wahlster (Eds.), Spinning the Semantic Web, MIT Press, 197-222

[Connolly et al., 2001] D. Connolly, F. van Harmelen, I.

Horrocks, D. L. McGuinness, P. F. Patel-Schneider and L. A. Stein (2001). DAML+OIL Reference Description.

https://www.360docs.net/doc/954471377.html,/TR/daml+oil-reference

[Conington et al., 1997] M. A. Covington, D. Nute and A.

Vellino (1997). Prolog Programming in Depth, 2nd ed.

Prentice-Hall

[Dean and Schreiber, 2004] M. Dean and G. Schreiber (Eds.) (2004). OWL Web Ontology Language Reference.

https://www.360docs.net/doc/954471377.html,/TR/2004/REC-owl-ref-20040210/

[van Gelder et al., 1991] A. van Gelder, K. Ross and J.

Schlipf (1991). The well-founded semantics for general logic programs. Journal of the ACM38 (1991): 620—650

[Governatori et al., 2001] G. Governatori, M. Dumas, A. ter Hofstede and P. Oaks (2001). A formal approach to legal negotiation. In Proc. ICAIL 2001, 168-177 [Grosof, 1997] B. N. Grosof (1997). Prioritized conflict handing for logic programs. In Proc. of the 1997 Inter-national Symposium on Logic Programming, 197-211 [Grosof et al., 2002] B. N. Grosof, M. D. Gandhe and T. W.

Finin: SweetJess: Translating DAMLRuleML to JESS.

RuleML 2002. In: Proc. International Workshop on Rule Markup Languages for Business Rules on the Semantic Web

[Grosof et al., 2003] B. N. Grosof, I. Horrocks, R. Volz and S. Decker (2003). Description Logic Programs: Combin-ing Logic Programs with Description Logic". In: Proc.

12th Intl. Conf. on the World Wide Web (WWW-2003), ACM Press

[Grosof and Poon, 2003] B. N. Grosof and T. C. Poon (2003). SweetDeal: representing agent contracts with ex-ceptions using XML rules, ontologies, and process de-scriptions. In Proc. 12th International Conference on World Wide Web. ACM Press, 340 – 349

[Levy and Rousset, 1998] A. Levy and M.-C. Rousset (1998). Combining Horn rules and description logics in CARIN. Artificial Intelligence104, 1-2 (1998):165 - 209

[Li et al., 2003] N. Li, B. N. Grosof and J. Feigenbaum (2003). Delegation Logic: A Logic-based Approach to Distributed Authorization. In: ACM Transactions on In-formation Systems Security 6,1 (2003)

[Maher, 2002] M. J. Maher: A Model-Theoretic Semantics for Defeasible Logic. In Proc. Paraconsistent Computa-tional Logic 2002, Datalogisker Srkifter 95 ,67-80 [Maher, 2001] M. J. Maher: Propositional Defeasible Logic has Linear Complexity. Logic Programming Theory and Practice 1(6): 691-711 (2001)

[Maher et al., 2001]M. J. Maher, A. Rock, G. Antoniou, D.

Billington and T. Miller (2001). Efficient Defeasible Reasoning Systems. International Journal of Tools with Artificial Intelligence 10,4 (2001): 483--501

[Marek and Truszczynski, 1993] V.W. Marek and M.

Truszczynski (1993). Nonmonotonic Logics; Context Dependent Reasoning. Springer Verlag

[Nute, 1994] D. Nute (1994). Defeasible logic. In Handbook of logic in artificial intelligence and logic programming (vol. 3): nonmonotonic reasoning and uncertain reason-ing. Oxford University Press

[RuleML] RuleML. The Rule Markup Language Initiative.

https://www.360docs.net/doc/954471377.html,

[SWI] SWI-Prolog, https://www.360docs.net/doc/954471377.html, [Wagner, 2003] G. Wagner: Web Rules Need Two Kinds of Negation. In Proc. First Workshop on Semantic Web Reasoning, LNCS 2901, Springer 2003, 33-50 [XSB] XSB, Logic Programming and Deductive Database System for Unix and Windows.

https://www.360docs.net/doc/954471377.html,

软件工程-银行储蓄管理系统源代码

package src.day01; public class ACC { //父类,以下是共有属性和方法 //卡号 protected static long id; // 名字 protected static String name; // 身份证 protected static String personId; //电子邮件 protected static String email; // 密码 protected static long password; //余额 protected static double balance; public ACC(){ } public ACC(long id,String name,String personId,String email,long password,double balance ){ this.id = id; https://www.360docs.net/doc/954471377.html, = name; this.personId = personId; this.email = email; this.password = password; this.balance = balance; } // 存款方法 public static void deposit(double money){ balance += money; System.out.println("存款成功,你存入的金额为:" + money); } public long getId() { return id; } public void setId(long id) { this.id = id; } public String getName() { return name; } public void setName(String name) { https://www.360docs.net/doc/954471377.html, = name; } public String getPersonId() {

SystemView仿真

---------------------------------------------------------------最新资料推荐------------------------------------------------------ SystemView仿真 二进制振幅键控2ASK systemvi ew仿真院(系): 班级: 学号: 姓名: 指导老师: 二进制振幅键控 2ASK 1、调制系统: 实验原理: 2ASK 的实现二进制不归零信号图 2: 2ASK 调制器原理框图在幅移键控中,载波幅度是随着调制信号而变化的。 一种是最简单的形式是载波在二进制调制信号 1 或 0 控制下通或断,这种二进制幅度键控方式称为通断键控(OOK)。 二进制振幅键控方式是数字调制中出现最早的,也是最简单的。 这种方法最初用于电报系统,但由于它在抗噪声的能力上较差,故在数字通信用的不多。 但二进制振幅键控常作为研究其他数字调制方式的基础。 二进制振幅键控信号的基本解调方法有两种: 相干解调和非相干解调,即包络检波和同步检测。 非相干解调系统设备简单,但信噪比小市,相干解调系统的性能优于相干解调系统。 1 / 3

2ASK 解调器原理框图: 图 3 乘法器coscte2ASK(t)(a)模拟调制法(相乘器法)cosct开关电路s(t)e2ASK(t)(b)通-断键控(OOK,On-Off Keying) s(t)e2ASK(t)BPF全波整流器LPF抽样判决器输出abcd定时脉冲(a)非相干解调(包络检波法)e2ASK(t)BPF相乘器LPF抽样判决器定时脉冲输出Cosct(b)相干解调(同步检测法)系统的相关参数:基带信号 amplitu=0. 5, offset=-0. 5, rate=10。 图 4 输入的调制信号: 图 5 已调信号: 图 6 2 调制解调系统: 系统相关参数: 基带信号频率=50HZ,电平=2,偏移=1,载波频率=1000HZ 模拟低通频率=225HZ,极点数为 3. 系统运行时间为 0. 3S,采样频率=20190HZ。 图 7 模块 3 为原始信号: 图 8 模块 8 为解调后信号: 图 9 模块 4 为已调信号: 图 1 0 功率谱图: Sink3 输入信号图 1 1 Sink8 输出信号: 图 1 2 2ASK 系统调制解调图对比: 图 1 3 图 14 3 系统仿真结果分析: 如图所示调制信号

全能管家多银行资金管理系统(IBS)宣传手册

全能管家多银行资金管理系统(IBS) 宣传手册 1

2

全能管家多银行资金管理系统( IBS系统) 系统背景 ”资金管理”——顾名思义是指企业和”钱”相关的所有活动的 一种统称。从企业资金管理发展的角度分析, 企业资金管理最初始的 目标就是加快收付款的速度、效率, 加快货币资金的流转。随着企业 的发展, 企业对资金的需求量大大增加, 这时资金管理所表现出来的主 要需求转换为对外部融资的需求, 这时合理的银企关系、财务资金成 本地控制、资产负债比率控制等演化为企业资金管理最重要的需求。 伴随着企业快速成长以及和资本市场的打通, 企业积累了大量的 财富, 同时货币市场的变幻莫测等, 将企业资金管理或者说财务管理人 员从筹集资金向如何将这些财富进行合法、合理的运用以及货币的保 值增值服务需求上转变。 为应对企业资金管理需求的变化和提升, 基于以客户需求为产品 创新源泉和动力的服务理念, 为更好地满足企业资金管理需求, 北京银 行汇聚财资管理智慧, 联合专业IT合作伙伴, 倾力奉献全能管家多银 行资金管理系统( IBS系统) , 致力于为北京银行企业客户伙伴提供一 站式资金、金融管理服务。 系统概述 全能管家多银行资金管理系统( IBS系统) 经过多银行数据服务程 序实现企业和各银行机构信息直通式处理, 实现企业多银行账户资金 的集中管控与统一划拨, 以全面、专业、便捷、灵活的系统服务, 满 3

足企业掌控多行账户信息、明晰资金流时效性、有效量化资金流、 加强风险管控等多项资金管理需求。 IBS系统主要功能包括: 统一数据服务平台、现金流管理、资金 计划管理、资金结算管理、内部银行管理、金融交易管理、投资理 财平台、综合查询系统等多个模块组成。 系统特点: ●为企业提供一站式金融服务: 北京银行IBS系统是一套整合了现代商业银行结算、信息、信 贷、理财服务以及企业资金管理各种需求的面向企业应用的专业资金 管理系统平台。 ●以企业流动性管理为核心: 北京银行IBS系统经过对企业多银行账户的统一管理实现企业对 账户资金实时监控管理的需求, 还进一步经过资金计划预算对企业未 来现金流和资金盈缺情况提供流量分析和平衡试算等功能, 方便企业 资金决策和头寸平衡。 ●先进的技术架构和部署模式: 北京银行IBS系统采用最先进的B/S系统架构, 真正做到单点部署, 多点使用, 同时客户端做到零维护, 方便企业的使用和维护。 应用价值 ●企业资金信息实时掌控 随着企业不断发展壮大, 资金需求、流量都不断加大, 如何能够透 4

银行储蓄管理系统

燕山大学三级项目设计说明书 题目:银行储蓄管理系统 学院(系):信息学院 年级专业:教育技术学15—1 学号: 学生姓名:付叶禹 郑凯峰 李文悦 王宇晨 李晓晗 指导教师:梁顺攀 教师职称:副教授 燕山大学三级项目设计(论文)任务书 院(系):信息学院教学单位:

说明:此表一式四份,学生、指导教师、基层教学单位、系部各一份。 年月日燕山大三级项目设计评审意见表

摘要 论文阐述的是在SQL server 2008开发环境下对银行储蓄管理系统的设计。希望通过该系统的应用,能促使银行储蓄管理工作的规范化、标准化和自动化,提高管理水平和管理效率,为管理工作提供更完善的信息服务和一个成功的信息管理系统。数据库是一个非常重要的条件和关键技术,管理系统所涉及的数据库设计分为:数据库需求分析、概念设计、逻辑设计过程。 本论文叙述了数据库设计的全过程。 主要分为: 1. 系统需求分析与功能设计阶段,包括功能需求、性能需求、数据需求、系统功能框图、系统总体数据流图及分模块数据流图、数据字典。 2. 总体设计阶段,包括系统总体功能模块图、功能模块描述、输入输出及统计查询等功能模块。 3. 概念设计阶段,包括系统各个模块的ER图及系统的总ER图。 4.逻辑结构设计阶段,包括系统各个模块的ER图所转化的关系模式。 关键词:数据库设计;管理系统; SQL server 2008;

目录 摘要...................................................... 1 绪论................................... 错误!未定义书签。1.1项目背景............................. 错误!未定义书签。1.1编写目的............................. 错误!未定义书签。1.1软件定义............................. 错误!未定义书签。 1.1开发环境............................. 错误!未定义书签。 2 系统需求分析 (2) 2.1信息与功能需求 (2) 2.2业务处理需求 (2) 2.3数据流图 (3) (3) (4) 2.4安全性与完整性要求 (8) 2.5数据字典 (8) 2.5.1储户基本信息表 (8)

{业务管理}IBM新一代银行核心业务系统

(业务管理)IBM新一代银行核心业务系统

新壹代银行核心业务系统 何京汉(IBM金融事业部银行资深方案经理) 背景 本文介绍新壹代核心银行所处的金融环境;结合目前国内银行所处的金融环境和银行客户的需求的新趋势,按照模型化银行(Modelingbank)的思想,介绍国内银行于设计新壹代银行核心系统是要考虑的主要问题。突出新壹代核心银行要解决的模型化银行的问题,国内系统和新壹代系统于观念上的差距,银行转型和信息规划设计的关系。国内从业人员普遍关心的金融产品概念(模型要点),核心银行的企业级客户文件(EnterpriseCIF)的原理。 国内外核心银行系统发展所处的环境 国外银行更换核心系统的努力 国外核心应用系统大多是70年代建成的,经过多年的运行后现状是:维护成本高,系统架构封闭,不易于加入新的功能且容易引起宕机。80年代至90年代国外银行,曾经试图更换这些系统,但大多归于失败,如花旗银行10亿美金的工程最终没有取得成功。 虽然,更换新的核心银行系统,难度极大,但银行仍于思考,为什么仍要将大量新的应用放于不灵活的且过时的系统上面?所以更换新的核心系统的努力仍于继续,只是吸取了80年代90年代的教训:银行必须采取新的策略去更新核心应用系统,以保证成功! 这些策略和市场趋势概括起来有: 用核心银行提供商的解决方案替换自我开发的核心银行系统。100强的银行70%的银行将去寻找"核心银行提供商的解决方案(Vendorbuiltsolutions)",即购买软件包。 主机方案的规模性得到验证。主机的核心银行方案,将继续流行。是因为它的规模性得到证实。尽管主机的技术没有新技术灵活,它的维护成本需要进壹步下降。 浏览器方式的解决方案(browser-basedsolutions)。市场上将会有更多的以浏览器方式出

银行储蓄管理系统需求分析设计

〖银行储蓄管理系统〗需求分析 2016年5月

目录 1 引言 (3) 1.1 编写目的 (3) 1.2 项目背景 (3) 1.3 定义 (3) 1.4 参考资料 (3) 2 任务概述 (3) 2.1 目标 (3) 2.2 运行环境 (3) 2.3 条件与限制 (3) 3 数据描述 (3) 3.1 静态数据 (3) 3.2 动态数据 (3) 3.3数据库描述 (3) 3.4数据词典 (5) 3.5数据采集 (6) 4 功能需求 (7) 4.1 功能划分 (7) 4.2 功能描述 (7) 5 性能要求 (8) 5.1 数据精确度 (8) 5.2 时间特性 (8) 5.3适应性 (8) 6 运行需求 (8) 6.1 用户界面 (8) 6.2 硬件接口 (8) 6.3 软件接口 (8) 6.4 故障处理 (8) 7 其他需求 (9)

1引言 1.1 编写目的 根据需求调研分析报告,定义系统功能和系统数据流图,通过编写需求分析规格说明书,让开发人员能够根据需求规格说明书来开发项目。 1.2 项目背景 软件名称:银行储蓄系统 委托单位:银行 开发单位:科技大学 主管:荀亚玲 1.3 定义 银行储蓄应用软件:基本元素为构成银行储蓄行为所必需的各种部分。 媒体素材:是指传播教学信息的基本才来单元,可分为五大类:文本类素材、图形(图像)类素材、音频类素材、动画类素材、视频类素材。 需求:用户解决问题或达到目标所需的条件或功能;系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 需求分析:包括提炼,分析和仔细审查已收集到的需求,以确保所有风险承担者都明其含义并找出其中的错误,遗憾或其他部族的地方。 1.4 参考资料 《软件工程导论——第5版》张海藩编著清华大学出版社 2任务概述 2.1 目标 完善目前银行储蓄系统,之智能跟上时代发展,同时通过实践来提高自己动手能力。 2.2 运行环境 操作系统:Windows XP/Windows Vista,支持环境:IIS 5.0 数据库:Microsoft SQL. Server 2000,编程环境:Microsoft visual basic 6.0中文版。 2.3 条件与限制硬件配置要求 硬什外部设备需奔腾133以上的pc机,内存需16兆以上 软件要求操作人员具有初步的相关知识 由于本系统为即时软件,刘数据蚓叫步要求较高,建议配置网络时使川叫靠性较高佝相关网络硬件设

System View通信系统仿真实验

第四部分System View通信系统仿真实验SystemView及其操作简介 美国ELANIX公司于1995年开始推出SystemView软件工具,最早的1.8版为16bit教学版,自1.9版开始升为32bit专业版,目前我们见到的是4.5版。SystemView是在Windows95/98环境下运行的用于系统仿真分析的软件工具,它为用户提供了一个完整的动态系统设计、仿真与分析的可视化系统软件环境,能进行模拟、数字、数模混合系统、线性和非线性系统的分析设计,可对线性系统进行拉氏变换和Z变换分析。 一、SystemView的基本特点 SystemView基本属于一个系统级工具平台,可进行包括数字信号处理(DSP)系统、模拟与数字通信系统、信号处理系统和控制系统的仿真,并配置了大量图符块(Token)库,用户很容易构造出所需要的仿真系统,只要调出有关图符块并设置好参数,完成图符块间的连线后,运行仿真操作,最终以时域波形、眼图、功率谱、星座图和各类曲线形式给出系统的仿真分析结果。SystemView的库资源十分丰富,主要包括:含有若干图符库的主库(MainLibrary)、通信库(Communications Library)、信号处理库(DSP Library)、逻辑库(LogicLibrary)、射频/模拟库(RF Analog Library)、Matlab连接库(M-Link Library)和用户代码库(Costum Library)。 二、SystemView系统视窗 1、主菜单功能 图1 系统视窗

遵循以下步骤进入SystemView系统视窗: (1)双击SystemView图标,开始启动系统。 (2)首先会出现SystemView License Manager窗口,可用来选择附加库。本实验中选择Selectlall再左键单击OK结束选择。 (3)然后会出现Recent SystemView Files窗口,可用来方便的选择所需打开的文件。在本实验中,左键单击Close结束选择。 完成以上操作,即可进入SystemView系统视窗。如图1所示。 系统视窗最上边一行为主菜单栏,包括:文件(File)、编辑(Edit)、参数优选(Preferences)、视窗观察(View)、便签(NotePads)、连接(Connections)、编译器(Compiler)、系统(System)、 图符块(Tokens)、工具(Tool)和帮助(Help)等11项功能菜单。 执行菜单命令操作较简单,例如,用户需要清除系统时,可单击“File”菜单,出现一个下拉菜单,单击其中的“Newsystem”工具条即可。为说明问题简单起见,将上述操作命令记作:File>>Newsystem,以下类同。各菜单下的工具条及其功能如下表所示: 表1 SvstemView4.5个菜单下的工具条及其功能

资金管理系统详细方案

XX集团资金管理中心设立方案 (试行) 索引 一、设立主体 二、设立目标 三、管理模式及主要职能 四、机构及人员设置 五、参与集团资金统管的公司及纳入监管的银行账户 六、资金流转方案 七、网银权限设置 八、内部账户及账号设置 九、内部存贷款利率设置 十、会计核算科目设置 十一、业务操作内容、流程及会计核算办法 十二、现有银行贷款事项及内部往来的后续处理 十三、注意事项 十四、附件

根据XX集团管理现状及未来发展要求,设立集团资金管理中心。设立方案如下: 一、设立主体 资金管理中心设立在XX集团有限公司。 资金管理中心作为XX集团公司的一个职能部门(利润中心),其所有业务受到XX集团董事长、总经理及财务总监的安排与指导。其所有经济业务设立独立账套核算,同时其涉及到XX集团公司、各下属企业的业务也纳入XX集团有限公司账套、下属企业账套进行核算。并且各账套之间有对应关系。 办公地点设立在XX集团办公室。 二、设立目标 1、实施高度集中控制的资金管理体系,加强集团资金管理与控制 2、资金实现事前计划、实时控制与分析,加快资金周转,提高资金使用效益 3、降低集团财务风险 三、管理模式及主要职能 将银行机制引入企业内部,建立集财务管理、金融管理和企业管理三位一体的现代企业管理模式。身兼银行和财会两种职能,承担企业外部资金结算、资金内部调剂、对外融资等业务。资金管理中心实时掌握集团资金的流量、流向、存量,随时监控子公司的资金使用,同时可以灵活调配“沉淀”存量资金,提高资金利用效率。 1、账户分散、资金集中的管理模式 集团的资金管理采取账户分散、资金集中管理的模式。即各下属企业在外部商业银行的现有账户不变,保持现有的资金业务处理及会计核算流程不变;资金管理中心将各下属企业的外部银行账户加以记录,资金管理中心开立内部账户对应各下属企业的外部银行账户;同时将下属企业的闲散资金每日归集到资金管理中心,作为下属企业的“内部存款”,资金管理中心会计、出纳按照资金计划进行支付单据的审批、拨付;各下属企业依据集团的审批处理资金业

银行核心系统简介

核心业务系统 描述:银行核心业务系统主要功能模块包括:公用信息、凭证管理、现金出纳、柜员支持(机构管理和柜员管理)、总账会计、内部账管理、客户信息、活期存款、定期存款、外币兑换、同城票据交换、客户信贷额度管理、定期贷款、分期付款贷款、往来业务、资金清算、金融同业、结算、人行现代支付、外汇买卖业务、国债买卖、保管箱、租赁、股金管理、固定资产管理等。 一、核心系统背景 VisionBanking Suite Core是集团在总结二十余年银行应用系统集成经验的基础上,认真分析中国银行业未来面临的竞争形势,吸纳国外银行系统中先进的设计理念,推出的与国际完全接轨、功能完善、易学易用、扩充灵活、安全可靠的新一代银行核心业务系统。该系统覆盖了银行整个基础业务范围,有助于银行提供给客户更方便、快捷和贴身的“一站式”服务。 在VisionBanking Suite Core银行核心业务系统的开发中,集团将先进的系统设计思想、技术和国内、国际银行界先进的银行业务模式、管理方法结合在一起。系统采用先进的C-S-S三层体系结构,拥有强大、稳定的系统核心。 在全面覆盖传统银行业务的基础上,突出“金融产品”概念,银行可方便定制新的业务品种、产品组装或更改业务模式;系统整合了银行的业务服务渠道,方便银行增值服务范围的扩展,在无须更改系统内核的情况下方便实现与外部系统的互联互通。系统在深化“大集中” 、“大会计”、“一本帐”、“以客户为中心”、“综合柜员制”等成熟的设计思想的基础上,建立了从“客户”、“产品”到“服务” 、“渠道”的集约化经营管理模式,提供了真正的面向客户的服务模式,作到了为客户定制差别化的服务。从而实现了银行集中经营、规范业务、个性服务、丰富渠道、减少风险、辅助决策、降低成本的目标;系统设计严格遵守业务流程和会计核算分离原则,方便于系统快速部署和适应业务流程再造要求。 集团对核心业务系统的不断发展和完善就是以技术的进步来支持和推动银行业务的拓展,为银行的可持续性发展奠定了坚实的基础。 VisionBanking Core的系统实现原则满足了银行业务系统所要求的:先进性、实时性、可靠性、完整性、安全性、网络化、开放性、易扩展性、易维护性、易移植性。 二、系统功能说明

银行储蓄管理系统的设计与实现毕业论文

通信系统仿真实验课程设计 题目银行储蓄管理平台开发设计 学院 2010222111 专业班级通信104 学生姓名霍守斌 指导教师大彬 哥 2013年 6月 15日 摘要 近几年来,随着科技的发展和社会的进步,尤其是计算机大范围的普及,计算机应用逐渐由大规模科学计算的海量数据处理转向大规模的事务处理和对工作流的管理,这就产生了以台式计算机为核心,以数据库管理系统为开发环境的管理信息系统在大规模的事务处理和对工作流的管理等方面的应用,特别是在银行储蓄管理之中的应用日益引起人们的关注。本文基于Visual C++数据库编程技术,以可视化的集成开发环境Visual studio 2008为开发工具, Access 2007为后台数据库实现了一个小型的银行储蓄管理系统,该系统主要功能包括用户注册、销户、存款、取款、查询历史记录、用户修改信息等功能。从而满足了广大人民群众的需要同时也实现了银行储蓄管理的系统化、规范化、自动化和智能化,提高了银行管理的效率。 关键字:Visual C++;Access 2007;银行储蓄管理系统

Abstract In recent years, as technology development and social progress, in particular, the popularity of a wide range of computers, computer application gradually from large-scale scientific computing shift large-scale mass data processing and workflow transaction management, which resulted in of the desktop computer as the core database management system for the development of environmental management information system in large-scale transaction processing and management, workflow applications, especially in the management of bank savings into the application has attracted much attention. Based on the Visual C + + database programming techniques to visualize the integrated development environment, Visual studio 2008 as development tool, Access 2007 database for the background to achieve a small bank savings management system, which mainly features include user registration, cancel the account, deposit , withdrawals, query history, user modify the information and other functions. To meet the needs of the masses but also to achieve the systematic management of bank savings, standardization, automation and intelligence to improve the efficiency of bank management. Key word: visual c + +; Visual studio 2008; Access 2007; Bank savings management 目录 摘要 I Abstract II

Systemview仿真

通信仿真实训总结Systemview软件仿真实验 姓名:邱永锋 班级:信息123班 学号:1213260142 指导老师:崔春雷

一、 实训目的 利用System View ,构造ASK 、FSK 、PSK 、AM 、FM 的信号仿真,从System View 配置的图标库中调出有关图标并进行参数设置,完成图标间的连线,然后运行仿真操作,最终以时域波形、眼图、功率谱等形式给出系统的仿真分析结果。 二、幅移键控ASK (一)、ASK 产生二进制振幅键控信号的方法主要有两种: 方法1:采用相乘电路,用基带信号A(t)和载波tcos(wt)相乘就得到已调信号输出; 方法2:采用开关电路,这里的开关由输入基带信号A(t)控制,用这种方法可以得到同样的输出波形。 (二)、原理及框图 1. 调制部分:设信息源发出的是由二进制符号0、1组成的序列,则一个二进制的振幅键控信号可以表示成一个单极性矩形脉冲序列与一个正弦载波的相乘,。所以二进制幅度键控调制器可用一个相乘器来实现、 OOK 信号表达式: S ook (t)=a(n)?Acos(ω0t) A: 载波幅度 ω0:载波频率 a(n):二进制数字信号 原理框图: 基带信号 a(n) 相乘器 调制信号Sook(t) 载波 Acos (ω0t) 2、电路图

2.2ASK 解调原理 1.解调部分:解调有相干和非相干两种。非相干系统设备简单,但在信噪比较小时,相干系统的性能优于非相干系统。这里采用相干解调。 原理框图: Sook(t) 相乘器低通滤波器解调信号a(n) 载波Acos( t) 2.信号图: 三.FSK的调制与解调 (二)、原理及框图 FSK是用数字基带信号去调制载波的频率。因为数字信号的电平是离散的,所以,载波频率的变化也是离散的。在本实验中,二进制基带信号是用正负电平表示。对于2FSK,载波频率随着调制信号1或-1而变,1对应于载波频率F1,-1对应于载频F2。

银行储蓄系统

《数据库系统原理》 课程设计 2011年12月31日

目录 一、概述------------------------------------------------- 3 1.1 课程设计的目的---------------------------------------------- 3 1.2 课程设计的内容---------------------------------------------- 3 1.3 课程设计的要求---------------------------------------------- 3 二、需求分析--------------------------------------------- 3 2.1 系统需求---------------------------------------------------- 3 2.2 数据字典---------------------------------------------------- 3 三、系统总体设计----------------------------------------- 3 3.1系统总体设计思路--------------------------------------------- 3 3.2 概念模型设计----------------------------------------- 3 3.2.1 局部E-R图------------------------------------------------ 3 3.2.2 全局E-R图------------------------------------------------ 3 3.3 逻辑结构设计------------------------------------------------ 3 3.4 数据库建立实施--------------------------------------- 3 3.4.1 建立数据库------------------------------------------------ 3 3.4.2 建立关系表------------------------------------------------ 3 四、系统实现--------------------------------------------- 3 五、系统评价--------------------------------------------- 3 六、课程设计心得、总结----------------------------------- 3参考文献:----------------------------------------------- 3致谢--------------------------------------------------- 3附录--------------------------------------------------- 3

01银行储蓄管理系统可行性分析.docx

精心整理软 银行储蓄管理系统 可行性分析 目录

一、引言 1.1 编写目的 经过对该银行储蓄系统项目进行详细调查研究,初拟系统实现报告,对软件开发中将要面临的问题及其解决方案进行可行性分析。明确开发风险及其所带来的经济效益。本报告经审核后,交由软件经理审查。 1.2 背景 项目名称:银行计算机储蓄系统 用户:××银行 说明:现在的银行储蓄系统工作效率低,不能满足广大人民群众的要,人们希望能更方便更省时地办理储蓄业务。 在这样的背景下,切需要建立一个新的、高效的、方便的计算机储蓄系统。 1.3 参考资料 ·《软件工程导论(第五版)》张海藩编着清华大学出版社出版 ·《软件工程》任胜兵邢琳编着北京邮电大学出版社 二、可行性研究的前提 2.1 基本要求 2.1.1 功能要求 此系统所要完成的主要功能有两方面: 储户填写存款单或取款单交给业务员键入系统,如果是存款,系统记录存款人姓名、住址、存款类型、存款日期、利率等信息,完成后由系统打印存款单给储户。 如果是取款,业务员把取款金额输入系统并要求储户输入密码以确认身份,核对密码正确无误后系统计算利息并印出利息清单给储户 2.1.2 性能要求 为了满足储户的要求,系统必须要有高的运作速度,储户填写的表单输入到系统,系统必须能快速及时作出响应,迅速处理各项数据、信息,显示出所有必需信息并打印出各项清单,所以要求很高的信息量速度和大的主存容量; 由于要存贮大量的数据和信息,也要有足够大的磁盘容量;另外,银行计算机储蓄系统必须有可靠的安全措施,以保证储户的存储安全。

2.1.3 接口要求 业务员键入储户的资料要全部一直显示在屏幕上;储户键入密码到系统以核对;计算机与打印机有高速传输的连接接口,最后以纸张的形式打印出清单给储户。 2.1.4 输入要求 业务员从存取款表单输入数据,要迅速精确,适当调整输入时间,不能让客户等太久,但也不能让业务员太过忙碌以免影响正确率,造成用户损失。 2.1.5 输出要求 要求快速准确地打印出存款或取款清单给客户。 2.2 开发目标 近期目标: 第一年内在一个银行建立一个银行内部计算机储蓄系统,初步实现银行储蓄系统计算机化,并保证该银行能够按期望顺利完成工作。 长期目标: 希望在三至四年内,在国内银行中建立该计算机储蓄系统,促进银行间的互联合作,实现银行储蓄系统的计算机管理体制,提高银行储蓄系统的整体水平;并实现银行储蓄系统的高效性、方便性、实用性、互联性,给储蓄用户带来方便和益处,从而提高银行的信用度,提高银行公司的经济效益和社会效益。 2.3 限制条件 2.3.1 开发时间 ( 只限于近期目标 ) 预定为半年。 2.3.2 运行环境 Windowsxp 及以上操作系统、数据库:MicrosoftSQLServer2000。MicrosoftVisualBasic6.0中文版. 2.3.3 使用寿命 该系统至少使用四年以上。 2.3.4 进行可行性研究的方法 采用调查方法:通过对银行业务员和客户的调查以获得第一手资料,确定客户和实际应用中的需求;然后经过座谈

多银行资金管理系统

多银行资金管理系统标准化管理处编码[BBX968T-XBB8968-NNJ668-MM9N]

多银行资金管理系统 多银行资金管理系统(Multi-bank System,简称MBS),是中信银行在专业分工、合作共赢的全新商业理念的指导下,联手专业软件厂商,根据国内集团企业的实际资金管理情况而打造出的多银行资金管理系统,不但融合了银行金融服务和软件厂商技术服务优势,创造了一种专业、可持续的服务模式,更以一种开放的心态进行系统研发,使得MBS的全新合作模式不排他。 功能完善的多银行资金管理系统 中信银行MBS在研发过程中吸收了银行和软件厂商两方面的先进经验,不但能够实现与银行产品服务的快速对接,同时能够更多地体现企业在资金预算、结算和内部财务控制等方面的管理需求,既可以为集团企业提供传统的现金管理服务,还能作为全面的企业内部资金管理系统,为企业提供多银行账户管理、资金结算划拨、计划预算管控和资金流量分析四大业务平台。 通过多银行账户管理平台企业可以自主设定和维护需要管理的所有银行账户,并按照自身的组织架构来定义账户结构,并可以在总部层面实时查询和掌握所有成员机构在各银行的资金余额和交易状况,所有信息按层级分别显示,余额自动汇总,整体资金情况一目了然。 通过资金结算划拨平台企业能够对各银行账户进行收付结算处理,支持企业根据自身财务制度灵活设置各种资金交易的审批流程。资金交易可以通过手动或自动方式发起,系统及时反馈交易信息。如果与ERP相连,还可以联动记账,生成财务凭证。同时所有资金交易均支持单笔录入或批量导入,支付时可以受企业预算控制,并提供多种控制方式。此外,企业还可通过特殊对账码实现自动对账,并生成余额调节表,减少人工操作。 通过计划预算管控平台企业可以建立全面的资金计划管理体系,包括制定统一的资金计划政策和模版,资金计划审批、执行、调整和控制等。企业也可以根据实际收支情况,自动提交计划执行情况,实现资金计划考核和资金风险防范。

银行管理系统-项目开发计划书

软件工程课程设计 项目计划书 项目名称:银行管理系统 学院:计算机科学与技术学院 专业:计算机科学与技术专业 班级: 姓名: 指导教师:

2011 年11 月03 日

目录 1 系统主题................................................................................................................................. 错误!未定义书签。 引言............................................................................................................................................. 错误!未定义书签。 背景/选题动机/目的................................................................................................................... 错误!未定义书签。 系统与“创新杯”的主题关系(2)......................................................................................... 错误!未定义书签。 市场调查过程和结论(3) ............................................................................................................ 错误!未定义书签。 2 需求分析................................................................................................................................. 错误!未定义书签。 概要............................................................................................................................................. 错误!未定义书签。 使用场景..................................................................................................................................... 错误!未定义书签。 可行性分析报告......................................................................................................................... 错误!未定义书签。 应用领域/实用性分析............................................................................................................. 错误!未定义书签。 未来发展方向............................................................................................................................. 错误!未定义书签。 3 团队组成和分工..................................................................................................................... 错误!未定义书签。 4 系统功能概述......................................................................................................................... 错误!未定义书签。 功能需求分析............................................................................................................................. 错误!未定义书签。 系统性能要求 ................................................................................................................. 错误!未定义书签。 功能点列表................................................................................................................................. 错误!未定义书签。 性能点列表................................................................................................................................. 错误!未定义书签。 数据描述..................................................................................................................................... 错误!未定义书签。 5 系统设计概要......................................................................................................................... 错误!未定义书签。 实现系统所采用的技术方案和技术亮点 ................................................................................. 错误!未定义书签。 系统构架..................................................................................................................................... 错误!未定义书签。 功能模块描述............................................................................................................................. 错误!未定义书签。 E-R图 ........................................................................................................................................ 错误!未定义书签。 用例图......................................................................................................................................... 错误!未定义书签。 概念数据模型图......................................................................................................................... 错误!未定义书签。 业务模型..................................................................................................................................... 错误!未定义书签。 界面 ........................................................................................................................................... 错误!未定义书签。 6 系统环境................................................................................................................................. 错误!未定义书签。 开发平台..................................................................................................................................... 错误!未定义书签。 Client运行环境......................................................................................................................... 错误!未定义书签。

相关文档
最新文档