Use Cases are typically related to 'actors', which are human or machine entities that use or interact with the system to perform a piece of meaningful work that helps them to achieve a goal. The set of Use Cases an actor has access to defines their overall role in the system and the scope of their action.
С первым предложением всё понятно. В ступор вгоняет второе, получается что-то не совсем складное Перевёл вот так:
Варианты использования, как правило, связаны с ‘актёрами’, являющиеся человеком или машиной, которые используют или взаимодействуют с системой для выполнения части значимой работы, которая помогает им добиваться цели. Набор вариантов использования актёра имеет доступ к определённым ролям в системе и границам их действий.
:)
Re: Подскажите как правильно перевести следующий абзац ?
C>Use Cases are typically related to 'actors', which are human or machine entities that use or interact with the system to perform a piece of meaningful work that helps them to achieve a goal. The set of Use Cases an actor has access to defines their overall role in the system and the scope of their action.
C>С первым предложением всё понятно. В ступор вгоняет второе, получается что-то не совсем складное Перевёл вот так: C>
C>Варианты использования, как правило, связаны с ‘актёрами’, являющиеся человеком или машиной, которые используют или взаимодействуют с системой для выполнения части значимой работы, которая помогает им добиваться цели. Набор вариантов использования актёра имеет доступ к определённым ролям в системе и границам их действий.
Термины Use Case и Actor лучше не переводить вообще. Только надо к нормальному русскому языку привести, оборотов поменьше. Основные ошибки:
"являющиеся" (несогласновано), должно быть "являющимися"
Не "добиваться" цели, а "достигать"
Не "границы" действия, а "область"
Последнее предложение абсолютно не верно. Должно быть что-то типа:
"Набор Use Case, к которым актёр имеет доступ, определяет общую роль и область действия этих Use Case в системе.
Re[2]: Подскажите как правильно перевести следующий абзац ?
Здравствуйте, Blazkowicz, Вы писали:
B>Термины Use Case и Actor лучше не переводить вообще.
Хотя, нет. Лучше переводить, но в скобках указывать англоязычный термин. Вместо перевода "актёр", лучше использовать "действующее лицо".
The following example of a sequence diagram shows the user or actor on the left initiating a flow of events and messages that correspond to the Use Case scenario. The messages that pass between objects become class operations in the final model.
Следующий пример диаграммы последовательностей показывает пользователя или актера, слева инициирующего поток событий и сообщения соответствующие сценарию варианта использования. Сообщения, которые проходят между объектами, станут классами операций в окончательной модели.
:)
Re[3]: Подскажите как правильно перевести следующий абзац ?
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Blazkowicz, Вы писали:
B>>Термины Use Case и Actor лучше не переводить вообще. B>Хотя, нет. Лучше переводить, но в скобках указывать англоязычный термин. Вместо перевода "актёр", лучше использовать "действующее лицо".
Да это по смыслу одно и то-же. Актёр, это пользователь или другая система взаимодействующая с проектируемой системой при её функционировании.
:)
Re[4]: Подскажите как правильно перевести следующий абзац ?
Здравствуйте, Cynic, Вы писали:
C>Да это по смыслу одно и то-же. Актёр, это пользователь или другая система взаимодействующая с проектируемой системой при её функционировании.
Нужно выбрать несколько наиболее значимых переводов книг и статей по UML и посмотреть как переведено там.
Следующий пример диаграммы последовательностей показывает пользователя или актера ([/b]слева,) инициирующего поток событий и сообщени[b]й, которые соответствуют сценарию варианта использования. Сообщения, которые передаются между объектами, становятся классом операций в окончательной модели.
на счет "класса операций" я не уверен, так как не понимаю что именно под этим подразумевается. И "окончательная модель" тоже не совсем то что имеется ввиду. Это либо окончательный вариант модели. Либо ещё что-то.
Re[4]: Подскажите как правильно перевести следующий абзац ?
Здравствуйте, Cynic, Вы писали:
C>Да это по смыслу одно и то-же. Актёр, это пользователь или другая система взаимодействующая с проектируемой системой при её функционировании.
Идея вообще какая. В обиходе никто терминами "Вариант использования" и "действующее лицо" не пользуется. Говорят обычно "юзкейс", "актёр". Поэтому я бы их не переводил вообще. Перевод, в данном случае, пониманию не способствует вообще.
Здравствуйте, Blazkowicz, Вы писали:
B>на счет "класса операций" я не уверен, так как не понимаю что именно под этим подразумевается. И "окончательная модель" тоже не совсем то что имеется ввиду. Это либо окончательный вариант модели. Либо ещё что-то.
Я так предполагаю что под классом операций имеется ввиду класс реализующий методы которые эти операции выполняют. Типа Login, ValidateUser и т.п.
"окончательная модель" нормально, соответствует контексту
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Blazkowicz, Вы писали:
B>>Сообщения, которые передаются между объектами, становятся классом операций в окончательной модели.
L>А не "операциями класса"?
A Use Case is a formal description of functionality that the system will have when constructed. An implementation diagram is typically associated with a Use Case to document which design elements (for example, components and classes) implement the Use Case functionality in the new system. This provides a high level of traceability for the system designer, the customer and the team that will actually build the system. The list of Use Cases that a component or class is linked to documents the minimum functionality that must be implemented by the component.
Перевёл так:
Вариант использования формальное описание функциональности, которую будет иметь созданная система. Диаграмма реализации обычно ассоциируется с вариантом использования в документе, в котором элементы дизайна (например, компоненты и классы) реализуют функциональность варианта использования в новой системе. Это обеспечивает высокий уровень прослеживаемости для системного архитектора, заказчика и команды, которая будет создавать систему. Список вариантов использования, являющийся компонентом или классом, связан с документами минимальной функциональностью, которая должна быть реализована этим компонентом.
Здравствуйте, Cynic, Вы писали:
C>Вот ещё мутный абзац: C>
C>A Use Case is a formal description of functionality that the system will have when constructed. An implementation diagram is typically associated with a Use Case to document which design elements (for example, components and classes) implement the Use Case functionality in the new system. This provides a high level of traceability for the system designer, the customer and the team that will actually build the system. The list of Use Cases that a component or class is linked to documents the minimum functionality that must be implemented by the component.
C>Перевёл так: C>
C>Вариант использования формальное описание функциональности, которую будет иметь созданная система. Диаграмма реализации обычно ассоциируется с вариантом использования в документе, в котором элементы дизайна (например, компоненты и классы) реализуют функциональность варианта использования в новой системе. Это обеспечивает высокий уровень прослеживаемости для системного архитектора, заказчика и команды, которая будет создавать систему. Список вариантов использования, являющийся компонентом или классом, связан с документами минимальной функциональностью, которая должна быть реализована этим компонентом.
to document — для того чтобы задокументировать
The list of Use Cases that a component or class is linked to — список юзкейсов к которому привязана компанента или класс. Правда, я не до конца уверен кто к кому тут привязан.
Этот список документирует минимальную функциональность. У вас явная проблема с идентификацией частей предложения, когда предлог выносится в конец.
Здравствуйте, Blazkowicz, Вы писали:
B>У вас явная проблема с идентификацией частей предложения, когда предлог выносится в конец.
Это потому, что я английский ни когда в жизни не учил, а переводить нужно
В общем я не понял так правильно:
An implementation diagram is typically associated with a Use Case to document which design elements (for example, components and classes) implement the Use Case functionality in the new system.
Диаграмма реализации обычно ассоциируется с вариантом использования для того чтобы задокументировать, какие элементы дизайна (например, компоненты и классы) реализуют функциональность варианта использования в новой системе.
и
The list of Use Cases that a component or class is linked to documents the minimum functionality that must be implemented by the component.
Список вариантов использования с которым связан компонент или класс документирует минимальную функциональность, которая должна быть реализована этим компонентом.
Здравствуйте, Cynic, Вы писали:
C>Это потому, что я английский ни когда в жизни не учил, а переводить нужно
Боюсь предположить как вы до этого докатились.
C>В общем я не понял так правильно:
Похоже на то.
Здравствуйте, Cynic, Вы писали:
C>Ну и последнее: C>
C>These implementation or realization links define the traceability from the formal requirements, through use cases on to components and screens.
Сдаюсь. Тут надо оригинал освоить чтобы понять. Не пятничное это занятие.
Что-то вроде "эти связи определяют возможность проследить (дизайн?) от формальных требованиеий до сценариев, компанент и экранов (форм?)"
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Cynic, Вы писали:
C>>Ну и последнее: C>>
C>>These implementation or realization links define the traceability from the formal requirements, through use cases on to components and screens.
B>Сдаюсь. Тут надо оригинал освоить чтобы понять. Не пятничное это занятие. B>Что-то вроде "эти связи определяют возможность проследить (дизайн?) от формальных требованиеий до сценариев, компанент и экранов (форм?)"
Ааа, не. "от формальных требований до компанент и экранов, через сценарии". Не знаю как лучше по-русски сформулировать.
Здравствуйте, Blazkowicz, Вы писали:
B>>Сдаюсь. Тут надо оригинал освоить чтобы понять. Не пятничное это занятие. B>>Что-то вроде "эти связи определяют возможность проследить (дизайн?) от формальных требованиеий до сценариев, компанент и экранов (форм?)" B>Ааа, не. "от формальных требований до компанент и экранов, через сценарии". Не знаю как лучше по-русски сформулировать.
Тут речь идёт о программе, редакторе UML и возможностях которые она предоставляет. В этом месте такой рисунок:
и такой абзац его комментирующий:
The example above shows that the use case 'Login' implements the formal requirement '1.01 Log On to the website'. It also shows that the 'Business Logic' component and 'ASP Pages' component implement some or all of the 'Login' functionality. A further refinement is to show the 'Login' screen (a web page) as implementing the 'Login' use case. These implementation or realization links define the traceability from the formal requirements, through use cases on to components and screens.
Я перевёл его так(без последнего предложения), но последнее предложение вгоняет в ступор:
Пример выше показывает как вариант использования ‘Login’ реализует формальное требование ‘1.01 Войти на веб-сайт’. Он также показывает как компонент ‘Бизнес логика’ и компонент ‘ASP страница’ реализует некоторую или всю функциональность ‘Login’. Дальнейшее уточнение показывает экран ‘Login’ как реализацию варианта использования ‘Login’.
Ещё пару предложений которые я не могу понять:
Sequence diagrams are an excellent way of documenting usage scenarios and both capturing required objects early in analysis and verifying object use later in design. The diagrams show the flow of messages from one object to another, and as such correspond to the methods and events supported by a class/object.
и
These correspond to the functional specifications found in structured methodologies, and form a contract that the Use Case performs some action or provides some value to the system.
Перевёл вот так:
