Differences

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

--- course_outline [2015/04/17 16:10] – jonathan
+++ course_outline [2015/06/24 17:53] (current) – jonathan
@@ Line 15: / Line 15: @@
 . **Testing**: Develop systematic approaches to organizing, writing, testing and debugging software.
-. **Analysis**: Develop insight into the process of moving from an ambiguous problem statement to a well-designed solution (analysis).
+. **Analysis**: Develop insight into the process of moving from an ambiguous problem statement to a well-designed solution.
-. **Architecture**: Design software using appropriate abstractions, modularity, information hiding, and design patterns (design).
+. **Architecture**: Design software using appropriate abstractions, modularity, information hiding, and design patterns.
 . **Tools**: Develop facility in the use of an IDE for editing, organizing, writing, debugging, testing and documenting code including the use of BON/UML diagrams for documenting designs. Also the ability to deploy the software in an executable form.
 . **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 ====