Teaching Logic to Information Systems Students: Challenges and Opportunities

Teaching Logic to Information Systems Students: Challenges and Opportunities

Anna Zamansky Information Systems Department, University of Haifa
Haifa, Israel
annazam@is.haifa.ac.il
Eitan Farchi IBM Research
Haifa, Israel
farchi@ibm.il
Abstract

In contrast to Computer Science, where the fundamental role of Logic is widely recognized, it plays a practically non-existent role in Information Systems curricula. In this paper we argue that instead of Logic’s exclusion from the IS curriculum, a significant adaptation of the contents, as well as teaching methodologies, is required for an alignment with the needs of IS practitioners. We present our vision for such adaptation and report on concrete steps towards its implementation in the design and teaching of a course for graduate IS students at the University of Haifa. We discuss the course plan and present some data on the students’ feedback on the course.

Information Systems, Logic, Education, Formal Methods
\Copyright

Anna Zamansky and Eitan Farchi\serieslogologo_ttl\volumeinfoM. Antonia Huertas, João Marcos, María Manzano, Sophie Pinchinat,
François Schwarzentruber54th International Conference on Tools for Teaching Logic11273\EventShortNameTTL2015

1 Introduction

The fundamental role of Logic in the Computer Science curriculum is widely recognized. The ACM CS undergraduate curriculum guidelines ([16]) explicitly state logic as a mathematical requirement which is directly relevant for the large majority of all CS undergraduates (together with elements of set theory and discrete probability). This recommendation is implemented in most of the standard CS undergraduate study programs by including in the curriculum a course in discrete structures which includes a significant amount of formal logic.

The (academic) field of Information Systems (IS) encompasses two broad areas: (i) acquisition, deployment, and management of information technology resources and services, and (ii) development and evolution of infrastructure and systems for use in organization processes. Thus, as opposed to CS, IS’s primary focus is on an organization’s mission and objectives and the application of information technology to further these goals. Yet both IS and CS require a common subset of technical knowledge, reflected also in the intersection of the respective study programs’ curricula.

Logic, however, does not appear to be in this intersection – almost none of the IS undergraduate study programs include such course in their curriculum. The ACM IS curriculum guidelines ([18]), which mention statistics and probability as required core IS topics and discrete mathematics as an optional one, but do not refer to logic as relevant: “Even though IS professionals do not need the same level of mathematical depth as many other computing professionals, there are, however, some core elements that are very important for IS professionals. To support in-depth analysis of data, IS professionals should have a strong background in statistics and probability. For those who are interested in building a strong skill set in algorithmic thinking, discrete mathematics is important."

We believe the current state of affairs is suboptimal for several reasons. First of all, all the reasons for including logic in the CS curricula still hold in the IS domain: it is widely acknowledged that studying logic directly contributes to software development skills, confirmed recently also by empirical studies ([14]). Secondly, the lack of experience with formal notation forms a major cognitive barrier to the adoption of formal methods in the industry ([21]). This is further reinforced by the fact that because many IS study programs tend to be marketed as programs "excluding the hard math"111Below are some exemplary quotes from webpages of academic institutions providing both CS and IS degrees on the comparison between the two: “As a rule, computer science requires more mathematics and analytical skill than information systems. Also, our experience has shown that it is easier to move from being a CS major to an IS major than the other way around. Therefore, if you feel reasonably comfortable with the math requirements, then you should start out as a computer science major." (Saint Michael’s College) “A major in CS will know a considerable amount of mathematics which will help in technological applications…An IS major needs to be aware of what information technology can contribute to an organization and how to bring that solution to fruition." (University of Missouri-St. Louis). , the students come to see the lack of mathematical courses as a benefit, and express disappointment222Quoting one of our graduate students who was assigned to read a research paper on formal methods: “When I see formal definitions, I just want to cry." Notably, she is one of the best students in her class. when any formal notations are integrated in the IS core courses – thus creating a vicious circle.

