Я пробовал несколько инструментов, например theBrain — позиционируется ровно для этого, но мне показался не слишком удобным, т.к. мне требовалось навешивать определенную семантику на связи, а у них связи только двух типов — вертикальные и горизонтальные. По крайней мере были таковыми 2 года назад, может быть что-то изменилось.
Сейчас для анализа подобных вещей использую Enterprise Architect. В нем помимо рисования диаграмм есть возможность просматривать иерархию связей, причем связи группируются по типам. В зависимости от задачи на разные типы связей накладываю определенную семантику (приходится держать её в голове), рисую диаграммы по разным аспектам задачи, потом анализирую иерархию связей для каждого объекта.
В принципе, натолкнули на мысль об интересной статье — использование EA для анализа технического задания (я как раз сейчас этим занимаюсь :-) ). Как карма позволит, обязательно запостю.
SVN — бесплатное решение.
есть много бесплатного хостинга SVN, пригодного не только для opensource решений.
для Git бесплатного облачного хостинга с ограничением доступа я не нашел :-(
Ага, вот так что-нибудь сделают хуками, а пользователи потом третируют разработчика исходного софта — откуда, дескать, у меня там глюки. У нас был пример несколько лет назад. В программе использовался встроенный движок скрипта для автоматизации некоторых действий. Касперский со своими хуками влезал, чтобы проверить этот скрипт и вылетал с громким треском (он-то думал, что это Internet Explorer...). А выглядело так, что на ровном месте падает наша программа.
Даже догадываюсь почему. Всякие хакеры давно облюбовали винду для испытания всяких гадостей. Вполне естественно, что мелкософт с этим посильно борется, повышая планку сложности реализации хука. Т.е. реализовать хук либо сложно, либо дорого :-).
Редактор маршрутов в ЕВФРАТ — это собственная разработка. Позволяет строить сколь угодно сложные (в т.ч. циклические) маршруты, состоящие из узлов определенных типов. Узлы бывают «человековыполняемые» — такие как поручение, согласование, ознакомление, а бывают «системовыполняемые» — ветвление (по условию), задержка, синхронизация.
Сам редактор встроен в клиентское место. Маршрут может быть общедоступный и использоваться повторно, также можно рисовать индивидуальные маршруты для каждого документа.
Вложенные списки от mindmap отличаются примерно как RTF от Plain text. В картах добавляется свобода передвижения узлов, навешивание ярлычков. Невольно стараешься оформить карту так. чтобы она не только отражала структуру, но и радовала глаз. Представленная таким образом информация лучше воспринимается.
Впрочем, я где-то читал или слышал (источник не помню) про исследование эффективности всех думательно-помогательных инструментов типа ментальных карт и прочих подобных конструкций. Так вот, было замечено, что на эффективность мышления и скорость принятия решений они практически не влияют!
Со своей стороны могу сказать следующее. Когда года три назад я наткнулся на статью про ментальные карты, а потом попробовал ими пользоваться — мне казалось что на меня сошло вдохновение. Я подсадил на них всех окружающих, использовал их и для управления задачами и планов презентаций, анализа техзаданий и многого другого. Через какое-то время (видимо мозг размялся и разработался) я стал с меньшим усилием умещать в голове иерархические конструкции и мне уже не всегда требования инструмент для рисования карт, хватало простого наброска в текстовом файле. Но, как говорится, аппетит приходит во время еды — захотелось мыслить более сложными категориями, не только иерархиями, но и сетями связей. Причем иметь возможность представить подмножество связей сети в виде иерархии по какому-то срезу. Такого инструмента, к сожалению, пока не нашел :-(. Придется, видимо, в какой-то момент сделать :-).
Приятно слышать что у кого-то это получилось.
Честно говоря, у меня не получилось использовать календарный метод планирования :-(, я в итоге остановился на комбинации календаря и MLO. Чаще всего проще оперировать со стеком задач, и только некоторые ставлю в календарь — те, которые просто нельзя двигать. И ничего не приходится передвигать на следующую неделю — оно само ползет! :-)
Да даже если apple и не пропустит. Точнее — как раз если не пропустит, то будет особенно уместно выпустить для андроида. Дескать, не хотите конкуренции — так получите ;-).
С уверенностью утверждаю, что СУБД Ники там не осталось :-(
Однако сохранена концепция работы со сложноструктурироваными данными, которая выросла именно из Ники. Одним из результатов является подсистема, которая позволяет работать с иерархическими данными, а хранить их при этом в реляционной СУБД. Впрочем, не обязательно в реляционной.
Именно эта система позволяет говорить о кроссплатформенности ЕВФРАТ Е1 в смысле используемой СУБД.
*Долго думал
Давайте чуть-чуть проанализируем. Чем плохо использование атрибутов по сравнению со словарем?
Судя по всему — только производительностью
Чем плохо использование словаря по сравнению с атрибутами?
На этот вопрос я долго не мог ответить даже для себя. Было только подсознательное ощущение какой-то неправильности. Наконец осознал. Проблема чисто организационная — информация о присоединенных атрибутах находится в стороне от объявления элементов перечисления. Таким образом, если когда кто-то будет добавлять элементы перечисления, то он может не сходу увидеть, что атрибуты добавляются где-то еще. Т.е. имеет место небольшое нарушение принципа DRY: каждый элемент перечисления нужно продублировать в инициализаторе словаря.
Вариант решения
В итоге мне кажется разумным использовать комбинированный вариант, а именно, писать метаданные в атрибуты, но завести словарь, информация в который загружается в процессе выполнения(например, в статическом конструкторе класса-расширения). Это обеспечит нужную производительность и сохранит прозрачность кода.
Да, наверное в случае когда нужно привесить одну строку такой вариант можно использовать.
Разница, наверное, не столько в читаемости, сколько в гарантии неизменности словаря.
Хотя был случай, когда я как раз такой словарь и использовал, а наполнялся он в процессе работы программы.
Насчет производительности ничего не могу сказать, но я не думаю, что конкретно в этом случае reflection сильно медленнее словаря, надо будет померять при случае.
Сейчас для анализа подобных вещей использую Enterprise Architect. В нем помимо рисования диаграмм есть возможность просматривать иерархию связей, причем связи группируются по типам. В зависимости от задачи на разные типы связей накладываю определенную семантику (приходится держать её в голове), рисую диаграммы по разным аспектам задачи, потом анализирую иерархию связей для каждого объекта.
В принципе, натолкнули на мысль об интересной статье — использование EA для анализа технического задания (я как раз сейчас этим занимаюсь :-) ). Как карма позволит, обязательно запостю.
есть много бесплатного хостинга SVN, пригодного не только для opensource решений.
для Git бесплатного облачного хостинга с ограничением доступа я не нашел :-(
Сам редактор встроен в клиентское место. Маршрут может быть общедоступный и использоваться повторно, также можно рисовать индивидуальные маршруты для каждого документа.
Впрочем, я где-то читал или слышал (источник не помню) про исследование эффективности всех думательно-помогательных инструментов типа ментальных карт и прочих подобных конструкций. Так вот, было замечено, что на эффективность мышления и скорость принятия решений они практически не влияют!
Со своей стороны могу сказать следующее. Когда года три назад я наткнулся на статью про ментальные карты, а потом попробовал ими пользоваться — мне казалось что на меня сошло вдохновение. Я подсадил на них всех окружающих, использовал их и для управления задачами и планов презентаций, анализа техзаданий и многого другого. Через какое-то время (видимо мозг размялся и разработался) я стал с меньшим усилием умещать в голове иерархические конструкции и мне уже не всегда требования инструмент для рисования карт, хватало простого наброска в текстовом файле. Но, как говорится, аппетит приходит во время еды — захотелось мыслить более сложными категориями, не только иерархиями, но и сетями связей. Причем иметь возможность представить подмножество связей сети в виде иерархии по какому-то срезу. Такого инструмента, к сожалению, пока не нашел :-(. Придется, видимо, в какой-то момент сделать :-).
Честно говоря, у меня не получилось использовать календарный метод планирования :-(, я в итоге остановился на комбинации календаря и MLO. Чаще всего проще оперировать со стеком задач, и только некоторые ставлю в календарь — те, которые просто нельзя двигать. И ничего не приходится передвигать на следующую неделю — оно само ползет! :-)
Однако сохранена концепция работы со сложноструктурироваными данными, которая выросла именно из Ники. Одним из результатов является подсистема, которая позволяет работать с иерархическими данными, а хранить их при этом в реляционной СУБД. Впрочем, не обязательно в реляционной.
Именно эта система позволяет говорить о кроссплатформенности ЕВФРАТ Е1 в смысле используемой СУБД.
Давайте чуть-чуть проанализируем.
Чем плохо использование атрибутов по сравнению со словарем?
Судя по всему — только производительностью
Чем плохо использование словаря по сравнению с атрибутами?
На этот вопрос я долго не мог ответить даже для себя. Было только подсознательное ощущение какой-то неправильности. Наконец осознал. Проблема чисто организационная — информация о присоединенных атрибутах находится в стороне от объявления элементов перечисления. Таким образом,
есликогда кто-то будет добавлять элементы перечисления, то он может не сходу увидеть, что атрибуты добавляются где-то еще. Т.е. имеет место небольшое нарушение принципа DRY: каждый элемент перечисления нужно продублировать в инициализаторе словаря.Вариант решения
В итоге мне кажется разумным использовать комбинированный вариант, а именно, писать метаданные в атрибуты, но завести словарь, информация в который загружается в процессе выполнения(например, в статическом конструкторе класса-расширения). Это обеспечит нужную производительность и сохранит прозрачность кода.
Э… насколько я помню, НИКА немножко не иерархическая СУБД
Разница, наверное, не столько в читаемости, сколько в гарантии неизменности словаря.
Хотя был случай, когда я как раз такой словарь и использовал, а наполнялся он в процессе работы программы.
Насчет производительности ничего не могу сказать, но я не думаю, что конкретно в этом случае reflection сильно медленнее словаря, надо будет померять при случае.
Но мне кажется что в глобальном смысле разумнее развивать покрытие сети, чем офлайн навигаторы.