Pattern-Oriented Software Architecture For Dummies
Once you know what pattern-oriented software architecture (POSA) is, diving into the software pattern community can be a real benefit — you can share your experience and gain from other people's experiences, too. When you use patterns, even design patterns, you must reference them clearly and accurately so that other people can find and use them, too. Finally, as you work with patterns, be sure to assemble your own pattern catalog — a handy reference as you face similar problems again.
What Is Pattern-Oriented Software Architecture?
Understanding pattern-oriented software architecture (POSA) begins with understanding the two concepts that it comprises: software architecture and software patterns.
Software architecture: Software architecture can mean different things, depending on your role. Developers think that it means the structure of the system being built. Testers think that it's the shape of what they need to test. For everyone, it's the high-level structure of the solution to a problem that the customer or client wants solved.
Software pattern: A software pattern is a solution to a software design or coding problem that has been useful at least three times. The recurrence shows that the pattern is a common solution that works over and over again. Patterns don't solve your problem for you, but they help you understand how to solve it. They explain the steps that you need to follow and explain the trade-offs you must balance to achieve a solution.
Putting these two concepts together, you get the high-level structure of a solution to a customer's or client's problem that is based on proven ideas. When you use the appropriate pattern to structure your solution, you can be confident that the basic structures of the architecture are sound, because they've been used before.
Getting Connected with the Software Pattern Community
Whether you're a software architect, engineer, or designer, you're likely interested in software patterns and, therefore, the software pattern community. You can get involved with this community in several ways:
Advocate for patterns. You can advocate for patterns within your workgroup or company and the industry as a whole. You can point your colleagues to pattern resources that you've found to be helpful and those that you think can help solve certain software design problems.
Write about your experiences using patterns. Blog about how patterns helped you solve a real problem, for example, or write a short article for a company or technical newsletter.
Be a pattern mentor. Show your colleagues how patterns can (and sometimes can't) solve software challenges, and help them find useful patterns for their own projects. You can help them learn how to write patterns, too.
Volunteer. Like any community, the pattern community has lots of volunteer opportunities. You can help improve other people's patterns by participating in writers' workshops at pattern conferences. After you've proved yourself, you can become a shepherd, helping other pattern authors get ready for writers' workshops.
Write your own patterns. Consider the things your colleagues ask you questions about — or the things you wish they'd ask you about. These topics may be appropriate for your first patterns.
Software Architecture: How to Reference Software Patterns
Whenever you're writing a document and want to refer to a software pattern, be sure to give your readers enough information that they can find the same pattern themselves. Software patterns appear in books, journals, and conference proceedings, and should be cited just like anything else. Here are some guidelines:
Set off the name. Within the body of your document, make the pattern name look different from the normal text somehow. Commonly, pattern authors do this by applying small-caps character formatting, underlining the pattern title, or capitalizing it consistently.
Tag the pattern. Mark the pattern so that readers can find the full pattern through a detailed reference. Use whatever referencing method you're applying in the rest of your document — footnotes, endnotes, or inline (with the text in parentheses).
Credit all your sources. For each pattern citation, include all the typical reference material, such as author, pattern name, and where you found the pattern (such as a book or website). Sometimes enough people know the reference so that you can use a shorthand.
Date the version. Always cite the date of the pattern version that you're using, especially if your source may be changed and updated. Patterns on websites, for example, can be updated easily. Because writing patterns is a never-ending process, patterns are continually being refined, and pattern authors list a new date for each new version.
Building a Software Pattern Catalog
When you start using patterns to solve software design problems, you'll find a few favorites. Record these favorites in your own software pattern catalog for future reference— it's good practice. Select the tools that you're most comfortable with (pencil and paper, word-processing document, web page, blog, or wiki) and that you're most likely to use when you face design challenges. Then follow these steps:
Identify the software development problems that you commonly encounter.
Your pattern catalog will be most useful if it addresses these problems.
Find the patterns that solve these problems.
You probably already have some favorite patterns that you use.
Organize your pattern catalog in sections to help you zoom in and quickly find the patterns that can help you.
Organize patterns by when you need them, by what kind of solution they provide, or by scope of pattern — any categorization that you find useful.
Connect the patterns.
Patterns work together, allowing you to solve big problems. Add references, hyperlinks, or other connections between the patterns so that you'll remember that when you used pattern X in the past, you also used pattern Y. Connecting patterns is easiest if you use an electronic cataloging method.
Keep your catalog current.
New patterns are published continually, and you may want to include some of them in your handbook. Also, if you find that you don't use some of the patterns anymore, remove them to make room for the new ones that you do use.