Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Андрей Морозов

Страницы: 1
1
UML SysML и пр. / Re: UseCase вне границ системы
« : 29 Января 2012, 00:48:00 »
Я тут статью одну прочитал и у меня появился ещё один вариант как показать тот факт, что в некотором случае, моя система обратится к другой систме "за помощью". Т.е., в моём случае, если пользователь активизирует UC Create Project и сработает точка расширния Create Model, то моя система обратиться к другой системе VISSIM для создания этой самой модели. При этом, линии соединяющие User с прецедентами моей системы - это GUI, а линия к VISSIM это COM Interface.
Мне этот вариянт нравится больше других. И с комментарием Виктора очень удачно совпало:
Цитировать
Всё же, всё то, что находится за границами системы принято изображать действующими лицами, не вариантами использования.

2
UML SysML и пр. / Re: UseCase вне границ системы
« : 26 Декабря 2011, 22:27:05 »
Цитировать
1. Мне кажется, в таком случае нельзя считать Create Model предусловием Create Project. Предусловие - это в некотором роде булевское выражение, которое вычисляется для определения доступности "кнопки", нажав на которую пользователь вызывает выполение кейза. У вас получается, что "кнопка" (условно) Create Project неактивна ("серая"), если до этого не были выполнены действия из Create Model. А вам нужно, чтобы она всегда была активна ("черная"), но если при ее нажатии Create Model еще не выполнялось, то чтобы оно было выполенено.
Согласен, UC Create Model не может называться предусловием для UC Create Project в формальном понимании этого термина, потому что UC Create Model (возможно) выполняется уже после начала UC Create Project, а значит предусловием не является.
У меня встречный вопрос. Если взять, Вашу аналогию с кнопками, то верна ли для неё диаграмма (отношение расширения между UC Create Model и UC Create Project)?

Цитировать
2. Соглашусь с bas, что отсутствие указания границ "материнской системы" делает более трудным понимание этой диаграммы и вызывает лишние вопросы.
В ответ позволю себе процитировать себя же :)
Цитировать
Кстати, во вложении картинка с MSDN, а ниже текст, поясняющий UC Deliver Meal:
Use cases outside the system scope
It is frequently useful to include on the diagram use cases that are part of the business but not dealt with by the system that you are developing. This helps developers understand the context of their work. For example, Deliver Meal could be shown as a use case involving the actors Restaurant and Customer, but outside the responsibility of the Meal Ordering Web Site.
- я понимаю, что хотели сказать авторы МСДН. Для лучшего понимания контекста нам важно не только определить варианты использования системы, но и показать, какая функциональность реализована "где-то в другом месте" (например, нам может быть важен сам факт, что "что-то" уже реализовано, хотябы для того, чтобы в последствии организовать с этим "чем-то" взаимодействие...) причём не важно где именно - главное, что не у нас.
Думаете так (картинка во вложении) будет понятнее/формально правильнее?

P.S.

Кстати, хочу запостить этот топик на англоязычном форуме. Интересно будет посмотреть, что скажут "на западе"... :)

3
UML SysML и пр. / Re: UseCase вне границ системы
« : 16 Декабря 2011, 23:55:13 »
Конечно опечатка! По Фрейду или нет - надеюсь нет :) Вообще я большой мастер художественной опечатки :) а Вы Эдуард Геннадьевич зоркий глаз! :)

4
UML SysML и пр. / Re: UseCase вне границ системы
« : 16 Декабря 2011, 23:02:45 »
Формально, скорее всего Вы правы, но мне кажется, что UC Deliver Meal может помочь в лучшем понимании границ проекта. Сразу становится понятно, что доставка в принципе есть и что она реализуется в другой системе (точно не в нашей). Можно предположить, что эта дополнительная информация может быть полезна для снятия возможной неопределённости в каких-то других местах...

Резюмируя, хочу сказать, что мне было полезно услышать ваши комментарии и советы и вообще, спасибо господам аналитикам за проявленный позитив!  :)

5
UML SysML и пр. / Re: UseCase вне границ системы
« : 16 Декабря 2011, 18:46:17 »
Цитировать
"вынося UseCase, я хочу показать, что существует некоторая функциональность, которая ... является предусловием к началу использования системы".
Функциональность чего?
Моё приложение, это плагин к другому, более крупному, приложению. Часть функциональности реализовано в "материнской" системе (внешние, по отношению к моей системе UC). Так вот, некоторая функциональность - это UC Create Model