Although we tend to agree that a typical IS major may need a less extensive mathematical background than a CS major, we believe that rather than excluding logic from the IS curriculum, a significant adaptation of the contents that are taught to align with IS objectives. Recently more voices are calling for a reconsideration of the traditional logic curriculum and its adaptation to the needs of future pracitioners. Several proposals on what to teach and how to teach it have been made in the context of CS ([13, 17, 19]).

In this paper we address these questions in the context of the IS curriculum. We report on our experience in designing and teaching the course "Logic and Formal Specification" to graduate students at the Information Systems (IS) department at the University of Haifa, which is one of the few to include a mandatory course on logic and formal methods in its graduate study program. We discuss our view of what should be included in the “IS logic toolbox" in order for the students to be able to carry out activities for checking (by proof, analysis or testing) that a software system meets specifications and fulfills its intended purpose. These tools should at least (i) by providing background on induction and propositional and first-order logic, and (ii) by providing the ability to read, write and reason about formal specifications. We share our insights on how the above can be achieved: (i) excluding complex mathematical intricacies, and (ii) providing simple yet software-related examples. Concerning the latter, we report on an ongoing work to develop a tool for measuring “simplicity" of Z specifications. While the above insights are yet to be empirically validated, some indications of the benefits of our approach are reflected in our students’ feedback, which we briefly discuss below.

2 The IS Logic Toolbox

The main practical objective in teaching logic to IS practitioners is to give them the ability to apply formal methods in industry. Application of formal aspects is particularly important for software quality control, i.e., activities for checking (by proof, analysis or testing) that a software system meets specifications and that it fulfills its intended purpose.

Due to the density of the IS curricula, currently one cannot afford to have one course on pure formal logic and then another on formal methods (this problem is also discussed in [20] in the context of CS). Therefore, one must develop some mixture of a introductory formal logic together with introduction to formal methods relevant for the IS domain. In what follows we briefly survey previous reflections on the content of logic and formal methods courses that practitioners really need and their integration into the curricula, and propose how to adapt the proposed ideas for the context of IS.

2.1 Previous Proposals

Recently there has been an ongoing discussion on whether the traditional logic syllabus for CS is relevant for practitioners. Since our main goal in this paper is to extend and adapt this discussion to the context of IS, we start by briefly outlining some relevant proposals (mostly in the context of CS), the ideas of which are close in spirit to the vision we present below.

In his paper “From Hilbert to a Logic Toolbox" [13], J. Makowsky questions the suitability of the standard logic syllabus to the needs of CS practitioners. He states: “The current syllabus is often justified more by the traditional narrative than by the practitioner’s needs." He further notes that most classical logic textbooks follow the narrative of the rise and fall of Hilbert’s program, emphasizing the following ideas: (i) Logic is needed to resolve the paradoxes of set theory; (ii) First-order logic (FOL) is The logic due to its Completeness theorem; (iii) The main theorems of FOL are the Completeness and Compactness theorems; (iv) The tautologies of FOL are not recursive; (v) One cannot prove consistency within rich enough systems. This, according to Makowsky, is not what a CS practitioner needs: “The proof of the Completeness Theorem is a waste of time at the expense of teaching more the important skills of understanding the manipulation and meaning of formulas." What he needs is: (i) understand the meaning and implications of modeling the environment as precise mathematical objects and relations; (ii) understand and be able to distinguish intended properties of this modeling and side-effects; (iii) be able to discern different level of abstraction, and (iv) understand what it means to prove properties of modeled objects.

In her papers [20, 19], J. Wing stresses the importance of integrating formal methods into the existing CS curriculum by teaching their common conceptual elements, including state machines, invariants, abstraction, composition, induction, specification and verification. She states discrete mathematics and mathematical logic as crucial prerequisites.

