Russian Qt Forum

Хочу написать приложение для кафе. Оно будет содержать разделы с информацией о меню, счетах, ингридиентах итд итп. Тоесть нужна какая-то модульная разработка... В качестве базы данных будет использоваться MySQL.
Вот и хочу спросить об извечной проблемме разделения логики и интерфейса... Как лучше спроектировать? Какие классы разработать? Или может что-то особенное из qt можно использовать? Куда запихнуть все селекты и апдейти?
Заранее благодарен за советы.

Есть же класс QCafeApp
 ;)

слишком абстрактный вопрос.

Ещё один POS? начните с постановки задачи, что вы вообще хотите сделать. и лучше - поиска потенциального заказчика и понимания его потребностей.

В программе вся информация заносится в БД. База данных mysql, как и говорил выше.
Главное меню примерно такого вида:
1. Склад
2. Расходы
3. Статистика
4. .....
Где в "Складе":
1. Информация о товарах: наименование, к-во.
2. Редактирование товаров: создание новых наименований, удаление, редактирование итд.
3. Возможность проводить закупки: к-во товара соответственно увеличивается..

"Расходы":
1. Блюда: удаление, редактирование и создание блюд из товаров(ингридиентов)
2. Продажа блюд.

"Статистика":
К-во проданных блюд, к-во товара что ушел за выбранных период итд...

Т.е. будет много диалогов где будет табличка, например с блюдами, а сбоку кнопочки "добавить", "редактировать", "удалить".
Как можно это все дело акуратно спроектировать... ?

Себестоимость блюд считать будете? При приготовлении разные там коэффициенты усушки, ужарки и т.п. учитывать будете?
Аналоги при приготовлении будете поддерживать?(ну нет у нас "семги на суши, горбушу вон бери - тоже подойдет") А себестоимость при этом будет по другому рассчитываться?

Товар на складе учитывать по стоимости будете или по количеству? штучные/весовые товары?  операция инвентаризации будет? а то у нас бухгалтерия - она такая. её все сразу подавай. и по стоимости тоже.
Кстати выгрузку в 1С вы же сделаете?

Работать с оборудованием собираетесь? с какими типами оборудования? продавать вам без ФР/КАССЫ - это уголовка)
если да, то X-Z-отчеты нормально сниматься будут? печать ПКО/РКО?
Оплату карточками будете поддерживать?
Скидочные акции? по дням недели, по часам, по карточке постоянного клиента, скидки процентами, и скидки суммами?

Печать заказа на кухню вы будете печатать на 2 кухни сразу? а звоночек там звенеть будет? а я могу отослать коктейль на бар, который тоже такой-же пос как и этот? а семгу - на кухню?что будет если на баре пос сломался? или на него вот только что коньяк пролили и он сгорел нафиг? ваша программа сообразит где надо распечатать заказ?

А если у нас хаб сгорел нафиг вот только что сейчас.... ваша программа может работать автономно - без сети какое-то время?

Столики поддерживать будете? заказы перемещать/разделять между столиками можно? ("а то знаете - мы хоть и компанией пришли, но вот они будут за себя сами платить").

Услуги будете учитывать? ну там типа "бой посуды-300ру", "наблевать в туалете-500ру"?

работать с наладонниками будете? "у нас крутой кафе - официантки топлесс и с наладонниками заказ принимают"?

________________________________________________
разгребайтесь пока) а я потом ещё вам расскажу как оно бывает на самом деле)))))))))))

Есть такая проблема?  ;)
Если у вас образование выше среднего, посмотрите А. Якобсон, Г. Буч, Дж. Рамбо УНИФИЦИРОВАННЫЙ ПРОЦЕСС РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. Это в качестве примера того, что разработка программного обеспечения не сводится только к программированию. Есть еще анализ, разработка требований, проектирование и т.д. Считайте, что программирование - это последний этап разработки программы. Не думайте, что это насмешка. Если вы молоды и способны обучаться, привыкайте к правильной технологии разработки. Вы можете получить стопятьсот советов, но правильность принятых решений увидите не сразу.
Вам уже сказали, что вопрос абстрактный. Начните с анализа бизнес-процессов. Потом выработка требований...

