Teaching Logic to Information Systems Students: Challenges and Opportunities
Abstract
In contrast to Computer Science, where the fundamental role of Logic is widely recognized, it plays a practically nonexistent 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.
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 indepth 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"^{1}^{1}1Below 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 MissouriSt. Louis). , the students come to see the lack of mathematical courses as a benefit, and express disappointment^{2}^{2}2Quoting 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 firstorder 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 softwarerelated 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) Firstorder 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 sideeffects; (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 industryinspired 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 firstorder 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 threeyear 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 authors^{3}^{3}3Perhaps 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 settheoretical 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 firstorder 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. Softwarerelated examples are adapted from Chapter 2 of ([3]). 
Classical Propositional and FirstOrder Logic: syntax and semantics, satisfiability and validity, Hilbertstyle 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 nonclassical logics^{4}^{4}4This part of the course is implemented by assigning each of the students a short presentation on a nonclassical 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 wellknown applications in verification, also other nonclassical logics have ISrelevant 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, manyvalued logic, fuzzy logic, nonmonotonic 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 wellstudied 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 tool^{5}^{5}5The tool is based on the opensource 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 20132014.
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 fulltime. 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 abilities^{6}^{6}6Examples: "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 practice^{7}^{7}7Examples: “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 practice^{8}^{8}8Examples: "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 softwarerelated 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 ISorientation would be a welcome addition to the large existing variety of CSoriented 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 CondoriFerná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 2glass 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 ICSE17 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(14):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/ieeecs 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 GertJan 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 37, 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 statebased formal requirements specification languages. In Proceedings of the 24th International Conference on Software engineering, pages 33–43. ACM, 2002.