通过在网上浏览，参考前辈们的文字思想，我认为软件架构的是如下这般设计出来的：
1、拿到软件需求后，经过一翻囫囵吞枣式的通读(而且是一边看一边脑子里飞速的转达：这块按我的经验应该如何实现)；
2、打开建模工具，根据需求上提到的几块功能模块要求，画上几个用例与时序图；
3、从需求中摘下几个事物建立类，填上类的属性，又从时序图中分出几个函数方法；
4、根据经验，依MVC分几层，套用已有的示例将最近新学的几个流行的框架添加上去。
这样就完成了架构。之后便是写架构设计文档，评审时打开文档或模型，指着用例图、时序图几乎是按需求文档解释一遍：系统包含什么功能，是怎么一步步完成的，系统的分层、选择了什么框架、模块之间的联系包括怎么通讯的及之间的参数与格式等等。
软件架构必须设计达到以下四个必须、一个不一定：
首先，软件架构是用来沟通的，软件架构必须满足软件项目所有步众代表都有自己立场与视角的模型、文档说明，且这些模型文档说明仅清晰包含自己立场与视角关注与有关的事物，不能有任何遗漏，也最好不要有多余。
其次，软件架构的每一步都是决策过程，而且关键需求决定架构，软件架构必须充分清楚地表达出这些决策与决策理由。众多的需求中为什么这些需求是关键需求？为满足这些关键需求，采用了什么样的关键机制、核心技术与第三方框架？什么选择这些关键机制、核心技术与第三方框架而不选用其它的？为什么说它们是可行的？
再则，软件架构必须为以后的开发提供足够的指导与限制，因此软件架构必须确定系统各元素间的关系、职责、交互接口与协作机制。仅仅划出几个层与层中包含的元素而不约束它们间的关系、职责、交互接口与协作机制，就如同一个公司，它的组织结构图就挂在墙上——再清晰不过了，但如果接口不清、机制不明，来了任务、出了事情不清楚找谁、如何汇报、怎样处理。
然后，软件架构必须突出强调通信机制、持久化机制和消息机制等公用模块的深入设计。通信机制、持久化机制和消息机制等公用模块较多的涉及软件的不同部分之间的交互，对系统的功能实现、非功能满足等成功因素起着举足轻重的作用。
最后，由于软件项目的不同、开发组织结构的不同、开发团队情况的不同，软件架构的设计粒度是不一定的。比如，航天航空领域中的软件系统对系统的可靠性等质量属性要求非常高甚至可以认为是荷刻，这种情况下对架构的设计详细程度的要求也会比较高；象IBM这样的大的团队中又有小的团队共同开发，架构的设计粒度到子系统级就足够了，各个小团队精通的技术各不相同，可以让其对子系统采用敏捷开发，对缩短工期、人尽其材有好处；有类似项目经验或项目团队所有成员整体技术水平较高的团队架构粒度可适当粗犷，而分布团队或涉及外包的情况则更强调架构的明确性。总之，架构设计对软件的不同部分的设计程度不应是整齐划一的，特别是具体的业务功能模块在架构设计中往往设计程度不深。