Конечно как спроектировать и какие классы писать - никто не скажет. Но не такой уж он и абстрактный, этот вопрос.  Человек понимает: стоит начать "клепать формочки" - и все, дальше уже никакой "архитектуры" не будет (и выбора тоже).

Могу предложить так: делить все файлы проекта на 2 категории: A - использующие QtGui и B - не использующие. Группа A может вызывать любые ф-ции группы B, но не наоборот. Все запросы к СУБД должны быть только в "B". Это конечно очень грубо/примитивно, но гораздо лучше чем ничего.

BTW: утверждение "программирование = последний этап" верно только для (с треском) проваленных проектов  :) Программирование просто "не первый этап"

Смею читать это как A - QtGui+Qt_non_Gui  и B - Qt_non_Gui+прочее.?

не хочу даже думать о том что тут могут посоветовать делать работу с БД на QT, не используя QT-шные классы для БД ^_^)


Полностью согласен) итерационный (итеративный) процесс разработки рулит.
Но для него нужен хороший аналитик или хорошее аналитическое мышление - надо уметь выделять главное и второстпенное, приоретизировать запросы, закладыватаь хорошую архитектуру))))
могу посоветовать почитать RUP (http://ru.wikipedia.org/wiki/RUP) - осеньлублуиуфашаюяго)))

Очень благодарен за советы!
Насчет "А. Якобсон, Г. Буч, Дж. Рамбо УНИФИЦИРОВАННЫЙ ПРОЦЕСС РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ." - уже скачал, посмотрел и понял что это все правильно, но не очень практично. Т.е. я все понимаю: пользователи, архитектура, UML, тестирование и прочее. Но как бы здесь и сейчас мне нужна конкретика...
2 Denjs, ваш пост это бомба ))) Уже раз 5 перечитал и еще буду перечитывать )) Большое спасибо за информацию, много нового для себя нашел!
Со своей стороны могу добавить что можно сделать еще группы блюд. Штук, кг и литров должно хватать. Также разные информаторы о критическом наличии товаров сделать итд итп... Вариантов развития много.

Но сначала версия будет оооочень простенькой, т.к. банально человеку сейчас нужно просто знать сколько продуктов ушло на n пицц+каких то там еще блюд. Т.е. изначально простая версия с учетом возможности роста (они ведь такие: сначала сделай только это, а потом еще кучу разных плюшек которые изначально и не предусмотришь...)
Раз разговор зашел за стратегию разработки то я думаю здесь будет уместная политика экстремального программирования: и клиент рядом, и итерации небольшие итд итп...

Нееееет, )))  вы не понимаете))) пока непонимаете )
освойте управление требованиями с помощью Прецедентов Использования (UseCase) (<<<- это самое важное!), (и поймите что управление требованиями не заканчивается правтически вплоть до окончания внедрения), примите и начните выполнять основные принципы итерационной разработки (например что итерация заканчивалась релизом, который можно отдать клиенту, что итерации должны быть одинаковые по продолжительности, что у итерации всегда должен быть "план итерации", и задачи; что после итерации надо уточнить собвтсенное видение проекта и узнать у клиента - туда-ли мы движемся  ....), поймите что такое есть "исполняемая архитектура", то такое "веха целей", "веха исполняемой архтектуры", что такое "разработка отталвивающаяся от прецедентов" и "компонентно-ориентированная архитектура", и ... впрочем этого для начала будет достаточно.
(это я вам  говорю как аттестованый по RUP специалист, и просто системный аналитик  ;) )

и примерно через годик вы начнете успешно применять итерационую разработку на практике. Именно итерационную разработку. Не абыкакание, не самопал, а стройный, устойчивый процесс с прогнозируеым результатом и достижением целей проекта и удовлетворения потребностей клиента ))

Всегда пожалуйста. Через 3-5 автоматизированных кафе/магазина у которых 3-4 поса - вы начнете понимать то-же самое.
Главное - не путайте "абы-какание" с итерационным экстрим-программировнаием.
Первое часто называют вторым, и в итоге люди не доверяют экстрим программированию, хотя при нормальной готовке - блюдо вполне себе вкусное.

