Здравствуйте, IT, Вы писали:
IT>Насколько мне известно, в янусе используются нетипизированные датасеты, что уже само по себе дырка в дизайне. На сервере сервис не следует простейшим правилам разбиения на слои, маппинг делается в ручную. На клиенте маппинг тоже делается в ручную. Но всё это, ещё раз повторяю, ни в коем случае не умоляет заслуг разработчиков. Просто это всё писалось давным давно. А сегодня вполне можно было бы задизайнить всё так, что бы и на сервере и на клиенте код методов сервиса и сохранение этого дела на клиенте занимало бы по паре строк.
Понятно, что со временем появляются новые знания, и всё старое можно сделать по-другому. Но это уже вопрос приоритетов, что переделывать, когда, а что пока оставить, и быть может надолго.
А новый сервис был сделан уже с учётом этого? Хотя, ты уже писал, что с ним не разбирался...
IT>Зато для веба нужен пейджинг почти для всех методов. Для януса не нужен, а для веба нужен. Это опять к слову о независимости клиентов от сервера.
Пейджинг — разбиение на страницы?
IT>У нас не стоит задачи предоставить вебслужбу (контракт) для удалённого взаимодействия с собой. У нас стоит задача обеспечить соответствующими сервисами янус, веб и NNTP клиентов. Контракт — это очень здорово, это позволяет максимально изолировать различные части системы друг от друга. Мне это всё очень нравится как правильный паттерн и хороший инструмент для достижения обеспечения более простого сопровождения. Но при всём при этом это всего лишь инструмент и относится к нему нужно соответственно.
Насчёт задачи согласен. А разве контракт не является способом её решения? Или так: есть другие способы решения этой задачи?
Поверь, у меня нет иллюзий на счёт использования правильных инструментов, лично я использую те, которыми владею и настолько, насколько владею. Если цель в принципе достижима с их использованием.
IT>Я думаю, что у тебя наблюдается некоторая путаница с системой твоих приоритетов. Это потребует некоторого объяснения. Я уже много раз об этом безуспешно говорил, например, здесь
Большое спасибо за ссылки и за объяснение.
IT>1. Функциональные требования. IT>2. Нефункциональные требования. IT>3. Сопровождаемость системы.
Функциональные — значат, что должен делать или чего не делать разрабатываемый продукт.
Нефункциональные — где он это должен делать или не делать. Выбор платформы (ОС, среда программирования, язык, библиотеки, алгоритмы, ...) для реализации функциональных требования относится к нефункциональным требованиям?
IT>Очевидно, что в твоём случае ты не можешь определиться с тем, как ты позиционируешь для себя веб-сервис януса.
Для меня он жизненно необходим. Т.е. в случае его отключения наступит ломка, и придётся забыть о форумах РСДН. Ну, либо домогаться по нескольким хорошо известным адресам его включения. После тех удобств, что предоставляет мне лично Янус, веб-мордой пользоваться я просто не могу.
Но возвращаясь к вопросу большей и меньшей связанности, не хочешь ли ты мне так длинно сказать (ну, чтобы я сам попробовал сделать вывод), что собствеено пофигу, есть или нет этой связности. Что это для функционала Януса и сервера вовсе не важно и дело сотого порядка. И собственно, обсуждать такие малозначимые вопросы — просто терять время, ну или мозг разминать, если больше нечем занятся.
Т.е. есть какая связанность между Янусом и сервером, нету ли её, это не имеет ни малейшего значения с точки зрения изложенной базы из трёх пунктов выше.
IT> ...моя главная и единственная задача — написать требуемый функционал, который бы хорошо работал и который было бы легко сопровождать. И этому всё подчинено.
Это надо написать большими буковами и поместить на самое видное место.
Здравствуйте, akasoft, Вы писали:
A>Понятно, что со временем появляются новые знания, и всё старое можно сделать по-другому. Но это уже вопрос приоритетов, что переделывать, когда, а что пока оставить, и быть может надолго.
Со временем ещё нарабатываются и появляются соответствующие инструменты, с помощью которых аналогичные задачи решаются значительно легче.
A>Пейджинг — разбиение на страницы?
Да.
A>Насчёт задачи согласен. А разве контракт не является способом её решения?
Является.
A>Или так: есть другие способы решения этой задачи?
Если под контрактом понимать веб-сервис и WSDL, то другие способы, конечно же есть. В том числе более эффективные, но менее кошерные. Например, избыточность XML можно убрать с помощью своего доморощенного формата передачи, допустим по записи на строку с запятой в качестве разделителя. Объём передаваемых данных уменьшиться в несколько раз. Можно применить маппер, который не будет создавать промежуточных структур данных. Т.е. прямо из ридера рекордсета данные будут прямиком уходит в html стрим. Т.е. на сервере не будет тратится лишнее время и память на преобразование данных из формата БД в формат объектной модели. На клиенте html стрим также без лишних ресурсов можно мапить прямо в БД клиента.
У этого решения есть свои недостатки, но есть и свои преимущества. Но как минимум это альтернативный способ.
A>Поверь, у меня нет иллюзий на счёт использования правильных инструментов, лично я использую те, которыми владею и настолько, насколько владею. Если цель в принципе достижима с их использованием.
Сойдёт.
IT>>Очевидно, что в твоём случае ты не можешь определиться с тем, как ты позиционируешь для себя веб-сервис януса.
A>Для меня он жизненно необходим. Т.е. в случае его отключения наступит ломка, и придётся забыть о форумах РСДН. Ну, либо домогаться по нескольким хорошо известным адресам его включения. После тех удобств, что предоставляет мне лично Янус, веб-мордой пользоваться я просто не могу.
Жизненно необходим именно веб-сервис или та функциональность, которую предоставляет янус?
A>Но возвращаясь к вопросу большей и меньшей связанности, не хочешь ли ты мне так длинно сказать (ну, чтобы я сам попробовал сделать вывод), что собствеено пофигу, есть или нет этой связности. Что это для функционала Януса и сервера вовсе не важно и дело сотого порядка. И собственно, обсуждать такие малозначимые вопросы — просто терять время, ну или мозг разминать, если больше нечем занятся.
Нет, я не это хочу сказать. Всё это не пофигу и это дело не сотого порядка. Выбор средств, дизайн и имплементация функционала напрямую влияют на третий пункт — на сопровождаемость. Веб-сервис можно реализовать многими способами, я предпочту тот, который мне даст более лёгкую сопровождаемость и при этом не войдёт в противоречие с функциональными/нефункциональными требованиями. Я хочу сказать, что такие вещи как связность — это инструмент для достижения главных целей, это та разменная монета, которой я готов легко пожертвовать, если я увижу другое, более приемлемое решение. Сама по себе связность не является для меня целью, это лишь средство достижения цели. Цель — сопровождаемоесть. Но при этом надо чётко понимать, что сопровождаемость складывается из правильных средств, грамотного дизайна и приличной имплементации.
Опять, блин, получилось как-то путанно
A>Т.е. есть какая связанность между Янусом и сервером, нету ли её, это не имеет ни малейшего значения с точки зрения изложенной базы из трёх пунктов выше.
Это не является целью. Говорить о связанности можно и нужно только в контексте сопровождаемости.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Речь идёт о том, что дизайн и имплеинтация сервиса для януса мог бы быть значительно лучше, если бы это учитывалось изначально при разработке сайта. Но в 2000 году об офлай клиенте речи вообще не было. Для нас тогда даже форумы имели второстепенное значение, соответственно и появились они лишь бы было.
Что-то я пропустил этот пункт.
А вот интересно, что имело первостепенное значение в 2000 году?
И какое значение, с твоей точки зрения, имеют форумы сейчас?
(Если ответы на эти вопросы не потребуют раскрытия какой-либо тайны.)
Здравствуйте, IT, Вы писали:
IT>Если под контрактом понимать веб-сервис и WSDL, то другие способы, конечно же есть. В том числе более эффективные, но менее кошерные. Например, избыточность XML можно убрать с помощью своего доморощенного формата передачи, допустим по записи на строку с запятой в качестве разделителя. Объём передаваемых данных уменьшиться в несколько раз. Можно применить маппер, который не будет создавать промежуточных структур данных. Т.е. прямо из ридера рекордсета данные будут прямиком уходит в html стрим. Т.е. на сервере не будет тратится лишнее время и память на преобразование данных из формата БД в формат объектной модели. На клиенте html стрим также без лишних ресурсов можно мапить прямо в БД клиента.
Собственно под контрактом я подразумевал нечто в стиле interface, т.е. формулирование и документирование некоторого набора методов, порядка их вызова и форматов данных, которыми будут обмениваться Янус и сервер. Не имея оговоренного набора этого самого interface мне предствляется затруднительным решить задачу взаимодействия.
В то же время, сам контракт можно модифицировать, модернизировать и быть может не требовать совместимости между предыдущими версиями, если это не скажется на сопровождении.
IT>Жизненно необходим именно веб-сервис или та функциональность, которую предоставляет янус?
Конечно же Янус. А что, есть способ поднять Янус "по воздуху"? Читай, не через вебслужбу?
IT>Нет, я не это хочу сказать. Всё это не пофигу и это дело не сотого порядка. Выбор средств, дизайн и имплементация функционала напрямую влияют на третий пункт — на сопровождаемость. Веб-сервис можно реализовать многими способами, я предпочту тот, который мне даст более лёгкую сопровождаемость и при этом не войдёт в противоречие с функциональными/нефункциональными требованиями. Я хочу сказать, что такие вещи как связность — это инструмент для достижения главных целей, это та разменная монета, которой я готов легко пожертвовать, если я увижу другое, более приемлемое решение. Сама по себе связность не является для меня целью, это лишь средство достижения цели. Цель — сопровождаемоесть. Но при этом надо чётко понимать, что сопровождаемость складывается из правильных средств, грамотного дизайна и приличной имплементации.
Получается, что на реализацию вебслужбы Януса большее влияние оказало именно требование сопровождаемости? Т.е. по другому — умения и навыки разработчиков вебслужбы нарабатывались и развивались по мере реализации вебслужбы? Потом пересматривались, переделывались. В то время как с функциональными и нефункциональными требованиями вопросов не возникало.
Здравствуйте, akasoft, Вы писали:
A>А вот интересно, что имело первостепенное значение в 2000 году?
Предполагалось делать упор на контент, а именно:
RSDN создан программистами для программистов. Главная цель создателей сайта заключается в том, чтобы хоть как-то компенсировать нехватку материалов по программированию на русском языке.
A>И какое значение, с твоей точки зрения, имеют форумы сейчас?
С моей точки зрения только общение может сделать из просто сайта комьюнити. Так что форумы тут имеют первостепенное значение.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, akasoft, Вы писали:
A>Собственно под контрактом я подразумевал нечто в стиле interface, т.е. формулирование и документирование некоторого набора методов, порядка их вызова и форматов данных, которыми будут обмениваться Янус и сервер. Не имея оговоренного набора этого самого interface мне предствляется затруднительным решить задачу взаимодействия.
Я задам другой вопрос. Имеет ли смысл создавать такой интерфейс между сервером и веб-интерфейсом? Они ведь тоже должны как-то взаимодействовать?
A>В то же время, сам контракт можно модифицировать, модернизировать и быть может не требовать совместимости между предыдущими версиями, если это не скажется на сопровождении.
IT>>Жизненно необходим именно веб-сервис или та функциональность, которую предоставляет янус?
A>Конечно же Янус. А что, есть способ поднять Янус "по воздуху"? Читай, не через вебслужбу?
Например, через WCF или банально через HTTP
A>Получается, что на реализацию вебслужбы Януса большее влияние оказало именно требование сопровождаемости? Т.е. по другому — умения и навыки разработчиков вебслужбы нарабатывались и развивались по мере реализации вебслужбы? Потом пересматривались, переделывались. В то время как с функциональными и нефункциональными требованиями вопросов не возникало.
RSDN — это вообще тренировочный полигон для девелоперов, народ тут и технологии изучал и идеи отрабатывал. По-этому, сказать чем руководствовались разработчики веб-службы сказать крайне сложно.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Посмотри на название топика. Как ты думаешь, что оно означает? Из-за этого я и завёлся. А потом уже началась неразбериха с терминологией.
Слона то я и не заметил Согласен, название такого двоякого толкования не допускает.
Моя смерть ездит в черной машине с голубым огоньком
Здравствуйте, IT, Вы писали:
IT>Я задам другой вопрос. Имеет ли смысл создавать такой интерфейс между сервером и веб-интерфейсом? Они ведь тоже должны как-то взаимодействовать?
Попробую ответить.
На мой взгляд, при работе через вебморду мы фактичекски работаем с трёхзвенкой. Имеется клиентский броузер со скриптовыми языками, имеется IIS с ASP.NET и языками программирования, имеется БД с хранимыми процедурами. За слой бизнеспроцессов отвечает прослойка с IIS, он же осуществляет проверку данных, вводимых пользователем, аудит работы. Долговременным и кратковременным хранилищем данных выступает серверная БД. Интерфейсом для броузера выступает набор URL, передаваемые данные представляют собой XHTML с JavaScript (или C#), принимаемые данные обусловлены протоколом HTTP и тоже поддаются описанию, как то имена полей, ограничения, содержимое.
Попробую оценить эту конструкцию с точки зрения трёх правил. У меня нет опыта эксплуатации IIS под серьёзной нагрузкой, но вот опыт использования виртуального хостинга на базе Апача и php говорит мне, что быстродействие и взаимодействие с базой является узким местом. Поэтому быстродействие (способность обслужить нужное количество клиентов за приемлимое время) я ставлю в функциональные требования. А красивость кода и его количество — в сопровождение.
С моей точки зрения необходимость делать ещё один слой между БД и IIS будет означать потерю быстродействия, хотя возможно, при этом уменьшится количество кода, приходящегося на слой IIS (ASP.NET, C#), что будет означать лучшую сопровождаемость.
Но предположим, что я всё-таки введу ещё один слой между БД и IIS. Что я с этого могу иметь? Могу поднять быстродействие за счёт кеширования в памяти каких либо данных, наиболее часто выбираемых. Могу централизованно управлять аудитом, причём не только от вебморды, но и от других возможных служб, взаимодействующих с этим слоем вместо непосредственной работы с БД. Если я начну кешировать не только на чтение, но и на запись в БД, то могу понизить надёжность системы. Электроэнергия теоретически может пропасть. Могу получить некий framework, с которым будет удобно и приятно работать мне, разработчику. Я могу стянуть весь теоретически общий код для всех предоставляемых служб во вне в один framework, отладить его и забыть. Но ведь это будет просто напоминать некоторую библиотеку функций, которой будет удобно пользоваться как для обслуживания веб-запросов, так и Януса, NNTP и того, что ещё может появиться. Разве это слой? Чем он будет отличаться от кода, написанного и работающего под IIS.
С тем же Янусом будет взаимодействовать опять же вебслужба, работающая под управлением IIS, а значит опять же ASP.NET и C#. Опять будет 4 слоя вместо трёх.
Если IIS и SQL Server умеют продуктивно настраиваться и работать с кешированием и частозапрашиваемыми данными нет особого смысла дублировать их работу. Это будет сопровождаемость по части кода, ведь при этом не понадобиться писать и отлаживать свой framework. И нефункциональные требования по части надёжности.
Ну а теперь ты мне скажи, зачем на самом деле нужен ещё один слой между "сервером и веб-интерфейсом"?
Здравствуйте, akasoft, Вы писали:
A>С моей точки зрения необходимость делать ещё один слой между БД и IIS будет означать потерю быстродействия, хотя возможно, при этом уменьшится количество кода, приходящегося на слой IIS (ASP.NET, C#), что будет означать лучшую сопровождаемость.
Ещё один слой, если он работает в том же процессе, никакой потери быстродействия не даёт вообще. Потери могут возникнуть при взаимдействии между процессами, но на одной машине они ничтожно малы, по сравнению с доступом к базе данных.
A>Я могу стянуть весь теоретически общий код для всех предоставляемых служб во вне в один framework, отладить его и забыть. Но ведь это будет просто напоминать некоторую библиотеку функций, которой будет удобно пользоваться как для обслуживания веб-запросов, так и Януса, NNTP и того, что ещё может появиться. Разве это слой? Чем он будет отличаться от кода, написанного и работающего под IIS.
А что в твоём понимании слой?
A>Ну а теперь ты мне скажи, зачем на самом деле нужен ещё один слой между "сервером и веб-интерфейсом"?
Речь шла не о слое, а о контракте. Например, между янусом и сервером имеется веб-служба с определённым контрактом. Вопрос нужен ли такой контракт между сервером и веб-мордой, точнее между ASP.NET и сервером. Теоретически это может дать определённые преимущества, практически — кучу проблем. Иногда может перевесить одно, иногда другое. Вот я и хотел узнать твоё мнение.
Если нам не помогут, то мы тоже никого не пощадим.
Мои телепатические возможности подвели меня. Вместо того, чтобы прямо тебя спросить, что ты имеешь ввиду, говоря "сервер" в контекстах "между сервером и Янусом" и "между сервером и веб-интерфейсом", я начал фантазировать и смоделировал трёхзвенку. Чтобы не фантазировать дальше, так и спрошу: что такое сервер?
IT>А что в твоём понимании слой?
Со слоями я впервые столкнулся в графике при использовании Corel Draw, оттуда вышло понимание слоя как нечта логически выделенного и изолированного, взаимодействующего с др. слоями с помощью контрактов (интерфейсов), слой можно "выключить" и заменить на другой, реализующий такой же контракт.
Библиотеки же, с которыми мне приходилось иметь дело, обычно предоставляли пользователю свой собственный контракт каждая, хотя могли делать примерно одно и то же.
Совокупность категорий классов или подсистем одного уровня абстракции.
Так что, скорее всего я путаю и смешиваю понятия.
IT>Речь шла не о слое, а о контракте. Например, между янусом и сервером имеется веб-служба с определённым контрактом. Вопрос нужен ли такой контракт между сервером и веб-мордой, точнее между ASP.NET и сервером. Теоретически это может дать определённые преимущества, практически — кучу проблем. Иногда может перевесить одно, иногда другое. Вот я и хотел узнать твоё мнение.
Я перешёл на слои потому, что плохо понимаю, что ты называешь сервером. Ну, не про ОС Windows 2003 Server же ты говоришь? В озвученной мною трёхзвенной модели и БД (SQL Server), и IIS, и ASP.NET, и вебслужба работают "на сервере", и только Янус работает "на клиенте".
IT>Базируется это хозяйство на очень простой системе приоритетов и разрешения противоречий. Список приоритетов у меня такой: IT>1. Функциональные требования. IT>2. Нефункциональные требования. IT>3. Сопровождаемость системы.
Вот в данном случае я абсолютно не согласен. Во первых "Сопровождаемость системы" — часть нефункциональных/функциональных требований. Во вторых, если ты не выполнил наиболее важные нефункциональные требования, то значит проект провален и клиент убежит от тебя. Ну и в третьих, приоритеты должны расставляться внутри функциональных/нефункциональных требования.
IMHO Возьмем, к примеру, rsdn. Основным нефункциональным требованием к нему должна быть масштабируемость. То есть работоспособность при пиковой нагрузке. Если сервер будет неработоспособен, то всем будет наплевать какие у нас остальные функциональные/нефункциональные требование. Всем будет абсолютно по фигу с каким быстродействием может отвечать сервер, насколько красива архитектура, и как мало на это времени потратили разработчики. Под это бывает (и наверняка случалось на rsdn) нельзя сделать некоторые функциональные требования.
Поэтому приоритеты нужно расставлять по каждому пункту в функциональных и нефункциональных требованиях.
Здравствуйте, GlebZ, Вы писали:
GZ>Вот в данном случае я абсолютно не согласен. Во первых "Сопровождаемость системы" — часть нефункциональных/функциональных требований. Во вторых, если ты не выполнил наиболее важные нефункциональные требования, то значит проект провален и клиент убежит от тебя. Ну и в третьих, приоритеты должны расставляться внутри функциональных/нефункциональных требования.
Т.е. ты хочешь свалить всё в одну кучу, а потом уже в ней расставить приоритеты? В результате у тебя получатся те же 1, 2, 3
GZ>Поэтому приоритеты нужно расставлять по каждому пункту в функциональных и нефункциональных требованиях.
Выше я упомянул, что требования могут переходить из одной категории в другую. Давай скажем так, наша задача разработать софт для поддержки большого портала. Большой — это уже требование, являющееся одной из наших основных задач и к нему следует относиться как к функциональному требованию.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Т.е. ты хочешь свалить всё в одну кучу, а потом уже в ней расставить приоритеты? В результате у тебя получатся те же 1, 2, 3
Нет. Приоритеты расставляются отдельно для функциональных требований, и отдельно для нефункциональных. И делятся на три группы по степени важности.
IT>Выше я упомянул, что требования могут переходить из одной категории в другую.
Нет. Не могут. Функциональные требования — это достаточно строгая конструкция которая определяет сценарии/действия пользователя. Они могут зависить друг от друга (например требования по администрированию), но они совершенно разные по форме и содержанию. IT>Давай скажем так, наша задача разработать софт для поддержки большого портала. Большой — это уже требование, являющееся одной из наших основных задач и к нему следует относиться как к функциональному требованию.
Игорь. Откуда такое требование ты взял? Это нормально для пользователя, но для разработчика это ничего не значит. Что такое большой портал? Относительно кого? В чем измеряется? В количестве форм, в количестве строк, или просто формы показываемые порталом должны быть большими? Все равно что, делайте что хотите, но решение должно быть большим и красивым.
Здравствуйте, GlebZ, Вы писали:
IT>>Т.е. ты хочешь свалить всё в одну кучу, а потом уже в ней расставить приоритеты? В результате у тебя получатся те же 1, 2, 3 GZ>Нет. Приоритеты расставляются отдельно для функциональных требований, и отдельно для нефункциональных. И делятся на три группы по степени важности.
Это всё становится слишком сложно. У меня ведь нет цели разработать формальную систему принятия решений. Моя задача упростить для себя принятие решений в 99% случаев. Пока эта система проста, она работает. Усложнение сделает её бесполезной.
IT>>Выше я упомянул, что требования могут переходить из одной категории в другую. GZ>Нет. Не могут. Функциональные требования — это достаточно строгая конструкция которая определяет сценарии/действия пользователя. Они могут зависить друг от друга (например требования по администрированию), но они совершенно разные по форме и содержанию.
Могут, могут. Например, строгость объектной модели одно из функциональных требований для публичных библиотек, и всего лишь средство достичь лучшего сопровождения для обычных задач.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
IT>Это всё становится слишком сложно. У меня ведь нет цели разработать формальную систему принятия решений. Моя задача упростить для себя принятие решений в 99% случаев. Пока эта система проста, она работает. Усложнение сделает её бесполезной.
Она не проста. Она просто неверна. Не может быть приоритета функциональных требований над нефункциональными. Может быть приоритет одного набора требований над другими. Независимо от того, функциональные они, или нефункциональные. Что касается формализма, то как результат он работает. И весьма верно работает. Функциональные/нефункциональные требования — это набор достижимых целей. Все остальное — это средства. Достижимость обозначает что по каждому требованию мы можем точно сказать что цель либо достигнута, либо не достигнута. Оно не допускает абстракции. И как результат, мы можем точно сказать что есть цель, а что средство. А какие цели не должны быть реализованы поскольку никому на фиг не сдались, хоть программисту и хочется это сделать.
IT>Могут, могут. Например, строгость объектной модели одно из функциональных требований для публичных библиотек, и всего лишь средство достичь лучшего сопровождения для обычных задач.
Видишь ли, объектная модель — это не есть цель. Это средство. Даже контракт не является целью. Цель может быть например:
Для функц. требований:
1. Пользователь может получить набор сообщений находящихся на определенном форуме и зарегистрированных начиная с определенного времени.
2. Пользователь может получить текст определенного сообщения.
3. Пользователь может получить сумму оценок для определенного сообщения.
Для нефункц. требований другое:
1. Система оставаться работоспособной при 100 одновременных запросах.
2. Время ответа при выполнении пункта 1,2,3 функц. требований не должно превышать n секунд при m одновременных запросах.
Пропишем ли мы, например, текст как неотъемлимое свойство сообщения, или будет запрашиваться по каждому сообщению — это уже выводится из данных целей. Вероятнее мы не сможем выполнить пункт 2 нефункц. требований если будем спрашивать по каждому сообщению. Но самое главное, при проектировании контракта, мы точно можем сказать что мы непротиворечим пунктам, и они остались достижимы.
Здравствуйте, GlebZ, Вы писали:
GZ>Она не проста. Она просто неверна.
А я клятвы верности никому и не давал
GZ>Не может быть приоритета функциональных требований над нефункциональными.
Ещё как может. Быстрая, но не делающая то, что нужно система нифиг никому не нужна. А вот работающая, но тормознутая имеет определённую ценность.
GZ>Может быть приоритет одного набора требований над другими. Независимо от того, функциональные они, или нефункциональные.
Какие ещё наборы? А как насчёт приоритетов внутри наборов? В общем, это всё усложнение на ровном месте.
GZ>Что касается формализма, то как результат он работает. И весьма верно работает.
Формализм здесь вообще не может работать в принципе, т.к. требования сами по себе есть суть предпочтениях, а значит никакой классификации не поддаются. Даже разделение на функциональные и нефункциональные весьма условно.
GZ>Функциональные/нефункциональные требования — это набор достижимых целей. Все остальное — это средства. Достижимость обозначает что по каждому требованию мы можем точно сказать что цель либо достигнута, либо не достигнута. Оно не допускает абстракции. И как результат, мы можем точно сказать что есть цель, а что средство. А какие цели не должны быть реализованы поскольку никому на фиг не сдались, хоть программисту и хочется это сделать.
Это ошибочное мнение. Существует вещи, которые не являются ни функциональными, ни нефункциональными требованиями, они даже нафиг не сдались ни юзеру, ни заказчику, тем не менее они являются первостепенными целями.
GZ>Видишь ли, объектная модель — это не есть цель. Это средство.
Я могу ещё раз привести пример с командой MS по надзору за согласованностью FW.
GZ>Даже контракт не является целью. Цель может быть например:
Это очень узкая трактовка, которая может быть справедливой только для одного узкого круга задач. Вот тебе ещё некоторые трубования к системе:
1. Обеспечение расширяемости функционала за счёт предоставления соответствующего API 3d party продуктам.
2. Обеспечение интерфейса для поступа внешних систем.
Это какой тип требований?
В конце концов существуют системы, в которых вообще нет пользовательского интерфейса и любая из функций системы не может подойти под категорию "Пользователь может получить текст определенного сообщения".
Что здесь является функциональными требованиями?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
GZ>>Не может быть приоритета функциональных требований над нефункциональными. IT>Ещё как может. Быстрая, но не делающая то, что нужно система нифиг никому не нужна. А вот работающая, но тормознутая имеет определённую ценность.
Это неверно определенные требования. Значит быстрота должна либо не быть целью, либо быть целью с низким приоритетом. Но например если в редакторе скорость вставки символа меньше чем скорость с которой его набирает пользователь, то такое решение никому не нужно.
GZ>>Может быть приоритет одного набора требований над другими. Независимо от того, функциональные они, или нефункциональные. IT>Какие ещё наборы? А как насчёт приоритетов внутри наборов? В общем, это всё усложнение на ровном месте.
Нет. Упрощение. Фактически мы видим набор целей важных для пользователя и не особо важных. Набор требований без которых пользователь будет считать проект неуспешным, и набор требований которые пользователи может перетерпеть.
IT>Формализм здесь вообще не может работать в принципе, т.к. требования сами по себе есть суть предпочтениях, а значит никакой классификации не поддаются. Даже разделение на функциональные и нефункциональные весьма условно.
Оно точно. Второй раз писать почему?
IT>Это ошибочное мнение. Существует вещи, которые не являются ни функциональными, ни нефункциональными требованиями, они даже нафиг не сдались ни юзеру, ни заказчику, тем не менее они являются первостепенными целями.
Например?
GZ>>Видишь ли, объектная модель — это не есть цель. Это средство. IT>Я могу ещё раз привести пример с командой MS по надзору за согласованностью FW.
Ссылку.
IT>Это очень узкая трактовка, которая может быть справедливой только для одного узкого круга задач. Вот тебе ещё некоторые трубования к системе: IT>1. Обеспечение расширяемости функционала за счёт предоставления соответствующего API 3d party продуктам. IT>2. Обеспечение интерфейса для поступа внешних систем. IT>Это какой тип требований?
Концепция. Оно абстрактно. Неабстрактно и достижимо будет набор требований — что должны делать данные библиотеки.
IT>В конце концов существуют системы, в которых вообще нет пользовательского интерфейса и любая из функций системы не может подойти под категорию "Пользователь может получить текст определенного сообщения". IT>Что здесь является функциональными требованиями?
А что клиентская программа не может является пользователем системы?
Здравствуйте, GlebZ, Вы писали:
GZ>Это неверно определенные требования. Значит быстрота должна либо не быть целью, либо быть целью с низким приоритетом. Но например если в редакторе скорость вставки символа меньше чем скорость с которой его набирает пользователь, то такое решение никому не нужно.
С чего ты взял, что не нужно. Может быть это редактор, делающий нечно, что невозможно сделать никакими другими способами. Пусть он подтормаживает, но зато хоть как-то это делает. Гораздо хуже, если бы он делал быстро, но не то, что нужно.
IT>>Какие ещё наборы? А как насчёт приоритетов внутри наборов? В общем, это всё усложнение на ровном месте. GZ>Нет. Упрощение. Фактически мы видим набор целей важных для пользователя и не особо важных. Набор требований без которых пользователь будет считать проект неуспешным, и набор требований которые пользователи может перетерпеть.
Зачем такие усложнения? Функциональные требования всегда являются целями.
IT>>Формализм здесь вообще не может работать в принципе, т.к. требования сами по себе есть суть предпочтениях, а значит никакой классификации не поддаются. Даже разделение на функциональные и нефункциональные весьма условно. GZ>Оно точно. Второй раз писать почему?
Напиши
IT>>Это ошибочное мнение. Существует вещи, которые не являются ни функциональными, ни нефункциональными требованиями, они даже нафиг не сдались ни юзеру, ни заказчику, тем не менее они являются первостепенными целями. GZ>Например?
Например, сопровождаемость.
GZ>>>Видишь ли, объектная модель — это не есть цель. Это средство. IT>>Я могу ещё раз привести пример с командой MS по надзору за согласованностью FW. GZ>Ссылку.
Было интервью на channel9 года три назад. Ссылка была кажется на www.theserverside.net.
IT>>Это какой тип требований? GZ>Концепция. Оно абстрактно. Неабстрактно и достижимо будет набор требований — что должны делать данные библиотеки.
Какая ещё концепция? Это можно быть требованием и целью разработки одной системы и может не быть требованием для другой.
IT>>Что здесь является функциональными требованиями? GZ>А что клиентская программа не может является пользователем системы?
Ну так приведи пример требований для программы, пользователями которой являются другие программы.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>С чего ты взял, что не нужно. Может быть это редактор, делающий нечно, что невозможно сделать никакими другими способами. Пусть он подтормаживает, но зато хоть как-то это делает.
Если он что-то делает лучше, но на нем плохо редактировать, то не стоит называть его редактором. Минимум — имиджевые потери. Максимум — отсыл пользователем к такой-то матери.
IT>Гораздо хуже, если бы он делал быстро, но не то, что нужно.
Вот для этого и стоит определять что нам нужно быстро делать, что не столь важно, а на что вообще не стоит обращать внимание и бить разрабочика по ковырялкам если его заносит.
IT>Зачем такие усложнения? Функциональные требования всегда являются целями.
Безусловно. Но функциональные цели также имеют приоритеты. Ну например, на RSDN — если я нажимаю на "рейтинг активности" — то в результате получаю ошибку timeout. И никто не плачет, поскольку цель редкоиспользуема и маловажна. Ее вполне можно убрать, привлекательность сайта не уменьшится. Если то же самое будет при просмотре сообщения или статьи — думаю здесь вообще ни одного посетителя не останется. Также и с клиентами. Если ты сможешь определить маловажные цели, то если не успеваешь по срокам их вполне можно опустить. Это не слишком понизит бизнес-привлекательность решения. Если не сделать хоть одну высокоприоритетное требование — это будет считаться провалом проекта.
GZ>>Оно точно. Второй раз писать почему? IT>Напиши
Функциональные требования — это достаточно строгая конструкция которая определяет сценарии/действия пользователя.
Нефункциональные требования — все остальные требования к программе.
IT>Например, сопровождаемость.
Сопровождаемость в разных задачах значат разные вещи. Что ты в данном случае имеешь ввиду под сопровождаемостью?
IT>Было интервью на channel9 года три назад. Ссылка была кажется на www.theserverside.net.
Сейчас посмотреть не могу, потом когда будет возможность.
IT>>>Это какой тип требований? GZ>>Концепция. Оно абстрактно. Неабстрактно и достижимо будет набор требований — что должны делать данные библиотеки. IT>Какая ещё концепция? Это можно быть требованием и целью разработки одной системы и может не быть требованием для другой.
Это может быть требованием другой системы, и обозначать совершенно разные вещи. Ну смотри — твое требование:
Обеспечение интерфейса для поступа внешних систем.
О чем говорит это требование? Да ни о чем. Может быть целью этого требования получение объекта по идентификатору и все оставшееся время мы можем париться на Канарах. А может быть клиенту нужны ad hoc запросы и без этого он работу не примет. И в результате при выполнении этого требования мы получим гемморой который будет стоить больше чем вся остальная часть программного продукта. При такой постановке требования — нет достижимой и ясно понимаемой цели которую возможно достигнуть.
IT>>>Что здесь является функциональными требованиями? GZ>>А что клиентская программа не может является пользователем системы? IT>Ну так приведи пример требований для программы, пользователями которой являются другие программы.
Ну так я и написал. Не нравится термин "пользователь", замени его на термин "пользовательская программа" или еще как-то. Смысл не меняется.
Здравствуйте, GlebZ, Вы писали:
IT>>С чего ты взял, что не нужно. Может быть это редактор, делающий нечно, что невозможно сделать никакими другими способами. Пусть он подтормаживает, но зато хоть как-то это делает. GZ>Если он что-то делает лучше, но на нем плохо редактировать, то не стоит называть его редактором. Минимум — имиджевые потери. Максимум — отсыл пользователем к такой-то матери.
А вот это не нам с тобой решать И само собой не на абстрактном примере.
IT>>Гораздо хуже, если бы он делал быстро, но не то, что нужно. GZ>Вот для этого и стоит определять что нам нужно быстро делать, что не столь важно, а на что вообще не стоит обращать внимание и бить разрабочика по ковырялкам если его заносит.
И в чём проблема? Мы же вроде как говорим о приоритетности одних требований над другими
IT>>Зачем такие усложнения? Функциональные требования всегда являются целями. GZ>Безусловно. Но функциональные цели также имеют приоритеты. Ну например, на RSDN — если я нажимаю на "рейтинг активности" — то в результате получаю ошибку timeout.
Это баг, а не цель. Этот баг нужно просто исправить и всех делов, хотя похоже там дело в железе.
GZ>И никто не плачет, поскольку цель редкоиспользуема и маловажна. Ее вполне можно убрать, привлекательность сайта не уменьшится. Если то же самое будет при просмотре сообщения или статьи — думаю здесь вообще ни одного посетителя не останется. Также и с клиентами. Если ты сможешь определить маловажные цели, то если не успеваешь по срокам их вполне можно опустить. Это не слишком понизит бизнес-привлекательность решения. Если не сделать хоть одну высокоприоритетное требование — это будет считаться провалом проекта.
Ты говоришь совершенно о другом. Я говорил о приоритетах при принятии конкретных решений при реализации той или иной функциональности. Ты же пытаешься свалить всё в одну кучу и тем самым усложнить весь процесс. Меня этот вопрос сейчас вообще не интересует.
GZ>
Функциональные требования — это достаточно строгая конструкция которая определяет сценарии/действия пользователя.
Это примерно тоже самое, что "Функциональное требование — это предложение, записанное на бумаге". В таком смысле да, это строгая конструкция. Но любые функциональные требования базируются на предпочтениях человека их составялющих, а значит не могут быть чётко категоризированы. К каким, например, категориям относятся требования к тёплости и мякгости?
GZ>Нефункциональные требования — все остальные требования к программе.
А как же концептуальные требования?
IT>>Например, сопровождаемость. GZ>Сопровождаемость в разных задачах значат разные вещи. Что ты в данном случае имеешь ввиду под сопровождаемостью?
Готовность системы к будущим изменениям.
IT>>Какая ещё концепция? Это можно быть требованием и целью разработки одной системы и может не быть требованием для другой. GZ>Это может быть требованием другой системы, и обозначать совершенно разные вещи. Ну смотри — твое требование: GZ>
Обеспечение интерфейса для поступа внешних систем.
GZ>О чем говорит это требование? Да ни о чем. Может быть целью этого требования получение объекта по идентификатору и все оставшееся время мы можем париться на Канарах. А может быть клиенту нужны ad hoc запросы и без этого он работу не примет. И в результате при выполнении этого требования мы получим гемморой который будет стоить больше чем вся остальная часть программного продукта. При такой постановке требования — нет достижимой и ясно понимаемой цели которую возможно достигнуть.
Так именно это и является целью — обеспечение интерфейса для внешних систем
IT>>>>Что здесь является функциональными требованиями? GZ>>>А что клиентская программа не может является пользователем системы? IT>>Ну так приведи пример требований для программы, пользователями которой являются другие программы. GZ>Ну так я и написал. Не нравится термин "пользователь", замени его на термин "пользовательская программа" или еще как-то. Смысл не меняется.
Меняется очень сильно. В зависимости от "замени, если не нравится" у тебя будет совсем другая реализация.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
