Differences

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

--- eiffel:why [2020/05/06 20:45]
jonathan [Design Principles covered in the course]
+++ eiffel:why [2020/05/13 02:11] (current)
jonathan [Example of a Top Level BON Class Diagram from an SDD]
@@ Line 3: / Line 3: @@
   * Because Eiffel the language, Eiffel the method and Eiffel the tool encourage thinking above the code level at the design level.
-  * The Eiffel IDE in particular is not just a tool that is used for large scale software development (e.g. the IDE, the compiler, and the various websites themselves are all written in Eiffel), it is also a tool for **model driven engineering** with good support for seamless round trip engineering between models ("blueprints") and code. See https://ieeexplore.ieee.org/document/8501488.
+  * The Eiffel IDE in particular is not just a tool that is used for large scale software development ((e.g. the IDE, the compiler, and the various websites themselves are all written in Eiffel)), it is also a tool for **model driven engineering** with good support for seamless round trip engineering between models ("blueprints") and code. See https://ieeexplore.ieee.org/document/8501488.
 ===== The Eiffel Method & Tool (IDE) =====
@@ Line 22: / Line 22: @@
 {{:eiffel:design-principles.png?780|}}
-OO Basics is assumed. The course covers the topics in the orange box labelled "Design", interleaved with a variety of Design Patterns that illustrate those principles. Specifications are implicated in every principle in the orange "Design" box. The design principles are needed for a solid understanding of the design patterns. For example, a core information hiding idea (stressed in the course) used in many patterns is:
+OO Basics is assumed. The course covers the topics in the <html><span style="color:#FF6666;">orange</span></html> box labelled "Design", interleaved with a variety of Design Patterns that illustrate those principles. Specifications are implicated in every principle in the <html><span style="color:#FF6666;">orange</span></html> "Design" box. The design principles are needed for a solid understanding of the design patterns. For example, a core information hiding idea (stressed in the course) used in many patterns is:
-> remove the part of the software that changes and encapsulate it elsewhere so that changes to it do not overflow and pollute the part that does not change.
+> Remove the part of the software that changes and encapsulate it elsewhere so that changes to it do not overflow and pollute the part that does not change. [Now when you encapsulate a component, that component will need a good API, and a good API must be properly specified.]
 The course has weekly labs, and a project (with two phases) with an open-ended design problem. All designs must be shown to be feasible and correct via unit and acceptance testing, and students must produce software design documents ([[:eiffel:why#system_design_document_sdd|see below]]) for the project and some of the labs.
-This is <html><span style="color: red;">red</span></html> a word.
 ===== Specifications vs. Implementations =====
@@ Line 74: / Line 72: @@
 In the above example we see program text (the class MATH) that includes  **specifications** of its features and their implementations. For example, the query __sqrt__ has a precondition (**require** clause) and a postcondition (**ensure** clause). The implementation is the body of the routine between the **do** and **ensure** keywords. There is also a class **invariant** that must be preserved by all routines (queries and commands) of the class. These **contracts** impose obligations between a **client** using the class and the **supplier** of the class.
+Suppose a client module calls ''sqrt(-200.42)'', i.e. with a negative number. Then the client has violated  their obligation, and the IDE will flag this as a precondition violation. Thus every client must first demonstrate that the precondition is satisfied before calling the function. The benefit to the client is that the supplier (the designer of modulo MATH) must demonstrate the correctness of the postcondition. This is called design by contract. All modules must interact with each other in accordance with the contracts, for the design to be correct. In the **contract view** of the program text we see only the contracts not the implementations.
 {{:eiffel:contract.png?740|}}
@@ Line 106: / Line 106: @@
 The double green arrows represent client-supplier relations (associations) between classes, and the single red arrows represent inheritance.
+==== Example of a Top Level BON Class Diagram from an SDD ====
+The "capstone" of the course is a project (usually with a team of 2 students) in two phases (in the second phase, more features are added). Below is one of the BON class diagrams produced by a team (taken from their software design document). This 3rd-year course is usually the first time most students design software with many classes (typically 15-20 classes are needed for a modular design).
+{{:eiffel:why:3311-draw.io.png?740|by 3311 students Jinho Hwang and Ato Koomson, with their permission}}
+===== Specifications in industrial use =====
+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 the video below for **Specifications in Industry** at Amazon, Google and Facebook.
+<HTML>
+<iframe width="560" height="315" src="https://www.youtube.com/embed/GMQMzk3DZug" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
+</HTML>

Software Engineering Documentation

User Tools

Site Tools

Differences

Page Tools