Кстати экстрим-программирование живет и не разваливаниется в абыкакиние только(!) при соблюдении ряда требований.
Одно из них - "автоматическое тестирование" (_полностью_ автоматическое!), подход "тест вперед", далее "парное програмирование",  понимание что такое user-story, и ещё немного чего сейчас не помню))). т.е. например с 1С экстрим-программировнаие практически не реализуемо . как минимум из-за невозможности нормального автоматического тестирования.
 (хотя тов. Белов и Ко успешно нанимали оутсорсеров со всей страны в 2004-2008 гг. и делали нечто подобное экстрим-программированию. что сейчас не в курсе)

Ежели пожелаете быть примерным учеником - могу выложить (если найду) "упрощенную методику итерационной разработки с применением элементов RUP". Она ориентирована на 1С, на малые участки работ (от 20 до 70 человеко-часов), полностью ручные операции (т.е. например нет автогенерации кода из UML-моделей) и монопольную разработку ("1 человек в команде"). Писана мною по итогам собственного фрилансерства в 2004-2006 гг.  По крайней мере не будете думать о том какие документы и как разрабатывать в первое время для управления требованиями.
но это если найду)

А зачем вообще изобретать велосипед? Есть же 1С.

>>А зачем вообще изобретать велосипед? Есть же 1С.
да, мне тоже не понятно. В 1С вроде и заготовки имеются, которые на современные кассовые аппараты можно нагрузить.

Есть пути решения по уму, а есть из разряда тяпнуть сейчас побыстрее. 1С - чаще всего попадает во вторую категорию. теперь по порядку.

во первых не "заготовки", "которые на современные кассовые аппараты можно нагрузить",
а конфигурации 1С-франчей. которые, смею сказать, стоят совершенно другие деньги чем 1С. "другие" - это как по тому факту что их надо платить отдельно (и дополнительно к стоимости 1С), так и потому что их сумма разительно отличается от самого 1С.


Во вторых далеко не всё можно успешно сделать на 1С.
Как только вы начинаете окунаться в детали, всплывает очень многоне очень приятных косяков.
В первую очередь это касается визуалных решений. Например редактор расположения столиков в зале - это отдельная "проблема" , которую часто решают заказным путем - в конфигураторе изменяют на форме расположение картинок.

Далее много чего, о чем я рассказал в #5 (http://www.prog.org.ru/index.php?topic=14904.msg98441#msg98441) - нет в конфигурациях для 1С. Во первых это огранияения платформы, а во вторых - трудность и стоимость обхода этих ограничений. Изобретать костыли для чужой программы - это гемор. Решения, которое позволяет вам динамически переключаться из онлайн-режима в оффлайн и обратно - например когда у вас сеть упала - это тоже отдельная лебединая песня,  в 1С этого нет. Хотя, кто-то может быть и смог сделать ещё один костыль, о у меня такой информации нет.

И исли уж говорит про кафе-рестора - есть R-Keeper и ряд других решений. а 1С в кафе на посах, или в ресторане - это зачастую ограниченное кастыльно-болезненное решение для тех кому жалко денег на нормальное решение.

Потому - пусть автор пишет. Может что  получится. Потому как 1С - в общем-то не сильно нужен. Даже если если подходит. Не говоря о том что 1С - убогая для программирования платформа с лоскутной логикой. из-за лоскутности и нелогичности - собственно убога, хотя да - там много чего есть. но все воняет лоскутностью - см выше)

Cмотрите немного дальше, чем текущий шаг, и текущая задача. Не надо портить мышление 1С-ом. От этого потом трудно отмыться.

ЗЗЫ: и аттестаты на конфигурироваyие 1С:Предприятие у меня тоже есть ;)
ЗЫ: мы на 1С автоматизировали не один год, не один маганзин и не одно кафе ;)

Поддерживаю. Не приходилось сталкиваться с 1С (бог миловал), но ситуацию знаю прекрасно. Использование "уже готовой системы" ну, не знаю как сказать... "опускает" программиста до уровня обслуживающего персонала.  "Да там все уже сделано, деньги заплачены, надо только приспособить" - таков ход мысли начальства/заказчика. А на деле часто совсем не так - половина не работает как надо. Светлая сторона "велосипеда" - решать самому вместо того чтобы зависеть от чужих решений и ошибок.

