User Tools
eiffel:why
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
eiffel:why [2020/05/06 20:52] 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. | * 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) ===== | ===== The Eiffel Method & Tool (IDE) ===== | ||
| Line 72: | 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. | 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|}} | {{:eiffel:contract.png?740|}} | ||
| Line 104: | Line 106: | ||
| The double green arrows represent client-supplier relations (associations) between classes, and the single red arrows represent inheritance. | 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> | ||
eiffel/why.1588798359.txt.gz · Last modified: 2020/05/06 20:52 by jonathan
Page Tools
