博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

本书每一个应用实例将主要强调宏观生命周期的一个特定部分以及适用的分析和设计(即微观)技能。

《基于卫星的导航》-从简化视角开发第一(segments,同汇编课中代码段、数据段、堆栈段等等释义是一样的,即代表系统中不同的部分)和第二(sub-systems)个级别的架构。我们意图是探索表示法和过程如何应用到系统架构的开发中。

架构的开发时伴随着系统功能需求与非功能需要逐步深入而一步步建立起来的,它是系统的最明了的蓝图。

宏观过程

初始

1. 定义问题边界,提供给我们的功能需求实际上是众多使命级别用例的容器(在UML中就是包)。

2. 决定mission用例,敲定高级别抽象的segments级别的逻辑架构。 

3. 系统用例,通过活动图(它是我们阐述系统行为的首要工具)来分析mission用例。

细化

目标是分配系统用例到segments,通过片段活动图,进一步将片段用例分配到子系统、组件。在整个开发过程中,功能分配时系统架构是关注的焦点,因为分配需要在任意抽象级别完成,而且分配粒度是不同的。

  • 系统
  • segment
  • 子系统
  • 组件

《交通管理》--应对一定需求变化且可以灵活扩展的系统架构

主要从系统工程(初始阶段)到硬件和软件工程 (细化阶段)。

大致流程同卫星导航系统(描述虽然不同,但是基本原型有众多相同之处,所以关注执行力比形式化的东西要重要的多),需求-》子问题-》跨子问题间的关键抽象与关键机制以及子问题的关键抽象与关键机制。

《人工智能-密码分析》--大规模复用黑板架构的实例

人工智能一般需要人类的知识库,针对不同人工智能领域逼近解。

《数据采集-气象监测站》--小系统也会很好地借鉴面向对象架构,并显露出一些面向对象开发过程的基本准则,小系统没有大的子问题,但是原理是一致的,只是抽象级别开始的等级与大系统比起来就不均等,不要以为小系统就不能很好地利用面向对象的方法来解决。

还想再次强调任务分配给软件、硬件,需要考虑能力、成本等问题。完善面向对象系统的标志是不需要搞乱现存架构,而是重用然后替身现有架构。

设计确保总是有一个传感器集合(不同类传感器通过继承结构来实现统一的多态动作)、一个显示管理器和一个输入管理器(通过用例场景的状态图来指示)。

    分析系统绝不能是一条道走到黑,死板硬套,将一种系统的开发流程一模一样的照搬。而是机动地采用灵活、方便、有效的方法。不同系统一般情况下开发过程所生成的工件是不同的。

《Web应用--休假跟踪系统》--Web应用的架构已经比较成熟,各个子问题虽然巨大,但都已经很好的解决了(比如应用服务器软件Tomcat等)。因此,我们所关注的焦点在于客户的业务逻辑,建造灵活且可扩展的业务系统架构是需要考虑的。此时,其实我们已经将整个问题的架构缩小到业务架构,如果问题比较小,那么就用不着业务架构了。

Web应用在细化阶段可以通过UX模型分析界面之间的关系。业务逻辑可以独立于界面来分析,因为一般视图和模型是没有直接依赖关系,这种关系已经被Web容器组件帮我们完成。