Было бы интересно посмотреть и подумать.

Меня как-то не тянет в сторону 1С. Это и сугубо личная неприязнь к монотонной бухгалтерской работе, ну и когда посмотрел как друг пишет эти русскоязычные запросы я понял что это не мое...
Поэтому лучше свое, маленькое и мобильное (как хочу так и ворочу).

ушел гуглить и курить доки....

нда, можно подумать программисты сами себе штаны шьют...
с таким подходом можно и без работы остаться...
ПС. Программист и есть обслуживающий персонал...
ПС2. Некоторые считают себя королями процесса, но шизофрения распространенное заболевание...

Вот когда вы сможете написать инструкцию для программитса, или превратить разработку ПО в конвеер (мечта идиота) -  вот тогда и вы и говорите про программистов как про обслуживающий персонал. Или когда обслуживающий персонал в большинстве своем должен будет иметь высшее образование... Вы путаете инженера и техника. Программисты в большинстве совем все-таки инженеры.

Я не поддерживаю Игоря в том, что "Использование "уже готовой системы" ну, не знаю как сказать... "опускает" программиста до уровня обслуживающего персонала." - это его "крайность", противоположенная вашей крайности. но согласен с ним что по результату.

имхо "1С - гроб программиста".

А в своем посте я только хотел сказать что 1С -крайне не логичная ситсема. 1С понять невозможно. Это надо зубрить. 1С в кишках - мерзок как логическа система. Это проектировал экономист, который считает что  раз в экономических теориях все надо тупо зубрить, - то и тут - можно прокатить на зубреже. (замечу - это никак не отменяет удобства многих объектов с точки зрения задач автоматизации - они покрывают то что нужно, и даже немного больше... но то как это делается... бррррр... >_< )

Вот Qt - он берется пониманием. Ты понял основные принципы и далее эти принципы и подходы работают во всем фреймворке. с 1С же - ты постоянно натыкаешься на костыли и "обходы". Я говорю о том как проектировали методы и о самом языке.

Как только программист начинает опускаться 1С - он начинает тупеть. Потому что ему приходиться тратиться на зубрежку, вместо понимания. "тут мы делаем копию объекта из обращаясь к источнику, а тут мы должны взять приемник и сказать ему - копируй себя из источника" - это разве логично?

Кроме того, что бы успешно освоить 1С - тебе надо забыть, целенаправлено забыть-вычистить-забанить все чему тебя учили в институте, в школе, на курсах. 1С - это особая стеза, колея со своими методами, подходами и решениями.

В тяжёлых случаях - 1С-овец перестает быть программистом и становится "конфигурастом". увы.
сам 1С называет процесс настройки концигурации "конфигурированием". Они не называют это "программированием".

Вот только и все) не позволяйте затягивать себя в 1С полностью. Целенаправленно работайте и программируйте на других языках тоже. Только так вы сможете сохранить гибкость ума и сможете сохранить возможность маневра - ввалившись в калею 1С выбраться будет трудно - вы просто не сможете перестроить своё мышление.

Хороший образчик бреда.
Я работаю с 1Сv7/1Сv8, С++, php, MS SQL и т.п.
Ничего там в 1С "непонятного" нет.
Все постижимо и в своей области пригодно.
Вы просто не имеете образования (читай ключа) к пониманию.
Я по специальности - бухгалтер-программист. Мне с пом. моих знаний достаточно легко разобраться с 1С-ными поделками.
Вы просто профнепригодны для такой работы. И не надо на "зеркало пенять, коли рожа крива".
ПС. Когда начал писать на Qt/С++ у меня возникли сложности в чтении кода. Но я их преодолел: нашел букварь по патернам и подкупил букварь страуструпа. Сложности исчезли.  Так что лучше ищите ключ к пониманию, а не брюзжите..

Это совершенно достаточно чтобы забанить на месяц (а лучше на 2). Надоело бухгалтерское хамство читать.
Слово за модераторами

Уважаемый... эээ.... panAlexey ....  бухгалтер-программист вы наш уважаемый)
скажите мне, глупому, каков, например, ключ к пониманию того, что для создания копии объекта - я должен в одном случае брать источник и говорить ему "выгрузи себя в копию", а в другом случае - брать копию, и говорить ей "загрузи себя из источника"?

