SmartPOS Development Log - With a twist!

Get help on programming - C++, Java, Delphi, etc.
Judas
Registered User
Posts: 2118
Joined: 17 Oct 2006, 02:00
Location: Stellenbosch
Contact:

Post by Judas »

rustypup wrote:
Judas wrote:We propose putting simple terminals, with mind-numbingly easy to use interfaces, in the kitchen to display the orders.
an excellent idea, but an old one. there are a number of practical reasons why this approach fails in the catering business, most of them revolving around the atmosphere found in the average kitchen. grease and humidity render touch screens useless in a very short space of time... ditto with keyboards.

because grease disolves rubber, effective sealing solutions are hellishly expensive.

paper is used because it's an inexpensive system which works well enough, not perfect, but usable. this system would have to address these issues before attempting to sell into this market...
Hmmm... Thanks rusty, I must admit that that hadn't occurred to me...

In those conditions it might be best to just stick with a docket printer, but instead of only printing out dockets when an order comes through, also print out notification dockets when an order is changed or cancelled. To the best of my knowledge, very few or no systems do that.

If anyone has any bright ideas on how to get around the problem - I'm all ears ;).
'One will rarely err if extreme actions be ascribed to vanity, ordinary actions to habit, and mean actions to fear.'
- Friedrich Nietzsche

'Do not argue with Judas, nube, that would be foolish!'
- D3PART3D
PypLaCe
Registered User
Posts: 214
Joined: 19 Apr 2005, 02:00
Location: Johannesburg
Contact:

Post by PypLaCe »

I think this is a brilliant idea and I would be glad to help. I'll start thinking of a couple of ideas for now...
Judas
Registered User
Posts: 2118
Joined: 17 Oct 2006, 02:00
Location: Stellenbosch
Contact:

Post by Judas »

PypLaCe wrote:I think this is a brilliant idea and I would be glad to help. I'll start thinking of a couple of ideas for now...
Thanks PypLaCe, any ideas you can come up with will be massively appreciated! :bigups:
'One will rarely err if extreme actions be ascribed to vanity, ordinary actions to habit, and mean actions to fear.'
- Friedrich Nietzsche

'Do not argue with Judas, nube, that would be foolish!'
- D3PART3D
PHR33K
Registered User
Posts: 779
Joined: 05 Sep 2004, 02:00
Contact:

Post by PHR33K »

I'm willing to help, but if you put me anywhere near Qt - I WILL shoot someone :evil:
Judas
Registered User
Posts: 2118
Joined: 17 Oct 2006, 02:00
Location: Stellenbosch
Contact:

Post by Judas »

PHR33K wrote:I'm willing to help, but if you put me anywhere near Qt - I WILL shoot someone :evil:
:lol:

Well, unfortunately the program is gonna be quite closely tied to Qt... There's going to be QStrings, QLists and QMaps flying around all over the place, meta-object compilers for everybody, signals and slots galore... ;)
'One will rarely err if extreme actions be ascribed to vanity, ordinary actions to habit, and mean actions to fear.'
- Friedrich Nietzsche

'Do not argue with Judas, nube, that would be foolish!'
- D3PART3D
PHR33K
Registered User
Posts: 779
Joined: 05 Sep 2004, 02:00
Contact:

Post by PHR33K »

:x
ew.
**** C++.
Lets do it in fasm! :D
Tolklein
Registered User
Posts: 699
Joined: 21 Nov 2004, 02:00

Post by Tolklein »

I remember, the POS systems I used to use. The managers would grumble about having to input new items or do price changes, as the interface was not user friendly and somewhat cumbersome. I also recall that on one of the systems, at the end of every night, a cash up would be done whereby the entire days sales would be printed. And if the paper run out during this little procedure, there was no way to do a reprint.

There were other niggly bits too that I can't quite recall, but I'll keep you posted
Slasher
Registered User
Posts: 7525
Joined: 23 Aug 2003, 02:00
Location: 5th rock from the sun.

Post by Slasher »

Mmmm, network at the office seems to be slightly slow. Having trouble getting TortoiseSVN downloaded...

O well, got the documents from the site in any case, will check around a bit now...

With the basic stock control you will be using - To what degree?

Will a product be split down into ingredients and amounts required? Or will it just be basic you have x amount of sugar on hand? If you split the ingredients down, you can have a rough control over when re-ordering is required...

