Проектирование программы для кафе

[zeonET]

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

[kirill]

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

[lit-uriy]

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

[Denjs]

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

[zeonET]

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

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

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

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

[Denjs]

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

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

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

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

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

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

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

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

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

[sergek]

Вот и хочу спросить об извечной проблемме разделения логики и интерфейса...

Есть такая проблема? 

Как лучше спроектировать? Какие классы разработать? Или может что-то особенное из qt можно использовать? Куда запихнуть все селекты и апдейти?

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

[Igors]

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

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

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

[Denjs]

делить все файлы проекта на 2 категории: A - использующие QtGui и B - не использующие.

Все запросы к СУБД должны быть только в "B".

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

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

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

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

[zeonET]

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

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

[Denjs]

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

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

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

2 Denjs, ваш пост это бомба ))) Уже раз 5 перечитал и еще буду перечитывать )) Большое спасибо за информацию, много нового для себя нашел!

Всегда пожалуйста. Через 3-5 автоматизированных кафе/магазина у которых 3-4 поса - вы начнете понимать то-же самое.

Раз разговор зашел за стратегию разработки то я думаю здесь будет уместная политика экстремального программирования: и клиент рядом, и итерации небольшие итд итп...

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

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

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

[Mysterious]

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

[lit-uriy]

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

[Denjs]

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

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

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


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

Далее много чего, о чем я рассказал в #5 - нет в конфигурациях для 1С. Во первых это огранияения платформы, а во вторых - трудность и стоимость обхода этих ограничений. Изобретать костыли для чужой программы - это гемор. Решения, которое позволяет вам динамически переключаться из онлайн-режима в оффлайн и обратно - например когда у вас сеть упала - это тоже отдельная лебединая песня,  в 1С этого нет. Хотя, кто-то может быть и смог сделать ещё один костыль, о у меня такой информации нет.

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

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

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

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

[Igors]

Не надо портить мышление 1С-ом. От этого потом трудно отмыться.

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