Причем это идентичные по логике классы - СписокЗначений и ТаблицаЗначений.

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

увы,увы... в 1С, такой "ключик" используется повсеместно... и не надо мне рассказывать ... мы с вами (надеюсь оба?) аттестованные в 1С специалисты по конфигурированию.

Если ваш навык зубрежки, затмевает навыки анализа и понимание сути - ну... то я только рад за вас)
мои-же скиллы, навыки и природные способности имеют нескольок другой профиль и сосредоточены несколько в других областях... мне противны нелогичные системы, как камешек в дорогом ботинке. потому и 1С мне противен как нелогичное лоскутное одеяло.

(ещё раз повторю, что я говорю не про бизнес-методы, а про более базовые вещи, которые можно/нужно было бы продумать получше)
ps: Зубрежка без понимания - это гроб программиста. Это вырождение к безмозглому кодеру.
pps: рад за вас, что у вас хватает ресурсов заниматься не только 1С. Не скатывайтесь в 1с-ную колею - не выберетесь. Занимайтесь С++, php помимо 1С - и сможете сохранить гибкое мышление.

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

Судя по названию объектов это версия 1Сv77.
Язык 2 книги общим объемом ~500 страниц.
+ 1 книга "Конфигурирование и администрирование". ~250 страниц
Проглочены за 1 неделю, ибо КПД от чтения много выше чем задавать
глупые вопросы на форуме и получать плюхи за то что лежит на поверхности
и ждать ответов на вопросы.
Да, зубрежка и что? Потратил неделю и забыл.
Да, есть некоторые нелогичные вещи. И что? Где их нет.
Учитесь принимать данность с достоинством.

Вы знаете, когда человек говорит, что он за неделю прочитал 750 страниц убористого текста (т.е. 100 страниц технической информации в сутки) и понял хотя бы большую часть возникает подозрение, что он врет.

мало ли что возникает. В жизни и не такое случается..
У меня был стимул - мне досмерти надоели километровые расчеты в MS Excel, так что эти книги я буквально "пожирал".
Тем более надоела низкооплачиваемая работа и хотелось смыться из деревни в город, а там были нужны знания.
Тем более навык в программировании был получен еше в колледже: dBase & Pascal...
Так что начхать мне на то что вы верите или не верите. Главное - у меня получилось....

Браво, panAlexey!  :)

Что никак не отменяет убогости "кишков 1С" как "логичной системы", а только лишь отражает ваше согласие с имеющимся положением вещей и прокачанность ваших навыков зубрежки. правда?)))))))

рад за вас, что лично вас 1С не бесит.
но не надо выдавать вашу эйфорию, за качество продукта, с помощью которого вы (да и я тоже так делал) зарабатываете деньги.

Я профессионал и прячу несущественные эмоции.

Весь тред не читал, а членами уже мерились?  ;D

тред нормальный... последняя страница - это да....

ах пиписки... к этому все подходит... не торопите события )))) moar drama должна разыгрываться по тактам, актам, и частям. постепенно, что бы даже зрители прочувствались....  сейчас только к аттетстато повытаскиванию подходим, потом подотремся аттестатами соперника (надо не забыть намазать свои аттестаты перцем)... а когда доставать больше будет нечего - достанем членомеры)))
мы-же таки адынэснеги, вах)))

по теме:
Бумажку нашел, подредактирую её на выходных на предмет грамматических очепяток и выложу...

да... жжоте товарисчи!  ;D
ок, жду ))

Тем временем начитался других разных тем и пришел к заключению что все делают как хотят.
Вот например вопрос человека с линукс.орг:
Ответы:

Или вот (http://www.prog.org.ru/topic_14399_0.html), по соседству искали идеал архитектуру. Претендентами были:

• Классика: классы "Х", "Y", "Z". Их методы - логика приложения. Классы прикручиваем к БД, ну и потом UI
• Подход ORM (бизнес-логика в виде хранимых процедур)
• Промежуточной слое, сервер приложений

Так и не выяснили что и к чему...
Вот я сейчас и хочу простенькое приложение "под присмотром" спроектировать. Т.к. что-то сварганить можно всегда, а тут есть возможность чему-то хорошему научится... Хотя все предусмотреть/спроектировать невозможно (когда-то заморачивался как лучше переменную назвать car_count или count_car), поэтому я думаю можно что-то и упускать и пускать на самотек... Хотя тут, ИМХО, идет в ход характер человека, один импульсивный - пишет сходу, правит, меняет итд и потом называет это методом Agile, другой три дня думает и за 10 мин пишет идеальный продукт...
Но это все уже разработка, а пока еще только исследование и анализ (затянулся однако ;) ).

Извините, "был занят, все дела"... :-\
Если ещё актуально - добро пожаловать.


Применение элементов RUP в разработке
малых ИС на базе 1С:Предприятие.

Методика применения итерационного подхода в малых проектах
по созданию программного обеспечения и информационных систем
http://fayloobmennik.net/210842
(извините, 700 кб pdf файл к посту не прикрепляется)

Спасибо, скачал, буду изучать...
Я пока что обхожусь малой кровью: выбрал model-view подход. Для таблиц товаров, блюд итд использую модели, все их засунул в отдельный класс cofeeEngine, а в UI для таблиц представления подставляю эти модели, а на кнопочки удаления/создания/итд вешаю методы этого (cofeeEngine) класса... Разная хитрая кафешная логика тоже будет в том единственном классе. Как считаете такой подход очень плохой? или еще можно жить? )

Если вы в контексте моей статейки - то мы о разном. Все что вы говорите - это про решения в области архитектуры. RUP же - про процесс разработки, подход к постановке требований и т.п. Анализ и Проектирование - это одна из дисциплин в RUP.

Если вообще - то надо подробнее смотреть и отталкиваясь от более конкретных и детального описания архитектуры понимать соответствует ваша архитектура ващим задачам или нет. Если по мне - так мне ближе всякие там ORM и иже с ними... но я давным давно был одинэснегом, и возможно мое мнение - это легкая форма "синдрома утенка" )))

Очень интересная тема. И много советов по части теории(в том числе чтение книжек по uml, где много воды и сложных запутанных фраз).  а вот как на практике реально спланировать диаграмму классов со всеми операциями и атребутами и взаимодействиями перед непосредственно кодированием, причем полностью во всех деталях. При этом учитывая весь инструментарий QT, наследуя от встроенных классов фреймворка, чтобы не изобретать велосипеды, а использовать все возможности по максимуму. Вот стала рыться в исходниках assistanta и designera, так как мой проект над которым работаю похож на эти, много нового узнала в том числе как они разделяют model-controller-view , почти разобралась с assistantoм,  построила UML диаграммы этого проекта, залезла в дизайнер, там жесть (мозг чуть не поломался). Короче, нужны какието знания как это проектировать все, может этому учат в вузах, просто я самоучка и получается всю практику получать только через чужой код. Хотя наверно это единственный способ

да, у меня те же вопросы что и у тебя nata267, )) архтектором быть хорошо, программистом тоже, но вот как бы это все грамотно связать? ))
ну ничего, понемножку что-то строю... как я понимаю существует много подходов к проектированию и это уже получается философский вопрос как правильно создавать приложение... главное его создать ;) P.S. ИМХО...

1 - никак. забудьте попытку (ла и саму идею) спроектировать программу "причем полностью во всех деталях" как бред сивой кобылы, как маразм ночного кошмара, как золотую мечту или "серебрянную пулю" ( Брукса же читали?)
Программа  - не здание. Она может и должна проектироваться по другому. Нет, вы конечно можете все сначала спроектировать, потом долго делать, а потом долго тестировать.... но и получите вы такую программу - лет через 5. В лучшем случае. Когда оно никому уже не нужно будет.
Это проходит только тогда, когда у вас достаточно времени и объемы программы не большие.

В остальных случаях - учитесь заниматься "ниспадающим проектированием" (наверное это так можно назвать) в процессе развития программы. Определяйте общую архитектуру и создавайте "исполняемую архитектуру" (термин RUP) в начале, а потом "выращивайте на этом мясо" в том виде как это требуется.