The above proposals on what to teach are extremely relevant for IS practitioners. On the question of how to teach, the paper “Integrating Formal Methods into Computer Science Curricula at a University of Applied Science" ([17]) of Tavolato and Vogt offers some useful insights. It discusses teaching formal methods at universities of applied sciences, where there are usually limiting factors which are relevant to the IS context as well: (i) students have very limited theoretical background, and (ii) they are strongly focused on the direct applicability of what they are taught. In this context the authors stress the importance of making the practical applicability of the theory understandable to students, and making use of real industry-inspired examples.
In what follows, we extend and adapt the above proposals to the context of IS, and provide our vision on aligning the teaching of logic to the needs of IS practitioners.

2.2 Our Vision: Making Logic Relevant for IS

Logic is a prerequisite for understanding and successfully using formal methods, which in their turn can significantly contribute to software quality control. We agree with [20] that the main basic formal conceptual elements that the students need to be familiar with include state machines, abstraction, composition, induction, invariants, specification and verification. While the students encounter the concepts of state machines, abstraction and composition at other IS courses (such as modeling and design), aspects related to working with formal specifications are not covered elsewhere. This leads to the following practical needs of an IS practitioner: (1) read, write and understand formal specifications, (2) be able to formalize informal specifications, (3) analyze specifications and detect sources of incompleteness, inconsistency and complexity, (4) reason about specifications, and (5) check a system against a specification.

Based on the above, adapting and extending the previous proposals to the context of IS, we arrive at the following IS logic toolbox: (a) Basic principles for reasoning about sets; (b) Induction and invariants; (c) Propositional and first-order logic and their axiomatizations; (d) Formal specification and verification.

As to how to teach logic to IS students, i.e., designing concrete teaching methodologies, the following considerations need to be taken into account:

  • Examples from software domains are useful. Although it has been believed for some time that studying logic improves software development skills, this common belief has recently been empirically validated. In a three-year study in the framework of the Beseme project ([14]), empirical data on the achievements of two student populations was collected: those who studied discrete mathematics (including logic) through examples focused on reasoning about software, and those who studied the same subject illustrated with more traditional examples. An analysis of the data revealed significant differences in the programming effectiveness of these two populations in favor of the former. As pointed out by [17], software related examples are also useful for increasing the motivation of students, who can see the applications of the studied material in the domain of their interest.

  • Cognitive difficulties should not be ignored. Empirical studies show that the use of formal methods poses objective difficulties for practitioners ([5, 9]). They are also hypothesized to be a major hindering factor for the acceptance of formal methods in industry ([21]). Although the cognitive processes of students when studying logic and formal methods are not well understood, they should not be ignored ([17]). Numerous studies in the education community addressed the gap between the students’ intuition and formal thinking in mathematics (see, e.g., [7]). Implementing similar ideas in the domain of teaching logic and formal methods may help deal with these barriers.

  • Intricate complexities are not always needed. Exposing the students to full intricate complexities of mathematical logic (such as a full proof of the completeness theorem, or dealing with variables not free for substitution) has the potential to confuse novices struggling to understand new ideas. However, most of the practitioners will not encounter them in industry. This is in line the research agenda of indirect application of formal methods ([11]), calling for hiding the intricate complexities behind automatic tools with intuitive user interface. The benefits of hiding logical complexity behind the more intuitive interface of functional programming are also mentioned in [14].

In view of the above considerations, the basic principles in the design of the course described below have been (i) use mainly examples from software domains, (ii) use comprehensible examples, and (iii) introduce the logical concepts at a basic level. The issue of comprehensibility also led to our ongoing work of automatically measuring comprehensibility of Z specifications, which we briefly describe below.

3 Teaching Logic at the IS Department of the University of Haifa

In this section we demonstrate how the vision presented in Section 2.2 has been implemented in our design of the course “Logic and Formal Specification". The course has been taught at the IS department at the University of Haifa for several years by both of the authors333Perhaps it is important to mention here the authors’ relevant background. The first author is an associate professor at the Information Systems Department at the University of Haifa with active research interests in applied logic. The second author is the manager of the Software Performance and Quality research group at the IBM Haifa Research Laboratory, and a member of the IBM corporate Board of Software Quality. Both of the authors have several years of experience in teaching logic and formal methods to various audiences of students. . The course is a mandatory course for graduate students, and its length is one semester, 4 hours per week.

