Анализ вариантов использования: основа разработки программного обеспечения.
Use-case analysis
Анализ вариантов использования: определение требований к ПО с точки зрения пользователя. Разработка, проектирование, сбор требований, ценность для клиента.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Анализ вариантов использования — это методика, применяемая для выявления требований к системе (как правило, в контексте разработки программного обеспечения или бизнес-процессов) и информации, необходимой для определения используемых процессов и классов (представляющих собой совокупность действующих лиц и процессов). Эти варианты использования применяются как при создании диаграммы вариантов использования, так и при общем анализе в процессе разработки или переработки программной системы или программы. Анализ вариантов использования служит фундаментом для построения системы.
Use case analysis is a technique used to identify the requirements of a system (normally associated with software/process design) and the information used to both define processes used and classes (which are a collection of actors and processes) which will be used both in the use case diagram and the overall use case in the development or redesign of a software system or program. The use case analysis is the foundation upon which the system will be built.
Предыстория
Анализ вариантов использования — основной метод сбора требований к использованию для новой программы или задачи. Основные цели анализа вариантов использования: проектирование системы с точки зрения пользователя, описание поведения системы на языке пользователя и определение всех внешне наблюдаемых функций. Другая задача анализа вариантов использования — чёткое определение: системных требований, способов использования системы, ролей пользователей в системе, действий системы в ответ на действия пользователя, результатов, получаемых пользователем, и ценности, которую клиент или пользователь получит от системы.
A use case analysis is the primary form for gathering usage requirements for a new software program or task to be completed. The primary goals of a use case analysis are: designing a system from the user's perspective, communicating system behavior in the user's terms, and specifying all externally visible behaviors. Another set of goals for a use case analysis is to clearly communicate: system requirements, how the system is to be used, the roles the user plays in the system, what the system does in response to the user stimulus, what the user receives from the system, and what value the customer or user will receive from the system.
Процесс
Анализ вариантов использования состоит из нескольких шагов.
There are several steps involved in a use case analysis.
Реализация
Реализация варианта использования описывает, как конкретный вариант использования был реализован в модели проектирования, с точки зрения взаимодействующих объектов. Этап реализации задает основу для анализа разрабатываемой системы. На этом этапе документируется первый, наиболее общий, набросок требований к системе, включающий в себя предварительное определение процессов, действующих лиц и данных, необходимых для системы. Именно эти элементы формируют классы анализа.
A Use case realization describes how a particular use case was realized within the design model, in terms of collaborating objects. The Realization step sets up the framework within which an emerging system is analysis. This is where the first, most general, outline of what is required by the system is documented. This entails rough breakdown of the processes, actors, and data required for the system. These are what comprise the classes of the analysis.
Описание
После того, как общий план будет завершен, следующим шагом является описание поведения системы, видимого потенциальному пользователю. Хотя внутреннее поведение также можно описать, это больше относится к проектированию системы, чем к сбору требований к ней. Краткое описание внутреннего поведения может быть полезно для того, чтобы убедиться с потенциальными пользователями, что системе не не хватает важного внешнего компонента из-за того, что он реализован внутри системы. Основная цель этого шага – предоставить достаточно информации для понимания того, какие классы необходимы для системы. Излишняя детализация может затруднить последующие изменения системы.
Once the general outline is completed, the next step is to describe the behavior of the system visible to the potential user of the system. While internal behaviors can be described as well, this is more related to designing a system rather than gathering requirements for it. The benefit of briefly describing internal behaviors would be to clarify with potential users that the system is not missing a vital component externally due to it being completed internally. The overall goal of this step is to provide just enough detail to understand what classes are required for the system. Too much detail can make it difficult to change the system later on.
Классы анализа
Этот шаг отбирает из списка классов только те, которые способны выполнять действия, необходимые для успешной работы системы. Если для системы классы еще не созданы, их необходимо создать перед выполнением этого шага. Классы можно создавать различными способами и из разных источников, например, на основе предыдущих, но схожих систем, корпоративных моделей или с помощью анализа данных. После создания и отбора классов необходимо установить связи между ними – теперь они называются классами анализа – которые моделируют задачи, решаемые системой.
This step narrows down the class list into those classes that are capable of performing the behavior needed to make the system function successfully. If no classes yet exist for a system, they must be created before this step can be completed. Classes can be created in many ways from many sources. A few examples are: previous—but similar—systems, enterprise models, and data mining. Once classes are created and narrowed down, relationships must be developed between classes, now called analysis classes, which model the task of the system.
Ответственность
Для каждого класса анализа, выявленного на предыдущем этапе, необходимо чётко детализировать его обязанности. Это обеспечит выполнение каждым классом конкретной задачи, которую не будет выполнять ни один другой класс в системе. Обязанности различных классов не должны пересекаться.
For each analysis class identified in the previous step, the responsibilities of the class must be detailed clearly. This will ensure that an individual class has a task to complete for which no other class in the system will also perform. The responsibilities of the different classes should not overlap.
Поведение
После того, как взаимосвязи между классами будут поняты, следующим шагом является детализация поведения, которое будут демонстрировать классы, и способов их взаимодействия для выполнения задач системы. Это включает в себя определение того, как классы взаимодействуют и обмениваются сообщениями на протяжении всего процесса разработки системы. Это определяется исходя из ранее установленных обязанностей классов. Определение того, какому классу направлено сообщение, основывается на ассоциациях, определенных на предыдущем этапе.
Once the relationships between classes are understood, the next process is to detail the behavior the classes will exhibit and how they will interact in order to complete the system. This entails determining how the classes communicate and send messages along the timeline of the system process being developed. This is derived from the responsibilities of the classes previously identified. Determining what class the message goes to follows the associations set up in the previous step.
Механизмы
Последний шаг — определить компоненты, которые предоставляют решение для проблемной области. Это включает в себя базы данных для хранения данных, обеспечение безопасности, обработку исключений и взаимодействие между процессами или программами.
The final step is to identify components that provide a solution to the problem domain. This would include databases to hold the data, security, exception handling, and communication between processes or programs.