A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I'm very happy writing code from a design or even a set of requirements. I'm happy writing a design (i.e. UML) from a set design which an architect has come up with.
But I'm newer to the field of actually being the architect. I'd love to know how more experienced people approach a new application. I'm finding it's tricky knowing where to begin... I came up with some subsystems or major functional areas which are important as my first task. My definition of being the architect is similar to being the designer, coming up with UML at a higher level... so I'll figure out the classes or groups of classes which comprise each area, but not what those classes look like, and I'd do sequence diagrams showing how pieces of the application should interact.
I'm not sure this is the kind of thing you can BE taught, what do others think? Are there good resources in the form of books or websites?
> I'm finding it's tricky knowing where to begin... I came up with some subsystems or major functional areas which are important as my first task.
Yes, but a related technique if I need to be more formal is that I start with the data: a "data flow diagram" models the system as a set of data stores (including internal storage and external device), plus a set of data transformations which move data from one store to another.
> I'm not sure this is the kind of thing you can BE taught, what do others think? Are there good resources in the form of books or websites?
When my employer wanted to teach me this in the 80s, they sent me to a Yourdon seminar called "Structured Design of Real-Time Systems" (and then gave me an opportunity to practice).
"Data" and "data store" in the sense that I referenced it above is more than only the data in a database: it also includes data displayed on the end-user's monitor, the internal state of various run-time objects, the objects contained within collections of objects ... essentially, the system's input, the system's output, and the system's internal state.
I find "data flow diagrams" a slightly higher-level view than the usual UML class and detailed sequence diagrams: I find they help to decompose a system into components, after which the components can be designed using OO.
Anyway if you're looking for someone who has taught this, you could look at what Ed Yourdon for example has published.
You have to be constantly critiquing the architectures handed down to you from the point of view of implementing. That wealth of applied experience will teach you the thought process which is really hard to describe as step 1 step 2 and step 3.
Friday, January 04, 2008
I think it *can* be learned, but it *can't* be taught.
By this I mean that there is no class/course you can enroll in, there is no book/textbook you can buy. No online training materials -- basically there's nothing you can purchase or pay someone that will teach it to you. Sure, you can pick up little tidbits here and there, some good guidelines and rules-of-thum -- but, in the end, there is no "How to be a System Architect in 21 Days" that's ever gonna teach you what you need to know to be successful.
The only way to learn these skills is by *doing*. Jump right in and start doing it. Figure out what works and what doesn't. Start small, with littly toy/hobby projects and work your way up from there. Start reading everything you can about the subject. Blogs. Whitepapers. Books. Technical manuals. You name it. Immerse yourself in system design/architecture for the next 3 to 5 years and you'll know by then if it's working or not.
There is no shortcut for this one.
Friday, January 04, 2008
Just reiterating what Chris says, everything is about the data -- where do you put it, what changes it, how does it get from here to there. After you've figured out the data flow, you decide on the structures or objects holding it. Then you go to the user side and figure out how the user will see and modify it.
That's how it is with games, simulations and real-time control software, anyway -- I've never done database stuff but I'd imagine database apps would be the same.
Friday, January 04, 2008
I am not that experienced either but the way I write personal software is to not design it. I use micro spirals. Something as small as open a window, put a button on a screen. After you get somewhere a spiral will be to redesign what you already have to build that next feature. Then you have a spirals to clean up interfaces and separate concerns.
Friday, January 04, 2008
I think about the problem and the requirements, jotting them down if necessary (level of formality depends on the project). This might include use cases.
Then I think about possible solutions, grabbing out the entities and data (much like the data flow diagram mentioned earlier). I might do this in Visio, or I might just do a sketch on the whiteboard. If I have technical limitations (e.g. interfacing with an existing system, forced to use a specific hardware deployment or language), I consider them here.
Then I typically let it gel in my head a bit, and then start identifying functional modules (be they classes, libraries, higher level chunks-of-features), and how they relate. This can get more technical, to the point of specifying rough interfaces, or narrowing down technology options, or drafting APIs. Schema drafts are done here too.
Once the overall higher level architecture is roughed in, it can be broken down into milestones or other delivery units, and either given to other architects or technical leads to further detail and implement, or I do it myself.
At this level it can be "design by code" or it may require further focused architecture work, in the case of somewhat dense logic or thorny problems that have to be figured out.
There are reviews at every step, and even during implementation you will find things you didn't consider, or requirements change, and you have to refine your higher level model appropriately.
It's both a craft and a science. Different designers have their own style as well.
Determining "Where to start" can be a challenge. I generally start with the data storage and move up and out from there. Sometimes, especially if I have a very use-case or user-interface driven set of requirements, I'll start there and boil the data out, designing down.
Friday, January 04, 2008
I worked with an old software architect that had the CRC system: Class, Responsibilities, Collaborators.
Basically one to four of us would walk up to a white board and say, "what does this thing need to do"? For each high level feature we're make a circle and label it ("it needs to store data, ok we need a data manager", "it will have a gui, ok we have a gui object", "it will have interaction with the client, ok we have a client manager"). Each circle/object represented a very high level feature/function of the app.
Then we'd iterate and look at each object. What does the data manager need to do? We'd break it down into smaller objects (actually, we'd erase the original object and replace it with a number of smaller objects). Lines would be shown to represent data flow/collaboration between other objects.
After a few iterations, we'd write down the CRC, ie each object's name (Class), responsibilities as we understood them, and the Collaborators (the other objects it would work with).
I was truly amazed to see how well this worked. Within an hour or two we'd have a high level architecture and a decent start at a high level design for very complex systems. I still use the system today.
Friday, January 04, 2008
I'll only cover software architecture and not system architecture which is different.
I would start from user stories. List down all the user stories for a particular release and then a story for implementation.
The story should have a business reason and therefore it will touch every aspect of the system. Instead of doing horizontal development (layer by layer), I tend to go for vertical layers (see Tracer Bullets ).
You can then jump directly to coding and try to come up with a workable system based on that user story. At this point, you should also develop, decide all the non-functional aspects of your system like logging, security etc.
Once you have the system, you can then refactor the Domain model into its own layer and evolve on that.
Also found a link on TopCoder forums today.
Well, first you get out your copy of Microsoft Powerpoint and make a lot of pretty pastel boxes. Then you start to label the boxes. Nested boxes with lots of unlabeled arrows are also good. Then call a meeting to present your single overhead of pretty pastel boxes to the engineering staff for not less than 3 hours. Be sure to answer all questions with "We still have to work that out."
Man! Have I seen too many of those.
The more software architectures I do the more I have come to realize some elements of a good software architecture. They are:
1. The whole problem has been addressed. Be wary of architectures that have a TBD component to them.
2. The interfaces between the elements are well defined. If the reason some functional element is in one area and not in another is not painfully obvious, it is likely that the design has not been worked on enough.
3. New ideas have been proven. By this I mean that new technologies have, at a minimum, been taken out by the architect and been shown to do what they are supposed to do. No dancing around with "The product *claims* they do this, so we will go with this" or worse "The product *claims* they will do this in the next release."
4. There is a project vocabulary which everyone understands and uses. There is an on-line dictionary to assist those who are not fluent. I can't tell you the number of times there have been long and loud arguments between people in violent agreement with each other but using different words.
5. The requirements around speed, auditability and up time have been designed for *up front*. Attempting to adjust for these later will *always* be more painful than designing it in from the start. If there is a speed requirement and the architect has not done a real speed proof-of-concept test, I would be very skeptical of the design.
6. Architects are human. They make mistakes. Good architects admit their mistakes and issue corrections. Bad architects pretend that the mistake did not happen.
You guys who've been in a 3 hour planning meeting with one powerpoint slide have no idea how bad it can get. You can spend years on design, with very little to show for it. (Don't do this.)
I also don't think there's any golden hammer for design. Big projects require different approaches from small projects. Sufficiently small projects can get away with almost anything. Sufficiently large and unwieldy projects can fail no matter what you do (Longhorn anybody?)
Here are a few principles I've found work for me.
a) Get the big picture right from the start.
b) Don't stress the details. In fact, don't have the details in the design at all if you can avoid it. The important things will make the design big enough as it is. The difference between design and code is all the unimportant stuff you leave out.
c) Divide any big design into smaller packages with interfaces between them. Keep the inside of each package private to that package, and keep its design private too. In fact, for first cut, don't bother to design the packages too much at all - provided you're confident each one can be done.
d) Each package may have its own architect. The others don't need to know. Keeps the main design smaller. Coders should specialise too.
e) Define significant interfaces. Try to get them roughly right, and keep them up to date and documented as they change (which they will).
f) Don't build big projects in one go. Find a way to make early versions that you can test. You can't test Powerpoints, so build something that at least sort of works as soon as possible. You could even show it to the customer. Then keep adding to it, and testing as you go.
Sunday, January 06, 2008
I guess the issue I have is that I see architure as just an extension of UML design. And I approach design thinking "well we need a class to do X and a class to do Y...". But with a whole application, this seems less optimal. I've actaully taken the plunge by just deciding on some key classes, figuring I can develop it from there. At least having something is better than a bunch of ideas in my head, surely!
> I guess the issue I have is that I see architure as just an extension of UML design.
Don't think that if something isn't expressed using UML, then it isn't architecture!
An invaluable thing which *can* be learned is the tool, syntax, notation, or grammar that you use to express an architecture. You're using UML class diagrams. I suggest that a higher-level type of diagram might be useful.
Look at http://www.yourdon.com/strucanalysis/wiki/index.php?title=Chapter_9#Make_Sure_That_Your_DFD_Is_Logically_Consistent for example.
First off I'm a computer science student so I'm only just learning all this formal stuff. Most of the software I develop isn't huge in scale and I'm a lone developer but this is the usual formula I use:
- Design the data model and a basic ER diagram
- Design the UI
- Write a list of features (not in too much detail)
- Start coding
For each feature on my list I leave it in a general description (usually just what it does) until I start working on it, at which point I start going into detail, making a list of all the tasks required to implement that feature in small manageable chunks.
What you choose is always up to personal preference, but I find the idea of designing an application out in detail before I write code to be a waste of time. You spend ages doing work and end up with nothing to show for it. You've got a nicely detailed spec but nothing you can sell and test and get feedback from users about. And from my experience you end up hitting problems during coding you didn't come across during design so you have to change things around anyway. Obviously this won't work for large teams though for smaller teams formal methods are in my opinion a hindrance.
Monday, January 07, 2008
I agree that the skill of designing an architecture is something that comes with experience, but if you want to take a procedural approach just as a guide, I recommend reading the Attributed Driven Design approach documented by Len Bass of the Software Engineering Institute:
1. Choose an element of the system to design. (The first time, this will likely be the entire system itself.)
2. Identify architecturally significant requirements that apply to the element being designed. The architecturally significant requirements are the combination of quality, business, and functional goals that apply to the element being designed and that will have the biggest impact on its architecture.
3. Choose patterns and tactics to satisfy the architectural drivers. There are known patterns to achieve various qualities and functionality. Choose the solutions that are most appropriate for the high priority architectural drivers.
4. Instantiate the pattern and tactics to create new design elements within the element. The new elements will be of the types dictated by the chosen pattern and tactics. Assign each new element its functionality and sketch an interface for it showing information flow.
Refine the quality, business, and functional goals and constraints and allocate them to the newly created design elements, which will be the subject of future iterations.
5. Repeat steps 1-6 until all of the drivers have been satisfied.
I recently designed a small application. The first iteration was not very clear, I got some hints from my boss. So, I started following that.
I think its more of an iteration thing. Build something small first, which seems to be a starting point. Have a base for the entire app.
e.g, is there a base toolbar that all panels will share? Should that go on a base page? should each panel have several other panels inside it?
I sometimes draw it out. Draw each and every page with a pen and try to visualize the design. That helps.
What are the communication points? I mean, do I use some external API? Where do I put the code for that? A small utility class that every page shares?
I don't think theres a fixed formula.
For me architecture focuses on the non-functional aspects of requirements(High Level Design). Detail design is the one actually look at the implementation details of the requirements (Low Level Design).
I always start with looking at the most important non-functional aspect (and I use following checklist to help me in thinking http://www.hasith.net/blog/2007/02/after-using-rup-templates-for-software.html )
The first step is the sketch the layers of the systems that enables the identifies non-functional requirement realization.
Monday, January 21, 2008
architecting a application means is build a skeleton or framework , it looks a base of building or a blueprint,
to measure a framework is good or not , I think it should responsible for modularize the application , every module should be easy to code , testing and so on .
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz