Use case is a description of the system behavior and its interaction with the external world. There were many arguments concerning the usability of this approach. Last decade radically changed the approach to the use case in the software design.

There is one very attractive idea concerning the use cases that appeared between 1992 and 1997. To describe this approach we have to answer the following questions.

-What is the use case - a strict exposition of the system requirement or a simple script?

-Is the script one more name for the use case?

-What is the level of formality or informality for the use case?

-Do the use cases present some interrelated structure of data?

For some people the use case was simply a definition for the term script (short description of the user's interaction with the system). The followers of this software design school think that the use case does not have any internal structure. If their quantity becomes too big, they are snapped to the heap. Nowadays, those who write the use cases in this way are satisfied with the results. However, the developers and explorers of the CASE tools (Computer Aided Software Engineering) thought that the informal artifacts would be incomplete, and they required a mathematical base and support by the CASE tools. They developed special programming tools, notations and programs, which helped to transform the use cases to the strict descriptions. Nevertheless, this approach achieved less quantity of followers. People needed a simple way to express their thoughts concerning the future system. They did not like to use the formal software tools, and, at the same time, they thought that additional work for the formalization of the use cases did not provide the desired results. To prevent these problems, one should perform two things:

-Proclaim that the use cases are requirements with some basic structures.

-Let people write whatever they need.

At first sight, these purposes seem to be in conflict; however, there is a way to create the structure meeting both conditions. There is no single template for the use cases. Some developers will describe everything shortly and informally. Therefore, the main script will take no more than one paragraph of the text. Other programmers will describe everything according to strict rules and forms. There are three levels of clarification for the use cases' description. The short description contains two- four sentences, which can be placed easily to an electronic table cell. The standard description contains all information described above. The full description combines the template which contains fields for the description of interested sides, minimal guarantees, post conditions, rules, performance limitations, etc. Most likely, those three formats will be never combined to a common entity. Projects and its developers are so different that it is hard to establish a similar approach for them. Some ambitious people may desire to perform their own input to the development of these technologies, thus, they will develop some methodologies of their own. The architecture of the Windows applications requires an efficient usage of the use cases for the successful solving of complicated tasks.