mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-07 15:22:31 +01:00
Code Issues Packages Projects Releases Wiki Activity

Initiative to replace "Eiffel language" and similar with "Eiffel programming language"

Browse Source 
Author:halw
Date:2012-08-20T14:24:39.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1149 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2012-08-20 14:24:39 +00:00
parent aecfc0a811
commit 026b3521a4
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/index.wiki
View File

@@ -24,7 +24,7 @@ Examples of incoming mechanisms include:
EIS plays an important role in the Eiffel software development method. Eiffel's focus is software quality. One aspect of the Eiffel method that contributes to software quality is the '''Single Product Principle''' as described in the [[ET: The Software Process in Eiffel#The Single Product Principle|Eiffel Tutorial]]: viewing the software as a single product which is expected to be repeatedly refined, extended, and improved. EIS plays an important role in the Eiffel software development method. Eiffel's focus is software quality. One aspect of the Eiffel method that contributes to software quality is the '''Single Product Principle''' as described in the [[ET: The Software Process in Eiffel#The Single Product Principle|Eiffel Tutorial]]: viewing the software as a single product which is expected to be repeatedly refined, extended, and improved.
The bulk of the Single Product Principle is made possible by the seamless nature of the Eiffel method and the elegant design of the Eiffel language. Eiffel allows multiple views of the single software product that are appropriate to certain phases of development and readable by those fulfilling certain development roles. For example, potential reuse consumers use the '''contract''' views to explore class specifications. Also in support of seamlessness and the single product is a single integrated set of tools, the EiffelStudio IDE, working across the entire lifecycle, providing, for example, automatic extraction of the contract views just mentioned. The EiffelStudio graphical views of software (BON and UML, as produced by the Diagram Tool) directly support these ideas through their "roundtrip style". That is, changes to the diagram immediately generate code and changes to the code are reflected in the diagram. Of course documents in other formalisms, for example software requirements specifications (SRS), remain necessary for human consumption; but they should be closely linked to the core project asset, the Eiffel code. The bulk of the Single Product Principle is made possible by the seamless nature of the Eiffel method and the elegant design of the Eiffel programming language. Eiffel allows multiple views of the single software product that are appropriate to certain phases of development and readable by those fulfilling certain development roles. For example, potential reuse consumers use the '''contract''' views to explore class specifications. Also in support of seamlessness and the single product is a single integrated set of tools, the EiffelStudio IDE, working across the entire lifecycle, providing, for example, automatic extraction of the contract views just mentioned. The EiffelStudio graphical views of software (BON and UML, as produced by the Diagram Tool) directly support these ideas through their "roundtrip style". That is, changes to the diagram immediately generate code and changes to the code are reflected in the diagram. Of course documents in other formalisms, for example software requirements specifications (SRS), remain necessary for human consumption; but they should be closely linked to the core project asset, the Eiffel code.
Within EiffelStudio, EIS effects this by ensuring that any documents existing outside the software itself can be linked to the software text and vice versa. For example, if an external software requirements document exists, say in PDF format, it is essential to record precisely the associations between elements in the requirements document and the portion of the software text in which those elements are realized. Perhaps the requirements document contains a statement: "Whenever the tank temperature reaches 50 degrees, the valve shall be closed". In the software text, there will be some feature, for example, <code>monitor_temperature</code> in the class <code>TANK</code>, reflecting this requirement. The requirements statement and the software feature should be linked to one another. This is to ensure that dependencies appear clearly, and that any change in either the requirements or the code triggers the corresponding update to the other side. This is what EIS provides. Within EiffelStudio, EIS effects this by ensuring that any documents existing outside the software itself can be linked to the software text and vice versa. For example, if an external software requirements document exists, say in PDF format, it is essential to record precisely the associations between elements in the requirements document and the portion of the software text in which those elements are realized. Perhaps the requirements document contains a statement: "Whenever the tank temperature reaches 50 degrees, the valve shall be closed". In the software text, there will be some feature, for example, <code>monitor_temperature</code> in the class <code>TANK</code>, reflecting this requirement. The requirements statement and the software feature should be linked to one another. This is to ensure that dependencies appear clearly, and that any change in either the requirements or the code triggers the corresponding update to the other side. This is what EIS provides.