|
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...?
|
|
|
|
|
Xpnctoc wrote: Does having a larger executable result in slower app launch time?
Probably, but unless you are loading and unloading thousands of times a minute it is unlikely to be an issue.
Xpnctoc wrote: When exactly to statically linked DLLs get loaded
On first call as far as I am aware.
|
|
|
|
|
Xpnctoc wrote: 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.
Without a context that is meaningless.
For starters .Net and Java always do dynamic loads.
Second performance is impacted much more significantly by requirements, architecture and design for most business applications.
Third some business required functionality cannot be implemented with dynamic loads. For example hotloads of a 24x7 server.
|
|
|
|
|
Well I guess I could have been a little clearer, but since, as you said, .NET and Java always do dynamic loads, that's obviously not what I'm talking about. I'm talking about plain old C++. I also did specifically mention video games and real-time simulations.
|
|
|
|
|
Xpnctoc wrote: I also did specifically mention video games and real-time simulations.
amic calls. Could be mistaken though.
Presumably you are familiar with 'video drivers' on PCs? The things that directly drive all the video on the box. They are pluggable components in the OS.
|
|
|
|
|
Xpnctoc wrote: 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.
During initialization, one creates a method-pointer, say, a delegate. During execution, you fire it. Can be pretty darn fast.
Xpnctoc wrote: But the issue seems a little more fuzzy between #2 and #3. Is there a significant advantage to one over the other in general?
If your requirements require such speed, you'd be best of in using QNX[^].
Bastard Programmer from Hell
|
|
|
|
|
I thought about using function pointers. But then the sheer number of them I would need to generate and maintain at application start-up seems like it would be more work that it's worth. Might as well just stick with static linking or a static library.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
