P209 leithiser-relationaldb-formal-specifications


Published on

How to store state definitions including boolean logic decompositions into a relational structure and integrate with the state definitions for applications.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

P209 leithiser-relationaldb-formal-specifications

  1. 1. A Relational Database Model for Representation of FormalSpecificationsRobert LeithiserDepartment of Computer Science and Software EngineeringAuburn University334 201-4536leithrm@auburn.eduABSTRACTLiterature has established the effectiveness of formal specificationsfor modeling specifications for computer system properties as wellas for verifying program correctness. However, tools that canenable the typical commercial software developer to utilize formalmethods are not in widespread use. A possible reason for this isthat commercial tools can more easily be produced if industry-standard storage mechanisms such as relational databasemanagement systems (RDBMS) can be leveraged as repositories.This paper explores how to model and store formal specifications,specifically those based on the Zed method, in a relationaldatabase. We explore a technique for fully decomposing thepredicate calculus to a relational database to provide a frameworkfor manipulation and reverse generation of formal specificationsand automating the implementation of relational states.Categories and Subject DescriptorsD.2.10 [Software Engineering]: Design–Methodologies andRepresentation.General TermsAlgorithms, Design, Human Factors, VerificationKeywordsZed, Relational Database Management System, RDBMS, FormalMethods, Relational State, State Transition, Formal Specification1. INTRODUCTIONFormal specifications provide a means to algebraically modelsystem behavior and state requirements as well as provide amechanism for verifying system correctness [17]. Despite theeffectiveness of formal specifications, implementation in industrystill lags behind their adoption in academia. In the name of RapidApplication Development (RAD) and “agile development” [1],much software development still relies on very lose interpretationof software models or specifications, code duplication,programmer preferences, and “brute-force” testing.One of the difficulties in utilizing formal specifications lies incomprehension [4] due in part to abstraction. This seems acontradiction in that abstraction is generally viewed as an assetfor understanding software architecture. However, abstractness isby definition not concrete and not malleable. Without a graphicalrepresentation of what the abstract model means, thespecifications will be counter-intuitive to those who typicallywork with code rather than discrete mathematics.Historically, graphical tools have provided the impetus forindividuals to embrace technological breakthroughs. Only whenthe technology is easy to use and visualize, does it generally gainwidespread acceptance. One only need think about the popularityof different software programs to realize that a graphical userinterface that is intuitive to use may be far more successful in themarketplace than a technically superior program that does notprovide a good user interface [12]. Programmers and projectleaders, even if educated in formal methods will leave thesebehind for the sake of deadlines if the tools are not easy to use.The Zed specification provides a mathematical technique tomodel relations through predicate calculus that includes state [17]and relational functions. Relational databases are based onsimilar foundations that include mapping of relations [11].Relational databases also provide the capability for animation [6]since data can be retrieved and manipulated from any vantagepoint in the model. Based on this, creation of a relationalframework for persisting Zed specifications can provide afoundation for development of better tools.One key to successful graphical interfaces is a relational objectframework [3] that stores metadata required for the interface. Anobject relational approach provides a two-pronged mechanism toenable user-friendly systems. The objects identify the behaviorsand properties while the relational aspect identifies how theobjects integrate with each other. Since formal methods, arebased on relationships derived from clearly defined set theory[16], we maintain that the information for the schema can bepersisted in a relational database management system (RDBMS)without loss of information. Relational storage of the predicatecalculus that retains the heuristics and constraints of thespecification enable opportunities for third-party tools andindustry-standard approaches such as Structured Query Language(SQL) or XML tools to utilize this data in graphical userinterfaces to query and manage the schema.Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the first page. To copyotherwise, or republish, to post on servers or to redistribute to lists,requires prior specific permission and/or a fee.ACM SE’06, March, 10-12, 2006, Melbourne, Florida, USACopyright 2006 1-59593-315-8/06/0004…$5.00.209
  2. 2. 2. RELATED WORK2.1 Zed Specifications – Perception/UsageLeaders in the formal methods community have written that it is amyth [7] to state that formal methods lie only in the domain ofhighly trained mathematicians. However, Gray [6] outlinesdifficulties of undergraduate students to understand formalmethods. He describes constraint animation as a means toovercome difficulties in utilizing formal methods. Animationallows queries against the specification to be answered in anautomated fashion. Our approach supports the animation conceptin that once the schema is stored in the repository, StructuredQuery Language (SQL) or standard query tools can examine themodel from various perspectives. Such manipulation would bevery tedious using a strictly mathematical text representation.2.2 Formal Methods: Tools and TrendsSeveral efforts have targeted creation and improvement of toolsto help further the adoption of formal methods including the Zedtechnique. However, most of the current attempts do not addressthe fundamental issue of database implementation. Instead, thecurrent approaches appear to be focused more on languageenhancements than on repository definition. Metadata definition[9] is foundational for moving forward with tools development.3. ZED RDBMS DESIGN REQUIREMENTS3.1 Design GoalsWe outline the following design goals to create a RDBMS thatprovides an environment that facilitates the manipulation andanimation of formal Zed specifications. The vision for this designis to foster an environment for increased use through acomprehensive and intuitive data repository.1. Decompose all Zed specifications to level of detail not onlyto support reverse-generation of the specification, but also tosupport manipulation and context-aware validation. That is,the specification information should be stored in a formatthat exposes the types and operations at the same level ofdetail as a text specification. This ensures that any tool thatleverages the database can provide context validation of newor updated specifications based on complete knowledge andintegration of related specifications. This also enablesadditional benefits such as automatic RDBMS schema/codegeneration based on the specification.2. Provide extensibility for universal as well as custom typedefinitions. This means that all types should be defined,including standard Zed types, so that they can be mappedand potentially processed by a rules-interface based enginein order to generate the specifications.3. Utilize native RDBMS database features to the maximumextent possible to leverage existing capabilities rather thanbuilding intelligence beyond that reflected by the schema.This minimizes the amount of business logic required toutilize the data model within an application3.2 Design ApproachThe Zed specification consists of a variety of operations orfunctions that can be defined between types and relations. Ratherthan attempting to define a database that encapsulates allpossibilities, we derive a database design to support a sampleapplication that represents typical specification scenarios. Thismakes the scope of effort manageable, while still prototyping theconcept. Our approach will be to first state the requirements ofthe system, next provide the Zed specification, and then walkthrough the Zed RDBMS design and verify its support of thepredicate calculus. We base the specification problem and samplesolution from a programming assignment from a formal methodsgraduate course [18].3.3 Flight Reservation System3.3.1 RequirementsThe Flight Reservation system books passengers onto flights, andhandles check-in and boarding tasks. The flights are characterizedby flight date/time and number. The following constraints applyto the system:1. Since there can be multiple flights a day, flight numbers for agiven day need to be unique.2. The system keeps track of passengers that made reservationson each flight. To check-in, a passenger must be booked onthat flight. Similarly, to board, a passenger must havealready checked-in and the flight must be assigned a gate.For our scenario, we will focus on the flight creationoperation.3.3.2 Scope of Work1. Define the necessary basic types, user defined sets, andglobal constraints for the system.2. Define the state space and invariants associated with thesystem.3. Define the schema for successful completion, various errorschemas, and complete (total) specification for the flightcreation operation.3.3.3 A Zed SolutionFirst, we define the type definitions and assumptions for thedatabase definition. Complex types are used that consist of sub-types (i.e. Date consist of Day x Month x Year) as well asenumerated types for the output report. Range declarations arealso used for certain types (i.e. Month == 1.12). Thesedemonstrate a variety of methods for declaring types. Onemethod not included in this solution for declaring a type involvesthe use of a function, which we will discuss later.Type Definitions:1. [Passenger, Gate]2. Day == 1..313. Month == 1..124. Year == N5. Date == Day x Month x Year6. Minute == 0..597. Time == Hour x Minute8. Flight = Date x Time x N210
  3. 3. 9. Report :== ok | flight_already_exists |nonexistent_flight | passenger_already_booked |passenger_not_booked | passenger_already_checkdin |passenger_not_checkedin | passenger_already_boarded |no_gate_assignedDatabase Definition:1. A passenger may be booked on more than one flight at atime2. A passenger may only check in to one flight at a time3. A passenger may only board one flight at a time4. A flight may only be assigned to one gateNext, we define the main schema, states of the schema andinitialization as shown below:Figure 1. Flight Reservation System Database SchemaFinally, we define our sample operation for creating a flight - theCreate_Flight operation:Figure 2. Flight Reservation System Create_Flight SchemaThere are additional specifications for booking a flight, checkingin, and boarding. However, for purposes of our exercise, we willonly model the first two operations, as the additional operationsdo not contain any constructs not already established in the firsttwo operations.4. THE ZED RDBMS IMPLEMENTATIONIn this section, we define the Zed RDBMS implementation byillustrating the database schema. We then enumerate the processfor populating the database to reflect the example. We utilizestandard database normalization principles using a functionaldependency approach [2] to identify the entities (relations) andrelationships between the entities.4.1 Zed RDBMS Database DesignA graphical representation of a candidate database model isshown below. This representation illustrates the major relationsand foreign key constraints for storing the Zed Schema. Someconstructs for enforcing rules required for the integrity of the Zedspecification are not shown in this diagram. This is mainly dueto limitations around the relational model. Further research mayshow that an object-relational database system would allowspecification of more advanced rules directly in the design211
  4. 4. Figure 3. Zed RDBMS Entity Relationship Diagram4.2 Entity Summary ChartThe below chart summarizes the purpose of each relation innarrative format. The definition section outlines specifically howeach entity supports the sample Zed specification.The names of the entities do not necessarily match what they arecalled in Zed. In order to provide a normalized and maintainabledatabase implementation, an optimal relational implementationdoes not map directly to Zed specification. In some cases, itrequires multiple relations to decompose a particular construct ofZed.212
  5. 5. Table 1. Zed Entity SummaryAttribute Creates a mapping to a type extendable to adomain. When the attribute is linked to adomain, it becomes a set relation. An attributethat is unbounded (not linked to a domain) mayserve as a global constant or a parameter. Toavoid inconsistencies at the predicate level, anattribute may not be referenced as both aparameter and a domain attribute.Domain Identifies a schema extended through anattribute mapped to a type. The type mustspecify all of the relations required for the set.This is done through the type compositionentity.DomainStateDefines a state of a domain; For example, adomain state may be changed (delta),unchanged, or initial. There is no limit on thenumber of states linkable to a domain. The stateof the domain is defined through the linkedpredicate.DomainTreeAllows domain entities to be organized such thata domain may be included in the schema ofanother domain; There are no limitationsregarding reuse of schemas. A domain schemamay be reused as a child domain in multipledomains and may itself be a parent of differentdomains. The definition is not recursive (i.e. adomain cannot be it’s own parent)Function A function represents a relational operator. Itcan either be a set or item operator (i.e.,memberOf, union, equals). The function isdefined in terms of its output type to ensureconsistency with the predicate arguments towhich it is linked. The output type of thefunction and input parameter type must alignwith the type of the related attribute.Operation Identifies a schema for operations: Operationsschemas are similar to domain schemas in thatthey support linkage of states. However, theyare defined through parameters rather thanattributes.OperationParameterDefines an attribute that may be used as an inputor output parameter.OperationStateDefines a state of an operation; Each operationstate is assumed to be unioned for the totalspecification. Thus, each operation state ismutually exclusive. As is the case with adomain state, the operation state is definedthrough the linked predicate.Predicate Defines an operator to be used with one or morearguments (PredicateArgument); Predicates arenamed for documentation purposes, but areorganized using the PredicateTree entity.PredicateArgumentMaps to an attribute in order to apply thefunction (operator) specified by the Predicateentity.PredicateTreeOrganizes predicates according to an expressiontree structure; This allows any combination offunctions with arguments to be specified whileretaining the granularity of the actual argument(attribute) and relational operator (function).Type Identifies the range and orientation of values;Types may be referenced by other types forsuper-type purposes or through the TypeComposition entity to create multi-part types.TypeCompositionAllows multiple types to be joined together toform a complex type. The types are joined in atotal function unless the nillable attribute is set,in which case a partial function is used.Type Value Identifies specific values allowed for a type –can be used for enumerated types or for rangespecifications.4.3 Approach4.3.1 Zed Item Naming ConventionsTo avoid code generation problems with object names, the datavalues for specification items are given in text format rather thannative notation. For example, DflightDb is defined in thedatabase as FlightDb_Delta. Similarly, a prime is identified bythe suffix “_prime”. Functions are identified by name along witha definition. Potentially, the definition could contain the actualspecial characters such as e for memberOf. For this iteration, thedefinition fields are based on the TeX specification to enablereverse-generation of a Zed specification using LaTex tools [10].4.3.2 Database ViewsFor presentation purposes, several views have been created in thedatabase. These views map the identifiers of the entities directlyto the descriptive names and join related entities. These are usedthroughout the ensuing example rather than the native data. Theactual data is linked in most cases by a unique identifier, ratherthan the descriptive values.4.4 Schema DefinitionWe now attempt to model the Zed Specification through datavalues stored in our Zed RDBMS. In this section and in theOperation Definition section, we enumerate the values required tosupport the example.4.4.1 Type DefinitionThe Type relation identifies the type name, along with a restrictorto define how to represent the type values. At this time, the onlyvalid restrictor besides “N” (positive integer) is range, whichindicates that a range of two values will construct the type. Thisdefines types such as hour or minute that have a definite range. Ifno restrictor is specified, any number of values may be associatedwith the type using the TypeValue table. TypeValue includes asequence number to order the low and high values. The sequencenumber can also be used for other types that do not require aspecific ordering for presentation purposes. For example, it maybe desirable to list the “OK” value as the first enumerated Reporttype value rather than sorting alphabetically.Table 2. Sample types with values:213
  6. 6. Type Restrictor Type ValuesHour Range 1,24Minute Range 1,60Day Range 1..31Month Range 1..12Year NBoolean True, FalseReport OK, flight_already_exists,no_gate_assigned,nonexistent_flight, etcFlightNo NPassengerThere are three additional features associated with type, only oneof which is implemented in this example. The unimplementedfeatures include definition through a function (predicated type)and super-typing. The SuperTypeName field permits abstractoperation definitions by allowing a sub-type to belong to a super-type. Type composition is used and it provides the capability toreuse the same type multiple times.The predicated type feature provides a mechanism to define atype in terms of a function by using the Predicate construct(discussed later). This feature supports special types that caninclude domain validation. For example, a UniqueId type couldbe defined such that all values in the domain of the type must beunique within a set based on the below Zed notation:N | A S : seq X • UNIQUE_ID S ¤ A i,j: dom S |i Îj • S(i)Î S(j))Another example could be an improved definition for the Daytype. Rather than this being simply a range from 1 to 31, thiscould be defined in terms of a function that calculated the validday range given the month and year.TypeComposition supports many-to-many mappings betweencomposition types and master types. This means that the samecomponent type may be used as part of multiple master types.For example, the Flight type requires a mapping of Date x Time xN (FlightNo). This is represented by associating types “Date”,“Time”, and FlightNo as component types with the master type“Flight”. A master type may itself be a component of anothermaster type. For instance, Date is a component of Flight, butDate itself consists of components Day, Year, and Month. Thisapproach is in keeping with Zed specification that allows freedefinition of composite types.Table 2. Sample Type Composition (TypeComposition):Master Type Component TypeTime HourMinuteDate DayMonthYearFlight DateTimeFlightNoBooking FlightPassenger4.4.2 Attribute definitionThe attribute definition step involves creating a mapping from atype for use in a domain, global variable, or parameter. Theattribute can then be used as an argument for a Predicate throughPredicateArgument to define post-conditions for states of theschema and operations. Unbounded attributes (not linked to adomain) are used for operation parameters.4.4.3 Domain definitionThe Domain relation defines the non-operational schemas tosupport the specification. The domain relation defines a schemaand identifies the subordinate relations based on mapping of theattribute to a particular type. The attribute thus becomes thepower set of the specified type. A cardinality attribute can bedefined in the schema to limit the set to a specific number ofoccurrences, but this feature is not required in this example.DomainTree supports organization of sub-domains under a masterdomain. A Domain may be enlisted as a sub-Domain in any otherDomain and a sub-Domain may itself contain domains. Forexample, Flights, Bookings, Checkins, Boardings, and gatesreference FlightDb as the parent domain. FlightDb is alsoreferenced as a child domain by both FlightDb_Delta andFlightDb_Schema. DomainTree is intended to be non-recursive -the domain cannot specify itself as the parent.Table 3. Sample Domain Tree (DomainTree):Parent Domain Child Domain with Type (Attribute)FlightDb Boardings: BoardingBookings: BookingCheckins: CheckinFlights: FlightGates: GateFlightDb_Delta FlightDb: SchemaFlightDb_Prime: SchemaFlightDb_Schema FlightDb: SchemaFlightDb_Delta: Schema4.4.4 Domain State and Predicate DefinitionDomainState constitutes the specification paragraph that includesthe schema and operations. Domain states may be createdwithout reference to a predicate if only the schema is needed. Inorder to define the state post-conditions for the specification, apredicate must be linked to the Domain State.Predicates are defined through relations between attributes. ThePredicate relation structure supports the decomposition of allattributes and functions. This is required to support the designgoals and allow reverse generation and consistency validation.All expressions are reduced down to the lowest database typesand functions – no free-format expressions allowed.The Predicate relation is the starting point for defining a predicateand its arguments. This relation provides the operator usedbetween arguments. If a predicate requires different operators(i.e. AND/OR) then separate sub predicates must be defined. Thisis equivalent to a parenthetical notation within the Zed predicatecalculus. The predicate structure is formed through the PredicateTree to support the complete logic structure. It allows multiplepredicates to be organized in a hierarchical fashion with differentoperations, similar to an Expression Tree [15]. PredicateTree andPredicate provide a blueprint for the logic.214
  7. 7. The specification of the attributes to utilize for arguments is donethrough the PredicateArgument relation. The number and role ofeach argument is derived based on the function associated withthe predicate. The attributes do not need to link to a domainschema. If an attribute is specified that belongs to a domainschema, the attribute must be part of the same domain schemalinked to the predicate. An unbounded attribute may be used forthe predicate argument in order to support the use of a globalvariable or a parameter. The sequence of the argument issignificant in the case where the function is not reflexive, such asfor a subset operator or implication operator because it defineshow to arrange the arguments in the context of the operator. Forexample for the predicate “boardings domain”, boarding isidentified as a subset of flights rather than the reverse.The following diagram illustrates an instatiation of data to supporta predicate tree for state “flight_exists”. This state could then beindicated as part of the predicate for a successful “Assign_Gate”operation. The item in bracket refers to the data structure. TheFunction entity determines the arguments that can be specified fora particular predicate operation.Figure 4. Flight Assignable predicate tree instantiation:4.4.5 Implementation SummaryAt this point, schema definition is complete. The databasecontains information necessary to reverse-generate the schemadefinition. Model consistency is provided through thecombination of database relationships and constraints discussed.The database can be used by a graphical UI to define Zedspecifications in a self-validating and context-sensitive fashion.Additionally, the RDBMS model can be generated directly fromthe specification. The below outlines high-level methods andrelational queries to generate specifications as well as RDBMS:1) GenerateZedSchema(Domain Name)2) Output elementary types (select types that are not part of amaster types) along with values3) Output composite types (select types that have componenttypes) and list the component types4) Output elementary domains (select domains that are not achild of other domains)a) Output domain name and type based on attributemappingb) Select predicate associated with the domainc) For each predicate in predicate treed) Output conditions recursively (continue to access eachpredicate until reaching bottom of tree outputtingconditional statements).5) For each domain in Domain Treea) Output domain name and typeb) Select predicates associated with the domains in thesame way as C3.6) GenerateRDBMS(Domain Name)7) Enumerate Domainsa) For each Domainb) Generate “Create Table” commandc) For each sub-type found in the attribute linked to thedomain tablei) Generate system-defined primary keyii) Generate column definitioniii) If column indicates not nillable, then this columnbecomes part of a second unique key.d) For each predicatee) Evaluate predicate functioni) If simple “in” relation function, then generateforeign key relationii) Create constraints using predicate attributes – thisrequires mapping the function (i.e. “memberOf”)to a SQL relational construct such as “Select xfrom table where x in table y”.4.5 Operation DefinitionOperation definition is similar to schema definition. The onlysubstantial difference is that operations include parameters thatare defined using the OperationParameter relation and thatattributes defined as Operation parameters are then specified inthe PredicateAttribute. The database must check that thepredicate arguments are parameters or that the predicatearguments are from the same domain schema.4.5.1 Operation ParametersThe parameters are linked directly with the operation. Thiseliminates the need to re-specify the same input and outputparameters for joined operations such as in the case of“create_database_ok and “create_database_failed_flight_exists”.Operation states are joined (union) to represent outcomes from thesame operation. Each operation state references a specificpredicate. This predicate identifier is related to the identicalrelations used for domain specification.215
  8. 8. 4.5.2 Operation Definition StepsOperation definition can be summarized as follows:1) Define high-level operations2) Define operation states for disjoint operation results (i.e.create_flight_ok and create_flight_failed)3) Create unbounded attributes (do not link to a domain) torepresenet parameters such as “newFlight?” or“report_out!”4) Link the unbounded attributes as parameters for theOperation5) Create predicates that describe actions along with theoperators for arguments to the predicate6) Create predicate tree to organize actions7) Identify the predicate arguments by linking in theattributes4.5.3 Operation Table ValuesThe contents of the relations required to support the CreateFlightoperation are:OperationName StateNameCreate_Flight Create_Flight_OkFlight_failed_existsThese two operations are unioned to form the total specification.The parameters required for the CreateFlight operation are:OperationName AttributeName TypeNameCreate_Flight newFlight_in Flightreport_out ReportThe operation states are decomposed into the below PredicateHierarchy:ParentPredicateParentOp.ChildPredicate ChildOp.create flight fail-flight existsand new flight in flight INand report flight exists equalscreate flight ok and boardings unchanged equalsand bookings unchanged equalsand checkins unchanged equalsand flight_prime is flightunion new flightequalsand gate unchanged equalsand Not_new flight inflightsNOTINand Report ok equalsflight_prime isflight union newflightequals flight union new flight unionNote that “flight_prime is flight union new flight” is broken downinto a child relation in order to support the union operator tocreate the new flight from the parameter. The predicateparameters are defined in a manner similar to that for the schemastate.4.5.4 Operation Implementation SummaryThe RDBMS at this point contains the information necessary togenerate operation schemas. Additionally, generation of storedprocedures to actually change data values and state based onparameter values received is possible. The algorithms forgenerating the operations schema are identical as that fordomains, except that the Operation and Operation States definethe schema paragraphs.The predicate attributes in conjunction with the parameterdefinitions can allow the generation of database stored proceduresthrough a mapping table that maps the equivalent functions toSQL Verbs. For instance, a function of “IN” that combineddomain attributes and parameter attributes in thepredicateArgument could generate a SQL statement of Select col1from table1 where col1 in (select col2 from table2 where col2 =parameter1.5. CONCLUSIONIn this paper, we have focused on the creation of a relationalmodel that can provide a repository for Zed specifications. Thishas significance for providing an infrastructure for creating tools.Using a Zed RDBMS representation allows third party tools toleverage information in the database to persist the information inthe database to XML. The approach for persisting RDBMSstructures in XML is discussed by Fong [5].Although formal specifications are not intended to provideimplementation details, many common software applicationrequirements may be met simply by implementing the statetransitions modeled through formal methods. For instance, thebusiness rules for workflow applications that require prior pre-conditions in order to perform the next operation can beimplemented directly from specification into a relational databasewith database constraints and table relationships.The reality is that all software systems are merely abstractions offinite-state machines. At the core, every operation performed isbased on the state of a set of variables at a given point in time.Thus we do not need to demonstrate the capability to transitionany formal specification that defines states to a state-orientedprogramming approach, we only need to determine the extent towhich the solution should be state-oriented which makes mostsense given the resources. As Budd [3] describes, the capabilityto automate state definition and implementation has significancein advancing efficiency and quality of software development.5.1 Limitations and ObjectionsComplexity: This scenario does not stress all of the requirementsfor relational representation of Zed specifications. More complexscenarios require more complex database entities – at this point,only a simple example has been pursued. However, Park [14] hasproven algebraically that persistence of any formal specificationcan be persisted relationally.Data Integrity: Consistency errors can only be prevented withdatabase constraints and through execution of stored proceduresfor input/updates to certain relations. This is due mainly tolimitations in current RDBMS implementations. This highlightsthe benefit of improving RDBMS systems to support post-conditional constraints natively within the metadata, forfacilitating the storage of metadata to support the formal methodsat the database level.216
  9. 9. Rapid Development: One of the objections to formalspecifications comes from the RAD programming community dueto the time involved. However, development time can actually beimproved by using tools that could facilitate the entry of Zedspecifications and generate code from the specifications. Herranz[8] describes a system called “SLAM” that integrates rapidprototyping with formal specification. Storing the specification ina database opens up the opportunity to automate code generationand maintenance.5.2 Areas for Further ResearchRelational Implementation: We have shown how to extend arelational database with specific tables to support a formalspecification schema. A much better approach is to support thisnatively in the RDBMS product, particularly since much of whatis being defined may in fact be actual database tables. Much ofthe implementation requires the coding of more complexconstraint checking than afforded by standard RDBMSimplementations. This code could be eliminated by supportingstate-oriented constructs in the database.Zed Graphical Manipulation Tool: Given the constraintsalready built into the database, such a graphical tool could easilyrender the relations within the specification and check the validityof specifications. This is a significant improvement over mostcurrent Zed tools that simply allow linear input of a specificationand then check for consistency. A relational database modelunder girding the tool can make it possible for the tool toobjectify the semantics and allow manipulation and cascading ofentities within the model.State-Oriented Programming Language Improvements:Various innovations can integrate more closely with state-orientedprogramming concepts. This includes the ability for a language tosupport constructs that are based on relational state rather thansimply on procedural language. State-oriented programming hasthe potential to revolutionize the quality of software development[13].6. ACKNOWLEDGMENTS1. Levent Yilmaz, PhD, Professor, Auburn for assistancewith Formal Methods and Zed notation examples2. Drew Hamilton, PhD, Professor, Auburn for guidancein formulating paper7. REFERENCES[1] Agile Aliance. 2005. Agile Alliance. Retrieved December12, 2005, from http://www.agilealliance.com/[2] Bernstein, P. A. 1976. Synthesizing third normal formrelations from functional dependencies. ACM Trans.Database Syst. 1, 4 (Dec. 1976), 277-298. DOI=http://doi.acm.org/10.1145/320493.320489[3] Budd, T. A. 1991. “Blending Imperative and RelationalProgramming,” IEEE Software, vol. 8, no.1, pp. 58-65 (Jan.1991),. DOI= http://dx.doi.org/10.1109/52.62933[4] Finney, Kate. 1996. “Mathematical Notation in FormalSpecification: Too Difficult for the Masses?” IEEETransactions on Software Engineering, (Feb. 1996) pp.158−159[5] Fong, J, Pang, F., Bloor, C. 2001. “Converting relationaldatabase into XML document”, Database and ExpertSystems Applications, 2001. Proceedings. 12th InternationalWorkshop on 3-7, (Sept. 2001), pp. 61 – 65.[6] Gray J., Schach S. 2000. “Constraint Animation Using anObject-Oriented Declarative Language”, Proceedings of the38th Annual ACM SE Conference, Clemson, SC, (Apr.2000), pp. 1-10. Available online athttp://www.cis.uab.edu/gray/Pubs/acmse-2000.pdf[7] Hall, Anthony 1990. “Seven Myths of Formal Methods,”IEEE Software, (Sept. 1990), pp. 11−19.[8] Herranz, Angel; Moreno-Navarro, Juan Jos´e "RapidPrototyping and Incremental Evolution Using SLAM," rsp,14th IEEE International Workshop on Rapid SystemPrototyping (RSP03), (2003), p. 201.[9] Jeffery, Keith, G. Metadata. The Future of InformationSystems, Retrieved on 12/12/2005 fromhttp://www.wmo.ch/web/www/WDM/ET-IDM/Doc-2-3.html[10] Latex Project Site. 2005. LaTeX – A document preparationsystem. Retrieved December 12, 2005, fromhttp://www.latex-project.org/[11] Markowitz, V. M. and Makowsky, J. A. 1990. IdentifyingExtended Entity-Relationship Object Structures in RelationalSchemas. IEEE Trans. Softw. Eng., vol. 16, no. 8 (Aug.1990), pp. 777-790. DOI=http://dx.doi.org/10.1109/32.57618[12] Nielsen, J. and Levy, J. 1994. Measuring usability:preference vs. performance. Commun. ACM vol. 37, no. 4(Apr. 1994), pp. 66-75. DOI=http://doi.acm.org/10.1145/175276.175282[13] Nomoto, H. 2004. State oriented programmingHigh Assurance Systems Engineering, 2004. Proceedings.Eighth IEEE International Symposium, (2004), pp. 304 –305[14] Park, H. C. and Kim, T. G. 1998. “A relational algebraicframework for VHDL models management,” Trans. Soc.Comput. Simul. Int. vol. 15, no. 2 (Jun. 1998), pp. 43-55[15] Preiss, B. R. 1999. Data Structures and Algorithms withObject-Oriented Design Patterns in Java. NY. Wiley. p. 264.Retrieved December 12, 2005, fromhttp://www.brpreiss.com/books/opus5/html/page264.html[16] Spivey, J.M. 1992. The Z Notation: A Reference Manual,Prentice-Hall, New York, NY, 1992[17] Wing, J.M 1990. “A Specifiers Introduction to FormalMethods,” IEEE Computer, (Sept. 1990) vol. 23, no, 9, pp.8-24,[18] Yilmaz, Z. (2005). Formal Methods for SoftwareEngineering - Flight Reservation Assignment. RetrievedDecember 12, 2005, fromhttp://www.eng.auburn.edu/~yilmaz/comp7730/HW4.pdf217