Articles tagged with: Design
Software architecture is often defined as the structure or structures of a system. There’s been a lot of attempts to define architecture from a software perspective and lots of debates over the years. Rather than start from scratch, I thought it would be more helpful to highlight some of the more useful definitions that I’ve come across.
Kruchten, Booch, Bittner, and Reitman on ArchitecturePhilippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman derived and refined a definition of architecture based on work by Mary Shaw and David Garlan (Shaw …
A Scenario and Feature Frame is a quick way to show your project’s incremental value and dependencies. It’s helpful for showing your management what you’ll deliver in terms of a baseline release. It’s helpful for you in terms of finding ways to reduce dependencies. If you have a bunch of scenarios that depend on certain features, then you don’t have cuttable scope. The key is to find ways to factor your scope into incremental value.
Scenario and Feature FrameA Scenario and Feature Frame is a powerful tool for analyzing …
Project-Management, Requirements »
Photo by Wonderlane
What’s a scenario? Not everybody uses the term “scenario” the same way. In the software industry, there’s three common usages of scenario:
The same as a use case.
A path through a use case.
An instance of a use case.
Usually, the most helpful one is “an instance of a use case.” Why? Because if a scenario is an instance of a use case, then it’s testable with concrete data.
Lessons Learned at Microsoft
At Microsoft, when there’s a customer challenge to solve, it’s common to ask “what’s the scenario?” This …
Photo by Wolfgang Staudt
What is systems architecture and why do we care? A systems architecture supports the highest layers of the enterprise architecture and it helps keep the enterprise architecture aligned to the business. In A Practical Guide to Enterprise Architecture (Coad Series), James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo write about systems architecture.
What is a SystemA system is the structure and constellation of machines, applications and network resources to support a particular function. McGovern, Ambler, Stevens, Linn, Sharan, …
How do you represent a software architecture? You can use a set of viewpoints including a conceptual architecture view, module view, execution view, and code view. This set of architectural viewpoints was originally proposed by Hofmeister, Nord, and Soni in their book Applied Software Architecture. In A Practical Guide to Enterprise Architecture (Coad Series), James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo write about the conceptual architecture view, the module view, the execution view, and the code view.
Conceptual Architecture ViewThe conceptual architecture …
What is the 4+1 view model of software architecture? It’s a way to show key viewpoints of an architecture. In A Practical Guide to Enterprise Architecture (Coad Series), James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo write about the 4+1 view model of software architecture.
Key Take AwaysHere’s my key take aways:
The four views are: logical, process, development, and physical.
The +1 is the scenarios. The scenarios are at the center of the model.
The logical view is a view of the important classes and …
You can divide software architecture structures into 3 groups: 1) module structures, 2) component-and-connector structures, and 3) allocation structures. These 3 groups map to 3 broad types of decisions for architectural design. The 3 broad types of decisions are: 1) how to structure modules, 2) how to structure components and connectors, and 3) how does the system relate to non-software structures. In Software Architecture in Practice (2nd Edition) (SEI Series in Software Engineering), Len Bass, Paul Clements, and Rick Kazman write about 3 groups of architectural structures.
Structure and View Bass, …
As we work through the patterns & practices App Arch Guide 2.0 project, I find myself repeating an important mantra …
“You can’t evaluate an architecture in a vacuum …”
You need scenarios to evaluate it against scenarios.
Scenario-Based Evaluation MethodsHere’s a list of some scenario-based evaluation methods:
Software Architecture Analysis Method (SAAM) - evaluate quality attributes against actual usage.
Architecture Trade_off Analysis Method (ATAM ) - evaluate how well the architecture satisfies particular goals, especially around trade-offs between qualities.
These are mostly variations of SAAM and ATAM.
Cost-Benefit Analysis Method (CBAM) - evaluates the architecture …
I’ve been researching data architecture practices. Along my travels I came across the book, A Practical Guide to Enterprise Architecture (Coad Series). In the book, James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo write about effective data architecture practices.
Key PracticesWith the benefit of experience, McGovern, Ambler, Stevens, Linn, Sharan, and Jo identify the following practices for effective data architecture:
Establish an infrastructure that allows for rapid changes in business requirements and database technologies.
Data that need to be shared and current should …
How do you create a candidate architecture in XP? The solution is to pick a set of stories that force you to build a skeleton of the system as a whole in your first iteration. If you can’t find the stories that force you to create the architecture you need, then you either put as much architecture in place as you need for now or you put the whole architecture in place on speculation. In Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series), Kent Beck writes about building …
How do you know which path to take? How do you find your glass ceilings? Unless you’ve been there and done that, you need to test your path to avoid significant do-overs. In Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series), Kent Beck writes about architectural exploration.
The programmers should also experiment with architectural ideas — how do you build a system for multiple levels of undo? Implement it three different ways for a day and see which one feels best. These little architectural explorations are most …
In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maiden mention periodic design refactoring:
A variant of the Incremental model appears to be the ‘Extreme Programing (XP)’ approach put forward in Beck (2000) in which integrity of the system architecture across all increments is maintained by periodic design ‘refactoring.’
While I’m not a fan of Big Design Up Front, I am a fan leveraging the following techniques up front to help reduce risk:
System stories up front (where system stories include the ‘ilities and quality attributes, such …
One of my favorite phrases is “incrementally render the solution.” While building our end-to-end application solutions, I find it helpful to first create a skeleton and then hang the solution off of it. Below is an example of solving an Intranet security scenario for an ASP.NET Web application. Pictures are worth a 1000 words.
On the patterns & practices team, to catalog app solutions, I use a simple “scenario and solution” approach. My manager calls these “cartoons.” The key is to create a visual representation of what’s important — similar to a whiteboard sketch. In fact, there was a point where we called these “whiteboard solutions.” Below is an example of the skeleton of a solution for a common ASP.NET intranet scenario where users are in AD and the role store is in SQL Server. Notice how lean the solution is (which makes it …
When I met with Gartner, I needed to illustrate how we were thinking about end-to-end application scenarios in patterns & practices. In addition to explaining the idea of App Types and the App Infrastructure Frame, I illustrated how it was possible to quickly decompose an application scenario if you know how to break it down. Below are some figures I used to help illustrate the ideas.
This is how I analyze an end-to-end application scenario:
A former patterns & practices team member, Wojtek Kozaczynski, created some figures I liked. He analyzed our Enterprise Library and Software Factories and created figures to show the usage scenarios that the solution assets are based on.
patterns & practices App Architecture
The following shows end-to-end architectures for a Web client and a Smart client:
As part of my preparation for writing a new application architecture guide, I’m analyzing our original patterns & practices Application Architecture Guide. Below I show what I think is the most important blueprints from the original guide.
Application Architecture (Canonical)
This is the original patterns & practices application architecture:
If you build LOB (line-of-business) applications, you’re familiar with Web, Smart Clients, Mobile and Web Services applications. In patterns & practices, we’ve organized programs around these application types to build more relevant, prescriptive guidance. Here’s examples of the end-to-end application types.
Smart Client / Mobile
Web Service / Service
Note the following codes: UIC=User Interface Components, UPC=User Process Components, SA=Service Agent, SI=Service Interface, BE=Business Entity, BC=Business Component, DAC=Data Access Component.
My Related Posts
App Infrastructure Frame
App Types, Verticals, and Scenarios
I’ve been looking for examples of how to organize software architecture styles. One book that looks promising so far is Software Architecture Design - Methodology and Styles. In this book, the authors identify the following architecture styles:
Component-Based Software Architecture
Data Centered Software Architecture
Data Flow Architecture
Implicit Asynchronous Communication Software Architecture
Interaction Oriented Software Architecture
Object Oriented Architecture