а потому-
2 - учите итерационные технологии. Имхо, учите 6-й RUP (тот который был до текущего) и его принципы - в частности - "компонентно-ориентированная аритектура" и "разработка отталкивающаяся от прецедентов" т.п.
Как вводная информация - приведенная выше моя методичка.

Поймите, что программа, требования и архитектура будут уточняться в ходе работ. Это ГАРАНТИРОВАННО!.
Поймите, что изменение - это не катастрофа, а ожидаемое и нужное действие. Начинайте планировать (как минимум "во времени", если по составу не всегда понятно) мероприятия по реакции на изменения ещё до того, как эти изменения появятся. (не появятся изменения- хорошо, будет резерв, но они появятся, поверьте мне ;) )
Не пытайтесь увидеть все в деталях. Ни одна битва не выигрывалась по плану. Но и ни одна битва не выигрывалась без плана. Стройте скелетную архитектуру, соблюдайте её костяк, и будьте готовы всегда изменить детали. ("да, у нашей зверушки будет 2 руки, 2 ноги, голова и хвост. А вот сколько пальцев и какой длины, а может вообще клешня будет нужна - станет понятно позже") Проектирование сегодня - это не один этап, который делается в начале - это постоянный процесс на протяжении всего периода развития программы (но с разной интенсивностью).

PS: И ещё - не ждите что у все получится))) у меня ушел год на то, что бы перестроить мышление с рамок "ТЗ, и только потом программа", на "итерационное развитие".
Не ждите что любое ваше руководство смоет вас понять. Часто это люди "старшего образа мышления" и с далеко не лучших шаблонами в голове. То что "спроектировать в деталях, а потом писать" критиковалось ещё с 60-х годов - в советских вузах не учили.
 Ну где-то так) удачи, обращайтесь))))

я прочитала принципы RUP об итерационном процессе разработки и понимаю что структура и взаимоотношения классов будут все время меняться по ходу развития программы, но хотелось бы знать как вообще проектируют эти классы на каком то определенном промежуточном этапе, на примере, на практике, разбор какого нибудь конкретного небольшого приложения.

По идее, они должны "развиваться", а не "меняться". От более грубых моментов к деталям.
Если они "просто меняются" - то что-то у вас не так, а вы рискуете попасть на "неуправляемый процесс разработки".

гм... вот в этой книжке (http://www.itshop.ru/Razrabotka-programmnyh-proektov-na-osnove-Rational-Unified-Process-RUP/l4t2i89730) есть пример мини-проекта (PSP-tools) от идеи до окончания внедрения. Там далеко не только про проектирование, акцент сделан на всем процессе, на его идеях, но думаю вам будет интересно/полезно. Т

Denjs
Ну вы не правы. Я написал программку, за год не поменяв требований вообще. Но там было очень много размышлений о юзкейзах. Требования меняются ибо заказчики блондинят+рынок меняется. Мой не менялся:)

Я говорю что "углубление в детали на ранних этапах" - есть "зло" ))) . По крайней мере в подавляющем числе случаев сегодня. Естественно методы и подходы надо применять в зависимости от ситуации и условий проекта.

Вы правы в том, что я упустил один аспект при котором "водопад" жизнеспособен - стабильность требований.

Но, имхо, вы забыли, наверное, упомянуть что :
 - или у вас проект был не большим (имею в виду объем разработки и её сложность, а не длительность проекта),
 - или область вам хорошо знакомая, для которой есть много наработок или фреймворков,
 - или вы не проводили совсем-детальное проектирование системы, сразу ринувшись в реализацию проекта (по причине что ест наработки, есть фреймворки или т.п.).
 - или вы говорите про неизменчивость высокоуровневых требований, забыв, что детали вы все равно меняли.... Мы можем наверное согласиться, что высокоуровневые требования останутся неизменными, но мелочи-то будут меняться. и мелочи могут поменять и извратить все .

 так? ну может ещё пара-тройка деталей и/или вариантов.

В общем случае - сегодня такие проекты скорее всего исключение, потому что нужна редкая совокупность факторов что бы процесс построенный по водопаду прошел нормально. Основные условия для него - небольшие объемы, из которых следует неизменчивость требований.

Т.е. ваш проект - исключение.

