DOCSLIB.ORG

Z Formal Specification Language - an Overview Mr

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Z Formal Specification Language - an Overview Mr International Journal of Engineering Research & Technology (IJERT) ISSN: 2278-0181 Vol. 1 Issue 6, August - 2012 Z Formal Specification Language - An Overview Mr. Vishal Ruhela Graduate Trainee Engineer, HCL Technologies, Noida, India In this paper an outline of formal method is Abstract described in Section 2.In Section 3 Difference between formal and informal specification language is presented. In Section 4 An Formal methods provide a much needed overview of Z formal specification language is solid software engineering foundation for the described. In Section 5 An example to describe ‘art’ of programming computers. Formal Z is presented. Conclusions are presented in specifications can be used to provide an Section 6. unambiguous and consistent supplement to natural language descriptions and can be rigorously validated and verified leading to the 2. An Outline early detection of specification errors. Z is a model oriented formal specification language In this section we describe formal method, based on Zermelo-Fränkel axiomatic set formal specification language and its different theory and first order predicate logic. It is a types. mathematical specification language, with the help of which natural language requirements 2.1. Formal Method can be converted into mathematical form. In this paper an overview of formal method is Formal methods used in developing presented. Z formal specification language is computer systems are mathematical techniques described using small example. for portraying system properties. Such formal methods provide structures within which software system can be specified, developed Keywords: Informal and Formal and verified in a systematic, rather than ad hoc, Specification Language, Model Oriented , Z. manner [2]. Formal methods can be applied throughout the development of a system to 1. Introduction precisely describe a system and involve the use of refinement techniques and proof obligation at each stage to ensure the correctness, With the ever-increasing complexity of completeness and consistency of specification. computer systems, reliable and effective, Formal methods used in developing computer design and development of high quality systems are mathematical based techniques for systems that satisfy their requirements is portraying system properties. extremely important. In the mission and safety critical system failure can cause cost overrun, loss of lives or even severe economic Formal methods can be used at a number consequences can arise. So, in such situations, of levels: it is necessary that errors are uncovered before software is put into operation. These Formal Specification: In computer science, challenges call for acceptance of proper a formal specification is a mathematical engineering methods and tools and have description of software or hardware that may motivated the use of formal methods in be used to develop an implementation. It software engineering. describes what the system should do, not There are varieties of formal specification (necessarily) how the system should do it. languages available to fulfill this goal and one Given such a specification, it is possible to use way to achieve this goal is by using Z formal formal verification techniques to demonstrate specification language. Z is model oriented that a candidate system design is correct with formal method based on set theory and first respect to the specification. This process of order predicate calculus [1]. formal specification is similar to the process of converting a word problem into algebraic notation. www.ijert.org 1 International Journal of Engineering Research & Technology (IJERT) ISSN: 2278-0181 Vol. 1 Issue 6, August - 2012 objects properly satisfy the specification. Formal development and verification: Formal specification languages use Formal development process involves mathematics as their basis. Most complex iteratively refining a formal specification to systems can be modeled using simple produce the finished system. Formal Methods mathematical objects, such as sets, relations differ from other specification systems by their and functions. A mathematical statement is heavy emphasis on provability and correctness. unambiguous and precise, which provides a By building a system using a formal way to give convincing arguments to justify specification, the designer is actually ones solutions, and allows proving that an developing a set of theorems about his system. implementation satisfies the mathematical By proving these theorems correct, the formal specification [2]. methods ensures the correctness of the system. The process of proving or disproving properties of the software system against a 2.3. Types of Formal Specification formal specification is known as formal Languages verification. Different types of Formal Specification Implementation: Once the model has been Languages are: specified and verified, it is implemented by converting the specification into code. As the 2.3.1. Model Based Languages difference between software and hardware design grows narrower, formal methods for There are a number of different ways to developing embedded systems have been write a precise specification. One approach is developed [2]. model based languages. In it the specification is expressed as a system state model. This state 2.2. Formal Specification Language model is constructed using well understood mathematical entities such as sets, relations, The representation used in formal methods is sequences and functions. Operations of a called a formal specification language. The system are specified by defining how they language is formal in the sense that it has a affect the state of the system model. formal semantics and as a result can be used to Operations are also described by the predicates express specifications in a clear and given in terms of pre and post conditions [3]. unambiguous manner. A formal specification The most widely used notations for developing language can be used to specify the task at model based languages are Vienna hand in a clear and concise manner. As formal Development Method (VDM) [4], Zed (Z) [1] methods and formal specification language has and B [5]. sound mathematical basis, it provides the means of proving that specification is 2.3.2. Algebraic Specification Languages realizable, complete, consistent and Process algebras are amenable to algebraic unambiguous. Even the most complex systems manipulation; however, there are also can be modeled using relatively simple languages which describe a system solely in mathematical objects, such as sets, relations terms of its algebraic properties. These and functions [2]. algebraic specification languages describe the A formal specification language is usually behavior of a system in terms of axioms that composed of three primary components or in characterize its desired properties. Examples of mathematical term we can say that it consists algebraic specification languages include OBJ of two sets, syntax and semantics and a set of [7] and the Common Algebraic Specification relation [2]. Language (CASL) [6]. In mathematical terms The specific notation with which specification algebra (or an algebraic system) consists of (1) is represented is defined by syntactic domain a set of symbols denoting values of some type, or syntax. Formal techniques can have referred to as the carrier set of the algebra; and considerably different semantic domain. (2) a set of operations on the carrier set. Semantics helps to define a universe of objects that will be used to describe the system. Set of 2.3.3. Process oriented Languages relations defines the rules that indicate which www.ijert.org 2 International Journal of Engineering Research & Technology (IJERT) ISSN: 2278-0181 Vol. 1 Issue 6, August - 2012 Concurrent systems are described using operator logs into the system. In this extract, process oriented formal specification language. does the word it refers to the password or the A specific implicit model for concurrency is operator identity? the basis for these languages. In these Vagueness often occurs because a system languages processes are denoted and built up specification is a very bulky document. by expressions and elementary expressions, Achieving a high level of precision respectively, which describe particularly consistently is an almost impossible task. It simple processes. Ex. Communicating can lead to statements such as the Sequential Processes (CSP) [8]. interface to the system used by radar operators should be user-friendly or the virtual interface 2.3.4. Hybrid Languages shall be based on simple overall concepts that Many systems are built with a combination of are straightforward to understand and use and analog and digital components. In order to few in number. A casual perusal of these specify and verify such systems it is necessary statements might not detect the underlying lack to use a specification language that of any useful information. encompasses both discrete and continuous Incompleteness: The most frequently mathematics. There has been recent interest in occurring problems with system specifications. these hybrid languages, such as CHARON [9]. For example, consider the functional A simple example of a nonlinear hybrid requirement: The system should maintain the system is that of a temperature controller. The hourly level of the reservoir from depth temperature of a room is controlled through a sensors situated in the reservoir. These values thermostat which continuously senses the should be stored for the past six months.
Load more

