Differences

This shows you the differences between two versions of the page.

--- eiffel:why:petition:start [2020/05/11 19:03]
jonathan [Grading Criteria]
+++ eiffel:why:petition:start [2020/05/12 17:16] (current)
jonathan [Learning Design by Contract in Eiffel]
@@ Line 118: / Line 118: @@
     * Evaluation:
       * Acceptance tests for design feasibility  and correctness
       * complete software design document (see [[:eiffel:why#system_design_document_sdd|SDD]]).
+      * A software engineering student who completed the course wrote as follows: "//the Project is one of the most important parts of the entire SE curriculum, since it is the only major programming project in 3rd year, similar to the 2311 one, and I would say I took more out of that assignment than any other project I’ve worked on (aside from capstone). It is difficult to create such a complete software design & development scenario, and efforts to shrink the workload through the inclusion of ETF definitely help try to make the process as ’small’ as it could be//".
+      * The workload is very high by comparison with other 3 credit courses in large part due to the project, but removing the project would also remove this learning outcome.
   * Labtest2
     * Evaluation of an unbounded undo/redo design pattern
@@ Line 160: / Line 162: @@
 > 5. EECS3311 places a heavy focus on design by contract. Apart from brief mentions, Test-Driven design or any other type of software design is not explored in depth. This heavy focus on design-by-contract is used as a justification for using the Eiffel language. However, we believe that students should also be able to learn to implement design by contract without explicit contracts - doing so should give students the ability to take away from the design by contract ideology and implement it in the real world with industry-standard programming languages.
+By the phrase "Test-Driven __design__", the students probably mean TDD ([[https://en.wikipedia.org/wiki/Test-driven_development#xUnit_frameworks|Test Driven Development]]), which relies on [[https://en.wikipedia.org/wiki/Test-driven_development#xUnit_frameworks|unit testing frameworks]]. Now unit testing is introduced right at the beginning in Lab0 and used throughout the course; in fact some combination unit testing, specification testing in design, or acceptance testing is used in every lab and the project. TDD is described early on and used repeatedly with the stress on regression testing of design feasibility and correctness as new features are introduced in the design.
-As explained above, the syntax in other language alternatives is not expressive enough to construct the specification beyond simple examples (e.g., ones which require quantifications or neste quantifications). Also, mixing "implicit" contracts (using programming exceptions) and implementations makes breaks the proper distinction between the two levels of abstraction.
+What is also perplexing is that in #4 of the petition, the complaint is that students have not studied testing, and "students may get a failing grade while passing all test cases if they do not pass the instructors' 'hidden' test cases, which can cause many issues with grading." The hidden tests are precisely there to ensure that students apply the regression testing aspect of TDD.
-We always start the course by explaining how design is different from implementation (what students focus on in first year and EECS2030 and EECS2011), and then justify why Eiffel is more suitable for learning about design (checking implementation w.r.t. contracts) than Java (which is arguably a suitable language for implementation but not
+The petition also claims that "other types of software design is not explored in depth", but this is not so as mentioned earlier and described in Design Principles mentioned in [[http://seldoc.eecs.yorku.ca/doku.php/eiffel/why#design_principles_covered_in_the_course|why eiffel: Fig 1]]. Many other design principles are covered in depth and applied in many design patterns (covered throughout the course in depth).
-design, due to the scaffolding you need to build for exception handling, which adds unnecessary coding burden to both caller/client and callee/supplier).
+Ada and Eiffel provide native language support for Design by Contract, but the principle that **specifications** are integral to design carries over to designing in any language. The Unified Modeling Language (UML) is the //de facto// modelling language in software engineering thus supports Design by Contract in the form  of OCL (Object Constraint Language). For other methods of specification, see [[https://youtu.be/-4Yp3j_jk8Q|Video: Thinking Above the Code]] and [[https://youtu.be/GMQMzk3DZug|Specifications in Industry]] at Amazon, Google and Facebook.
 ==== Learning Software Design in Eiffel ====
@@ Line 170: / Line 174: @@
 > 6. In summary, the course does not focus on Software Design, in contradiction with its name. Instead, it focuses on gaining knowledge of the semantics of proprietary, obsolete tools and heavy software testing (again - with students that do not know proper test plans and testing patterns).
-What we describe above justifies that the use of the Eiffel language, method and tool which allows us to have a clear distinction between implementation and specification, and we are thus able to focus on design. The fact that a new language is used should not be a concern, given the amount of resource, as well as scheduled lab hours and TA/instrutor office hours.
-As mentioned above, student evaluation in the past have been quite positive.
+In summary, the course focuses on many foundational aspects of design, and a sequence of labs and a significant project allow students to exercise these various design principles. As mentioned above, student evaluation in the past have been relatively positive.

Software Engineering Documentation

User Tools

Site Tools

Differences

Page Tools