Use cases and non-functional requirements all feed the architecture. Non functional requirements tell us things like response times, geographic distribution of users, compatibility and interaction with other systems. These drive a lot of big choices like "this will be a browser application" or "the app will be hosted at an 3rd party computing facility" or "we'll use JMS to abstract MQ-Series messaging with system X" or "I'm going to need redundant database servers". Use cases tell us things like "user profile updates must affect the user the next time they log on" which (in my current life) indicates distributed cache synchronization is required.
There is no formula for translating requirements to architecture. You have to learn to identify architecturally interesting things in use cases, other docs, hallway conversations.
There's a growing school of thought that you can build evolutionary architecture that grows to meet each new requirement instead of trying to nail it all down at the start. I buy it if you have the skills and discipline to practice really excellent design and manage dependencies like a hawk. See some recent blogs at ButUncleBob.com about Robert Martin's experience in changing fundamental parts of the Fit Wiki for some insight into this.
Does that help? Raise some more questions?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Feb 09, 2005
Yes, thank you. I have read about use cases and non-functional requirements in RUP books. I thought maybe there's no conventional solution. I try to use RUP first and some practical advises could be very helpful for me. I have read many things and I can't see through all the processes. Outlining of architecutre has to be done after making the first design model? I mean you analyze use cases to find candidate analysis classes and make sequence diagrams to model your system. Them you may have some idea about your system so you can baseline the architecture. Or I'm wrong? Do you know a summary or guideline of processes and workflows?
Joined: Jan 29, 2003
Architecture works at many scales and levels of abstraction. During RUP's inception phase the customer might say "My clients all across the country will use this" and the architect might think "Web app". The customer says "We require 24x7 service with no outage over 5 minutes." and the architect thinks "geographically distributed sites, database clusters ... hope you can pay for this". The customer says "We expect to announce this on Weekly Business Report" and the architect thinks "Rapid, flexible horizontal scalability ... server farm? Leased hosting?".
By the time you have a good scope and system charter at the end of inception many teams find they have enough to run a "spike" proof of the architecture bits and start on any framework support they'll need before they bring the full developer population on board.
Then there's nitty gritty, day to day architecture. Do we add a new component for this use case or add to the functionality of another? Can we buy this function or reuse something already in the company? How do we control dependencies so we can roll out the next release without breaking anything?
Sigh, it never ends. Wait, that's good! I'm still getting paid for this!
Oh, and forgot to answer your specific question - RUP has roles, activities and deliverables that you can view as an architecture track. RUP includes everything anybody might ever want to do, so you have to read carefully and pick out what makes sense to you.
Some teams don't pull this out as a separate track, but figure that every design decision either plays with the existing architecture or introduces some change. Everybody on the team has architecture awareness all the time so there's no special architect or set of activities. [ March 21, 2005: Message edited by: Stan James ]