|
Application Architecture 101
Up to this point I have been able to design applications in my head. I would get a vision for what the application should do and how it should do it. I would visualize all the major components, how each of the components would be designed, how they would be tested, what the UI should contain, how the data would flow, etc. Then I would jot down a few notes and be off and running.
Basically, I'm a cowboy coder. I don't use any formal methodologies.
I always knew that someday this would catch up to me and now it has. I'm starting a project (an enterprise database application) that is too large and complex to get a good vision of in my head, and I'm just not sure where to start.
Any of you architecture gurus have an X-step process that you follow when designing applications?
Cowboy Coder
Friday, November 21, 2003
Repeat after me: "No silver bullet!"
Now say it again. There is no methodology that can make it work.
I suggest you read Fowler's Patterns of Enterprise Application Architecture. He basically gives you an overview of the design of an enterprise database app, and then describes 40 or so useful patterns. There's some more information on his web site, http://www.martinfowler.com
That won't tell you much about methodology, but it may give you a bit more insight about the design.
As far as methodologies go, I should state that my employer uses XP to great success. We also work with some really first-rate people, as well.
Hope this helps!
Mike Swieton
Friday, November 21, 2003
Cowboy, you are probably a GOOD designer, if you've been doing it successfully so far.
The idea that using some formal process automatically equates with good design is just not on. In fact, it very easily hides atrocious design. People who cannot design can just step through things and draw little diagrams, so that it looks like they're doing useful work, when the design quotient is dreadful.
This is the reality of a lot of enterprise apps these days.
JM
Friday, November 21, 2003
One thing that has helped me though, is by reading fowler, and others, (I'm particularly liking Java Enterprise Design Patterns), is that they point out a lot of flaws. You don't have to use their patterns, but they point out a lot of quirks that can come up sooner or later, and just having those in the back of your head can be invaluable.
Vince
Friday, November 21, 2003
I think the main issue is not what methodolgy to use, rather what type of conceptual model is suitable for describing the system. My rule of thumb is that it should contain about 15 things on the top level, regardless of wheter you are designing a space shuttle or a toaster. Depending on the scope of the system, you will need to model the parts of this top model with varying formalism. The reason for having 15 things is that around that number is the max normal persons can handle complexity wise without too much brain strain.
The criteria for a successful conceptual model is that you should be able to discuss the main technical trade-offs using the entities in this model. This means that you have to be very specific about what the linse, arrosws, clouds and boxes mean.
Use UML or what ever. I rarely use formal UML for large systems, since I'm not really comfortable with it's symbols. I tend to make up my own, even though that means I have to be very careful to describe the semantics of thise symbols.
I find this easier in most cases since the symbols in the model often seems more natural for the problem space than the more abstract package, class, component etc. For lower level closer-to-code models UML is fine.
hope it helps
/H
henrik
Friday, November 21, 2003
If you're sick of code and fix, I'd recommend "How to be lazy without really trying"
http://magnonel.guild.net/~schwern/talks/How_To_Be_Lazy_Redux/What_Works/slide001.html
Once you've got a handle on that, then i'd recommend XP or another, not disciplined iterative model. But How to be lazy is a great start.
Matt H.
Friday, November 21, 2003
If you don't know where to start then it might be the case that this particular project is bigger than what one person (or at least you) is capable of doing by themselves in a timely manner.
Question: Are you responsible for doing everything or will you be working with others such as an analyst? In other words, tell us more about your job responsibilities.
Maybe a complete software development methodology that you can adapt and follow is what you are really looking for? If not, you can always attempt to adopt certain design practices that a particular enterprise software developer uses. Mike Swieton already mentioned Martin Fowler. This person has written several books that discuss the approach he uses when tasked with designing an object-oriented enterprise software application/system. Peter Coad is another book author who has written several books on designing object-oriented enterprise software applications/systems.
I am sure someone will come along and post a whole slew of appropriate book authors that they feel you should check out.
One Programmer's Opinion
Friday, November 21, 2003
No ARCHITECTURE is so haughty as that which is simple.
--John Ruskin, 1819-1900, British Critic, Social Theorist
Tapiwa
Friday, November 21, 2003
Architecture is easy: you just stare at the paper until droplets of blood appear on your forehead.
-- Unknown
Tapiwa
Friday, November 21, 2003
Writing is easy. All you do is stare at a blank sheet of paper until drops of blood form on your forehead.
-- Gene Fowler
Cowboy Coder
Friday, November 21, 2003
"People who cannot design can just step through things and draw little diagrams, so that it looks like they're doing useful work, when the design quotient is dreadful"
Perhaps, but I hope you aren't suggesting that people who "draw little diagrams" only do it to pretend that they are working.
I use Visio Architect a lot to help me with my designs. I build my ERDs there as well as to design my classes with their UML tools. (C# code primarily)
I don't use all of the UML features, nor do I stick with a specific methodology. But like the original poster says, once you get beyond a relatively small design, it becomes near impossible to keep everything in your head. You need something to help organize your thoughts.
Mark Hoffman
Friday, November 21, 2003
Cowboy Coder, thank you for the attribution. Will update my archive.
Tapiwa
Friday, November 21, 2003
(respectfully)
I've got a pithy historical quote for any situation.
--Tapiwa
Exception guy
Friday, November 21, 2003
It is interesting the way this thread has gone: moderately anti-heavyweight architecture.
There have been other times architecture has been mentioned where "vee must have discipline, yah?" has been the dominant mode.
Anyone consider "hoser" for their safe word?
hoser
Friday, November 21, 2003
Exception guy... I just need to get out more! :-)
I pick my favorite quotation and store them in my mind as ready armor, offensive or defensive, amid the struggle of this turbulent existence.
-- Robert Burns, 1759-1796
It is a good thing for an uneducated man to read books of quotations. . . . The quotations, when engraved upon the memory, give you good thoughts. They also make you anxious to read the authors and look for more.
-- Winston Churchill
Tapiwa
Friday, November 21, 2003
A little more background on me:
I am the sole "in-house" programmer for a 6t00+ manufacturing company. The budget's still tight, so contracting a senior architect is not feasible. The majority of my projects are small to medium sized ASP and now ASP.Net applications. There have been some larger applications that I've developed, but they have grown incrementally over time. I have read Fowler's "UML Distilled", and I am familiar with a number of the tools for design. I need to get started on this soon, so I don't have the luxury of spending a few weeks reading Fowler's new book or any other.
Maybe I'm just in a rut. I just feel like I'm stuck and I need a kick in the ass to get going on it. Something like: start here, then do this, then this, and this, ..., and finally this.
Any one got a simple "Sponge Bob's instructions for blowing a bubble" type of process that they generally follow?
Cowboy Coder
Friday, November 21, 2003
Why not build the system in pieces? If you are careful about putting up good interfaces, most systems can be built piece by piece. Should help with the complexity and get value to your users earlier.
suggestion
Friday, November 21, 2003
Often large systems look horrendously complicated and sap the gumption to just start because they have lots of agregations of tiny complications that seem to descend into fractally complicated combinations.
In reality, those agregations really are fractal, they look much the same as every other kind of software system you've likely come across before.
And if someone smells 'Patterns' at this point, its true but at a greater level of abstraction.
If you can see the interfaces between whole subsystems then you can cleave the development into those subsystems (and later cleave them into smaller units). If you can't see the interfaces then begin with the Use Cases.
But make those Use Cases tell you a story about what a user sees of the application and expects back from the application. (this of course is not the entire system just the user's view but its a beginning).
Then you can begin to descibe the conditions and processes that are going to be required and you'll start to see the recurring pattern of the system . Once you see that pattern the interfaces will fall into place and you'll be less panicky.
In Zen and the Art of Motorcycle Maintenance, Pirsig talks about a class in Rhetoric (is there such a thing nowadays?), that was having a problem in writing anything about a subject, even the view out of the window.
And so he had them write about a brick in the wall and they were able to write and some of them found it hard to stop. The gumption leak was stopped because the noise of trying to comprehend a whole scene no longer overwhelmed the student's capacity to write it down. The whole scene was too strident, they couldn't determine where to begin. Given a tiny subset (that the example is itself self-similar is purposeful) allowed them to control what they perceived and write about it.
System design is like that. Find the story you can tell about the system, then tell it to someone else.
Simon Lucy
Sunday, November 23, 2003
This may be a silly suggestion, I dont know. I dont do enterprise level stuff. What I do, sometimes, is start with the overall goal of the app and the break it down into smaller and smaller parts untill I have a heirarchy. If you do it carefully and work it over a couple of times, this map can be used as a model for the program. Prolly best for procedural coding though.
Like so:
1: Let users edit HTML documents
1.1: WYSIWYG editig
1.2: Source text editing
1.1.1: Manage formating
1.1.2: Manage page layout
1.2.1: Standard textedit features
..and so on untill you have a bigass tree structure. I think this method is originally for writing academic papers though :D but it works well enought for games and stuff.
Eric DeBois
Sunday, November 23, 2003
 Recent Topics
Fog Creek Home
| 
