|
ASCII Art is a paint, ain't it? 
http://www.codeproject.com/Messages/4037183/Design-Quandary-v2.aspx[^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
My first thought ... before reading the other responses to this message ... was that the end-user should add "layers" via a menu, or other UI element, until the limit is reached. Which might leave more room for UI ?
But, if it is important to you that all six possible layers be presented, then an alternative to going the route of emulating "layers" in PhotoShop, or whatever, might be to use an "Outlook" style "TaskBar" control, where one, selected, layer ui expands full-size, and the others are in their "collapsed state."
This type of control is so easy to simulate in WinForms, just using contained panels inside a panel, docking, and a mousedown event for all contained panels that adjusts their vertical sizes.
It seems to me that having a series of checkboxes that control only whether the "layer" has the possible transformations (Flip, Mirror) applied to it is kind of "counter-intuitive." I think I'd either move those checkboxes inside the layer UI's, and title them 'Allow Transform' or come up with ?
Having a 'Restore' button next to the graphic transform buttons also doesn't feel quite right to me; what about putting that next to the 'Save' button ? I should disclaim this suggestion by saying I don't really know if 'Restore' applies only to 'undoing' the last transform, or more 'global' application state.
best, Bill
"Beauty is in the eye of the beholder, and it may be necessary from time to time to give a stupid or misinformed beholder a black eye." Miss Piggy"
|
|
|
|
|
http://www.codeproject.com/Messages/4037183/Design-Quandary-v2.aspx[^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Hi,
We are studying the implications of upgraing our software for use on Windows 7. We currently support XP only. We provide bespoke software that acts as cash register for a certain industry. None of our customers has their cashregister connected to the internet, a situation that will not change much in the forseable future. We distribute all our software by CD. Say we register a certificate suitable for signing, and sign our binaries. How does Windows 7 check the certificate, and whether or not it is revoked without an internet connection.
Is there another way of avoiding the anoying warning boxes.
Regards,
Bram van Kampen.
Bram van Kampen
|
|
|
|
|
There are so many books/standards on how to document architecture. But I am not aware of any book/standard on how to document (detailed) design.
Example:
The architect creates on documentation for "OurServerComponent" with all the high-level views according to any standard ( e.g. IEEE1471).
But where and how do I have to document the low-level-design of my own 5 classes?
modified 24-Sep-11 13:00pm.
|
|
|
|
|
Visual Studio class diagram, Rational Rose, UML diagramming tool...not sure if that is what you are after
CodingYoshi
Artificial Intelligence is no match for Human Stupidity.
|
|
|
|
|
Hi Yosh,
no this is not what I'm looking for.
I'm looking for some guidance(or standard) on how structure design-documentation in the best way.
For architecture there are clear rules available now (IEEE-Standard or beyond-view from SEI).
But how and where do I organize/structure the UML diagrams for my 500 classes? My diagrams were intended to be used not by me but by my audience. My colleages put them automatically in the trash, because nobody can see the complete picture from all of my details
|
|
|
|
|
What CodingYoshi says is right. UML is the standard. You may wish to preface your class diagrams with a component diagram. Then break the classes up accordingly. If you have 500 classes in a single library, this will be a valuable exercise and ask questions about the current design.
There are books re documentation. I teach this subject and wrestled with the same question. The answer is there are guides but no standard. Each project is unique, there audiences vary. Documentation needs to be tailored to the project and audience.
"You get that on the big jobs."
|
|
|
|
|
Of course, UML is the standard for modelling/diagramming. But it says nothing to the "strategy for documentation-structuring".
Hard to explain what I want, let's try with an example:
I have written my architectural documentation Ieee1471-compliant, with all the viewpoint, views and the like. But now I have to document 500 classes/lower-level-components. It should not be part of the architecture-document (clearly kept out by ieee-guidance). But where else should I do it? Should I create a document "MyProjectsSwDesign.doc"? And which content/structure does it have. I have so many books on design, but all of them explain how to do single diagrams in the best way, nothing else.
A similar topic, but at another area, requirements-engineering/management, is the SRS. Also here -the SRS templates from Ieee -is an international standard/method
modified 26-Sep-11 13:10pm.
|
|
|
|
|
Just a thought, maybe you could use a tool like Sand Castle[^]
That way the code is documented at the same time. Unless IEEE compliance is a requirement, I wouldn't worry to much.
"You get that on the big jobs."
|
|
|
|
|
seems all have the same lack of info as me
|
|
|
|
|
I didn't even know about the spec that you originally mentioned.
I have always rolled my own process docs.
|
|
|
|
|
for detailed design, I also roll my own docs
|
|
|
|
|
There are some software design practices available, some of them are related to the industry that the applications are designed for, for instance there are specific IEEE standards the apply to medical devices. As for standards specific to documentation I'm not familiar with any standard, as long as the software practices are applied correctly.
However a good luanching point would be a site such as the IEE computer society. Here they provide some good information.
http://www.computer.org/portal/web/swebok[^]
The FDA also provides some guidance as to what should be documented for software requirements and design descriptions. Here is a link to a pdf file from the FDA:
General Principles of Software Validation[^]
Cheers!
It was broke, so I fixed it.
|
|
|
|
|
Hi, I need some thoughts on a design for at car rental service.
Multiple offices exists in the company. An office can move a car from its car pool to another office if demands in their region changes. A car movement can be based on seasonal reasons and therefore a move can be scheduled in advance.
How do I solve the double relationship that would exist when a scheduled move has be invoked?
The car still belongs to office 1 until a certain date. But the car also belongs to office 2 when that date has been reached. Meaning that office 1 can still lease it out until that date and office 2 can start leasing it out from that date.
My first thought is to create a many to many relationship like this.
CARS
--------
ID | Name
1 | Ford
STATION
---------
ID | Name
1 | NY
2 | BOS
STATION_CARS
-------------------------------------------------------
StationID | CarID | DateAvailableFrom | DateAvailableTo
1 | 1 | 01.01.2011 | 01.11.2011
2 | 1 | 02.11.2001 | 01.02.2012
But i also need to register the "scheduled move" object, making it visible to the staff and deleteable, in another table. Seems kind of messy so i wonder how others have dealt with this scenario.
Any thoughts would be much appreciated.
|
|
|
|
|
I am no expert with this stuff. But I would personally think that a "Scheduled Moves" table (a junction table) would be the best solution. I say this based on what I have learned over the past several months.
Scheduled Moves
SourceStationID, DestinationStationID, CarID, DateEffective
Those are the fields I would see in the junction table. Just my opinion.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Homer77 wrote: Seems kind of messy so i wonder how others have dealt with this scenario
Normalization, to BNF (3NF+); following those steps always leads to a decent relational design.
Bastard Programmer from Hell 
|
|
|
|
|
Hi everyone,
I am doing some research on SOA design tools. Would you mind telling me some most popular tools, either open-source or commercial ones? I would appreciate your replies.
|
|
|
|
|
At present there are no established tools available for SOA design. IBM has a tool but dont know how successful it is. This may be an interesting read for you: http://soadecisions.org/soad.htm[^]
Eclipse also has a product on this: http://www.eclipse.org/stp/[^]
I have not used a pure SOA design tool as such, still using the CASE\UML tools to define the design. I believe it would still take some more time to have a well defined SOA tool.
|
|
|
|
|
Hi ,
I am having a requirement to develop a project related with mechanical engineering computation. I need a suggession , will it be a good practice to go with VC++ and COM .
If the project will not require multiple change request then in this case which pattern should be best suited ?
If I use COM what will be its benifit?
Any suggession will help me my thought process . Thanks
|
|
|
|
|
From what you posted COM has nothing to do with it.
You haven't stated anything that has anything to do with patterns.
If you understand algorithms, math, the engineering domain and C++ very well then in terms of performance you might be able to produce a faster solution with C++ than another language. Especially if you profile it (presuming the design is ideal to start with.)
This applies ONLY to the computations, and not any other required functionality.
pandit84 wrote: Any suggession will help me my thought process
Start with designing a solution and do not consider an implementation (C++/COM) until you have that design.
|
|
|
|
|
|
General architectural question: From what I've been able to gather, there are basically 3 approaches to handling code that is reusable across multiple projects:
1. Dynamic linking: build a DLL, use API functions like LoadLibrary() and GetProcAddress() to link to the desired functionality at run time.
2. Static linking: build a DLL, use a .lib file to establish the external proc addresses at compile time.
3. Static library: build a LIB only, use as input that becomes part of the .exe file for a given project.
It seems pretty obvious that #1 would represent the worst execution time because of the need to look up a proc address before calling it.
But the issue seems a little more fuzzy between #2 and #3. Is there a significant advantage to one over the other in general? What about in high-demand applications such as video games or real-time simulators, or where the library function is expected to be called dozens of times per second?
Thanks for your help.
|
|
|
|
|
I think that in performance terms there is very little to choose between 2 and 3. The trade-off comes when you have lots of apps running in your machine - using a DLL you have only one copy of each library function in memory, with the static library you have one copy for each app.
|
|
|
|
|
That's kind of what I thought. Does having a larger executable result in slower app launch time? When exactly to statically linked DLLs get loaded -- on application start, first call, etc...?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
