Розробка мікро-облікової системи на lua, частина друга. Постановка завдання

Тепер трохи про саму задумом. Передбачається, що програма буде відповідати наступним умовам:
  • Максимально можлива переносимість,
  • Швидкий уніфікований інтерфейс,
  • Можливість максимально швидкого зміни даних,
  • Відсутність необхідності у фіксації часу модифікації документа,
  • Необхідність у відстеженні балансу по клієнтам (сальдо).
Програма повинна певним чином управляти інформацією. На вході їй повинні надаватися:
  • Дані про клієнта: ім'я / найменування та пов'язані телефони, причому телефонів може бути більше двох;
  • Дані про позиції: найменування і вартість. Даний тип використовується для фіксацій операцій і витрат — тобто, позиція може мати як негативну, так і позитивну вартість (виплати замовника + витрати на обладнання / дорогу / операції та інші радості);
  • Дані для формування документа, зібрані з попередніх;
На виході користувач повинен отримувати наступну структуру:
  • Каталог користувача даних,
  • Каталог телефонів з прив'язкою до користувачів,
  • Каталог позицій з можливістю редагування,
  • Каталог документів з можливістю зміни клієнтських виплат.

Тепер домовимося про термінологію.
Клієнт — юридична або фізична особа, якій послуга надається. У програмі клієнта, представляють його ім'я / найменування та телефон. Мені більше і не треба.
Позиція — опис графи приходу / витрат грошових коштів, мають свою вартість. Вартість може бути як позитивна (виплата від замовника, оплата витрат та інше), так і негативна (оплата замовлення / витрат, не — або недовыплаты за оказаным послуг і так далі). Складається з найменування та фактичної вартості.
Документ — облікова структура, що зберігає дані про вартість позиції і фактичне покритті клієнтом витрат на неї.
Сальдо — фактична різниця між обсягом наданих клієнту послуг та виплаченого грошового еквівалента. У програмі буде використовуватися як загальне сальдо, так і окреме на кожного клієнта.

Програма створювалася при наступних умовах:
  • Відсутність в необхідності делегування користувальницького доступу для обробки інформації;
  • Інтерфейс повинен бути швидким, тому найбільший інтерес представляють різні види текстового інтерфейсу;
  • Заради можливості максимального перенесення коду (наприклад, на Win-машину з встановленим комплектом «Lua for Windows») сам код був максимально спрощений, як і середовище розробки. Це означає мінімальний час розгортки програми в іншому середовищі і меншу кількість правок при використанні утиліти luac.
  • Відпрацювання мінімально необхідної кількості функцій дозволила спростити до крайньої міри схему бази та алгоритми її обслуговування;
  • І так, я не робив відпрацювання помилок при виконанні запитів — я постарався максимально виключити. Так, я дилетант у Lua, але мені зараз більше і не потрібно. Якість коду приходить з часом.
Тепер про структуру програми:
  • Програма складається з модулів: головного, безлічі виконавчих і модуля доступу до бази. Взаємодія відбувається в режимі конвеєра;
  • Головний модуль не має доступ до модуля керування базою, але має примірники виконавчих. Виконавчі модулі вже мають доступ до примірника модуля доступу.
  • Програма після виконання команди повертається в головне меню.
Взаємодія модулів програми, джерела даних і людини виглядає так:
image
Схема користувальницьких прецедентів (use case) виглядає так:
Велика схема use case. Бажано відкрити в новій вкладці.image

Користувальницькі сценарії поділяються на наступні категорії:
  • Управління користувацькими даними, яка в свою чергу ділиться на функції управління телефонним довідником і списком клієнтів;
  • Управління позиціями — функції створення, модифікації, перегляду і видалення;
  • Управління документацією;
  • Розрахунок балансу за документами: загальний і для окремого користувача.
База даних являє собою набір таблиць, пов'язаних з допомогою первинних автоинкрементных ключів. Додатково використовується відображення при видачі загальної інформації (хоча це спірне рішення):
image
Передача даних відбувається через прошарок модуля database, що є модулем доступу. Виконавчі форми створюють запити, які в нього і посилають. Всі дані виконавчі модулі розбирають самостійно. За фактом, database є контейнером для екземпляра класу «luasql-sqlite3», сполученого з базою.

Маленька деталь. Базу довелося створювати через програму sqliteman, оскільки ініціалізація таблиці з первинним ключем автовычисляемого типу (autoincrement) при ручному формуванні запиту не працює. Але, на всяк випадок, я сформував дамп бази для подальшої розгортки:
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE "feedback" (
"number" INTEGER PRIMARY KEY AUTOINCREMENT,
"customer" TEXT,
"phone" INTEGER
);

CREATE TABLE "customer" (
"number" INTEGER PRIMARY KEY AUTOINCREMENT,
"name" TEXT
);

CREATE TABLE "position" (
"number" INTEGER PRIMARY KEY AUTOINCREMENT,
"nominal" TEXT,
"price" REAL
);

CREATE TABLE "document" (
"number" INTEGER PRIMARY KEY AUTOINCREMENT,
"customer" INTEGER,
"position" INTEGER,
"income" REAL
);

DELETE FROM sqlite_sequence;
INSERT INTO "sqlite_sequence" VALUES('customer',8);
INSERT INTO "sqlite_sequence" VALUES('feedback',10);
INSERT INTO "sqlite_sequence" VALUES('position',2);
INSERT INTO "sqlite_sequence" VALUES('document',6);
CREATE VIEW "journal" AS select document.number, customer.name, position.nominal, document.income, position.price
from document, customer, position
where document.customer = customer.number
and document.position = position.number;
COMMIT;


І на солодке — скріншот роботи програми:
Головне меню.image

Відпрацювання розрахунку балансу по клієнту.image


І так, це швидкий текстовий інтерфейс! Зате не замучаюсь з перенесенням програми (з GTK — залежним інтерфейсом) на іншу машину!

В наступних статтях буду окремо розповідати про роботу окремих модулів програми і викладати їх початкові коди.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.