Собственно написав пару программных систем, и начитавшись умных книжек, задался вопросом как правильно проектировать. Какие есть средства? Какие стандарты? UML панацея или нет? Сижу сейчас над написанием новой проги, к делу подхожу основательно – в редактор слепо не бросаюсь, пытаюсь все изобразить как, что с чем будет взаимодействовать и наследоваться. Но все довольно сумбурно, я уже в своих записях путаюсь.
Подскажите как вообще правильно подходить к этому вопросу?
19 февраля 2010 в 10:00
>> Ну мало ли что они думают…
Убило=)))
18 февраля 2010 в 20:01
> закачик думает, что это будет осуществляться так, а программист совершенно по другому, – для этого и делается точное описание.
Ну мало ли что они думают, это редко определяет архитектуру ПО. Собственно в гибких методологияхкак раз все делается для того чтобы подобные вещи не документировать, а обговаривать устно и дешево менять.
18 февраля 2010 в 19:01
капитан очевидность детектед
Буду курить UML, спасибо
18 февраля 2010 в 14:05
eUML – unified modeling language.
18 февраля 2010 в 13:02
>> а последовательность действий пользователя – это не так важно, их
>> можно менять.
Как раз, это очень важно: разные люди по разному видят эту последовательность: закачик думает, что это будет осуществляться так, а программист совершенно по другому, – для этого и делается точное описание.
>> Но ты вроде в серьезной конторе работаешь, вы там как доку
>> оформляете?
У нас используется UP, поэтому довольно много артефактов. Из диаграмм UML используется:
диаграмма классов, диаграмма компонентов, диаграмма взаимодействия, Data flow, Use case – все они делаются как общие по проекту, так и по конкретным частям (если это требуется). Есть ещё общий doc-документ, где ведётся описание всей архитектуры.
17 февраля 2010 в 18:00
#18>>>Кроме того, никто не заставляет придерживаться официальных нотаций, главное, что бы было понятно тебе и твоей команде.
Я то так и делаю для uml юзаю Dia, и вобще там всякие схемки рисую или от руки.
Но ты вроде в серьезной конторе работаешь, вы там как доку оформляете?
ЗЫ для UML вроде было чото в эклипсе, но последний раз я наставил плагинов и оно было жутко неповоротливым, до умл не добрался.
17 февраля 2010 в 13:04
> Кстати, для NetBeans есть неплохой UML-плагин
Вроде как больше нет, его выкинули из нетбинса, вроде какраз потому что считали его недостаточно хорошим и советовали вместо него VisualParadigm
> Основную ценность представляют даже не сами Use Case- диаграммы, а модель прецедентов (или сценариев)
Ну хз, имхо как раз сами юзкейсы чуть ли не самая полезная диграмма, так как именно она описывает функции продукта.
а последовательность действий пользователя – это не так важно, их можно менять.
17 февраля 2010 в 13:00
Жень, полностью UML мало кто знает, да это и не нужно, так как обычно используется небольшое количество диаграмм. Кроме того, никто не заставляет придерживаться официальных нотаций, главное, что бы было понятно тебе и твоей команде.
Кстати, для NetBeans есть неплохой UML-плагин – он даже код может генерить, но, если не ошибаюсь, только Java.
>> Use Case – то, что можно будет делать с вашей прогой, изображенное в >> виде диаграмки.
Основную ценность представляют даже не сами Use Case- диаграммы, а модель прецедентов (или сценариев), в которой подробно описано, что и в какой последовательности происходит с точки зрения пользователя.
16 февраля 2010 в 19:00
> Прежде всего я не против UML юзаю его, но не в полнуюмеру(не знаю я его)
Ну лично я считаю что юмл можно спокойно перевирать по вашему усмотрению – главное чтоб вас поняли.
> Расшифруйте пожалуста юзкейсы и HLD
Use Case – то, что можно будет делать с вашей прогой, изображенное в виде диаграмки.
HLD = High Level Design- архитектура, но на очень высоком уровне. типа что есть клиент, а есть сервер, причем сервера три и каждый из них делает то-то и то-то
16 февраля 2010 в 18:02
Прежде всего я не против UML юзаю его, но не в полнуюмеру(не знаю я его). А госты вобще есть проги же сдаются, в приемку заказчику плюс внутреняя дока, когда все происходит как описано в посте #6.
#14 Расшифруйте пожалуста юзкейсы и HLD
16 февраля 2010 в 13:05
В Agile диаграммы классов – расходный материал – они меняются чуть ли не каждый день. Вообще, имхо, диаграммы классов стоит только генерить по коду на ходу, смотреть что где,устранять лишние зависимости и выкидывать.
16 февраля 2010 в 13:05
Диаграммы классов – расходный материал в любых итерационных методологиях. Тут как раз очень полезно обратное проектирование. Но изменять их каждый день – это уже перебор=)
16 февраля 2010 в 13:01
Всё зависит от размера приложения:
– если это небольшой сайтик, который делает один человек за пару недель, то там можно даже без юзкейсов
– если работает больше двух человек и несколько месяцев, то будет очень сложно без проектирования
А вообще диаграмма классов (компонентов), висящая на стене, очень сильно помогает при разработке: сразу видишь, что и как работает.
16 февраля 2010 в 10:03
> Даже в Агильных методологиях предполагается, что перед кодированием есть фаза проектирования.
Не, ну разумеется какое-то проектирование нужно. юзкейсы, HLD, но не более того.
16 февраля 2010 в 10:00
>>be Agile. Пишите чтоб работало – потом рефакторьте, как завещал >>Фаулер. остальное придет с опытом.
Даже в Агильных методологиях предполагается, что перед кодированием есть фаза проектирования (на бумаге или в редакторе – не важно).
Перед кодирование очень помогают разобраться Sequence diagramm, диаграмма классов и предметной области – эти три вещи, на мой взгляд, должны быть обязательны.
Хороший UML-редактор это Enterprise Architect, но он платный;)
15 февраля 2010 в 23:04
Леонид, ну в принципе они сами могут и не кодить, правда это прошлый век.
15 февраля 2010 в 23:04
я к тому, что их время стоит существенно дороже.
15 февраля 2010 в 23:04
А я к тому что они вообще не нужны)
15 февраля 2010 в 23:04
ну, это уже зависит от масштабов производства.
15 февраля 2010 в 23:03
а если подойти к вопросу филосовски
то
[quote]любое знание формирует мышление человека в рамках этого знания и мешает выходу мысли за пределы этого знания[/quote]
моё мнение: главное чтобы ПО мало весило и быстро работало. а вот какие там алгоритмы – это на совести программиста.
15 февраля 2010 в 23:03
be Agile. Пишите чтоб работало – потом рефакторьте, как завещал Фаулер. остальное придет с опытом.
На самом деле никто не знает как правильно проектировать, если конечно он не писал до этого что-то аналогичное, впрочем даже это редко спасает.
А с учетом реальности, в которой требования меняются каждую неделю – сильно увлекаться проектированием(таким когда люди сидят и целыми днями чертят диаграмки даже не думая начать кодить) – пустая трата времени.
15 февраля 2010 в 23:03
Николай, такие люди не должны кодить
они чертят, другие люди описывают, а кодят уже третьи 
)
15 февраля 2010 в 23:02
карандаш, бусажка и голова
а все остальное – только их заменители
15 февраля 2010 в 23:02
а почему вам не нравиться юмл ? Тем что там не все так строго и однозначно ?(можно по разному описать, опускать детали).
Могу сказать свое ощущение, что четкое понимание проекта у меня сразу не появляется, а в процессе только, есть грубое, и в процессе кодинга, оно становиться более четким.
Да в любом проекте меняется архитектура, не значительно но все же. Нельзя заранее все продумать, все мелочи и детали