UP: Документ с исходной архитектурой(Прочитано 6087 раз)
Вопрос по Unified Process (я в нём новичок).

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

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



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

А вообще, если не затруднит. Хочется узнать, какой набор документов (артефактов) используете?
Never let schooling interfere with your education (Mark Twain)



Re: UP: Документ с исходной архитектурой Ответ #1 : 28 Марта 2011, 08:27:30
Не совсем понятно, какой смысл вкладывается в понятие "группа".
Что значит группа моделей почему она отделяется от группы доступа.
Что это такое группа модулей "обычный пользователь" и т.п.
Цитировать
В каком формате (каком документе) ПРИНЯТО описывать такие архитектурные требования?
Какие такие архитектурные требования?



Re: UP: Документ с исходной архитектурой Ответ #2 : 28 Марта 2011, 18:05:30
Заранее извиняюсь за «многа букаф». Подход к описанию всех шагов разработки пока не оформился в моей голове, потому страдаю от некоторой размытости суждений  :)
Давайте я лучше попробую с другой стороны подойти.

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

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

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

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

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

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

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

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

В самом общем виде мой вопрос(ы) в следующем. Какие документы обычно используются (ведутся) в процессе разработки, при переходе от итерации к итерации и от фазы к фазе? Те же диаграммы и спецификации прецедентов оформляются потом в какой-то единый документ? Как и где (в какой форме) описываются нефункциональные требования? Я знаю о модели классификации требований FURPS, но это знание не отвечает на вопрос как, блин, всё это ГРАМОТНО оформить!?  ???
« Последнее редактирование: 28 Марта 2011, 18:09:11 от Андрей Морозов »
Never let schooling interfere with your education (Mark Twain)



Re: UP: Документ с исходной архитектурой Ответ #3 : 28 Марта 2011, 18:41:58
Если следовать унифицированному процессу (или его конкретным проявлениям в виде RUP, OpenUP и иже с ними), тогда ответ прост. Берем рекомендации оных процессов и делаем как велено:)

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

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

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

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

Или пример Miranda. Примеров масса



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

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

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

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



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

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

или обычно так не делают?
Never let schooling interfere with your education (Mark Twain)



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

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

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

ВИ типа "управление чем-либо" - это типичный шаблон CRUD. Его можно использовать, а можно незаморачиваться особо.



Re: UP: Документ с исходной архитектурой Ответ #6 : 29 Марта 2011, 10:26:40
Большое спасибо за ответ!
Хоть книг у меня и много, но они редко могут ответить на вопрос "а что, если вот ТАК попробовать?" :) Я очень рад возможности услышать ответ, пусть даже на нелепый вопрос :)
Never let schooling interfere with your education (Mark Twain)



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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19