Differences

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

--- course_outline [2015/04/17 16:11] – jonathan
+++ course_outline [2015/06/24 17:53] (current) – jonathan
@@ Line 22: / Line 22: @@
 . **Documentation**: Develop the ability to write precise and concise software documentation that also describes the design decisions and why they were made.
+===Commentary===
+A design for a software product is the combination of its specification (to verify its safety and correctness) and a suitable architecture (for maintainability). A design that is not correct cannot be a good design. A design that does not have a suitable modular architecture is not a good design.
+===Eiffel==
+Why do we use the Eiffel method in this course? The worldview underlying the Eiffel method is to treat the whole process of software development as a continuum; unifying the concepts behind activities such as requirements, specification, design, implementation, verification, maintenance and evolution; and working to resolve the remaining differences, rather than magnifying them. Anyone who has worked in both specification and programming knows how similar the issues are. Formal specification languages look remarkably like programming languages; to be usable for significant applications they must meet the same challenges: defining a coherent type system, supporting abstraction, providing good syntax (clear to human readers and parsable by tools), specifying the semantics, offering modular structures, allowing evolution while ensuring compatibility. The same kinds of ideas, such as an object-oriented structure, help on both sides. Eiffel as a language is the notation that attempts to support this seamless, continuous process, providing tools to express both abstract specifications and detailed implementations. One of the principal arguments for this approach is that it supports change and reuse. If everything could be fixed from the start, maybe it could be acceptable to switch notations between specification and implementation. But in practice specifications change and programs change, and a seamless process relying on a single notation makes it possible to go back and forth between levels of abstraction without having to perform repeated translations between levels. [Quoted from [[https://bertrandmeyer.com/2014/12/07/lampsort|here]]]
 ==== Topics ====