We don't want to have a stand alone DMS, we rather like to integrate a library/framework with basic structure and functions we can use in our code.
Like versioning, Check-In/Out mechanism.
Based on this and your other posts this isn't going to be easy.
So far you have asked for - Check in /out - Versioning - Rights management - Document attributes, presumably associated with a user.
That would all need to come from somewhere. And it would need to be stored some where.
As per the other request a source control system would handle the first two requirements. But you would need to handle the second two yourself. And I expect that you have other unstated requirements as well.
Overall it suggests that you do in fact want a DMS.
I still relatively new to most things but in particular very new to design patterns and I'm struggling to pick a good pattern for a particular task.
I've chosen to do the Mandelbrot 'rite of passage' by trying to build a 'pluggable' class structure so that I learn more from this exercise than perhaps I otherwise would.
What I have right now looks like (I think) the strategy pattern with the builder pattern (I think) hidden in the constructors. I.e. I have an Imager class that has two members, both of which are of an Interface type. One interface is for the fractal set (mandelbrot, julia etc.) and provides a pluggable iteration / algorithm. The second is for a colouriser which provides a way to turn the results of the iteration into a colour. The set has a member that is an interface type, it is for the specific F(Zn) calculation in Zn+1 = F(Zn) + c. The colouriser also has one member that is an Interface type, it is for mapping the output of the colouriser to a specific colour. I think that is the strategy pattern? But I'm not certain (a) if it is, (b) if I've implemented it correctly or (c) if there's a better choice.
The Imager constructor can take a new set and a new colouriser, The set xcan take a new function and the colouriser can take a new mapper. I think that's builder?
Any help or guidance on a good choice for the job I described above would be very welcome as indeed would any help deciphering what I've already done!
Happy to provide code etc. as required to make sense of the mangled gibberish above.
I am beginning a basic shop floor control system for a client who currently consults giving advice on optimizing manufacturing processes. My problem is that he uses very broad and vague terminology in descriinbign requirements to me, and I would like, ideally, to consult some reference models or diagrams or such systems, but Google research is proving quite slow and not to fruitful.
For example, my client uses the term 'machine' for what I have found out could rather be called a 'work center', and has no term for what I have found out should be called a 'work center'. Adding additional tables required for a nice system design but don't feature in his paper design adds more challenge. What do I call the definition of 'the process done by a work center to produce a product (or BOM item)' etc.
There's no guarantee that the client is using accepted terminology. What you might want to do is to include a definitions section in your documentation that ties the terminology down; we've done this in the past and it's surprising how well it works when the client uses 6 or 7 terms to describe exactly the same thing.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
There's no guarantee that the client is using accepted terminology.
Never mind a guarantee; there's hardly even a vague suggestion that he is using accepted terminology. I'm trying to find a nice taxonomy I can use for candidate terms we can agree on and move forward with.
I found Openbravo[^], an open source ERP system, which is very promising. Will look at it tonight.
Oracle documentation can be found here[^], (EBS, MRP, basically the whole line of their products) and I've been banging my head on the desk for the last 3 days trying to find any documentation even remotely useful.
I'm working on a highly-customised E-Business Suite (so maybe lack of documentation shouldn't come as a surprise), and I need to call some APIs to automate some tasks (No, I don't need help, yet )
All I'm saying is, Oracle documentation is , but it might prove useful for your MRP research terminology
Full-fledged Java/.NET lover, full-fledged PHP hater. Full-fledged Google/Microsoft lover, full-fledged Apple hater. Full-fledged Skype lover, full-fledged YM hater.
Last Visit: 31-Dec-99 19:00 Last Update: 29-Mar-17 12:19