软件架构通过不同的视图进行表示——功能、操作、决策等等 。没有任何单一视图能够表示整个体系结构 。
并非所有视图都需要表示特定企业或问题领域的系统体系结构 。架构师将确定足以表示所需软件架构范畴的视图集 。
通过编写不同视图的文档说明并捕获每个部分的开发，您可以向开发团队和业务及 IT 参与者传达有关该不断发展的系统的信息 。软件架构具有一组其预期要满足的业务和工程目标 。
体系结构的文档说明可以向参与者传达这些目标将如何实现 。为体系结构的各个方面编写文档说明，有助于架构师弥补用白板描述解决方案（使用框线图方法）与以对下游设计和实现团队有意义的方式表示解决方案之间众所周知的差距 。
体系结构的框线图留下了大量有待解释的空间 。需要揭示的细节通常隐藏并令人混淆地固守在那些框线背后 。
文档说明还可以促进创建切合实际并且可以系统开发（例如遵循标准模板）的体系结构构件 。作为一门学科，软件架构是非常成熟的 。
您可以利用最佳实践和指导 。
8. 常用的软件架构有那些 1 。当一个线程进入moniter（也就是说站用一个object），另一个线程只有等待或返回，而我们把返回就称为一种模式，这种模式的英文是Balking 。
2 。这两个线程可以是有序的执行，而不是让OS来调度，这时我们要用一个object来调度，这种模式称为Scheduler 。（这个词及其含义其实OS中就有） 。
3 。如果这两个线程同时读一个资源，我们可以让他们执行，但如果同时写的话，你闭着眼睛都会知道可能出现问题，这时我们就要用另一种模式（Read/Write Lock） 。
4 。如果一个线程是为另一个线程服务的话，比如IE中负责数据传输的线程和界面显示的线程，当一个图片没有传完时，另一个线程就无法显示，至少是部分没有传完 。那么这时我们要用一个模式称为生产者和消费者，英文是Producer-Consumer 。
5 。两个线程的消亡也可以不是完全又OS来控制的，这时我们需要给出一个条件，使得每个线程在符合条件是才消亡，也就是有序的消亡，我们称为Two-Phase Termination 。
那么有这5个线程模型，基本上可以用到大多数编程任务中 。我需要指出的三点是：
1 。从高层次上我们可以再验证是否含盖了所有的情况 。
2 。其实模式不是完全固定的或者说象定律一样，而模式可以为不同的情况进行适当 的调整和组合，目的是为了简洁和高效 。
3 。学习模式是为了具备更好的分析问题的能力 。
文章插图