|
Pete O'Hanlon wrote: It depends what she was putting in
Yes, obviously she can't figure out to put in the same words she put into her post here. That was my point. 
It seems to me that anyone wanting to know anything about Agile and has not yet found Amblers site just isn't looking.
led mike
|
|
|
|
|
Hell - even Wikipedia has an article or two.
|
|
|
|
|
Hi Everyone,
So I'm stumbling my way through trying to design a system that I'm working on, and I realized that just as there are patterns that are often talked about in OO design there appears to be common questions asked when thinking through and validating the design.
At this point, I'm not exactly sure what they all are, but it seems I'm asking the same questions over and over in order to make sure my design works.
So... what questions do you ask yourself when reviewing a design?
|
|
|
|
|
I generally ask questions like:
What problem is this attempting to solve?
Does it solve it?
What other ways could this be done?
Are they easier or a better fit?
Is it necessary, or are we just adding fluff?
Is this maintainable?
And the questions to ask at the end:
What's missing?
How do we accept this (what are the acceptance criteria)?
|
|
|
|
|
Pete O'Hanlon wrote: I generally ask questions like:
What problem is this attempting to solve?
Does it solve it?
What other ways could this be done?
Are they easier or a better fit?
Is it necessary, or are we just adding fluff?
Is this maintainable?
And the questions to ask at the end:
What's missing?
How do we accept this (what are the acceptance criteria)?
And the question after the question at the end:
What's for lunch?
|
|
|
|
|
Along the lines of what Pete posted you can look at the Agile and RUP[^] analysis to see those and more considerations along with suggested timing of when questions need to be asked and asked again. Be sure to check out the links in that page, it's just a starting point.
led mike
|
|
|
|
|
Does it satisfy the requirements of a good user interface (assuming it ultimately leads to software someone uses and not a machine or other software).
I tend to think about the requirements and the user experience first, even mock up a UI on paper. Try to eliminate as much work or complexity on the part of the user as possible so that the user can focus on accomplishing *tasks* rather than manipulating data.
Once I have that decided the rest is easy because it simply has to meet the criteria of satisfying the task oriented design decisions.
If you start from the bottom up on the other hand then you are faced with uncertainty at every level and ultimately could end up with a very computer programmer oriented design but not a user friendly design. (i.e. the end user get's exposed too much to the inner workings of tables and databases and how the computer and software works instead of simply being able to view it as a machine that helps them accomplish the tasks they already know and understand).
This is the essential pivot point between what users percieve as "good" software and what users perceive as "bad" software.
"The pursuit of excellence is less profitable than the pursuit of bigness, but it can be more satisfying."
- David Ogilvy
|
|
|
|
|
I was just commenting on this[^] article, and said:
"My general rule is that design should be top-down, but implementation should be bottom-up."
Has anyone else come to this conclusion?
Or have reasons not to do it that way?
|
|
|
|
|
There is no cookie cutter rule or process or whatever that I can tell. The needs vary from project to project and even more so from company to company. If there is anything close to a cookie cutter map of project activities it would be this one.[^]
PIEBALDconsult wrote: My general rule is that design should be top-down
That doesn't really work with large systems having a relational database back end which is very common. Starting with the model and designing off of that for the different sub systems of the system is normally the way it works.
led mike
|
|
|
|
|
led mike wrote: Starting with the model and designing
That would seem to imply that you've already begun implementation -- creating the database.
Ideally, one of the last steps of design would be defining the database schema, then the first step of implementation would be creating the database and work up from there.
In many cases (including my current project), this can't really be achieved because the system accesses third-party databases, but there may still be the need to define views and such. This is true of any off-the-shelf product to which one must interface.
|
|
|
|
|
First I reiterate, my example is for a large business application. This means different project types could vary greatly from what I am saying.
PIEBALDconsult wrote: That would seem to imply that you've already begun implementation -- creating the database.
No, you start by modeling (design phase) the model. So..
PIEBALDconsult wrote: Ideally, one of the last steps of design would be defining the database schema,
Yes, I am saying from my experience one of the first things you do is model/design your model and part or all of that can end up being implemented in one or more database schemas.
led mike
|
|
|
|
|
PIEBALDconsult wrote: "My general rule is that design should be top-down, but implementation should be bottom-up."
I've ran into something similar in my own experience--I've come up with some pretty good solutions when the design specifications were done from the top down, and when the implementation was done from the bottom-up to meet those specifications. Generally, I don't introduce any patterns or any preconceived architecture until I can get the simplest prototype up and running (using standard structural programming techniques) and then refactor it and generalize it at various points until a design emerges.
It works for me in most cases, but the trade off in this case is that this approach assumes that you can pretty much refactor your way out of anything--and this might not be the best way to do things if you have a team that doesn't have much experience in refactoring. Without refactoring, the approach I mentioned above will quickly descend into a "Code & Fix" scenario, so overall, I would recommend it if you can guarantee that you can keep your code base relatively clean..
|
|
|
|
|
I don't know the meaning of "refactoring".
No, seriously, I have to find a definition of "refactoring".
Chances are, I do it, but I just don't know it.
|
|
|
|
|
|
Yes, I've come to the same conclusion over the years. In fact I've come to believe in a form a form of 'undirected' development sometimes known as z-programming. The concept is that you keep a proportion of your team busy all the time coding from the bottom up without any particular spec or goal, simply taking the existing set of low level facilities, be that APIs or COM objects or graphics primitives and combining in ways that seem like they might be useful, creating data structures and containers and algorithms that conform to best practices but don't have any particular application in mind. You do your design from the top down and create at least one empty shell style prototype which consists mostly of the UI of the product and any product specific novelties. Application development then becomes a process of filling in the functionality using the generic tools you've developed. One of the key things being no-one is allowed to reinvent for a specific app anything that's already available in the codebase for generic usage. You soon find if there's an area your z-programmers have been ignoring and they can be directed to concentrate on it. This does a number of things, it keeps programmer busy, it makes them write truly generic code, it allows them to concentrate on what they're good at and to be creative, it ensures that re-use ( a goal but seldom a reality ) actually happens.
This is all great for desktop application but if and how it might be applied to web based applications is still amystery to me 
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Matthew Faithfull wrote: z-programming
Huh, I hadn't heard of that. I do some, but I didn't know it was a "good thing".
|
|
|
|
|
The link is now dead but if I get the drift of what's being discussed I have to say design should *ALWAYS* be from the top down.
(One point I need to make that I come from the background of a small company that designs, builds and sells software globally, we don't have teams to do this or that, there are very few of us and we each do everything, no one is a specialist "designer" or strictly a "coder".)
Designs that are bottom up are noticeable (for all the wrong reasons) in an instant because they focus on how the computer works, not how the user thinks. A user thinks about tasks they want to accomplish, a programmer thinks about how the computer will process information.
If the programmer is let loose to do the design and they are a rookie with little exposure to real world feedback on their design they will often and naturally think about the data first going bottom up, it seems natural to start at the bottom (the stuff they know best) and work their way up to the real world application (probably the stuff they are the least comfortable with).
After some real world seasoning and feedback (and most important of all time on the support queue) hopefully they will start to think about the tasks the user needs to accomplish in the fewest steps and simplest method to get the user there with no thought at all to how it will be implemented during design, mock up a UI because it helps even on paper, run it past non programmers etc.
Only then start thinking about implementation with the goal of satisfying the task oriented design.
As far as implementing it, I don't know if it matters that much as long as the goals are satisfied.
I prefer a "literary" implementation, neither top down or bottom up. Working on a huge project with a small team can be overwhelming, it's easier to work on rough details and refine later.
I plot out rough outlines on paper first, like chapter headings, code those items first so I have everything covered but not fully implemented, then go in and refine each one, perhaps adding "section headings" for each "chapter", filling in the bits between the chapters. In this way you always have a mental feeling that you have the whole project covered and the rest is just refinements. It becomes far less overwhelming and seems more like bite sized chunks.
For example let's say I have a large project with hundreds of business objects, I would create all the objects first without any real code implementation, look it over think about the design, make changes as necessary, try to get it as quickly as possible to the point where I can roughly make a real interface to try out the workflow, then go in and fill in all the CRUD methods (create, read, update, delete), then go back in and add business rules or further refinements.
Of course this is often based on a data access layer that I've already developed some time ago so I guess in a sense if you are starting from nothing then you do need to do a little bottom up first but you can't simply go in a straight line from bottom to top. (Unless it's been planned far *too* much and too detailed to begin with. Always a bad mistake to make, some looseness is required.)
"The pursuit of excellence is less profitable than the pursuit of bigness, but it can be more satisfying."
- David Ogilvy
|
|
|
|
|
I tend to do modelling and implemention top-down.
Okay, I tend to implementation a bit randomly, depending on how much research is necessary.
Though, in general I start by designing the forms, then continue with the functionality necessary to fill them and finally get the background stuff the user doesn't notice.
When I write code I always keep in mind, what it is supposed to accomplish, not the details at the bottom but ultimately the results on top.
John C wrote: For example let's say I have a large project with hundreds of business objects, I would create all the objects first without any real code implementation, look it over think about the design, make changes as necessary, try to get it as quickly as possible to the point where I can roughly make a real interface to try out the workflow, then go in and fill in all the CRUD methods (create, read, update, delete), then go back in and add business rules or further refinements.
I tend to do the same, in order to set the basic structure for the application.
|
|
|
|
|
I am looking for ideas for avoiding contamination of proprietary code by a GPL application. I need to be able to use the GPL application without opening up my code to GPL. I would like to get feedback from folks who may have encounter this issue and considered using some RPC mechanism to establish client/server type architecture potentially using shared memory for data passing. This is for a multimedia type application. Thanks. Fred
|
|
|
|
|
If I understand GPL correctly, you are toast either way.
If you derive, use, intaract with a GPL product you have to go GPL.
The only way I know of to bypass it is to ask the developers if you may buy the right to use it w/o GPL.
|
|
|
|
|
Simple answer - find an alternative component that doesn't use GPL. Maybe find one that uses LGPL or is closed source. You can't arbitrarily decide to ignore the GPL license - the author's have decided to license the component that way, and if you use it you agree to abide by the decision.
|
|
|
|
|
Fred Garvin wrote: avoiding contamination of proprietary code by a GPL application
This sounds like a twist in reality, are you an IT manager? 
Anyway, here are some possibilities. First, there speaks nothing against using GPL-ed applications, e.g. using the Apache web server does not require your web applications or content to fall under the same license. Secondly, consider contacting the author (copyright holder) and ask if you may purchase the product under an alternative license, e.g. some software is dual-licensed to fit proprietary needs. Finally, consider going open source yourself and possibly benefit from community/developer feedback.
Hope it helps.
/M
|
|
|
|
|
That is in part because the Apache web server is licensed under the Apache license - which is not very much like the GPL at all...
|
|
|
|
|
I've been using the following pattern with transactions for some time now, without problems.
try
{
}
catch ( System.Exception err )
{
}
I have been operating under the assumption that if Commit or Rollback is called for a non-existent transaction, then throwing an exception is the right thing to do. The Commit and Rollback in question are my methods that check for null and throw InvalidOperationException rather than NullReferenceException.
But recently I've run into some problems. For some reason (which I still need to investigate further, but I have an idea) the Commit fails because the transaction doesn't exist, which means the Rollback will also fail. Having an exception thrown through the catch is, of course, nasty.
I could change the methods to raise an event instead of throwing.
I could filter the exception to log but not rollback on certain exceptions (like InvalidOperationException).
Has anyone else had to deal with this situation?
Does anyone have a better pattern for this?
|
|
|
|
|
Well, the transaction can easily be checked by looking at the transaction on your command, e.g
if (myCommand.Transaction != null)
{
myCommand.Transaction.Commit();
}
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)