Also, how about adding a 'time management' in a miniscule way to it, allowing waiters to sign in on the system when they get there, and not have to clock in as well. Then this can be interfaced to other systems to allow EDI of clock-in/out times..
My BF2142 Stats:
Image


Slasher : Former member of www.PCFormat.co.za
I have reached the end of my near 5 year forum life. Farewell good days...

slasher (at) webmail (dot) co (dot) za
User avatar
rustypup
Registered User
Posts: 8872
Joined: 13 Dec 2004, 02:00
Location: nullus pixius demonica
Contact:

Post by rustypup »

Slasher wrote:If you split the ingredients down, you can have a rough control over when re-ordering is required...
again, a nice to have feature, but not one that is ever successfully implemented. this is more of a user issue than anything else.

99% of the time, JIT inventory, (sooner or later), becomes a stock check at close of business where they will place an order on the wholesaler for next morning delivery. for this purpose a low-stock report is sufficient.

yes, JIT inventory works, to a degree, but it introduces a fair amount of complexity into inventory maintenance, something which the hospitality trade struggles with already - in order to sell this in, the simpler the user's interface, the better. depending on how modular the system's design is, this could be provided as an extension to the underlying logic as opposed to its basis. :idea:

as to signing in, in most cases this already happens when they report to their station using the fingerprint reader. given how the shift-system works, tracking waitrons is tricky at the ebst of times, (they may swap shifts between themselves, only alerting management on the day of the change), and shift-planning tends to be quite fluid. management rarely cares about who was there at what time, only who wasn't, information which can be gleaned from the fingerprint log reports.
Most people would sooner die than think; in fact, they do so - Bertrand Russel
Slasher
Registered User
Posts: 7525
Joined: 23 Aug 2003, 02:00
Location: 5th rock from the sun.

Post by Slasher »

I now it is a nice-to-have.

Just a thought that got into my head. I was merely slinging around some rudimentary nonsense that got into my head.

It would also never be accurate with the staff using different amounts in every item made etc. Never accurate, yet a thought...

Also, in terms of signing in - I know some systems has the biometrics basis, but not all places use this yet. The reason for wanting to know who was / was not there is just to make it easy for that control. I intended the time-management idea as an option for people that do not have biometrics and pay-roll integration. Smaller places will not want to pay for all that.

Also, will Biometrics be integrated as a log-on option for the waiters or not?

I love brainstorming... I just throw out ideas and watch it get ripped to shreds :)
My BF2142 Stats:
Image


Slasher : Former member of www.PCFormat.co.za
I have reached the end of my near 5 year forum life. Farewell good days...

slasher (at) webmail (dot) co (dot) za
Kronos
Moderator Emeritus
Posts: 4280
Joined: 28 May 2003, 02:00
Location: Azeroth
Contact:

Post by Kronos »

Well, this sounds interesting. Although I don't know much about the restaurant business, I do have a lot of common sense. :)

Also, you have another serious programmer at your disposal. Provided I have available time, and I can get used to coding with those funny IDE's, API's and other tools you want to use :P
Image
Slasher
Registered User
Posts: 7525
Joined: 23 Aug 2003, 02:00
Location: 5th rock from the sun.

Post by Slasher »

*Yawn*

Most of the tutorial is quite boring actually... It more explains the basic uses of certain functions such as if / do / while etc. rather than more syntax based things I was hoping for. Is very close to exactly the same as C# thus far. Approaching OO now, expecting some bigger changes there..
My BF2142 Stats:
Image


Slasher : Former member of www.PCFormat.co.za
I have reached the end of my near 5 year forum life. Farewell good days...

slasher (at) webmail (dot) co (dot) za
Slasher
Registered User
Posts: 7525
Joined: 23 Aug 2003, 02:00
Location: 5th rock from the sun.

Post by Slasher »

Kronos wrote:Well, this sounds interesting. Although I don't know much about the restaurant business, I do have a lot of common sense. :)

Also, you have another serious programmer at your disposal. Provided I have available time, and I can get used to coding with those funny IDE's, API's and other tools you want to use :P
I think the basis of the restaurant business is quite common sense based.

When one thinks of the logical flow, it is a very basic principle that will be applied.

Im getting quite interested to see how all this will nicely run together...

Judas - I just saw you have a Database Definition file, but could not download it from the office yet. Is that just for creating database, or do you have tables yet?

