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

Author:halw

Browse Source 
Date:2012-07-14T12:44:44.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1124 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2012-07-14 15:50:27 +00:00
parent e2e3f1dad6
commit dd7c292889
2 changed files with 7 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -20,12 +20,13 @@ Examples of outgoing mechanisms include:
Examples of incoming mechanisms include:
* For supported tools, selecting external information linked to an Eiffel developer object and having EiffelStudio open automatically and targeted to that object.
==Why use EIS==
==EIS and the Eiffel method==
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|Eiffel Tutorial]]: viewing the software as a single product which is expected to be refined, extended, and improved repeatedly.
The greatest part 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 specification.
EIS augments this process by ensuring that any documents existing outside the software itself are closely linked to the software and vice versa. For example, if a an external software requirements document exists, say in PDF format, it is essential to record precisely 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 two elements should be linked, in particular 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.
EIS complements this process by ensuring that any documents existing outside the software itself are closely linked to the software and vice versa. For example, if a an external software requirements document exists, say in PDF format, it is essential to record precisely 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.