物件導向軟體之架構(Object-Oriented Software Construction)探討

Graph database models can be defined as those in which data structures for the schema and instances are modeled as graphs or generalizations of them, and data manipulation is expressed by graph-oriented operations and type constructors. These models took off in the eighties and early nineties alongside object-oriented models. Their influence gradually died out with the emergence of other database models, in particular geographical, spatial, semistructured, and XML. Recently, the need to manage information with graph-like nature has reestablished the relevance of this area. The main objective of this survey is to present the work that has been conducted in the area of graph database modeling, concentrating on data structures, query languages, and integrity constraints.

/pdf/survey-of-graph-database-models-2ssdmgcn9a.pdf

Survey of graph database models

A comprehensive framework for representing and using nonfunctional requirements during the development process is proposed. The framework consists of five basic components which provide the representation of nonfunctional requirements in terms of interrelated goals. Such goals can be refined through refinement methods and can be evaluated in order to determine the degree to which a set of nonfunctional requirements is supported by a particular design. Evidence for the power of the framework is provided through the study of accuracy and performance requirements for information systems. >

/pdf/representing-and-using-nonfunctional-requirements-a-process-eodpokl5uc.pdf

Representing and using nonfunctional requirements: a process-oriented approach

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166Just Add Users and Stir? . . . . . . . . . . . . . . . . . . . . . . . . . .166Major Bibliographic Sources for Participatory Design . . .167

Participatory design: the third space in HCI