Should be quite a good exercise to explain 3rd normal etc to the newbies here...

Im ready to do the work I can find time for :) :)
My BF2142 Stats:
Image


Slasher : Former member of www.PCFormat.co.za
I have reached the end of my near 5 year forum life. Farewell good days...

slasher (at) webmail (dot) co (dot) za
Judas
Registered User
Posts: 2118
Joined: 17 Oct 2006, 02:00
Location: Stellenbosch
Contact:

Post by Judas »

Slasher wrote: With the basic stock control you will be using - To what degree?

Will a product be split down into ingredients and amounts required? Or will it just be basic you have x amount of sugar on hand? If you split the ingredients down, you can have a rough control over when re-ordering is required...
I think that rudimentary stock control for items that can be easily measured - say, the number of beers remaining - will be a lot easier to implement in the beginning. The architecture is quite modular though, so oughtn't be too difficult to support for more complex stock control later if necessary.
Slasher wrote:Also, how about adding a 'time management' in a miniscule way to it, allowing waiters to sign in on the system when they get there, and not have to clock in as well. Then this can be interfaced to other systems to allow EDI of clock-in/out times..
There's going to be some basic time management, in the sense that managers can set the waiter's shifts and the waiters can check their work schedule from a terminal. As rusty said, it might not be practical to enforce shifts and whatnot though - waiters tend to swap shifts fairly regularly.
Slasher wrote:Also, in terms of signing in - I know some systems has the biometrics basis, but not all places use this yet. The reason for wanting to know who was / was not there is just to make it easy for that control. I intended the time-management idea as an option for people that do not have biometrics and pay-roll integration. Smaller places will not want to pay for all that.

Also, will Biometrics be integrated as a log-on option for the waiters or not?
I'm definitely hoping to get fingerprint scanner support in to the program - although I must admit that I have no idea how to implement it at this stage, and I don't have access to a fingerprint scanner at the moment. The program's design is very modular, however, and the device subsystem is quite distinct from the rest of the program, so it shouldn't be difficult to pop in some extra classes to handle fingerprint scanners, cash drawers, and any other more unusual hardware at a later stage.
Kronos wrote:Also, you have another serious programmer at your disposal. Provided I have available time, and I can get used to coding with those funny IDE's, API's and other tools you want to use :P
Thanks Kronos, much appreciated :D. The only API we'll be using is Qt, and that's quite easy to learn if you've got a bit of C++ background... As for the IDE - I don't think it's going to work to force an IDE on everybody, since everyone has their own preference anyway... I'll probably just write the code with vim, but anybody else can use whatever IDE tickles their fancy.
Slasher wrote:*Yawn*

Most of the tutorial is quite boring actually... It more explains the basic uses of certain functions such as if / do / while etc. rather than more syntax based things I was hoping for. Is very close to exactly the same as C# thus far. Approaching OO now, expecting some bigger changes there..
Overall, the underlying concepts of C# are pretty much the same as C++. The key difference is C++'s use of header files, covered in the OO part of the tutorial. The inheritance mechanism is also slightly different, but overall the same principles apply.
Slasher wrote:Judas - I just saw you have a Database Definition file, but could not download it from the office yet. Is that just for creating database, or do you have tables yet?

Should be quite a good exercise to explain 3rd normal etc to the newbies here...
At this stage, we've got a rudimentary database design, complete with (I think) all of the necessary tables and some basic documentation. I haven't yet had time to go over the database thoroughly and get it into 4th normal form, or at least third normal - but hopefully I'll have time for that later...

I was meaning to post a bit of a tutorial on 1st, 2nd, 3rd and 4th normal forms today, but I'm a bit knackered at the moment, just got back from work :).

If anybody is keen to help out at this stage, checking the database out to make sure that it's complete and 4th normal would be a massive help at this point... In order to edit the database definition, you'll need a great little Java tool called Druid. There are also some database diagrams in .png format under version control, which might be a bit easier to inspect :D.

Also, some casual use cases would be quite helpful to people unfamiliar with the project or problem domain I suspect... I'll try to get a start on that later too.

EDIT: The Qt 4 documetation is here, for anybody interested in checking out its capabilities and getting a feel for the API.
'One will rarely err if extreme actions be ascribed to vanity, ordinary actions to habit, and mean actions to fear.'
- Friedrich Nietzsche

