软件系统设计的原则与技术

需积分: 5 11 浏览量更新于2024-06-30 收藏 796KB PDF 举报

"软件设计原则和要点" 软件设计原则是指在软件开发过程中遵循的一些基本原则和要点，以确保软件系统的质量、可靠性和可维护性。这些原则和要点来自于软件设计的实践经验和理论研究，旨在指导软件开发者设计和实现高质量的软件系统。 1. 简单性（Simple）软件设计的第一个原则是简单性。简单性是指软件系统的设计应该尽量简单、直接和易于理解。简单的设计可以减少软件系统的复杂度，提高开发效率和维护性。 2. 及时性（Timely）软件设计的第二个原则是及时性。及时性是指软件系统的设计应该能够满足用户的需求，并且能够在规定的时间内完成任务。及时性的设计可以提高软件系统的响应速度和实时性。 3. 高效性（Efficient）软件设计的第三个原则是高效性。高效性是指软件系统的设计应该能够最大化地使用系统资源，减少资源浪费，提高系统的性能和效率。 4. 适应性（Adaptable）软件设计的第四个原则是适应性。适应性是指软件系统的设计应该能够适应不断变化的需求和环境，具有良好的可扩展性和可维护性。 5. 可靠性（Dependable）软件设计的第五个原则是可靠性。可靠性是指软件系统的设计应该能够确保系统的稳定运行，避免系统崩溃和错误。 6. 便捷性（Yummy）软件设计的第六个原则是便捷性。便捷性是指软件系统的设计应该能够提供良好的用户体验，易于使用和操作。技术要点： 1. 近似技术（Approximate）近似技术是指软件设计中使用近似算法和模型来解决问题，提高设计效率和速度。 2. 增量技术（Incremental）增量技术是指软件设计中使用增量式开发和测试，逐步完善和改进软件系统。 3. 分治技术（Divide & Conquer）分治技术是指软件设计中将复杂的问题分解成小问题，逐步解决和整合，提高设计效率和质量。设计原则： 1. 系统设计原则系统设计原则是指软件设计中遵循的一些基本原则和要点，以确保软件系统的质量、可靠性和可维护性。 2. 算法设计原则算法设计原则是指软件设计中遵循的一些基本原则和要点，以确保算法的正确性、效率和可靠性。软件设计原则和要点是软件设计的基础和核心，遵循这些原则和要点可以确保软件系统的质量、可靠性和可维护性。

• How hard is it to write your program so that the language guarantees a safe, bulletproof abstract

state, in which a variable always has the expected type and only an explicit write can change

its value? Usually this means strong typing and garbage collection. Java is safe in this sense,

C++ is not (unless you hide unsafe features behind a safe abstraction),

R65

and JavaScript is in

between. If the abstract state isn’t bulletproof, debugging is much harder.

• Is the language well matched to your problem domain? Is it easy to say the things that you say

frequently? Is it possible to say all the things that you need to say?

• What static checking does the compiler do? A bug found at compile time is much easier to fix.

• How hard is it to make your program efficient enough, and to measure how it uses resources?

2.4 Modules and interfaces—Keep it clean. Keep basic interfaces stable.

The only known way to build a large system is to reinforce abstraction with divide and conquer:

break the system down into independent abstractions called modules. I’ll call the running code of

a module a service; sometimes people call it an object. The spec for a module does two things:

− it simplifies the client’s life by hiding the complexity of the code (see above), and

− it decouples the client from the code, so that the two can evolve independently.

Thus many people can work on the system productively in parallel without needing to talk to each

other. Since a spec embodies assumptions that are shared by more than one part of a system, and

sometimes by a great many parts, changing it is costly.

It’s common to call the spec of a module its interface, and I’ll do this too. Unfortunately, in

common usage an interface is a very incomplete spec that a compiler or loader can process, giving

just the data types and the names and (if you’re lucky) the parameters of the operations, rather than

what the actions do with the state. Even a good description of the state is often missing.

A really successful interface is like an hourglass: the spec is the narrow neck, with many clients

above and many codes below; it can live for decades. Examples: CPU ISAs (instruction set archi-

tectures such as x86 and ARM), file systems (Posix), reliable messages (TCP), names for Internet

services (DNS), web pages (HTTP and HTML). Ousterhout’s book on software design

R53

gives

many smaller examples, emphasizing how important it is to make the spec much smaller and sim-

pler than the code.

A module boundary doesn’t just decouple its code from the clients; it can decouple its execu-

tion and resource consumption as well. If the interface is asynchronous neither side waits for the

other, so the service can keep running no matter what the clients are doing, and vice versa. And it

can manage the way it consumes storage and other resources independently of its clients. Thus the

service is an autonomous agent. How does this show up in the spec? A complete spec doesn’t just

say enough about the service’s internal state to say what results it returns; the spec also describes

how it consumes any resources it shares with its clients. An autonomous service doesn’t share

resources, so its spec is simpler and a system that uses it is more dependable and easier to change.

Distributed transactions are an interesting example.

2.4.1 Classes and objects

Mathematics is the art of giving the same name to different things. —Henri Poincaré

Q43

A very popular variation on modules attaches the spec and code to a data item, usually called an

object. Programs organized this way are called object-oriented. You package the specs for a set of

routines called methods with the same type of first argument into a single spec, here called a class-

pec (it’s called an abstract base class in C++ and Python). The code for the classpec is a class, a

dictionary that maps each method name to its code. An object that has the class attached is an

instance of the class.

For example, the classpec Ordered T might have methods eq and lt. If x is an instance of

Ordered T, then x.eq(y) calls the eq method in x’s class with arguments (x,y). Adding methods

to a class makes a subclass, which inherits the superclass methods; so Ordered T is a subclass of

an Equal T class that has only the eq method. An Ordered T instance is also an Equal T instance.

2.4.2 Layers and platforms

A system usually has lots of modules, and when a module’s spec

changes you need to know who depends on it. To make this easier, put

related modules into a layer, a single unit that a team or vendor can ship

and a client can understand. The layer only exposes chosen interfaces, and a lower layer is not

allowed to call a routine in a higher layer. So a layer is a big module, normally a client of its host,

a single layer below it, with one or more layers as its clients above it. Layers are good for decou-

pling, but they are not free. Unless you’re very careful, there’s a significant cost for each level of

abstraction. Usually this cost is worth paying, but if performance is important it’s prudent to meas-

ure it. There are two ways to reduce it: make it cheaper to go from one layer to another, or bypass

some layers (making the system a lot more complicated and hard to maintain). The ideas in § 2.4.4

on open systems can also help.

Usually you build a system on a platform, a big layer that serves a wider range of clients and

comes from a different organization. Common platforms are a browser (the interface is a document

object model accessed through JavaScript) or a database system (the interface is SQL), built on an

operating system platform (Windows or Linux; the interface is kernel and library calls) built on a

hardware platform (Intel x86 or ARM; the interface is the ISA). It’s turtles all the way down: the

hardware is built on gates and memory cells, which are built on transistors, which are built on

electrons . Here is a 2020 example with all the turtles:

Host

YOU

Clients

PeersPeers

剩余54页未读，继续阅读

dugri

粉丝: 0
资源: 1

软件系统设计的原则与技术

Thinking in Software

ISPF Design Coding Hints and Tips

Mac Kung Fu Over 400 Tips Tricks Hints and Hacks for Apple OS X 2nd Edition

Guide and Hints for Samsung BLE API

oracle_hints

meeting hints 2

hints_website

oracle HINTS用法

Oracle SQL Hints

英文原版-Introduction to the Design and Analysis of Algorithms 1st Edition

最新资源