Author:halw

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


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1124 abb3cda0-5349-4a8f-a601-0c33ac3a8c38

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

@@ -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.
+
 
 

documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki

@@ -15,6 +15,8 @@ Unlike earlier approaches, the Eiffel model assumes that the system is divided i
 
 The Eiffel techniques developed below, in particular information hiding and Design by Contract, make the concurrent engineering process possible by letting the clusters rely on each other through clearly defined interfaces, strictly limiting the amount of knowledge that one must acquire to use the cluster, and permitting separate testing. When the inevitable surprises of a project happen, the project leader can take advantage of the model's flexibility, advancing or delaying various clusters and steps through dynamic reallocation of resources. 
 
+==The Single Product Principle==
+
 Each of the individual cluster life cycles is based on a continuous progression of activities, from the more abstract to the more implementation-oriented:
 
 
@@ -25,6 +27,8 @@ You may view this picture as describing a process of accretion (as with a stalac
 
 These properties make Eiffel span the scope of both "object-oriented methods", with their associated notations such as UML and supporting CASE tools (whereas most such solutions do not yield an executable result), and "programming languages" (whereas most such languages are not suitable for design and analysis). 
 
+Additionally, within the EiffelStudio development environment, the concept of '''single product''' is extended to documents external to the software itself, by the [[Eiffel Information System|Eiffel Information System (EIS)]] which allows the linking elements of the software text to portions of external documents and vice versa.
+
 ==Seamlessness and reversibility==
 
 The preceding ideas define the '''seamless approach''' embodied by Eiffel. With seamlessness goes '''reversibility''': the ability to go back, even late in the process, to earlier stages. Because the developers work on a single product, they can take advantages of bouts of late wisdom -- such as a great idea for adding a new function, discovered only at implementation time -- and integrate them in the product. Traditional approaches tend to discourage reversibility because it is difficult to guarantee that the analysis and design will be updated with the late changes. With the single-product principle, this is much easier to achieve.