'Do not argue with Judas, nube, that would be foolish!'
- D3PART3D
Slasher
Registered User
Posts: 7525
Joined: 23 Aug 2003, 02:00
Location: 5th rock from the sun.

Post by Slasher »

Judas wrote:
Slasher wrote: Also, will Biometrics be integrated as a log-on option for the waiters or not?
I'm definitely hoping to get fingerprint scanner support in to the program - although I must admit that I have no idea how to implement it at this stage, and I don't have access to a fingerprint scanner at the moment. The program's design is very modular, however, and the device subsystem is quite distinct from the rest of the program, so it shouldn't be difficult to pop in some extra classes to handle fingerprint scanners, cash drawers, and any other more unusual hardware at a later stage.
Biometrics used with the correct API is actually laughingly easy to implement. I have coded them into C# and VB.net applications. http://www.biometrics.co.za has an ActiveX API available, as well as the fact that I own a Digital Persona U.are.U 4000B left from Varsity days sponsorship.

Im not too sure what API is available for implementation into C++, but the basics are really simple. Biggest nuisance for me is to catch the biometrics string and store it into a database. Something which is suprisingly difficuly to see, as it is stored in a string variable, but encrypted so that you can not just physically and easily display the string 'format' it extracts for a finger print. Thus, knowing wether something was written or not took me a night or two of frustration...

Loved Biometrics still though. Once I got it working, now I just want to use it into a more complex mod, like add it to my PC case and use it for logging into Windows or something along those lines...
My BF2142 Stats:
Image


Slasher : Former member of www.PCFormat.co.za
I have reached the end of my near 5 year forum life. Farewell good days...

slasher (at) webmail (dot) co (dot) za
Judas
Registered User
Posts: 2118
Joined: 17 Oct 2006, 02:00
Location: Stellenbosch
Contact:

Post by Judas »

Slasher wrote:
Judas wrote:
Slasher wrote: Also, will Biometrics be integrated as a log-on option for the waiters or not?
I'm definitely hoping to get fingerprint scanner support in to the program - although I must admit that I have no idea how to implement it at this stage, and I don't have access to a fingerprint scanner at the moment. The program's design is very modular, however, and the device subsystem is quite distinct from the rest of the program, so it shouldn't be difficult to pop in some extra classes to handle fingerprint scanners, cash drawers, and any other more unusual hardware at a later stage.
Biometrics used with the correct API is actually laughingly easy to implement. I have coded them into C# and VB.net applications. http://www.biometrics.co.za has an ActiveX API available, as well as the fact that I own a Digital Persona U.are.U 4000B left from Varsity days sponsorship.

Im not too sure what API is available for implementation into C++, but the basics are really simple. Biggest nuisance for me is to catch the biometrics string and store it into a database. Something which is suprisingly difficuly to see, as it is stored in a string variable, but encrypted so that you can not just physically and easily display the string 'format' it extracts for a finger print. Thus, knowing wether something was written or not took me a night or two of frustration...