Цитировать
2. выполнение какого кейза является предусловием использования системы?
UC Create Model реализован в "материнской" системе и является как бы предусловием к использованию моей системы. Если модель не была создана в "материнской" системе, то срабатывает точка расширения в моём UC Create Project и модель в "мартеринской" системе создаётся вместе с проектом в моей (UC Create Model).

Цитировать
что есть внешний UC, что есть в (вашем понимании) системный?
Системный UC - тот, которые находится в границах системы (system boundaries), внешний - за её пределами.

Кстати, во вложении картинка с MSDN, а ниже текст, поясняющий UC Deliver Meal:
Use cases outside the system scope
It is frequently useful to include on the diagram use cases that are part of the business but not dealt with by the system that you are developing. This helps developers understand the context of their work. For example, Deliver Meal could be shown as a use case involving the actors Restaurant and Customer, but outside the responsibility of the Meal Ordering Web Site.

Я действовал по аналогии, единственное, позволил себе соединить внешний и внутренний UC отношением расширения.

6
UML SysML и пр. / UseCase вне границ системы
« : 16 Декабря 2011, 16:57:38 »
Здравствуйте, глубокоуважаемые аналитики!

Вопрос такой. Как с вашей точки зрения, корректна ли слудующая диаграмма вариантов использования (картинка во вложении)

Если словами, то коррекно ли:
1. Выносить UseCase за границы системы? (вынося UseCase, я хочу показать, что существует некоторая функциональность, которая
       1.1 важна для пользователя в контексте (бизнес-контексте) использования системы
       1.2 является предусловием к началу использования системы
       1.3 может быть выполнена неявно в одном из юзкейсов системы (скрыто от пользователя), т.е. для неё нет пользовательского интерфейса в системе, но есть программный)
2. Использовать "внешний" UseCase в качестве расширяющего для системного юзкейса?

7
Для всех / Re: xUML(Executable UML)
« : 22 Апреля 2011, 21:52:15 »
Ни на один из Ваших вопросов ответить не могу :) но мне лично интересно, почему именно xUML? Вам по работе/учёбе нужно? С какой целью интересуетесь?

8
Наверное, пункт
Цитировать
Объектно-ориентированый дизайн ПО
подразумевает владение UML как инструментом для это самого дизайна  :)

9
да, о том, что это Microsoft best practices пишут на каждом заборе :)
Просто интересно, может кто-то опытный и знакомый с этой методологией видит откуда "ноги растут"  :)

10
Большое спасибо за ответ!
Хоть книг у меня и много, но они редко могут ответить на вопрос "а что, если вот ТАК попробовать?" :) Я очень рад возможности услышать ответ, пусть даже на нелепый вопрос :)

11
может кто знает, что Microsoft взял за основу для своей методологии внедрения?

12
Снимаю шапку перед всеми!!! (хоть уже и столько лет прошло)  :)
Мегаполезные доки!!!

13
Цитировать
Возможность добавления новой функциональности без перекомпиляции основного кода - есть атрибут качества - расширяемость

за атрибут качества - спасибо! Не хватает мне пока широты мышления :)

Цитировать
Потому вероятно ее можно передать через набор ВИ:
установка нового модуля
модификация модуля
настройка модуля
удаление модуля

Да, теперь это кажется очевидным :)



Скажите, ещё один вопрос, а часто ли на практике встречается вложенность ВИ? На сколько хороша идея сначала описать самый общий набор ВИ для системы (без описания сценариев), например:
  • управление пользователями
  • управление задачами
  • управление модулями
  • ...

а потом, на каждой итерации УП "уточнять/расширять" некоторые ВИ (например, с помощью ВИ более низкого уровня, связанных отношениями расширения и/или включения) уже с описанием сценариев? Для ВИ "управление модулями", это могут быть описанные Вами ВИ:
  • установка нового модуля
  • модификация модуля
  • настройка модуля
  • удаление модуля

или обычно так не делают?

14
Заранее извиняюсь за «многа букаф». Подход к описанию всех шагов разработки пока не оформился в моей голове, потому страдаю от некоторой размытости суждений  :)
Давайте я лучше попробую с другой стороны подойти.

Рассмотрим два связанных между собой требования клиента.
Требования гласят, что, помимо прочего, клиент хочет иметь возможность в будущем добавлять в приложение функциональность (какую сам ещё не знает) не прибегая к перекомпиляции или изменению уже написанного кода. Также он хочет, чтобы была реализована возможность регулировать доступ к этой функциональности посредством групп пользователей. Т.е. чтобы, например, модуль аналитики был доступен только аналитикам и управленцам, а модуль работы данными был доступен всем, кроме аналитиков и т.д.

