From 10f23ac294c681c7fbbc3b919143773e765db8e3 Mon Sep 17 00:00:00 2001 From: halw Date: Mon, 20 Aug 2012 13:15:19 +0000 Subject: [PATCH] Initiative to replace "Eiffel language" and similar with "Eiffel programming language" Author:halw Date:2012-08-20T13:15:19.000000Z git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1130 abb3cda0-5349-4a8f-a601-0c33ac3a8c38 --- .../method/eiffel-tutorial-et/et-software-process-eiffel.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki b/documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki index 257ee309..3beba97e 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki @@ -23,7 +23,7 @@ Each of the individual cluster life cycles is based on a continuous progression [[Image:tutorial-3]] -You may view this picture as describing a process of accretion (as with a stalactite), where each steps enriches the results of the previous one. Unlike traditional views, which emphasize the multiplicity of software products -- analysis document, global and detailed design documents, program, maintenance reports... --, the principle is here to treat the software as a '''single product''' which will be repeatedly refined, extended and improved. The Eiffel language supports this view by providing high-level notations that can be used throughout the lifecycle, from the most general and software-independent activities of system modeling to the most exacting details of implementation tuned for optimal run-time performance. +You may view this picture as describing a process of accretion (as with a stalactite), where each steps enriches the results of the previous one. Unlike traditional views, which emphasize the multiplicity of software products -- analysis document, global and detailed design documents, program, maintenance reports... --, the principle is here to treat the software as a '''single product''' which will be repeatedly refined, extended and improved. The Eiffel programming language supports this view by providing high-level notations that can be used throughout the lifecycle, from the most general and software-independent activities of system modeling to the most exacting details of implementation tuned for optimal run-time performance. 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).