developer.com
Search EarthWeb
CodeGuru | Gamelan | Jars | Wireless | Discussions
Navigate developer.com
Architecture & Design  
Database  
Java
Languages & Tools
Microsoft & .NET
Open Source  
Project Management  
Security  
Techniques  
Voice  
Web Services  
Wireless/Mobile
XML  
New
 
Technology Jobs  

   Developer.com Webcasts:
  The Impact of Coding Standards and Code Reviews

  Project Management for the Developer

  Defining Your Own Software Development Methodology

  more Webcasts...




Return in early January to see which technologies and products won.




Developer Jobs

Be a Commerce Partner














 


Developer News -
Big Enterprise Linux Moves, Green Networks in 2009    December 26, 2008
Gifts for All in Linux 2.6.28    December 24, 2008
Merb Merges With Rails    December 24, 2008
Sun's Unwired Motherboard Plans    December 24, 2008
Free Tech Newsletter -

Achieving 20/20 Vision Through Architecture Viewpoints
By Jeff Ryan

Go to page: 1  2  3  Next  

The Blind Men and the Elephant

The story of the blind men and the elephant illustrates how six people with very accurate views can miss the big picture.

Was the elephant like a stone wall, as one man observed when he tried to push it over and it wouldn't budge? Or was it like an oak tree, as said the man who put his arms around one of the huge legs? Or was it a snake, a rope, a spear, or a fan as the other men surmised? Yes—but none of the men had 20/20 vision and thus none were seeing the big picture.

Have you worked on a software development project where there was a cloudy or unbalanced view of what needed to be accomplished? Did the architecture flow from the requirements? Was the architecture fully described? Were the right stakeholders engaged? Was this project successful?

Considering a standard set of architecture viewpoints will provide the 20/20 vision you may be lacking. This article outlines seven viewpoints that help you gain a holistic view of a project and to successfully identify and partner with stakeholders. It is written with an architect or senior developer who has some familiarity with UML in mind.



Click here for a larger image.

Figure 1: Solution Architecture Viewpoints

The "What" Viewpoints

One of the key principles of software design is to understand the problem before considering the solution. This means that you must put the "what" before the "how." All too often, you follow the impulse to jump to the solution when you haven't yet articulated the problem. The first three viewpoints you will consider will provide a clear view of the problem to be solved.

Functional Requirement Viewpoint

The Functional Requirement Viewpoint describes the high level business requirements or "whats" being considered. The solution architecture that follows should flow from meeting the needs articulated here.

UML (Unified Modeling Language) Use Case Diagrams can be helpful to represent this viewpoint. A Use Case Diagram is a graphical table of contents of the high level functional requirements of the system. A Use Case Diagram answers the key questions of what users will be using the system and what high level functions they will be using the system for.

Figure 2: Sample Use Case Diagram

From an architecture perspective, the functional requirement viewpoint is not about the detailed requirements that are captured in textual use cases, but rather about understanding the users and the high level functions they need to perform.

Another useful tool for capturing the high level functional view of the system is a user interface wireframe or prototype. A picture truly is worth a thousand words in capturing high level requirements.

Non Functional Qualities Viewpoint

One viewpoint often overlooked is the Non Functional Qualities Viewpoint; it articulates the non-functional requirements of a project. These requirements create certain expectations for the underlying architecture.

Whereas the Functional Requirement Viewpoint will tell you what should happen if a single user presses the "Buy Now" button, the Non Functional Qualities Viewpoint will tell you what should happen if 10,000 users press the "Buy Now" button.

Quality attributes, which express the desired non functional qualities of the system, are used to capture the non functional requirements. The questions quality attributes answer includes:

  • How many users will be logged on to the system?
  • How many transactions will be performed in a given time period?
  • What is the expected response time?
  • What are the hours of operation?
  • How frequently will changes be needed to the system?
  • How sensitive is the system to security breaches?

Quality attributes can be categorized into those qualities observable at runtime versus those observable at design time. Examples of runtime qualities include performance, availability, usability, and scalability. Examples of design time qualities include maintainability, ease of integration, testability, reusability, and conceptual integrity. Arguably, conceptual integrity is the most important judge of a solution architecture because it relates to its understandability and longevity.

Go to page: 1  2  3  Next  


Tools:
Add www.developer.com to your favorites
Add www.developer.com to your browser search box
IE 7 | Firefox 2.0 | Firefox 1.5.x
Receive news via our XML/RSS feed


Architecture & Design Archives






internet.comearthweb.comDevx.commediabistro.comGraphics.com

Search:

Jupitermedia Corporation has two divisions: Jupiterimages and JupiterOnlineMedia

Jupitermedia Corporate Info

Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Tech Jobs | Shopping | E-mail Offers