3.1 Course Description

Below we provide a short description of the course’s main topics, which are divided into two main parts:

Part I: Introduction to Logic

  • Informal laws of mathematical reasoning

    Our starting point is the place where the students left off in a discrete mathematics course: with basic set-theoretical concepts. However, our primary focus is not on understanding the concepts themselves, but on reasoning about them by applying informal logical laws. Accordingly, the students are asked to provide proofs of basic claims, explaining which laws were used at each stage. The presentation of the informal laws and other proof tips is adapted from [12]. The informal laws become explicit at the object level when classical propositional and first-order logic are introduced to the students (E.g., the law for proving general statements can be captured by the rule inferring from , and the law for proving conditional statements is captured by the deduction theorem.)

  • Induction: mathematical, structural and computational induction.
    Induction is in the heart of several formal concepts relevant for verification and validation of software: fixed point constructions, model checking, program analysis and many more. Therefore a special emphasis is put on the topic throughout the course, highlighting its various manifestations, e.g. proving syntactic properties of logical formulas, proving the deduction theorem, proving invariants with respect to a Z specification. Software-related examples are adapted from Chapter 2 of ([3]).

  • Classical Propositional and First-Order Logic: syntax and semantics, satisfiability and validity, Hilbert-style axiomatization, formalization of natural language sentences.
    For this part of the course we mostly adapt parts of the standard presentation of most mathematical logic textbooks. We make a special emphasis on formalization of natural language specifications and induction at the expense of omitting the proofs of the Completeness and Compactness theorems (in line with the recommendation of [13]).

  • Survey of non-classical logics444This part of the course is implemented by assigning each of the students a short presentation on a non-classical logic or its applications of his choice. While the importance of temporal logic in this context is perhaps the most obvious one due to its well-known applications in verification, also other non-classical logics have IS-relevant applications. Our goal here is to increase the awareness of the students to the immense variety of logics outside the realm of classical logics, as well as engage them more actively in the course. Several students have reported that exploring new logics on their own was the part they enjoyed the most in the course. : temporal logic, modal logic, many-valued logic, fuzzy logic, non-monotonic logic, paraconsistent logic.

Part II: Introduction to Formal Specification

This part of the course builds up on the knowledge obtained at the previous part. The final aim is for the students to be able to understand and write formal specifications using the Z notation. For this we have adapted the material from the textbook [15], covering the basic aspects of Z: types, schemas and reasoning about Z specifications. However, staying faithful to our vision oulined above, we have developed our own set of examples, which are (i) "simple" and (ii) related to software domains. In what follows we shortly discuss what we mean by "simple" and how "simplicity" can be measured.

Measuring comprehensibility of Z specifications

The notion of simplicity (item (i) above) is not well understood. Comprehensibility (or understandability) of specifications is usually thought of as the degree to which information contained in a specification is understandable to the reader, and this is a well-studied topic in software engineering (see, e.g., [6] for a survey). However, we are aware of only a few works on Z specifications ([8, 10]), all of which on the structural dimension. We believe, however, that simplicity is a key to comprehensibility of specifications, at least at the stage of learning the topic. Our attempt to quantitatively measure "simplicity has led to our ongoing project of developing automatic tools for this purpose. Our current hypothesis is that the nesting of definitions is and shortening notations by introducing additional symbols decrease the understandability of specifications. We are currently developing a tool555The tool is based on the open-source Java framework Community Z tools ([2]). for measuring "simplicity" of specifications. Using this tool, we plan to empirically check our hypothesis, as well as to consider other comprehensibility dimensions.

Students’ Acceptance