Loved Biometrics still though. Once I got it working, now I just want to use it into a more complex mod, like add it to my PC case and use it for logging into Windows or something along those lines...
I think that the biggest problem is going to be finding a platform-independent biometrics API... I forsee that we might need to have different code for different platforms, and conditionally build the right code at compile time :(. Not the ideal solution, but it might be the only way in this case.
'One will rarely err if extreme actions be ascribed to vanity, ordinary actions to habit, and mean actions to fear.'
- Friedrich Nietzsche

'Do not argue with Judas, nube, that would be foolish!'
- D3PART3D
Slasher
Registered User
Posts: 7525
Joined: 23 Aug 2003, 02:00
Location: 5th rock from the sun.

Post by Slasher »

I think there are a few platform independent API's available. Will just have to google.

Biggest nuisance is the different Biometrics units and driver sets that can be implemented. Digital Persona and U.are.U are the biggest I have seen as well as found from a bit of googling. Seem to be a favuorite to use, with even Microsoft rebranded units available...
My BF2142 Stats:
Image


Slasher : Former member of www.PCFormat.co.za
I have reached the end of my near 5 year forum life. Farewell good days...

slasher (at) webmail (dot) co (dot) za
Judas
Registered User
Posts: 2118
Joined: 17 Oct 2006, 02:00
Location: Stellenbosch
Contact:

Post by Judas »

This might be a good time to address the system architecture, so here goes...

At present, the architecture has only been broken down to the subsystem level, as described in architecture/Architecture Overview.txt file in version control.

Before we begin, it's important to remember that the primary goal of any architecture should be to minimise the complexity of the system. Taken as a whole, a software project is simply too big for any one person to deal with at one time. To quote Edgar Dijkstra, one of software eningeering's greats, "The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task with full humility, and avoids clever tricks like the plague.".

For that reason, software development is largely concerned with breaking down the program into smaller, more manageable, chunks. The first division is into subsystems. A subsystem is simply a group of classes and functions that all serve a common goal. Examples would be that part of the program that handles the interface, or the database, or external devices, etc.

We further divide subsystems into classes. Classes and object-object programming have revolutionised the way we write code. Simple put, an object in a program is analagous to an object in real life. For example, if you were writing a program that deals with cars, you would would have many types of "Car" object. This is where the distinction between a class and an object come in. A class is basically a template for objects; in this case you would have one "Car" class that describes what kind of attributes and a car can have - eg. it has a colour, a top speed, a fixed number of doors, etc. From that one Car class, you create multiple objects that represent different types of cars. You might create a object called "ferrari" of the type "car" that has red paint and two doors, as well as a object "mazda" with blue paint and four doors.

I'll go into objects in more detail later, but it's absolutely crucial that you understand the concept, so I very highly recommend reading the Wikipedia article on object-oriented programming and the OOP section of the previously posted C++ tutorial if you are not familiar with OOP.

Classes are further broken down in to functions. Functions are small groups of code that have a single, well-defined, purpose. For example, a you might have a function called "showMainWindow" that will pop-up the main window of the program.

I'll explain objects and functions in much more detail once we get to those levels of architecture, but for now it's sufficient that you have the general idea of their purpose.

Managing Complexity
I cannot stress highly enough that managing complexity is software's primary imperative. If you don't make a dedicated effort to make the architecture as simple as possible, the software will eventually enter an entropy death-spiral - gradually becoming more and more complex, until no-one really understands what it does.

We have two primary means of managing complexity: Abstraction and Encapsulation.

Abstraction:
Abstraction is presenting a consistent interface to a class or a subsystem, so that a programmer can concentrate on one level of complexity. An example of every-day abstraction would be talking about a town. You know that a town is a collection of houses, but you can understand the concept of a town without knowing the detail of every single house. That is an abstraction. If you had to know all the details of every single house in order to understand what a town was, that would be a poor abstraction, because thinking about towns would become a very complex business.

From a programming perspective, the principle is the same. A prime example is accessing data from the database. At its lowest level, you access the data using raw SQL queries, which is quite a complex process, relatively speaking. However, often you don't want to know about that level of detail - you want to be able to just call the function

Code: Select all

findUser("Judas")
rather than

Code: Select all

findUser("SELECT * FROM users WHERE name='Judas'")
As you can imagine, if you had to constantly worry about building SQL queries as in the second example, it would unnecessarily distract you from your goal - the simple process of finding a user.

This is where we talk about levels of abstraction. Different levels of abstraction deal with the different levels of complexity, so you can address a problem at the right level of complexity.

Running with the above example, you might have to functions: executeSQL(), which executes a SQL query, and findUser(), which simply looks up a user. The findUser() function should handle all of the SQL internally, leaving you free to focus on the task at hand without having to worry about the much more error-prone task of pulling information out of the database.

Encapsulation:
Encapsulation and abstraction go hand in hand. Encapsulation goes one step further than abstraction: not only should you present a consistent abstraction so that the programmer doesn't need to worry about underlying complexity, but you should prevent the programmer from even knowing what underlying complexity is going on. When using the findUser() function, a programmer shouldn't know if the user's data is being retrieved from the database, from the network or just being made up on the spot. If it doesn't matter to the programmer using the function, he shouldn't need to think about it - freeing up the programmers valuable grey matter to focus on other, more important, issues.

The Subsystems
When designing subsystems, you want to keep them as loosely connected as possible. You should be able to pull out a subsystem and replace it with another one, or take a subsystem and use it in another program, with as little difficulty as possible. For that reason, the amount of communication between subsystems should be strictly limited.

For example, if subsystem A which communicates with systems B, C and D, it's going to be very difficult to remove or replace that subsystem - because you'll need to do something about all of those connections to other systems, or else you'll break the program. By contrast, if subsystem A only communicates with system B, it becomes much easier to disconnect the subsystem from the rest of the program.

At this stage of the architecture, we have these subsystems defined:

Databse:
The databse subsystem manages all low-level database operations, such as connecting, disconnecting, and performing queries. The database subsystem should not be able to communicate directly with any of the other subsystems.

Initially, we were going to use a dedicated network subsystem and a client/server model to handle networking. However, because the program will mostly be used on LANs or on VPNs, all of the terminals should have direct access to the database server, so it makes little sense to add the extra complexity. Rather, each computer running the program will connect directly to the database to get the information it needs.

Entity:
The entity subsystem contains all of the classes that map to real-world objects. For example, classes like "User", "Bill", "Order" and "Item" would be found here. They present a higher level of abstraction than the Database subsystem, because you can just search for a user and get a User object rather than searcing the database with SQL queries and getting simple data types.

Furthermore, the Entity subsystem hides the fact that information is coming from a database. When you call User::findUser(), you don't know if the data is going to come from the database, a flat file, or the network, because the entity subsystem will handle all of that internally.

The Entity subsystem is closely tied to the Database subsystem, and can communicate directly with the Database subsystem and no other. The reason for not simply including the Entity classes in the Database subsystem is so that, if need be, we can add a network subsystem later, and hide that from the rest of the program with the Entity classes.

Application Classes:
The application classes are the backbone of the system - they perform most of the logical processing, and control most of the program's operation. The Application Classes subsystem can communicate with the Entity, GUI, and Devices subsystems.

GUI:
The GUI subsystems controls the program's user interface. The main reason for making this a subsystem on its own is so that we can muck around with the UI as much as we like without disrupting any of the rest of the program. The GUI subsystem can't directly communicate with any other subsystems.

Devices:
The device-related classes - such as printers, fingerprint scanners, cash drawers, etc. are stored in their own subsystem because this will likely be the more volatile and complex part of the program. We definitely want programmers working on the application classes to be able to use printers, drawers, and other hardware without needing to worry about the underlying drivers, protocols, etc.

The communication between the subsystems could be summed up with this diagram:

Image

I should highlight that the design is in no way fixed - indeed, this is about the sixth design that I've come up with :P. So, if you have any ideas on how to make the design better or simpler, don't hesitate to say so!
Last edited by Judas on 11 Dec 2007, 17:18, edited 1 time in total.
'One will rarely err if extreme actions be ascribed to vanity, ordinary actions to habit, and mean actions to fear.'
- Friedrich Nietzsche

'Do not argue with Judas, nube, that would be foolish!'
- D3PART3D
Kronos
Moderator Emeritus
Posts: 4280
Joined: 28 May 2003, 02:00
Location: Azeroth
Contact:

Post by Kronos »

Judas wrote:I think that the biggest problem is going to be finding a platform-independent biometrics API... I forsee that we might need to have different code for different platforms, and conditionally build the right code at compile time :(. Not the ideal solution, but it might be the only way in this case.
It shouldn't be that much of a problem if the system is as modular as you intend.
Do you mean for the modular extensibility to be customized in code, or as plug-ins to the compiled app?
Image
Judas
Registered User
Posts: 2118
Joined: 17 Oct 2006, 02:00
Location: Stellenbosch
Contact:

Post by Judas »

Kronos wrote:
Judas wrote:I think that the biggest problem is going to be finding a platform-independent biometrics API... I forsee that we might need to have different code for different platforms, and conditionally build the right code at compile time :(. Not the ideal solution, but it might be the only way in this case.
It shouldn't be that much of a problem if the system is as modular as you intend.
Do you mean for the modular extensibility to be customized in code, or as plug-ins to the compiled app?
I think that modular extensibility to the code will make for the simplest architecture, rather than loading external modules. However, I'm open to the idea of external module loading if you think it will make for a better solution.
'One will rarely err if extreme actions be ascribed to vanity, ordinary actions to habit, and mean actions to fear.'
- Friedrich Nietzsche

'Do not argue with Judas, nube, that would be foolish!'
- D3PART3D
Kronos
Moderator Emeritus
Posts: 4280
Joined: 28 May 2003, 02:00
Location: Azeroth
Contact:

Post by Kronos »

Judas wrote:
Kronos wrote:
Judas wrote:I think that the biggest problem is going to be finding a platform-independent biometrics API... I forsee that we might need to have different code for different platforms, and conditionally build the right code at compile time :(. Not the ideal solution, but it might be the only way in this case.
It shouldn't be that much of a problem if the system is as modular as you intend.
Do you mean for the modular extensibility to be customized in code, or as plug-ins to the compiled app?
I think that modular extensibility to the code will make for the simplest architecture, rather than loading external modules. However, I'm open to the idea of external module loading if you think it will make for a better solution.
I think it makes it easier for deployment, because then you can extend it as required, per "customer". instead of having to deploy everything whether the user intends to use such features or not.

One Restaurant might want to use the stock module, while another won't. but now, you install everything regardless of whether it might be used or not.
Image
Judas
Registered User
Posts: 2118
Joined: 17 Oct 2006, 02:00
Location: Stellenbosch
Contact:

Post by Judas »

Kronos wrote:
Judas wrote:
Kronos wrote:
Judas wrote:I think that the biggest problem is going to be finding a platform-independent biometrics API... I forsee that we might need to have different code for different platforms, and conditionally build the right code at compile time :(. Not the ideal solution, but it might be the only way in this case.
It shouldn't be that much of a problem if the system is as modular as you intend.
Do you mean for the modular extensibility to be customized in code, or as plug-ins to the compiled app?
I think that modular extensibility to the code will make for the simplest architecture, rather than loading external modules. However, I'm open to the idea of external module loading if you think it will make for a better solution.
I think it makes it easier for deployment, because then you can extend it as required, per "customer". instead of having to deploy everything whether the user intends to use such features or not.

One Restaurant might want to use the stock module, while another won't. but now, you install everything regardless of whether it might be used or not.
You know, you may be right. And it would have the added benefit of helping to prevent developers from breaking abstraction, and make unit testing easier... Okay, I'm convinced :). Module loading it is.
'One will rarely err if extreme actions be ascribed to vanity, ordinary actions to habit, and mean actions to fear.'
- Friedrich Nietzsche

'Do not argue with Judas, nube, that would be foolish!'
- D3PART3D
SoulBlade
Registered User
Posts: 11025
Joined: 29 Sep 2003, 02:00
Location: /\/¯¯¯¯¯\/\
Contact:

Post by SoulBlade »

Cool, count me in..although I did c++ last in 2002. :oops:
Core i5 3550 | 8GB RAM | 500W | Samsung T260 | GTX760 OC | 4.56TB HDD space
Judas
Registered User
Posts: 2118
Joined: 17 Oct 2006, 02:00
Location: Stellenbosch
Contact:

Post by Judas »

The use of modules for non-essential features (hat-tip to Kronos ;)) requires a new architecture, so here are the new subsystems:

Data subsystem:
The Data subsystem is a combination of the previous database and entity subsystems. It presents a high-level view of the underlying data source. Because modules now interact with the subsystem directly, data-access security should be enforced at this level. The operations that are allowed to be carried out on the database are dependent on the permissions of the currently logged in user.

Core subsystem:
The core subsystem contains core functionality, such as login/logout, ordering, docket printing, etc. This subsystem is also responsible for initialising and setting up the modules. Responsible for controlling the UI.

Modules subsystem:
External dynamic link libraries (.dll or .so) that can be imported in to the program at run time to provide additional features. Eg. reporting, stock keeping, etc. Modules that require a UI will be required to pass widgets back to the core subsystem, which will then
display them on screen.

Devices subsystem:
As before, provides access to external hardware such as printers, biometrics devices, cash drawers, etc.

GUI:
As before.

The new communication diagram looks like this:
Image
'One will rarely err if extreme actions be ascribed to vanity, ordinary actions to habit, and mean actions to fear.'
- Friedrich Nietzsche

'Do not argue with Judas, nube, that would be foolish!'
- D3PART3D
Slasher
Registered User
Posts: 7525
Joined: 23 Aug 2003, 02:00
Location: 5th rock from the sun.

Post by Slasher »

Judas
Im Guessing we will be using the Open Source Library version of QT? 44ish mb?

Ok, got Bloodshed, Druid, QT... Now I can start messing around and playing a bit... Modular seems to be the best idea.
My BF2142 Stats:
Image


Slasher : Former member of www.PCFormat.co.za
I have reached the end of my near 5 year forum life. Farewell good days...

slasher (at) webmail (dot) co (dot) za
Post Reply