Есть ещё один вариант (увы так чаше всего бывает когда люди говорят про успешность применения ТЗ).
"проект построенный по ТЗ" - "фейк". (я вам верю, но привожу статистику о том, что часто кроектся за тем, что люди говорят про "успешные проекты построенные по водопаду").
За фразой "мы работали по тз" сегодня часто кроется откровенная ложь, лукавство...  часто - выгораживнаие себя, ради того что бы хорошо выглядеть в глазах клиента/заказчика. (да, иногда и в силу того, что заказчик "глух", но чаще - это "пылевглазапускание"). Иногда доходит до того, что "ТЗ" пишется постфактум или подгонятеся под реальную программу - после реализации проекта.
И не надо мне говорить что это не так. Это именно так, особенно в гос-конторо-подобных организациях (в том же РЖД) .
 (я тут работаю и вижу многие бумаги приходящие нам на рецензию и не только). или оно (ТЗ, ТП, "ПМ", "ПЗ") не соответствует действительности, или слишком абстрактно и витеевато написано, или пишется постфактум. Прочее представлено в исчезающе малом объеме.

вот ещё полезная штука: OpenUP. Суть его в том, что это похоже на RUP, но все доступно бесплатно.
 IBM >> developerWorks Россия >> Rational >> Статьи >> OpenUP - это просто (http://www.ibm.com/developerworks/ru/library/kroll/index.html?S_TACT=105AGX99&S_CMP=GR01)

В том-то и дело что на небольшом приложении (напр плагине) все получается прекрасно - так как пишут в вумных книжках. Но с ростом объема решаемых задач все становится иначе. Переделывать архитектуру придется - и лучше воспринимать это спокойно. Вот пример из моей недавней практики, заказчики говорят

- нам надо чтобы альфа-канал можно было загружать/контролировать из отдельного имеджа. 

Они не пытаются "проскочить на шару", т.е. понимают что такие изменения требуют времени и денег. Но технически не легче - имедж для альфы может иметь др. формат, размеры, разрешение чем для RGB, надо что-то решать с UI и.т.п. - от моей стройной архитектуры остаются "рожки да ножки"  :)

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

Цитата из книги по шаблонам проектирования:

Каркас - это набор взаимодействующих классов, составляющий повторно используемый дизайн для конкретного класса программ. Например, можно создать каркас для разработки графических редакторов в разных областях: рисование, сочинение музыки, САПР. Другой каркас упростит построение приложений для финансового моделирования. Каркас можно подстроить под конкретное приложение путем порождения специализированных  подклассов от входящих в него абстрактных классов...
Каркас диктует определенную архитектуру приложения...
Если проектировать приложение нелегко, инструментальные библиотеки - ещё сложнее, то проектирование каркаса - задача самая трудная.

Конец цитаты.

Получается есть такие готовые каркасы. Только где их взять?? Чтобы не изобретать велосипед?

Наверное это про фреймворки... или какие-нибудь библиотеки реализующие тот или иной велосипед;)

nata267, спасибо что подняли тему, почитал с удовольствием.

Процесс продумывания на этапе начальных размышлений самый важный, тут можно "нехило" промахнуться и процесс разработки может пойти достаточно сложным путем, если не сказать совсем не тем. На одной из итерации возможен крутой разворот со всеми вытекающими время-затратами.

В моем  случае, практически на этапе размышлений, мне достался достаточно сложный проект. Благодарен предыдущему программисту за то, что архитектура была построена на модульности, и мне пришлось ее вести до этапа внедрения. Интуитивно следовал основным принципам RUP, получил огромный опыт и удовольствие от работы.  Были достаточно сложные финты-запросы-хотелки со стороны заказщика, но они протекали безболезненно.

Обращаюсь к Denjs (http://www.prog.org.ru/index.php?action=profile;u=7371) и zeonET (http://www.prog.org.ru/index.php?action=profile;u=7181)
Еще жив документ из сообщения msg104639 (http://www.prog.org.ru/index.php?topic=14904.msg104639#msg104639)? Файлообменник ругается на его отсутствие.

Уважительное спасибо.

брать тут:  http://izokh.ru/doku.php?id=articles:rup_1c

Всегда пожалуйста.

Устраиваемся на работу в "Макдоналдс", смотрим как работает программа R-Keeper, пишем то же самое.