На основе этих требований я решаю, что приложение будет состоять (в упрощённом виде) из:
•   исполняемого файла (exe) – загрузчика модулей
•   и, собственно, модулей (dll), которые реализуют некий общий интерфейс для их поиска, загрузки и запуска на выполнение загрузчиком.

Также я принимаю решение, что приложение должно производить идентификацию пользователей с последующим определением их принадлежности к некми группам, чтобы при загрузке модуля можно было определить входит ли пользователь, от имени которого происходит загрузка, в группу для которой данный модуль является разрешённым. Так как «будущие» модули пока ничего не знают о тех группах, которые будут созданы пользователями системы, то необходимо жёстко прописать некоторые правила, которые помогут будущим модулям описать свою принадлежность (скажем посредством атрибутов). Таким образом, появляются следующие  ограничения:
  • в системе изначально предопределены три группы пользователей
    • группа обычных пользователей
    • группа управленцев
    • группа аналитиков
  • каждый пользователь системы должен придалежать хотябы одной из этих групп

Теперь для меня встаёт вопрос, как мне это всё ПРАВИЛЬНО описать.

Требование по добавлению функциональности в будущем не является функциональным или, точнее, это требование более высокого уровня, чем «обычное» требование, отвечающее на вопрос ЧТО система должна ДЕЛАТЬ. Соответственно это требование не может быть описано «диаграммой вариантов использования» с последующим раскрытыем конкретной ПОСЛЕДОВАТЕЛЬНОСТИ ДЕЙСТВИЙ в виде сценариев. Во всяком случае я не представляю как это сделать  :-\

Вопрос №1, где и в какой форме мне это (видимо нефункциональное) требование описать? В каком док-те?

Далее, требование регулировки доступа к функциональности посредством групп. Тут всё понятно, это «вариант использования» «Авторизация», со сценарием, в котором описан основной и альтернативные потоки процесса авторизации.

Вопрос №2, (пока писал кажется понял ответ  ::) ) был в том, где и в какой форме описать ограничения. Тут я понял что делать, как только назвал ограничения ограничениями (а не нефункциональными требованиями). Ограничения (видимо) можно описать в спецификации прецедента «Авторизация», в резделе ограничения  :) Хотя, с другой стороны, эти ограничения более высокого уровня, чем сам процесс авторизации пользователя.

В самом общем виде мой вопрос(ы) в следующем. Какие документы обычно используются (ведутся) в процессе разработки, при переходе от итерации к итерации и от фазы к фазе? Те же диаграммы и спецификации прецедентов оформляются потом в какой-то единый документ? Как и где (в какой форме) описываются нефункциональные требования? Я знаю о модели классификации требований FURPS, но это знание не отвечает на вопрос как, блин, всё это ГРАМОТНО оформить!?  ???

15
Вопрос по Unified Process (я в нём новичок).

Из теории знаю, что архитектура в UP описывается 4+1 представлениями. Понятно также, что "полное" 4+1 представление должно получиться где-то в конце фазы "Проектирование".
Для того, чтобы "пройти" контрольную точку фазы "Начало", я должен наметить архитектуру в самых общих чертах и, желательно, поставить артефакт "Документ с исходной архитектурой". Всё это звучит очень логично и красиво.
Представление об исходной архитектуре мною составлено и имеется в крайне неструктурированном виде - заметки, да схемки "на полях". Самое время всё это дело обобщить и оформить в виде док-та, но, т.к. архитектурные требования не являются функциональными, я не могу выразить их в диаграммах Use Case. Например:
Группы (речь о аутентификации) могут быть двух видов:
  • группы модулей
  • группы доступа
В системе изначально присутствуют 3 обязательных группы модулей:
  • обычный пользователь
  • менеджер
  • аналитик

Пользователь должен обязательно принадлежать к одной из 3х групп модулей.



Собственно, вопрос вот в чём. В каком формате (каком документе) ПРИНЯТО описывать такие архитектурные требования? У меня они упомянуты в док-те Vision, но мне бы хотелось, чтобы у меня был отдельный документ с (пока базовой) архитектурой, которую не описать диаграммой размещения или пакетов.

А вообще, если не затруднит. Хочется узнать, какой набор документов (артефактов) используете?

Страницы: 1