- ksacvet777
- Постоялец
Надо б тогда определиться: что означает стрелка , а что просто соединительная линия.
Вот например, что стрелка означает ??
наследование, использование, проекто(кодо)-зависимость ?
По мне , так полезнее было бы видеть диаграммы "кодо-зависимости", например блок А зависит от блока Б, то есть если перешишешь блок Б, то придётся переписывать и блок А. Блок А в этом случае можно переписывать (переделывать) и это не затронет блок Б.
Вот такая диаграмма проектировочной зависимости была бы полезнее.
Вот : "взбредшая" в голову идея: диаграммы вообще-то хорошая штука и на интуитивном уровне этот визуальный метод стоит применять, но... они получаются неудобные и громоздкие ((
идея: было бы хорошо если диаграммы были бы не в виде 2-х мерных картинок , а в виде ТРЁХ-МЕРНОЙ диаграммы (диаграммы в трёхмерном пространстве).
Сами знаете , что такое 3-д и какие фишки можно бы было реализовать.
чукча все-таки не читатель ( казалось бы, при чём здесь делфи?
Z
> P.S.: Въдрано из документации движка...
так-так-так :)
и кто прикалывался над моим скромным пожеланием иметь описание (грубое) движка в виде диаграммы(м) ( схем )?
недавно перевели на новый проект - опять те же грабли :)
Вий
Не соглашусь про первый опыт, может я исключение, но первое проектирование у меня было ужасно и именно по этому я не перестал этим заниматься, а наоборот озадачился как бы сделать так, чтобы всё было не так плохо, как в первый раз.
А всё-таки, вот в рассуждениях всё гладко, а как на практике? Сколько проектов делалось по этой методологии, сколько из них доведены до конца, сколько в срок (это не стёб, реально интересно).
ksacvet777
Ну дак человек не может в уме держать больше 5-6 объектов одновременно. Надо просто рассматривать в одно и то же время не всю диаграмму, а интересующую в текущий момент часть и не пытаться размышлять обо всём, а как-то постепенно и планомерно.
ksacvet777
>> Надо б тогда определиться: что означает стрелка , а что просто соединительная линия...
Уже довольно давно определились. Есть великолепный стандартизированный язык проектирования. Называется UML.
И все те типы диаграмм, которые здесь обсуждаются, в него входят. Каждая используется для своей цели.
Wolshebnik
А тебе UML-диаграмма когда-нибудь реально помогла ?
ksacvet777
> А тебе UML-диаграмма когда-нибудь реально помогла ?
Мне помогала, конечно если она нормально сделана а не от балды :)
Более того в нынешнем проекте на работе сделан лог который автоматически строит сиквенс диаграммы для звонков, где указаны все участвующие в разговре стороны, абоненты, мультимедия серверы, управляющие серверы, БД, а стрелочки описывают обмен сообщениями. Жмёшь на любую стрелочку и видишь какие данные были отправлены, сразу виден протокол, кто кому чаво пересылал, с какими настройками и т.п. Офигенно удобно.
Phoenics, выложишь скрин, ради теоретического интереса?
Phoenics
> Более того в нынешнем проекте на работе сделан лог который автоматически строит
> сиквенс диаграммы для звонков
это не имеет отношения к проектированию... но уверен что оно сильно помогает в отладке...
Amber
в моём IE8 это выглядит вот так: http://imglink.ru/show-image.php?id=0ee1f5d16cd447e29efe2424c5b746fa
Pushkoff
> это не имеет отношения к проектированию... но уверен что оно сильно помогает в
> отладке...
это да, но я например всегда всё проектирую перед реализацией, в том числе и схемы рисую, ну кроме совсем уже тривиальных вещей и проходного кода (например тестового).
Забавно =)
Собрался народ из двух типов компаний и спорят о необходимости проектирования и возможности обойтись без него )
Это как если бы ВАЗ и Астон Мартин спорили о подходах к созданию машин, не заморачиваясь о том, что у них машины разные и рынки сбыта не совпадают.
Всех всё устраивает, у всех всё работает. С одним маленьким НО: Астон Мартин задорого соберёт жигули, а ВАЗ не соберёт Астон Мартин никогда.
Glok
по моему тут никто не говорил, что проектирование не нужно... тут стоит вопрос о полезности диаграмм и их типов на этапе проектирования...
судя по всему первый раз некоторым теоретикам вообще не грозит.
> Так, для реализации всей игры в виде 1 большой функции с кучей goto свойственна высокая производительность кода и еще более высокая сложность его
>написания и поддержки
такое представление о коде игры далеко от настоящего, как счетные палочки от уравнений математической физики.
человек, ничего не спроектировавший, вещает о том "что значит проектировать системы". что, в общем, довольно забавно.
для того, чтоб собрать астон-мартин нужны как-бы не только его чертежи.
нужны соотв. квалификации рабочие, нужны технологии производства всех частей с необходимым качеством. материалы опять-же.
А то получается, что таз-у не хватает только чертежей )
Тут-же скорее о том как у одних машины делают, а у других "пока наши корабли бороздят просторы вселенной".
Вий
я расскажу...
проектировал и писал ОС для диплома. около 6 месяцев, хотя идея жила во мне несколько лет...
начинал писать инклюды, в них имена функций и предполагаемые параметры, естественно без реализаций...
потом писал что зачем вызывается и откуда берет данные, в виде пояснительных записок ко всяким практикам и научным работам... в ходе этих описаний выяснялось где я не прав и переписывал инклюды и то что их затрагивает... многое держал в уме, так как не знал как это представить схемотически...
сделать все так как хотелось не хватило времени, но в целом проектирование считаю успешным, так как выработанная идея практически не менялась в ходе набивания кода... на набор кода ушло около 3 месяцев (причем эти 3 месяца приходилось совмещать с работой)... то что я считал основными моментами (многозадачность и примитывы синхронизации) я реализовал...
диаграммы и блоксхемы для диплома строил по уже рабочему коду...
Тема в архиве.