Recommended publications
  • Formal Specification Methods What Are Formal Methods? Objectives Of
    ICS 221 Winter 2001 Formal Specification Methods What Are Formal Methods? ! Use of formal notations … Formal Specification Methods ! first-order logic, state machines, etc. ! … in software system descriptions … ! system models, constraints, specifications, designs, etc. David S. Rosenblum ! … for a broad range of effects … ICS 221 ! correctness, reliability, safety, security, etc. Winter 2001 ! … and varying levels of use ! guidance, documentation, rigor, mechanisms Formal method = specification language + formal reasoning Objectives of Formal Methods Why Use Formal Methods? ! Verification ! Formal methods have the potential to ! “Are we building the system right?” improve both software quality and development productivity ! Formal consistency between specificand (the thing being specified) and specification ! Circumvent problems in traditional practices ! Promote insight and understanding ! Validation ! Enhance early error detection ! “Are we building the right system?” ! Develop safe, reliable, secure software-intensive ! Testing for satisfaction of ultimate customer intent systems ! Documentation ! Facilitate verifiability of implementation ! Enable powerful analyses ! Communication among stakeholders ! simulation, animation, proof, execution, transformation ! Gain competitive advantage Why Choose Not to Use Desirable Properties of Formal Formal Methods? Specifications ! Emerging technology with unclear payoff ! Unambiguous ! Lack of experience and evidence of success ! Exactly one specificand (set) satisfies it ! Lack of automated
    [Show full text]
  • Certification of a Tool Chain for Deductive Program Verification Paolo Herms
    Certification of a Tool Chain for Deductive Program Verification Paolo Herms To cite this version: Paolo Herms. Certification of a Tool Chain for Deductive Program Verification. Other [cs.OH]. Université Paris Sud - Paris XI, 2013. English. NNT : 2013PA112006. tel-00789543 HAL Id: tel-00789543 https://tel.archives-ouvertes.fr/tel-00789543 Submitted on 18 Feb 2013 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. UNIVERSITÉ DE PARIS-SUD École doctorale d’Informatique THÈSE présentée pour obtenir le Grade de Docteur en Sciences de l’Université Paris-Sud Discipline : Informatique PAR Paolo HERMS −! − SUJET : Certification of a Tool Chain for Deductive Program Verification soutenue le 14 janvier 2013 devant la commission d’examen MM. Roberto Di Cosmo Président du Jury Xavier Leroy Rapporteur Gilles Barthe Rapporteur Emmanuel Ledinot Examinateur Burkhart Wolff Examinateur Claude Marché Directeur de Thèse Benjamin Monate Co-directeur de Thèse Jean-François Monin Invité Résumé Cette thèse s’inscrit dans le domaine de la vérification du logiciel. Le but de la vérification du logiciel est d’assurer qu’une implémentation, un programme, répond aux exigences, satis- fait sa spécification. Cela est particulièrement important pour le logiciel critique, tel que des systèmes de contrôle d’avions, trains ou centrales électriques, où un mauvais fonctionnement pendant l’opération aurait des conséquences catastrophiques.
    [Show full text]
  • Implementing a Transformation from BPMN to CSP+T with ATL: Lessons Learnt
    Implementing a Transformation from BPMN to CSP+T with ATL: Lessons Learnt Aleksander González1, Luis E. Mendoza1, Manuel I. Capel2 and María A. Pérez1 1 Processes and Systems Department, Simón Bolivar University PO Box 89000, Caracas, 1080-A, Venezuela 2 Software Engineering Department, University of Granada Aynadamar Campus, 18071, Granada, Spain Abstract. Among the challenges to face in order to promote the use of tech- niques of formal verification in organizational environments, there is the possi- bility of offering the integration of features provided by a Model Transforma- tion Language (MTL) as part of a tool very used by business analysts, and from which formal specifications of a model can be generated. This article presents the use of MTL ATLAS Transformation Language (ATL) as a transformation artefact within the domains of Business Process Modelling Notation (BPMN) and Communicating Sequential Processes + Time (CSP+T). It discusses the main difficulties encountered and the lessons learnt when building BTRANSFORMER; a tool developed for the Eclipse platform, which allows us to generate a formal specification in the CSP+T notation from a business process model designed with BPMN. This learning is valid for those who are interested in formalizing a Business Process Modelling Language (BPML) by means of a process calculus or another formal notation. 1 Introduction Business Processes (BP) must be properly and formally specified in order to be able to verify properties, such as scope, structure, performance, capacity, structural consis- tency and concurrency, i.e., those properties of BP which can provide support to the critical success factors of any organization. Formal specification languages and proc- ess algebras, which allow for the exhaustive verification of BP behaviour [17], are used to carry out the formalization of models obtained from Business Process Model- ling (BPM).
    [Show full text]
  • A Classification and Comparison Framework for Software Architecture Description Languages
    A Classification and Comparison Framework for Software Architecture Description Languages Neno Medvidovic Technical Report UCI-ICS-97-02 Department of Information and Computer Science University of California, Irvine Irvine, California 92697-3425 [email protected] February 1996 Abstract Software architectures shift the focus of developers from lines-of-code to coarser- grained architectural elements and their overall interconnection structure. Architecture description languages (ADLs) have been proposed as modeling notations to support architecture-based development. There is, however, little consensus in the research community on what is an ADL, what aspects of an architecture should be modeled in an ADL, and which of several possible ADLs is best suited for a particular problem. Furthermore, the distinction is rarely made between ADLs on one hand and formal specification, module interconnection, simulation, and programming languages on the other. This paper attempts to provide an answer to these questions. It motivates and presents a definition and a classification framework for ADLs. The utility of the definition is demonstrated by using it to differentiate ADLs from other modeling notations. The framework is also used to classify and compare several existing ADLs. One conclusion is that, although much research has been done in this area, no single ADL fulfills all of the identified needs. I. Introduction Software architecture research is directed at reducing costs of developing applications and increasing the potential for commonality between different members of a closely related product family [GS93, PW92]. Software development based on common architectural idioms has its focus shifted from lines-of-code to coarser-grained architectural elements (software components and connectors) and their overall interconnection structure.
    [Show full text]
  • Behavioral Verification of Distributed Concurrent Systems with BOBJ
    Behavioral Verification of Distributed Concurrent Systems with BOBJ Joseph Goguen Kai Lin Dept. Computer Science & Engineering San Diego Supercomputer Center University of California at San Diego [email protected] [email protected] Abstract grams [4]), whereas design level verification is easier and more likely to uncover subtle bugs, because it does not re- Following condensed introductions to classical and behav- quire dealing with the arbitrary complexities of program- ioral algebraic specification, this paper discusses the veri- ming language semantics. fication of behavioral properties using BOBJ, especially its These points are illustrated by our proof of the alternat- implementation of conditional circular coinductive rewrit- ing bit protocol in Section 4. There are actually many dif- ing with case analysis. This formal method is then applied ferent ways to specify the alternating bit protocol, some of to proving correctness of the alternating bit protocol, in one which are rather trivial to verify, but our specification with of its less trivial versions. We have tried to minimize mathe- fair lossy channels is not one of them. The proof shows that matics in the exposition, in part by giving concrete illustra- this specification is a behavioral refinement of another be- tions using the BOBJ system. havioral specification having perfect channels, and that the latter is behaviorally equivalent to perfect transmission (we thank Prof. Dorel Lucanu for this interpretation). 1. Introduction Many important contemporary computer systems are distributed and concurrent, and are designed within the ob- Faced with increasingly complex software and hardware ject paradigm. It is a difficult challenge for formal meth- systems, including distributed concurrent systems, where ods to handle all the features involved within a uniform the interactions among components can be very subtle, de- framework.
    [Show full text]
  • An Architectural Description Language for Secure Multi-Agent Systems
    An Architectural Description Language for Secure Multi-Agent Systems Haralambos Mouratidis1,a, Manuel Kolpb, Paolo Giorginic, Stephane Faulknerd aInnovative Informatics Group, School of Computing, IT and Engineering, University of East London, England b Information Systems Research Unit, Catholic University of Louvain (UCL), Belgium c Department. of Information and Communication Technology, University of Trento, Italy d Information Management Research Unit, University of Namur, Belgium Abstract. Multi-Agent Systems (MAS) architectures are gaining popularity for building open, distributed, and evolving information systems. Unfortunately, despite considerable work in the fields of software architecture and MAS during the last decade, few research efforts have aimed at defining languages for designing and formalising secure agent architectures. This paper proposes a novel Architectural Description Language (ADL) for describing Belief-Desire-Intention (BDI) secure MAS. We specify each element of our ADL using the Z specification language and we employ two example case studies: one to assist us in the description of the proposed language and help readers of the article to better understand the fundamentals of the language; and one to demonstrate its applicability. Keyword: Architectural Description Language, Multi-Agent Systems, Security, BDI Agent Model, Software Architecture 1 Corresponding Author: [email protected] 1 1. Introduction However, as the expectations of business stakeholders are changing day after day; and The characteristics and expectations of as the complexity of systems, information new application areas for the enterprise, and communication technologies and such as e-business, knowledge management, organisations is continually increasing in peer-to-peer computing, and web services, today’s dynamic environments; developers are deeply modifying information systems are expected to produce architectures that engineering.
    [Show full text]
  • Should Your Specification Language Be Typed?
    Should Your Specification Language Be Typed? LESLIE LAMPORT Compaq and LAWRENCE C. PAULSON University of Cambridge Most specification languages have a type system. Type systems are hard to get right, and getting them wrong can lead to inconsistencies. Set theory can serve as the basis for a specification lan- guage without types. This possibility, which has been widely overlooked, offers many advantages. Untyped set theory is simple and is more flexible than any simple typed formalism. Polymorphism, overloading, and subtyping can make a type system more powerful, but at the cost of increased complexity, and such refinements can never attain the flexibility of having no types at all. Typed formalisms have advantages too, stemming from the power of mechanical type checking. While types serve little purpose in hand proofs, they do help with mechanized proofs. In the absence of verification, type checking can catch errors in specifications. It may be possible to have the best of both worlds by adding typing annotations to an untyped specification language. We consider only specification languages, not programming languages. Categories and Subject Descriptors: D.2.1 [Software Engineering]: Requirements/Specifica- tions; D.2.4 [Software Engineering]: Software/Program Verification—formal methods; F.3.1 [Logics and Meanings of Programs]: Specifying and Verifying and Reasoning about Pro- grams—specification techniques General Terms: Verification Additional Key Words and Phrases: Set theory, specification, types Editors’ introduction. We have invited the following
    [Show full text]
  • Architecture Description Language) COMS W4115 Alan Khara Ask2206 February 11, 2014
    1 of 13 General Purpose ADL (Architecture Description Language) COMS W4115 Alan Khara Ask2206 February 11, 2014 1.0 Introduction In the design of system architecture1, a blueprint of the system typically comes second, after requirements are gathered in the process of architecture development. This is followed by design verification and, later, implementation. Initially, the domain of Architecture Description Languages (ADLs) was confined to the design phase and was highly motivated by Object Oriented paradigm [1] [2] [3]. ADLs were mainly graphical in nature, with numerous Line and Box representations that were later standardized by Object Management Group (OMG) in Unified Model Language2 (UML) [4][5]. Being quickly adopted by industry, UML was infested with ambiguous features: a given relationship between components of a system could be ambiguous and yield two different interpretations of the same drawing [2]. Research during the last decade has worked to solve this problem on two different fronts. One line of research seeks to extend UML in order to make it less ambiguous [6] [7] [8] [9]. Another kind of research is finding new ADLs (graphical and text based) that have more rigorous and well defined semantics [10] [11] [12][13]. Both of these trends are important with respect to defining the problem scope of the proposed project. Because they are mainly driven by industry, efforts to extend UML are inherently domain- specific [14]. The primary motivation behind the development of UML is to overcome ambiguity and reduced the communication gap that exists among various stakeholders. This is tackled by either introducing constraints or adding new vocabulary.
    [Show full text]
  • Comparative Studies of 10 Programming Languages Within 10 Diverse Criteria Revision 1.0
    Comparative Studies of 10 Programming Languages within 10 Diverse Criteria Revision 1.0 Rana Naim∗ Mohammad Fahim Nizam† Concordia University Montreal, Concordia University Montreal, Quebec, Canada Quebec, Canada [email protected] [email protected] Sheetal Hanamasagar‡ Jalal Noureddine§ Concordia University Montreal, Concordia University Montreal, Quebec, Canada Quebec, Canada [email protected] [email protected] Marinela Miladinova¶ Concordia University Montreal, Quebec, Canada [email protected] Abstract This is a survey on the programming languages: C++, JavaScript, AspectJ, C#, Haskell, Java, PHP, Scala, Scheme, and BPEL. Our survey work involves a comparative study of these ten programming languages with respect to the following criteria: secure programming practices, web application development, web service composition, OOP-based abstractions, reflection, aspect orientation, functional programming, declarative programming, batch scripting, and UI prototyping. We study these languages in the context of the above mentioned criteria and the level of support they provide for each one of them. Keywords: programming languages, programming paradigms, language features, language design and implementation 1 Introduction Choosing the best language that would satisfy all requirements for the given problem domain can be a difficult task. Some languages are better suited for specific applications than others. In order to select the proper one for the specific problem domain, one has to know what features it provides to support the requirements. Different languages support different paradigms, provide different abstractions, and have different levels of expressive power. Some are better suited to express algorithms and others are targeting the non-technical users. The question is then what is the best tool for a particular problem.
    [Show full text]
  • 1 an Introduction to Formal Modeling in Requirements Engineering
    University of Toronto Department of Computer Science University of Toronto Department of Computer Science Outline An Introduction to ‹ Why do we need Formal Methods in RE? you are here! Formal Modeling ‹ What do formal methods have to offer? ‹ A survey of existing techniques in Requirements Engineering ‹ Example modeling language: SCR ƒ The language ƒ Case study Prof Steve Easterbrook ƒ Advantages and disadvantages Dept of Computer Science, ‹ Example analysis technique: Model Checking University of Toronto, Canada ƒ How it works ƒ Case Study [email protected] ƒ Advantages and disadvantages http://www.cs.toronto.edu/~sme ‹ Where next? © 2001, Steve Easterbrook 1 © 2000-2002, Steve Easterbrook 2 University of Toronto Department of Computer Science University of Toronto Department of Computer Science What are Formal Methods? Example formal system: Propositional Logic ‹ First Order Propositional Logic provides: ‹ Broad View (Leveson) ƒ a set of primitives for building expressions: ƒ application of discrete mathematics to software engineering variables, numeric constants, brackets ƒ involves modeling and analysis ƒ a set of logical connectives: ƒ with an underlying mathematically-precise notation and (Ÿ), or (⁄), not (ÿ), implies (Æ), logical equality (≡) ƒ the quantifiers: ‹ Narrow View (Wing) " - “for all” $ - “there exists” ƒ Use of a formal language ƒ a set of deduction rules ÿ a set of strings over some well-defined alphabet, with rules for distinguishing which strings belong to the language ‹ ƒ Formal reasoning about formulae in the language Expressions in FOPL ÿ E.g. formal proofs: use axioms and proof rules to demonstrate that some formula ƒ expressions can be true or false is in the language (x>y Ÿ y>z) Æ x>z x+1 < x-1 x=y y=x ≡ "x ($y (y=x+z)) x,y,z ((x>y y>z)) x>z) ‹ For requirements modeling… " Ÿ Æ x>3 ⁄ x<-6 ƒ A notation is formal if: ‹ Open vs.
    [Show full text]
  • Modeling, Specification Languages, Array Programs
    Chapter 4 Modeling, Specification Languages, Array Programs This chapter presents some techniques for verifying programs with complex data structures. Typical examples of such data structures are arrays and lists. The main ingredient is to provide extensions to the language of expressions and formulas, under the form of an expressive specification language. Section 4.1 presents generalities about specification languages, while other sections present an overview of the constructs for modeling and specifying as they are available in the Why3 tool [7]. Finally, Section 4.6 is dedicated to the modeling and the proof of programs on the array data structure. 4.1 Generalities on Specification Languages There have been a lot of variants of specification languages proposed in the past. Various classes of such languages are characterized by the kind of logic that they are based on. Algebraic Specifications This class of languages is characterized by the use of multi-sorted first-order logic with equality, and usually the use of rewriting techniques [13], which permits to mix executable- style and declarative-style specifications. Famous languages and tools of this class are Larch [17], KIV [26], CASL (Common Algebraic Specification Language) [2], OBJ [16], Maude [10]. Set-theory based approaches Another class of languages is based on classical Set theory. These languages are not typed, the typing properties being instead encoded by formulas on sets. Reasoning on such languages is also typically done by rewriting techniques. A precursor of this class is the Z notation [27]. It is used in tools like VDM [18], Atelier B [1], etc. Higher-Order Logic Higher-Order Logic is characterized by the use of mathematical functions as objects of the language.
    [Show full text]
  • A Formal Methodology for Deriving Purely Functional Programs from Z Specifications Via the Intermediate Specification Language Funz
    Louisiana State University LSU Digital Commons LSU Historical Dissertations and Theses Graduate School 1995 A Formal Methodology for Deriving Purely Functional Programs From Z Specifications via the Intermediate Specification Language FunZ. Linda Bostwick Sherrell Louisiana State University and Agricultural & Mechanical College Follow this and additional works at: https://digitalcommons.lsu.edu/gradschool_disstheses Recommended Citation Sherrell, Linda Bostwick, "A Formal Methodology for Deriving Purely Functional Programs From Z Specifications via the Intermediate Specification Language FunZ." (1995). LSU Historical Dissertations and Theses. 5981. https://digitalcommons.lsu.edu/gradschool_disstheses/5981 This Dissertation is brought to you for free and open access by the Graduate School at LSU Digital Commons. It has been accepted for inclusion in LSU Historical Dissertations and Theses by an authorized administrator of LSU Digital Commons. For more information, please contact [email protected]. INFORMATION TO USERS This manuscript has been reproduced from the microfilm master. UMI films the text directly from the original or copy submitted. Thus, some thesis and dissertation copies are in typewriter face, while others may be from any type of computer printer. H ie quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleedthrough, substandardm argins, and improper alignment can adversely affect reproduction. In the unlikely, event that the author did not send UMI a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note will indicate the deletion. Oversize materials (e.g., maps, drawings, charts) are reproduced by sectioning the original, beginning at the upper left-hand comer and continuing from left to right in equal sections with small overlaps.
    [Show full text]