Вопрос разработчикам ПО: средства описания структуры программы

компьютеры программирование ПО разработка

Vindicar, 303 просмотра

Пользуетесь ли вы какой-либо программой для описания структуры создаваемого ПО?
И как именно вы описываете эту структуру?
* Делаете полноценные диаграммы классов, событий и прочего средствами UML?
* Или обходитесь заметками на манжетах и сигаретных пачках (ну или в Блокноте/в комментариях к коду)?
* Или же пишете код, держа всю структуру в голове?
* Слышал про применение для этой цели интеллект-карт... есть ли те, кто пробовал?

Примечание:
alexxksys
То есть вы утверждаете что имеет смысл применять интеллект-карты для описания структуры ПО? Хорошо, посмотрим что это за зверь такой...

Примечание:
bungholio
>>>Полноценные диаграммы довольно часто
Непосредственно в процессе разработки? По моему скромному опыту, пока формализуешь своё представление в конкретный тип диаграмм, можно забыть что ты, собственно, разрабатываешь.
>>>А, да, кейворды
Спасибо. Попробую ваш вариант тоже.

Примечание:
bungholio
Это всё хорошо. Осталось научиться это применять...
Спасибо за ответ, в любом случае.

Ответы:

Alexandr Xks

Держать всё в голове не очень удобно, т.к. не занимаюясь проектом какое-то время теряется много информации.
Касательно mind-maps существуют неплохие программки Mindjet MindManager и MindMapper.
Очень удобны для описания проекта, от объектной модели и до самих форм.

Без имени

Да.
Полноценные диаграммы довольно часто
На манжетах обычно "прикидки", "почеркать", когда вообще неясно куда двигаться.
В голове избегаю держать, в итоге бардак получается.
"интеллект-карта" = mind map? (если да, то русский эквивалент термина на редкость неудачен) если да, то пробовал, но не проникся, видимо манжеты лучше. Набросок после формализации превращается в нормальную диаграмму.

Без имени

(что-то я сморозил с кнопками "ответить"/"дополнить")
RE: Дополнение #2
Примерно так:
1. Проектирование на манжетах (ТЗ это же по сути дела большая такая манжета)
2. Формальное проектирование (здесь уже производится документация)
3. И собственно написание кода (возвращаясь время от времени к 2, shit happens)
соответственно, возврат из состояния 2 в 1 это FAIL и всеми силами следует избегать...
>>>в конкретный тип диаграмм, можно забыть
Это в любом случае придется делать, рано или поздно, лучше рано, потому что если, тем паче, уже будет какой-то код написан - скорее всего он окажется в блочном комментарии, в лучшем случае, после чесания в затылке, получится что, половину метода (например) надо перенести в абстрактный класс, а остальные две трети реализовать в разных потомках (сумбур и хаос)
Я убежден, что переход 2 -> 1 = потеря времени и сил.

Kipp

UML.

15 лет назад

RPI.su - самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.

Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.

Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.