You need to start learning Software Engineering, and in such a course you can learn those diagrams. Typically you would be needed to learn how a user would be using the application, how the data flows, and how application works. So there is a diagram for all of those, which you must know. It would be best, if you could join a local institute where they train and teach you, online and self-paced would still be confusing.
As already pointed out learning UML is a good starting Point for a object-oriented language like Java.
I can recommend the book "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development" by Craig Larman [^] to learn about how to actually apply modelling in real scenarios.
If you are an experienced developer then at least some of the UML (presumably what you are referring to) should make sense. Like class diagrams and sequence diagrams.
Some of the others like package diagrams are ignorable. Only time I ever used that was in a tool specifically intended to be a full UML code generation and IDE (and it did not succeed.)
If you are doing this for a class, and not a job, you will not have the necessary experience to get the point of most of them. So you are going to just need to memorize and hope. Even so the class diagram should at least be generally obvious.
For me the only ones I use, as a developer and architect, are class, sequence, use case and rarely state. Keeping in mind of course that an Architect or Design document is not defined only by the diagrams but also requires a lot of verbiage to explain and tie the parts together.
I'm not much of an Architect so I need some advise.
We have a home-grown very badly designed queue that buffers data for a legacy system. The data is sent to the queue and stored in a sql table then the host service takes the top item and attempts to send it on. Do not assume the receiving legacy systems are .NET or even SOA... I may need to drop this stuff to an XML file. Fun right? On success, the queued item is archived.
I have the opportunity to rewrite this. I want this buffer to handle any type of request (not a rigid data structure) and we need to report on the meta-data in the queue. So, I basically want to store the message or serialized object in an XML field and keep meta data in a separate table to meet the reporting requirements.
I've been looking for a design pattern (factory?) that I can follow or an example project on how to do this. Please make a recommendation.
I'm also aware of msmq. I doubt the decision-makers would allow me to go this direction but this is my one opportunity to get their buy-in. Can someone help me by telling me if msmq is a good solution for this and, if so, point out an article as to why? I assume msmq can only interact with web/wcf services. Is that true?
Be aware that msmq has a hard limit on the size of messages. Slightly less than 2 meg if I remember. You can break it up and send it but that introduces more complications, again as I remember, error handling becomes difficult in those cases. And is impossible for some routing strategies.
Additionally routing for msmq is built in which means it attempts to find its own route. And you must be aware of this as it can have significant impacts if firewalls are in place in production and the correct ports are not opened (seemingly everywhere.)
Joel Palmer wrote:
The data is sent to the queue and stored in a sql table then the host service takes the top item and attempts to send it on
Why is that a problem? It means that back ups are already handled. How are you going to handle backups if you put the data into the file system?
Joel Palmer wrote:
I have the opportunity to rewrite this. I want this buffer to handle any type of reques
You didn't specify any other actual request in your problem description. Don't generalize without real cases. It complicates things and at least some times makes actual usage with other cases more difficult rather than easier. If you do have actual cases then you would use that to first determine your requirements.
That said a message queue, of some sort, is already a general solution. They also support persistence (ones I have seen do) in either the file system or databases. You would need to look for a guaranteed delivery solution for your messages. That is something that must be specifically configured for any queue.
the App is a speaking keyboard
and when a key is pressed the sound should
So the wave data has to be available in memory.
The App should start fast.
The only reason to port from MFC to WPF is
to have more beautiful dialog.
Because I see, with the resource techniques the access to data implemented with resource-techniques are only possible with streams,
I want to prepare the data, e.g. by declaring long arrays.
So presuming that the arrays do not exceed some limit in .Net itself, which you would need to test...
1. Create the array(s).
2. Write code that wraps the array(s) in a Stream.
You might need several classes for 2 depending on the exact stream that you need but you can start with the 'MemoryStream' class and research it from that.
I would expect that you should experiment with creating a new stream each time or attempting to keep a single instance. The former shouldn't be a problem because you are using a memory blob so the object cost is low.
If there is some reason that your data is unusual you might need to create your own stream class.
You mentioned streams so I provided a solution that allows for a stream but a in process one (not file based.)
With speech you are going to need to pass a large amount of binary data using some api. Any implementation is either going to do that via an array or a stream even if the exact implementation is hidden.
Presumably you have an API of a library not under your control and you are using it. If it takes a stream then you pass it a stream (my in process solution.) If it takes an array then you pass an array (which you presumably already know how to create.)
If you add a Gb worth of data, and change some code so it needs be recompiled, then yes, it will take long. If you don't want that then make sure it isn't compiled each time by splitting it into its own assembly.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]