ion function Dl----~======~====~--·D3 a Aggregation] H x hx ]Aggregation function x x function Abstraction function D2 A D4ion function D2 A D4 Fig. 4.1 Commuting Diagram for Aggregation and Abstraction 64 4. Extending the Entity-Relationship Model If the diagram is not commuting then we can use divergence functions which model divergence of the discrete values and the according values for the continuous scale. Such models could be statistical models based on distribution functions for the case of average or summarization functions. We could use interval models for the case of min/max functions. In both cases, we are using approximation functions for abstractions instead of point-to-point mappings. We introduce now nested attributes with more complex domains. Given a data scheme DD = (U, D, dom) and a set of names N A different from U, a set of labels L now formally defines the set UN of nested attributes with the empty word A. 1. AEUN. 2. UCUN. 3. If X E UN then l: X E UN for l E L. 4. If distinct X1, ... , Xn E UN and X EN A then X(X1, ... , Xn) is a (tuplevalued) nested attribute in UN. This attribute type can also be used in the notion X. 5. If X' E UN and X EN A then X {X'} is a (set-valued) nested attribute in UN. 6. No other elements are in UN. The underlying data domains can be complex. Thus, the domain type can be constructed similar to the construction presented for complex attributes. If, for instance, the attribute ZIPCode is used then it may be useful to separately store the complex domain with check sums and additional information (check tables). The set L is used as an additional naming language. Each attribute can be labeled by names or labels from L. Labels can be used as alias names for attributes. They are useful for shortening expressions of complex attributes. They can carry a meaning but do not carry semantics. They can be omitted whenever it is not confusing. Additionally, other type constructors can be used for defining nested attributes: lists of values, e.g., < X >, vectors or arrays of values, e.g., XR;ff;(Y) with an index attribute Y, minimal and maximal index values and bags of values, e.g., nx~ . Furthermore, we can use optional components, e.g., [X]. For simplicity purposes we restrict the model to tuple and set constructors. However, list and bag constructors can be used whenever type constructors are allowed. Note that in [GPV88] an analogous notion of nested attributes is introduced, but with the following additional condition: for different nested 4.2 Entity and Relationship Types 65 attributes X, Y , the sets AT( X) and AT(Y) of atomic attributes used in X and Y are disjoint. Now we can extend the function dom to Dom on UN. 1. Dom(.X) = 0 . 2. For A E U , Dom(A) = dom(A). 3. For l: X E UN, Dom(l: X)= Dom(X). 4. For X(X1, ... ,Xn) E UN , Dom(X) = Dom(Xl) x ... x Dom(Xn) where M1 X .•• x Mn denotes the Cartesian product of the sets M1, ... , Mn. 5. For X{X'} E UN , Dom(X{X'}) = Pow(Dom(X)) where Pow(M) denotes the powerset of the set M. Two attribute types X, Yare called domain-compatible if Dom(X) = Dom(Y). For the data scheme DD the set Dnn denotes the union of all sets Dom(X) for X E UN. A tuple on X~ UN and on DD = (U, D, dom) is a function t : X -+ Dnn with t(A) E Dom(A) for A E X . Let us now define the key concept based on shallow equality and on the structure [AFT92). To do this we need the definition of the subattribute, which uses the approach of[Yok88). Assume a data scheme DD = (U, D, dom) and the set UN. Let h be the function with the empty graph. 1. For A E U , 0 and A are themselves subattributes of A . For a tuple t on A the function t1. is the restriction oft to 0. 2. For X(X1, ... ,Xn) E UN and {Z1, ... ,Zm} ~ {X1, ... ,Xn} (m:::; n) and subattributes Yi of Z; (1 ::=; i ::=; m), X(Y1, ... , Ym) is a subattribute of X(X1, ... , Xn) . For a tuple ton X(X1, ... , Xn) the restriction tx(Y" ... ,Ym) oft to X(Y1, ... , Ym) is defined by the equality tx(Y1 , ... ,Ym)(Yi) = t(Z;) lv; (1 ::=; i ::=; m) where the restriction of dE Dom(Z;) to Yi is denoted by d IY;· 3. For X {Y} E UN and a subattribute Z of Y, X { Z} is a subattribute of X {Y}. For a tuple t on X {Y}, the restriction tx {Z} oft to X { Z} is defined by the equality tx{z}(X{Z}) = t(X{Y}) lz. For a given set of attributes X = {X1, ... , Xn} and {Z1, ... , Zm} ~ {X1, ... , Xn} and subattributes Yi of Z; ( 1 ::=; i ::=; m ), {Y1, ... , Ym} is a generalized subset of {X1, ... ,Xn}. An entity type Eisa pair (attr(E), id(E)) , where E is an entity set name, attr(E) is a set of attributes and id(E) is a non-empty generalized subset of attr(E) called the key or identifier. The notion of entity types can be extended to entity types with key sets or with sets of constraints: 66 4. Extending the Entity-Relationship Model E = (attr(E), {idj(E) 11 ~ j ~ m}) with m keys or E = (attr(E), E) where Eisa set of integrity constraints. Concrete entities e of E can be now defined as tuples on attr(E). At any fixed moment in time t the present entity set Ec for the entity type E is a set of tuples r on attr(E) for which id(E) is a key, i.e., for two different tuples r, r' from Ec the inequality Tid(E) -=f. rfd(E) is valid. This approach is more general than approaches used in (NF) 2 relations. In order to use a simple semantics in [BRS82] and [Hul90], partitioned normal forms are introduced. An entity set is in partitioned normal form if the atomic attributes are a key of the set and any non-atomic value, a component of a tuple of the relation, is also in partitioned normal form. However, the subclass of entity sets in partitioned normal forms is generally not closed under the algebra of nested relations [PDG89]. Furthermore, it is not natural to restrict entity types to those with key sets consisting only of atomic attributes. For instance, the entity type Person = ( { Name(First,Fam),Addr(Zip, Town, Street(Name, No)), Gender}, { Name(First,Fam) }) would not be allowed. It is possible to use the behavior equality [AFT92] for the key definition. Then the key definition corresponds exactly to the key definition of (NF) 2 relations after flattening with the unnest operation. These two approaches do not differ if the tuple constructor is used but they differ if the set operator is used. The following three tuples defined on Phones= (Person, Telephones{(Rooms{Room}, N umbers{TelN umber})}) r = (a, {( { b}, { c, d}) , ( { e, !} , { d, h})}) , r' =(a, {({b, e, !}, {d}), ({b}, {c}), ({e, !}, {h})}), and r" =(a, {({b}, {d}), ({b}, {c}), ({e}, {d}), ( { e}, { h}), ( {!}, { d}), ( {!}, { h})}) are not shallow-equal but they are behavior-equal. These tuples can carry different semantics. Therefore, sometimes behavior equality or other equality concepts may be useful for the application area. The key definition based on behavior equality is stronger than the key definition based on shallow equality. Furthermore, we can introduce a general key concept using functions. Given a set M and a function f : attr(E) --t M, the function f is called a general key of Ec if the inequality f(r) -=f. f(r') is valid for all distinct r,r' E Ec. This notion is very general. It can be used to represent distinction of tuples by shallow equality, by behavior equality, by reduction systems, by aggregation functions, and by transformation to another type. 4.2 Entity and Relationship Types 67 It also covers the concept of the entropy key. Given an entropy function£ and a query q on E. Then q is called £-key of Ec if £(Ec) = £(q(Ec)). Sometimes, it is necessary to use more general key concepts. For instance, if first names are represented by a set or list of names then subsets or sublists could be considered to be equal to its superset or superlist, respectively. In some cases, a super/subtype relationship with more than one subtype occurs. This choice can be modeled by the union of the subtypes. The construct to be used is called a cluster type. Clusters based on entity types can be defined by the disjoint union of types. The disjointness can be weakened for relationship types. Furthermore, we require that the identification types of the components of a cl':lster are domain-compatible. Take now the set of types {R1, ... , Rk} as given. These types can be clustered by a "category" or a cluster C = R1 + R2 + ... + Rk. For a cluster C = R1 + ... + Rk we can similarly define a set cc as the 'disjoint' union of the sets Rf, ... , Rf. If R1, ... , Rk are entity types (0-order relationship types) then Cis a cluster of entity types. The cluster is defined "fRc Rc d" .. t 1 1 , . . . k are IS JOin . The disjointness is necessary because of identification requirements. The identification types id(Ri) of components R; of R have the same domain. They can be reduced using labels: C = h : R1 + l2 : R2 + ... + lk : Rk for pairwise distinct labels h, 12 , ... , lk. Instead oflabels we may use the component number. However in these cases, each object used in a cluster has a value which is labeled by the corresponding label name or component number. In the case of clusters as components of other types, the disjointness is weakened. Entity types E 1 , ... , Ek are now given. A (first-order) relationship type has the form R = (ent(R), attr(R)) where R is the name of the type, ent(R) is a sequence of entity types and of clusters of these, and attr(R) is a set of attributes from UN. A first-order relationship type R = (R1, ... , Rn, {B1, ... , Bk}) and for a given moment t sets Rf, ... , R<;[ are now given. A first-order relationship r is an element of the Cartesian product Rf x ... x R<;[ x Dom(B!) x ... x Dom(Bk)· We distinguish between entity types and clusters. If all R; are entity types then a first-order relationship set Rc is a set of relationships, i. e. Rc ~ Rf X ... X R<;[ X dom(B!) X ..• X aom(Bk)· 68 4. Extending the Entity-Relationship Model If R; is a cluster R; 1 + ... + R; k then the relationships in Rc are distinct according toR;, i.e., f~r r, r' E Rb either r.R; -:

Entity-Relationship Modeling

With Serviceflow Management we put the service nature of inter-organizational processes into the center of modeling, design and architectures. The underlying conceptual distinction between the serviceflow, the portion of the process where the customer's concern is evaluated and cared for, and background processes, guides in (1) providers as well as designers to focus on service design and delivery, (2) to provide support for serviceflows with enhanced flexibility and service configuration and (3) to design service points where service workers and customers "meet". By this, the original workflow metaphor, which directs the design of process support from a mass production point of view, is questioned and replaced by a more suitable concept, which considers social and quality aspects in service delivery. Instance-based XML process representations and generic components and architectures for their exchange and for the provision of service tasks are presented, discussed, and exemplified by an e-health process.

/pdf/serviceflow-beyond-workflow-concepts-and-architectures-for-3i058ffycg.pdf

Serviceflow Beyond Workflow? Concepts and Architectures for Supporting Inter-organizational Service Processes

The designing of IT support for the management of inter-organizational service processes inherits the full complexity of aspects dealt with in approaches altering, automating, and supporting these processes in general--and it needs to go beyond. As customer concerns, especially in long-lasting processes, may change over time, support has to provide flexible service, adjustments among different providers, and opportunities to care for the customer. With serviceflow management (SFM) we argue in favor of putting these service-related aspects in the center of modeling, design and architectures. Its conceptual distinction between the serviceflow (as the portion of the process where the customer's concern is evaluated and cared for) and background processes enables SFM (1) to guide providers as well as designers to focus on service design and delivery, (2) to provide support for serviceflows with enhanced flexibility and service configuration, and (3) to suggest the design of service points where service workers and customers "meet". Thus the original workflow metaphor, which directs the design of process support from a mass production point of view, is questioned and replaced by a more suitable concept, which considers social and quality aspects in service delivery. Instance-based XML process representations, generic components and architectures for their exchange as well as for the provision of service tasks are presented and discussed, exemplified by an e-health process.

Serviceflow beyond workflow? IT support for managing inter-organizational service processes

In contrast to the relational model methods in OODBs must enforce structurally defined constraints such as inclusion and referential constraints. It has been shown that this is possible for basic generic update operations that are determined by the schema. However, such operations only exist for value-representable classes.

Integrity Enforcement in Object-Oriented Databases

In the process of developing an Information System, one passes through stages that include requirements gathering, design specification, and software implementation. The purpose of the TDL language is to express the conceptual design of an information system; it is the intermediate language in a triad that includes the language Telos, which captures an evolutionary view of the application domain and requirements, and DBPL, a procedural programming language that has persistent values and transactions supporting the development of databases. We consider TDL's features for specifying the data and eventual procedural components of the system, and discuss how these are related to its companions. We also survey several tools for manipulating TDL descriptions which are currently under development, and give a detailed example of the iterative refinement of TDL designs into DBPL programs.

Ingrid Wetzel

Papers

Serviceflow Beyond Workflow? Concepts and Architectures for Supporting Inter-organizational Service Processes

Serviceflow beyond workflow? IT support for managing inter-organizational service processes

Integrity Enforcement in Object-Oriented Databases

Support for data-intensive applications: conceptual design and software development

Object-Oriented Construction Handbook