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

Общий раздел => Методологии => RUP EUP AUP OpenUP => Тема начата: Андрей Морозов от 28 Марта 2011, 00:13:31

Название: UP: Документ с исходной архитектурой
Отправлено: Андрей Морозов от 28 Марта 2011, 00:13:31
Вопрос по Unified Process (я в нём новичок).

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

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



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

А вообще, если не затруднит. Хочется узнать, какой набор документов (артефактов) используете?
Название: Re: UP: Документ с исходной архитектурой
Отправлено: Galogen от 28 Марта 2011, 08:27:30
Не совсем понятно, какой смысл вкладывается в понятие "группа".
Что значит группа моделей почему она отделяется от группы доступа.
Что это такое группа модулей "обычный пользователь" и т.п.
Цитировать
В каком формате (каком документе) ПРИНЯТО описывать такие архитектурные требования?
Какие такие архитектурные требования?
Название: Re: UP: Документ с исходной архитектурой
Отправлено: Андрей Морозов от 28 Марта 2011, 18:05:30
Заранее извиняюсь за «многа букаф». Подход к описанию всех шагов разработки пока не оформился в моей голове, потому страдаю от некоторой размытости суждений  :)
Давайте я лучше попробую с другой стороны подойти.

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

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

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

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

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

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

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

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

В самом общем виде мой вопрос(ы) в следующем. Какие документы обычно используются (ведутся) в процессе разработки, при переходе от итерации к итерации и от фазы к фазе? Те же диаграммы и спецификации прецедентов оформляются потом в какой-то единый документ? Как и где (в какой форме) описываются нефункциональные требования? Я знаю о модели классификации требований FURPS, но это знание не отвечает на вопрос как, блин, всё это ГРАМОТНО оформить!?  ???
Название: Re: UP: Документ с исходной архитектурой
Отправлено: Galogen от 28 Марта 2011, 18:41:58
Если следовать унифицированному процессу (или его конкретным проявлениям в виде RUP, OpenUP и иже с ними), тогда ответ прост. Берем рекомендации оных процессов и делаем как велено:)

Следуя UP. Часто выделяется спецификация требований в виде описания вариантов использования. Все что не относится к ВИ или по тем или иным причинам решено в ВИ не включать, может быть отражено с спецификации дополнительных требования в классификации FRUPS+

Вопросы безопасности, управления доступом и прочими - являются функциями, сервисами и т.п., которые трудно локализовать в том или ином модуле. Их и называют cross-cutting.

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

Возьмем любую cms, например, joomla. Она сделана ровно так как вы хотели бы (правда тут все проще, код не компилирован и доступен в исходном виде). Но сути не меняет, в любом случае клиент должен знать каким -образом создать и подключить модуль в работающую систему.

Или пример Miranda. Примеров масса
Название: Re: UP: Документ с исходной архитектурой
Отправлено: Андрей Морозов от 28 Марта 2011, 21:40:01
Цитировать
Возможность добавления новой функциональности без перекомпиляции основного кода - есть атрибут качества - расширяемость

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

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

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



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

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

или обычно так не делают?
Название: Re: UP: Документ с исходной архитектурой
Отправлено: Galogen от 29 Марта 2011, 08:04:15
Вложенность ВИ - на практике это не приветствуется, а в теории запрещено.
ВИ - не функция, а аспект использования функций. Потому алгоритмическая декомпозиция (в смысле вложенности) не приветствуется. Однако сама по себе декомпозиция естественно имеет место. При переходе от БВИ к СВИ например.

Включение одного ВИ в другой - это все-таки не вложенность, а элемент структуризации. Но обычно на начальных стадиях анализа аспекта использования с этим не следует слишком заморачиваться.

Следует понять - ВИ - инструмент для анализа аспекта использования (назначения) системы. Тут мы пытаемся дать ответы на вопросы: что делает система, кому это надо, кто инициирует процесс, кто внешний может участвовать в этом процессе, какие цели обеспечиваются, чьи интересы достигаются  или защищаются

ВИ типа "управление чем-либо" - это типичный шаблон CRUD. Его можно использовать, а можно незаморачиваться особо.
Название: Re: UP: Документ с исходной архитектурой
Отправлено: Андрей Морозов от 29 Марта 2011, 10:26:40
Большое спасибо за ответ!
Хоть книг у меня и много, но они редко могут ответить на вопрос "а что, если вот ТАК попробовать?" :) Я очень рад возможности услышать ответ, пусть даже на нелепый вопрос :)
Название: Re: UP: Документ с исходной архитектурой
Отправлено: Galogen от 29 Марта 2011, 10:56:28
Большое спасибо за ответ!
Хоть книг у меня и много, но они редко могут ответить на вопрос "а что, если вот ТАК попробовать?" :) Я очень рад возможности услышать ответ, пусть даже на нелепый вопрос :)
Это нормально. И лишний раз говорит, что несмотря на кучу книг, нужно еще свой мозг настроить на воприятие того, что там заложено. А это не делается вдруг. Так что не стесняйтесь задавать вопросы. Главное, что Вы уже и сами заметили. При формулировки вопроса так, чтобы и другие поняли, чего вы хотите спросить , вдруг, ловишь себя на мысле, что ответ уже найден :)