软件架构设计的方法论—分而治之与隔离关注面
软件架构设计原则与方法
软件架构设计原则与方法软件架构设计是指在软件开发过程中，根据需求和目标确定系统的整体结构和组成部分，以及它们之间的关系和交互方式。
一个良好的软件架构设计能够确保软件系统具有稳定性、可扩展性、可维护性和可重用性。
在进行软件架构设计时，可以遵循以下原则和方法。
一、单一职责原则单一职责原则要求一个类或模块只负责一项功能或职责。
这样可以使代码更加清晰、简洁，并且易于维护和重用。
每个类或模块应该有明确的功能，并且不承担与其职责无关的其他功能。
二、开闭原则开闭原则要求软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。
即在不修改已有代码的情况下，通过添加新的代码来实现功能的扩展。
这样可以降低系统的耦合性，提高系统的可维护性和可扩展性。
三、里氏替换原则里氏替换原则要求任何一个基类可以出现的地方，子类一定可以出现。
子类对象可以替换父类对象，并且程序执行的结果不变。
这样可以提高代码的可复用性，使系统更加灵活。
四、依赖倒置原则依赖倒置原则要求要依赖于抽象，而不是依赖于具体实现。
高层模块不应该依赖于低层模块，二者都应依赖于抽象。
通过使用接口或抽象类，可以实现模块间的解耦，提高系统的灵活性。
五、接口隔离原则接口隔离原则要求客户端不应该依赖于它不需要的接口。
一个类对另一个类的依赖应该建立在最小的接口上。
通过定义粒度合适的接口，可以减少类与类之间的耦合，提高系统的可维护性和可扩展性。
六、迪米特法则迪米特法则要求一个对象应该对其他对象有尽可能少的了解。
每个对象对其他对象的依赖应该尽量减少，只与朋友通信。
这样可以减少对象之间的耦合，降低系统的复杂性。
七、模块化设计模块化设计将软件系统划分成若干个独立的组件或模块，每个模块只负责一项功能或职责。
通过模块化的设计，可以提高系统的可维护性和可重用性，并且便于团队的合作开发。
在进行软件架构设计时，可以使用以下方法：一、面向对象分析与设计（OOAD）面向对象分析与设计是一种常用的软件架构设计方法。
软件架构设计的核心原则和方法(一)
软件架构设计的核心原则和方法简介：在现代社会中，软件已经成为人们生活中不可或缺的一部分。
无论是电商平台、社交媒体还是智能手机应用，背后都离不开复杂的软件系统。
软件架构设计就是为了构建可靠、可扩展和可维护的软件系统而进行的系统化过程。
本文将探讨软件架构设计的核心原则和方法，旨在为软件开发人员提供一些有价值的指导。
一、模块化设计模块化设计是软件架构设计过程中的关键一步。
它将软件系统分解为不同的模块，每个模块负责特定的功能。
模块之间通过接口进行交互，实现了低耦合和高内聚的特性。
在进行模块化设计时，需要将注意力放在模块边界的划分上，确保模块之间的职责清晰明确。
同时，借助于面向对象设计原则，如单一职责原则、开闭原则等，可以确保模块内部的高内聚性和低耦合性。
二、结构化设计结构化设计是软件架构设计的另一个重要原则。
它强调将软件系统切分为不同的层次，每个层次负责不同的职责。
常见的软件系统层次包括用户界面层、业务逻辑层和数据访问层等。
通过结构化设计，可以将系统的复杂性分割为若干更简单的部分，使得系统的开发、测试和维护变得更加容易。
此外，结构化设计也有助于实现系统的可扩展性，当需求发生变化时，可以更方便地添加或修改相应的层次。
三、可伸缩性设计随着用户数量和数据量的增加，软件系统需要具备良好的可伸缩性，以满足不同规模的需求。
可伸缩性设计是指系统能够根据需求的变化增加或减少资源的能力。
在进行可伸缩性设计时，需要考虑如何合理分配系统的资源，如服务器的数量、存储容量等。
此外，还可以采用一些分布式技术，如负载均衡、分布式缓存等，实现系统的横向扩展能力。
通过合理的可伸缩性设计，可以提高系统的性能和可用性。
四、安全性设计软件系统的安全性是现代社会中不可忽视的重要问题。
安全性设计涉及到系统对于数据隐私、用户身份认证等方面的保护。
在进行安全性设计时，需要根据系统的具体需求，选择合适的安全机制。
例如，对于需要保护用户数据的系统，可以采用加密技术；对于需要保护用户身份的系统，可以采用双因素认证等。
软件架构设计的原则与方法
软件架构设计的原则与方法在现代软件开发领域中，软件架构设计是非常重要的一环。
一个良好的软件架构设计能够保证软件系统的可维护性、可扩展性以及可靠性。
本文将介绍一些软件架构设计的原则与方法，以帮助开发人员在进行软件架构设计时能够按照规范和最佳实践进行。
一、单一职责原则单一职责原则是指一个类应该只有一个引起它变化的原因。
换句话说，一个类应该只有一项职责，而不应该承担过多的责任。
这样可以提高代码的可维护性和可理解性。
二、开放-封闭原则开放-封闭原则是指软件实体（类、模块、函数等）应该是可扩展的，但是不可修改的。
通过使用抽象和接口，可以实现对已有代码的扩展，而无需修改已有代码，这样可以降低系统的维护成本。
三、里氏替换原则里氏替换原则是指子类必须能够替换父类，而不影响程序的正确性。
也就是说，任何使用父类的地方都可以使用子类，而不需要修改任何代码。
通过遵循里氏替换原则，可以提高系统的可扩展性和复用性。
四、依赖倒置原则依赖倒置原则是指高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
抽象不应该依赖于具体细节，具体细节应该依赖于抽象。
通过使用接口或抽象类，可以实现高层模块和低层模块的解耦，提高系统的扩展性和可维护性。
五、接口隔离原则接口隔离原则是指客户端不应该依赖于它不需要使用的接口。
一个类对另一个类的依赖应该建立在最小的接口上。
通过定义符合单一职责原则的小接口，可以避免客户端依赖不必要的接口，减少耦合度，提高系统的灵活性和可维护性。
六、迪米特法则迪米特法则是指一个对象应该对其他对象有尽可能少的了解。
也就是说，一个对象应该只和其直接朋友通信，而不要与陌生对象通信。
通过遵循迪米特法则，可以减少对象之间的依赖关系，降低耦合度，提高系统的可维护性和可扩展性。
七、统一建模语言（UML）统一建模语言是一种用于软件开发过程中的可视化建模工具。
在软件架构设计中，使用UML可以帮助开发人员清晰地表达系统的结构和行为。
UML提供了用例图、类图、对象图、序列图等多种图形化建模方式，可以帮助开发人员更好地理解和设计软件架构。
软件开发中的软件架构设计方法
软件开发中的软件架构设计方法引言在软件开发中，软件架构设计是至关重要的一部分。
软件架构设计是指设计软件系统的整体结构，包括各种组件之间的关系。
如果软件架构设计不合理，将会导致软件系统出现各种各样的问题，甚至无法正常工作。
因此，软件架构设计是软件开发过程中的关键环节，软件开发者必须对此进行认真的思考和分析。
正文软件架构设计的目的是为了满足系统的需求，并且使得软件系统是可维护的、可扩展的、可重用的、可移植的和可靠的。
软件架构设计可以采用不同的方法和工具来实现。
本文将讨论几种常见的软件架构设计方法。
1. 分层架构分层架构是将软件系统分成若干层，每一层都有特定的功能。
通常情况下，较高的层次通常与较低的层次联系起来。
例如，用户界面层可以与数据层交互，数据层可以从数据库中检索数据，并且用户界面层可以使用这些数据。
分层架构有助于将软件系统分割成更小的组件，这样可以使得软件系统更易于维护和扩展。
2. 模块化架构模块化架构是将软件系统分成若干模块，每个模块都有明确定义的功能。
这些模块可以按照某种方式组合在一起来构建软件系统。
通常情况下，模块化架构可以使得软件系统更易于维护和升级。
3. 服务导向架构服务导向架构是一种基于服务的架构，它将软件系统分解为若干服务（或微服务），每个服务提供某种功能，并且可以通过网络进行通信。
服务导向架构可以使得软件系统更灵活，更易于扩展和替换。
此外，由于服务彼此独立，因此服务可以使用不同的开发语言和技术实现。
4. 事件驱动架构事件驱动架构是一种基于事件的架构，它强调事件如何影响软件系统的不同部分。
通常情况下，软件系统可以通过事件来通知其他组件发生的事情。
例如，当用户提交一个表单时，该表单可以触发一个事件，以便可以执行某些操作。
结论软件架构设计是软件开发的关键环节，需要开发者进行认真的思考和分析。
在本文中，我们介绍了几种常见的软件架构设计方法，包括分层架构、模块化架构、服务导向架构和事件驱动架构。
软件架构模式与设计思想：选择适合的架构模式
软件架构模式与设计思想：选择适合的架构模式软件架构模式是指在软件系统的设计过程中，选择和应用的一种结构模型，用于解决软件系统中的复杂性和可维护性的问题。
而设计思想则是指在软件设计过程中，所采用的一种思维方式和方法论。
选择适合的架构模式和设计思想，对软件系统的可扩展性、可维护性和可重用性具有重要影响。
本文将介绍几种常见的软件架构模式和设计思想，并分析它们的特点和适用场景。
1.分层架构模式：分层架构模式将软件系统划分为不同的层次，每个层次具有不同的功能和责任。
通常包括表现层、业务逻辑层和数据访问层。
这种模式的优点是结构清晰，便于维护和扩展。
适用于中小型的软件系统，例如企业内部管理系统、电子商务系统等。
2.客户端-服务器架构模式：客户端-服务器架构模式是将软件系统划分为客户端和服务器两部分，客户端负责向用户提供界面，服务器负责处理业务逻辑和数据存储。
这种模式的优点是逻辑清晰，各个模块之间的耦合度低。
适用于分布式系统，例如Web应用程序、移动应用程序等。
3. MVC架构模式：MVC架构模式将软件系统划分为模型、视图和控制器三个部分，模型负责数据的存储和处理，视图负责界面的展示，控制器负责协调模型和视图之间的交互。
这种模式的优点是逻辑清晰，各个模块之间的耦合度低。
适用于需要频繁修改界面和业务逻辑的系统，例如网页应用程序、桌面应用程序等。
4.微服务架构模式：微服务架构模式将软件系统划分为多个小而独立的服务单元，每个服务单元具有独立的功能和负责的业务逻辑。
这种模式的优点是系统的可扩展性和可维护性较高，每个服务单元可以独立开发、部署和更新。
适用于大型的复杂系统，例如电商平台、大型社交网络等。
5.面向对象设计思想：面向对象设计思想是指将软件系统的问题划分为不同的对象，每个对象具有属性和方法，对象之间通过消息传递进行交互。
这种设计思想的优点是模块化和可重用性较高，对象之间的关系和行为具有清晰的表达。
适用于面向对象开发的系统，例如Java、C++等。
软件架构设计方法理论
软件架构设计方法理论1.软件架构概述1.1什么是软件架构◎ 软件架构的概念很混乱。
如果你问五个不同的人，可能会得到五种不同的答案。
◎ 软件架构概念主要分为两大流派：组成派：软件架构= 组件+ 交互。
决策派：软件架构= 重要决策集。
◎ 组成派和决策派的概念相辅相成。
1.2软件架构和子系统、框架之间的关系◎ 复杂性是层次化的。
◎ 好的架构设计必须把变化点错落有致地封装到软件系统的不同部分( 即关注点分离) 通过关注点分离，达到“系统中的一部分发生了变化，不会影响其他部分”的目标。
◎ 软件单元的粒度：* 粒度最小的单元通常是“类”。
* 几个类紧密协作形成“模块”。
* 完成相对独立的功能的多个模块构成了“子系统”。
* 多个子系统相互配合才能满足一个完整应用的需求，从而构成了软件“系统”。
* 一个大型企业往往使用多套系统，多套系统通过互操作形成“集成系统”。
◎ 软件单元的粒度是相对的。
同一个软件单元，在不同场景下我们会以不同的粒度看待它。
◎ 架构(Architecture) 不等于框架(Framework) 。
框架只是一种特殊的软件，框架也有架构。
◎ 可以通过架构框架化达到“架构重用”的目的，如很多人都在用Spring 框架提供的控制反转和依赖注入来构建自己的架构。
1.3软件架构的作用◎ 如果一个项目的系统架构(包括理论基础) 尚未确定，就不应该进行此系统的全面开发。
-- Barry Boehm,《Engineering Context 》◎ 一个缺陷充斥的系统，将始终是一个缺陷充斥的系统。
-- Timothy C. Lethbridge, 《面向对象软件工程》◎ 软件架构设计为什么这么难？因为它是跨越现实世界与计算机世界之间鸿沟的一座桥。
软件架构设计要完成从面向业务到面向技术的转换，在鸿沟上架起一座桥梁。
需求-> 架构设计-> 软件架构-> 系统开发-> 软件系统~~~~~~~~ ~~~~~~~~◎ 软件架构对新产品开发的作用：* 上承业务目标。
软件架构设计需要关注的重点问题
软件架构设计需要关注的重点问题在如今数字化信息技术高速发展的时代，软件作为信息化的重要手段和载体，其开发和运行所涉及的软件架构设计问题越来越受到关注。
软件架构设计是软件工程中的核心环节，它关系到软件质量、可重用性、可维护性、可扩展性等诸多方面，对于软件的开发周期、开发成本以及开发人员的技术水平都有着举足轻重的影响。
要想实现一个高质量、高效率的软件开发过程，必须关注软件架构设计需要关注的重点问题。
一、软件需求分析软件架构设计的首要任务是根据软件需求分析，确定软件系统的架构风格和应用场景。
软件需求分析可以帮助开发人员更好地理解软件所需实现的功能及其背后的业务逻辑，更好地对软件进行细致的分析和划分，从而指导架构设计人员确定系统架构的主要设计原则和范围。
二、软件架构模式的选择选择适合的软件架构模式，是软件架构设计的核心问题，也是软件成功与否的关键因子。
常见的软件架构模式包括：分层模式、MVC模式、SOA模式、微服务模式等。
不同的架构模式适用于不同的场景，需要根据实际情况针对性地选择合适的方案。
三、软件设计原则软件设计原则是软件开发的重要准则，它是保证软件质量的重要手段。
其中的几个基本原则包括：高内聚、低耦合、开闭原则、单一职责原则、迪米特法则等。
遵守这些原则可以保证软件系统的可维护性，可扩展性和可重用性，从而降低软件开发、维护和扩展的难度和风险。
四、软件安全设计随着网络技术的不断发展，软件的安全性问题越来越受到重视。
软件大量的用户数据和敏感信息往往是黑客攻击和各种恶意软件入侵的目标。
为了保证软件系统的安全，软件架构设计人员需要重点考虑软件系统的安全设计，包括数据加密、访问控制、输入验证等多个方面，尽可能从系统设计上保障软件系统的安全性。
五、软件性能优化软件的性能问题是一项永恒的话题。
随着软件运行时对硬件资源的复杂运算需求和对数据量的增长，软件的性能瓶颈成为了用户关注的焦点。
软件架构设计人员应该重点考虑软件的性能优化问题，从设计时尽可能减少不必要的硬件资源占用和运算量，提升软件运行的效率和速度，保证用户的使用体验。
软件架构设计的基本原则
软件架构设计的基本原则软件架构设计是对软件系统整体结构的规划和设计，是软件开发过程中非常关键的一环。
一个良好的软件架构设计能够提高软件的可维护性、可扩展性和可重用性，降低软件开发和维护的成本，并保证软件系统的稳定性和性能。
在进行软件架构设计时，有一些基本原则是需要遵循的。
本文将介绍一些常见的软件架构设计原则，以指导开发人员在设计软件架构时的决策。
一、模块化与高内聚低耦合模块化是将大型软件系统划分为多个相对独立的模块，每个模块负责处理特定的功能或任务。
模块化设计有利于代码的复用和维护，并且方便团队并行开发。
同时，模块之间的耦合度应尽可能低，即模块间的依赖关系应简化，这样方便对系统的修改和扩展。
二、分层与分离关注点分层是将软件系统划分为多个层次，每个层次负责不同的职责。
分层设计可以使得系统的各个部分相对独立，易于维护和测试。
此外，还应该遵循分离关注点的原则，即将不同功能的代码分离开，减少功能之间的耦合。
三、单一职责原则每个模块或类应该只负责实现单一的职责。
这样可以提高代码的重用性和可维护性，同时也易于测试和调试。
如果一个模块或类承担了过多的职责，就容易导致代码混乱和功能耦合。
四、开闭原则开闭原则是指软件实体（模块、类、函数等）应该对扩展开放，对修改关闭。
也就是说，在添加新功能或修改现有功能时，不应修改原有的代码，而是通过扩展的方式来实现。
这样可以保证系统的稳定性和可维护性，减少由于修改引起的风险。
五、接口隔离原则接口隔离原则强调客户端不应该依赖它不需要的接口。
一个类或模块应该只为其客户端提供对其需要的接口，而不需要提供无关的接口。
这样可以降低模块间的耦合度，提高系统的灵活性和可维护性。
六、依赖倒置原则依赖倒置原则是指高层模块不应依赖于低层模块，而是二者都应该依赖于抽象。
这样能够降低模块间的依赖关系，提高系统的可扩展性和可维护性。
通过面向接口编程，可以实现依赖倒置原则。
七、迪米特原则迪米特原则也被称为最少知识原则，即一个对象应该尽可能减少与其他对象之间的相互作用，使得系统中的各个模块相对独立。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
实现（分 析）
Analysis Model
精化（映 射）
软件交付
实施（转 化） QC确保 每个中间 制品的质 量
定义（引申） Use-Case Model
Design Model
CMMI过程域关系示意图
过程管理Process Management过程域
Organizational Process Focus Organizational Process Definition Organizational Training Organizational Process Performance Organizational Innovation and Deployment
16
多边形对象集合关系示意
多边形 Polygon
四边形 Quadrangle 矩形 Rectangle
三角形 Triangle
五边形 Pentagon
归类法识别的多边形类层次
18
抽象与软件的表述 ——抓住软件问题的要害与根 本，简化构架设计处理的内容
19
软件表述——开发的前提条件
抽象表述 （Abstract） 问题域 （Problem Context）
控制过程的执行
Control the Processes
Configuration Management Process and Product Quality Assurance Measurement and Analysis
Causal Analysis and Resolution Decision Analysis and Resolution Organizational Environment for Integration
22
示例：抽象
Salesperson
Customer
Product
23
模块化与分而治之 ——构架设计中的管理学，以分 工协作来扩展团队解决复杂软 件问题的能力
24Leabharlann 抽象解决不了软件中的规模问题
9抽 象 能 够 很 好 地 降 低 单 个 软 件 元 素 的 复 杂 度，但却解决不了软件中的规模问题 • 根据 7 ＋ / － 2 原则，人能够同时处理的元素是 5～9个，当软件中对象（种类）的数目超过一 定限度后，人们就无法同时去思考和处理这些 对象了。 9模块化通过划分，帮助人们将同时要考虑的 对象数目减少到普通智力的人能够胜任自如的 地步。
项目管理Project Management过程域
Project Planning Project Monitoring and Control Supplier Agreement Management Integrated Project Management Integrated Supplier Management Integrated Teaming (IPPD) Quantitative Project Management Risk Management
用例模型（需求）
影响（映射）
现实具象 （Concrete）
定义（抽象） 经理 顾客 职员
业务
需要 支持（运行）
解决域 （Solution Context）
限制（反作用）
规定（实现）
设计模型（架构）
被描述
软件交付
基于对象的软件系统观
交互 操作 对象实例
属性 操作
消息 对象实例
属性 操作
连接
Actor
13
过程、活动与思维法层次结构示意
过程层
过程域＃1 Process Area 1 过程域＃2 Process Area 2 过程域＃n Process Area n
实践/活动＃1 Practice 1 问题解决周期#1 problem solving 问题解决周期#2 problem solving 问题解决周期#n problem solving
12
光有宏观的过程、方法还不够
z无论是简单的问题解决步骤，还是包含了大量实践 活动的软件过程域（科目），它们都属于宏观的解 决途径。然而，任何软件问题，其最终解决还是要 落实到具体的细节之上，这些问题细节需要采用与 之相对应的微观方法来解决。 z例如，架构设计作为技术解决过程域中的一项实践 （或者分析设计科目中的一项活动），涉及到大量 的模块划分问题；而帮助人们进行划分的方法则主 要有比较、分类等思维法。
支 撑 过程 的执行
Support the Processes
支持Support过程域
软件架构设计中的方法论 ——微观思维方法在软件开发 中的运用
11
破除软件开发中的神秘主义
z国内软件界存在一定程度的神秘主义倾向，在自己 无力使用常规软件工程途径解决软件问题后，往往 简单地将软件开发归于艺术化、玄学化。 z经常看到的一种典型现象——某个高手熬了几个通 宵，终于拿出了一个精巧的设计方案；团队其他成 员都很钦佩他，并想向他学习其中设计的技巧；但 高手吹嘘说这完全是靠其灵感所得，思考过程毫无 逻辑可言。
30
示例：封装
将实现从客户角度隐
藏 客户只依赖于接口
31
抽象 vs 封装
9抽象和封装都是一种简化问题的思维模式， 但它们实现简化的方式不同: • 抽象剔除了不相关的内容，以突出重点； • 相对应地，封装则隐藏了相关但不需要被知道 （不能被剔除）的内部细节，以减少依赖。 9剔除与隐藏对于外部（客户）而言，其效果 是等价的
Order Entry
Order Processing System
Order Fulfillment
Billing
27
封装和层次化 ——构架设计中的划分与组织技 巧，帮助团队不断提升所开发 软件的规模数量级
28
模块化带来模块之间关系处理问题
9将系统划分为若干模块后，人们可以分别在各模块 内部处理那些数量已大幅减少的元素；但为了确保系 统的完整一致，人们同时还必须在系统层面来处理这 些模块及其之间的关系。 • 根据 7 ＋ / － 2 原则，人能够同时处理的元素是 5 ～ 9 个，但此间实际上还有一个隐含的条件，就是每个元 素本身的复杂度也不超过一定限度。由此，如果模块 对外展现的内容过多，人们仍然是无法在系统层面处 理这些模块（及其关系）的。 9封装在模块化划分的基础上进一步简化了模块本身 对外暴露的复杂度。
7
先选择方法的问题解决流程示意图
明确问题的性质与特点 如问题没能被解 决，往往需要选 择新的方法再次 去尝试
选择适合解决本类问题的方法（过程）
依照既定的方法（过 程）制定问题解决计划
通常是若干 基本问题解 决周期的某 种有机的组 合排列
分配人力及其它资源，执行问题 解决计划，直到问题被最终解决 贯彻既定方法（过程） 中定义的步骤，寻求并 实施最佳解决方案
33
层次化Hierarchy
9所谓层次化是指任何组织成为一种树状结构 的抽象级别或顺序； 9在面向对象的范式中，层次结构包括：
监控问题解 决计划的执 行
评估与验收问题解决结果
8
软件开发过程原理
以往软件 项目 以往软件 以往软件 项目 项目
经验总结 为规范化 软件过程 软件 过程 QA监督实际开发 活动执行了过程 规范——确保开 发过程质量
业界经验
经理 顾客
规范化
化 实例
业务
表述（抽象） QC确保 每个中 间制品 的质量
职员
29
封装Encapsulation
9所谓封装是指将特性（属性、行为）在物理 上局限于一个单独的黑盒抽象中，且将它们 的实现（和相关的设计决定）隐藏于公共接 口背后； 9在面向对象的范式中，从系统、子系统到对 象都拥有封装的特性。
z抽象类（还有接口）使得客户代码client code只需要关注 对象外在行为中与它相关的部分（忽略对象固有的但并不相关 的其它外在行为，例如从其它类继承的操作）； z对象的封装机制则封闭了对象所有的内部结构和内部行为， 使得客户代码无需关注对象内部的细节。
2
问题解决规律 ——人类如何解决复杂问题
3
问题解决 Problem Solving
z问题解决是思维的一种形式；当个人或组织 不知道如何从已知条件得到目标（期望结 果）的时候， “解决问题 ”这一智力活动便开 始了。
4
问题解决流程示意图
识别与澄清问题
收集相关信息 如问题没能 被解决，则 再 次 尝 试 （下一轮解 决周期）
25
模块化Modularity
9所谓模块化是指逻辑和物理上将事物 分解为更小、更简单的分组（例如需求 和类），从而满足软件工程化管理的需 要； • 模块化的实质——“分而治之”； • 在面向对象的范式中，子系统、包、构 件和对象本身都是模块化的实体元素。
26
示例：模块化
将较大规模、复杂的系统分解 为可以管理的分块
分析问题和评估已有信息
考虑各类解决方案选 项与结论
选择并实施最佳解决方案
5
软件开发的方法（理）论框架基础
z软件被用来解决人们的业务或领域问题，开 发软件的过程就是去获得解决业务问题结果 的过程。 z人类在问题解决规律研究方面已经有大量的 现成成果；传统的问题解决步骤，实际上为 软件开发（解决软件问题）提供了现成的 （战略级的）理论方法框架。 z现代的软件工程技术，其基础实际上就建立 在这些问题解决规律之上。
对象实例 对象实例
属性 操作 属性 操作
外 部 系 统
消息
对象实例
属性 操作
目标系统
抽象abstraction
9所谓抽象是指关注事物中与问题相关 的部分（通常是一个角度或方面），而 忽略其它不相关内容（细节）的一种思 考方式； • 抽象依赖于选择的问题领域和角度； • 在面向对象的范式中，使用从问题域的 抽象来表达目标系统（例如对象和 类）。