The course has only been taught in its current form for five years, so making decisive conclusions about its effectiveness is perhaps premature. However, an important dimension in evaluating such effectiveness is the students’ acceptance and reaction. To gain a better understanding of these factors, the first author has undertaken a preliminary qualitative study using a questionnaire filled by twenty three students who took the course in 2013-2014.

It should be noted that the limiting factors typical of our target audience are in many aspects similar to those described in [17]. The first is lack of mathematical background: the undergraduate IS study program at the University of Haifa does not include a course in logic, and the majority of students have only a background in discrete mathematics, where they are taught very basic concepts of set theory. The second limiting factor is their lack of motivation: the majority of the students return to graduate school several years after receiving their B.A, while working full-time. They typically expect the topics to be directly relevant to their IS practice, and usually exhibit difficulty in coping with the dense and abstract material taught in the course. In light of these factors, we were expecting some of the students to claim, basically, that the course was too hard without being helpful for their future as IS practitioners. However, only one student out of 23 felt the course was not useful for his practice. A full analysis of the data obtained from students is out of the scope of this paper. However, some aspects highlighted by the data were that (i) the majority of students felt the course has improved their analytical thinking abilities666Examples: "I don’t use logic or Z on a daily basis in my research or my work, but it improved my modelling skills", “I think it can be even more useful as an introduction to programming, because it teaches you to think systematically", "Every graduate student needs this course as a basis for study and research".; (ii) the majority of students felt the part related to formal specification is relevant for their IS practice777Examples: “I think Z language is the most useful part, because it is applied in industry", “If I encounter any other formal notation in industry, it will take me less time to get familiar with the subject".; and (iii) some students felt the course has directly improved their daily IS practice888Examples: "I started using truth tables at work to rule out impossible behaviors", "I was surprised to find out how helpful the tools we obtained are in my daily work"..

4 Summary and Future Research

There has recently been a discourse on the relevance of traditional logic courses to future computer science practitioners. Jeannette Wing writes in [19]: “…we still face the educational challenge of teaching mathematical foundations like logic and discrete mathematics to practicing or aspiring software engineers. We need to go beyond giving the traditional courses and think about who the target students are." This paper discusses these issues for the target population of IS students, for whom the lack of direct relevance of the traditional logic courses seems to have led to their exclusion from the curriculum. We believe logic is central to IS objectives, as it is the key to applying formal methods in specification, verification and validation of information systems. Ideally, we need more empirical evidence in the spirit of the Beseme project ([1]) that such courses are useful for IS practitioners. In addidion, there is a need for a wider discussion on what logical background is needed for Information Systems practitioners and how it should be taught. In a contribution to such discussion, we have reported on our insights from teaching the “Logic and Formal Specification" course to graduate IS students. Like previous authors report in the context of CS, we have seen that using software-related and comprehensible examples, as well as simplification of logical intricacies contributes to achieving the courses’ objectives. From a more practical perspective, a future direction is an empirical investigation of how to make formal specification more understandable for students. This question is particularly interesting due to its direct relation to the more general topic of comprehensibility of specifications. In this context we plan to extend and refine our tool for automatic analysis of Z specifications and carry out an empirical evaluation. From the angle of education, strategies for an efficient integration of logic and formal methods into the IS curricula are required (along the lines of [4, 20]), as well as an investigation of the ways to bridge intuitive and analytical thinking processes in logic and formal methods (along the lines of [7]). In this context we would also like to point out that a textbook with an IS-orientation would be a welcome addition to the large existing variety of CS-oriented books.

References

  • [1] Beseme website, http://www.cs.ou.edu/ beseme/.
  • [2] CZT website, http://czt.sourceforge.net/manual.html.
  • [3] Alfred V Aho and Jeffrey D Ullman. Foundations of computer science, volume 2. Computer Science Press New York, 1992.
  • [4] Ian Barland, Matthias Felleisen, Kathi Fisler, Phokion Kolaitis, and Moshe Y Vardi. Integrating logic into the computer science curriculum. Innovation and Technology in Computer Science Education, 2000.
  • [5] Deirdre Carew, Chris Exton, and Jim Buckley. An empirical investigation of the comprehensibility of requirements specifications. In Empirical Software Engineering, 2005. 2005 International Symposium on, pages 10–pp. IEEE, 2005.
  • [6] Nelly Condori-Fernández, Maya Daneva, Klaas Sikkel, and Andrea Herrmann. Practical relevance of experiments in comprehensibility of requirements specifications. In Empirical Requirements Engineering (EmpiRE), 2011 First International Workshop on, pages 21–28. IEEE, 2011.
  • [7] Lisser Rye Ejersbo, Uri Leron, and Abraham Arcavi. Bridging intuitive and analytical thinking: Four looks at the 2-glass puzzle. For the Learning of Mathematics, 2014.
  • [8] K Finney, N Fenton, and A Fedorec. Effects of structure on the comprehensibility of formal specifications. In Software, IEE Proceedings-, volume 146, pages 193–202. IET, 1999.
  • [9] Kate Finney. Mathematical notation in formal specification: Too difficult for the masses? Software Engineering, IEEE Transactions on, 22(2):158–159, 1996.
  • [10] Kate Finney, Keith Rennolls, and Alex Fedorec. Measuring the comprehensibility of Z specifications. Journal of Systems and Software, 42(1):3–15, 1998.
  • [11] Heinrich Hussmann. Indirect use of formal methods in software engineering. In ICSE-17 Workshop on Formal Methods Application in Software Engineering Practice, Seattle (WA), USA. Proceedings, pages 126–133. Citeseer, 1995.
  • [12] David Makinson. Sets, logic and maths for computing. Springer, 2012.
  • [13] Johann A Makowsky. From Hilbert’s program to a logic tool box. Annals of Mathematics and Artificial Intelligence, 53(1-4):225–250, 2008.
  • [14] Rex L Page. Software is discrete mathematics. In ACM SIGPLAN Notices, volume 38, pages 79–86. ACM, 2003.
  • [15] Ben Potter, David Till, and Jane Sinclair. An introduction to formal specification and Z. Prentice Hall PTR, 1996.
  • [16] Mehran Sahami, Mark Guzdial, Andrew McGettrick, and Steve Roach. Setting the stage for computing curricula 2013: computer science–report from the acm/ieee-cs joint task force. In Proceedings of the 42nd ACM technical symposium on Computer science education, pages 161–162. ACM, 2011.
  • [17] Paul Tavolato and Friedrich Vogt. Integrating formal methods into computer science curricula at a university of applied sciences. In TLA+ Workshop at the 18th International Symposium on Formal Methods, Paris, Frankreich., 2012.
  • [18] Heikki Topi, Joseph S Valacich, Ryan T Wright, Kate Kaiser, Jay F Nunamaker Jr, Janice C Sipior, and Gert-Jan de Vreede. Is 2010: Curriculum guidelines for undergraduate degree programs in information systems. Communications of the Association for Information Systems, 26(1):18, 2010.
  • [19] Jeannette M. Wing. Teaching mathematics to software engineers. In Algebraic Methodology and Software Technology, 4th International Conference, AMAST ’95, Montreal, Canada, July 3-7, 1995, Proceedings, pages 18–40, 1995.
  • [20] Jeannette M Wing. Weaving formal methods into the undergraduate computer science curriculum. In Algebraic Methodology and Software Technology, pages 2–7. Springer, 2000.
  • [21] Marc K Zimmerman, Kristina Lundqvist, and Nancy Leveson. Investigating the readability of state-based formal requirements specification languages. In Proceedings of the 24th International Conference on Software engineering, pages 33–43. ACM, 2002.
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
""
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
   
Add comment
Cancel
Loading ...
192845
This is a comment super asjknd jkasnjk adsnkj
Upvote
Downvote
""
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters
Submit
Cancel

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test
Test description