| rev |
line source |
|
meillo@2
|
1 .\".if n .pl 1000i
|
|
meillo@0
|
2 .de XX
|
|
meillo@0
|
3 .pl 1v
|
|
meillo@0
|
4 ..
|
|
meillo@0
|
5 .em XX
|
|
meillo@1
|
6 .\".nr PI 0
|
|
meillo@1
|
7 .\".if t .nr PD .5v
|
|
meillo@1
|
8 .\".if n .nr PD 1v
|
|
meillo@0
|
9 .nr lu 0
|
|
meillo@0
|
10 .de CW
|
|
meillo@0
|
11 .nr PQ \\n(.f
|
|
meillo@0
|
12 .if t .ft CW
|
|
meillo@0
|
13 .ie \\$1 .if n .ul 999
|
|
meillo@0
|
14 .el .if n .ul 1
|
|
meillo@0
|
15 .if t .if !\\$1 \&\\$1\f\\n(PQ\\$2
|
|
meillo@0
|
16 .if n .if \\n(.$=1 \&\\$1
|
|
meillo@0
|
17 .if n .if \\n(.$>1 \&\\$1\c
|
|
meillo@0
|
18 .if n .if \\n(.$>1 \&\\$2
|
|
meillo@0
|
19 ..
|
|
meillo@0
|
20 .ds [. \ [
|
|
meillo@0
|
21 .ds .] ]
|
|
meillo@1
|
22 .\"----------------------------------------
|
|
meillo@0
|
23 .TL
|
|
meillo@0
|
24 Why the Unix Philosophy matters
|
|
meillo@0
|
25 .AU
|
|
meillo@0
|
26 markus schnalke <meillo@marmaro.de>
|
|
meillo@0
|
27 .AB
|
|
meillo@1
|
28 .ti \n(.iu
|
|
meillo@2
|
29 This paper discusses the importance of the Unix Philosophy in software design.
|
|
meillo@0
|
30 Today, few software designers are aware of these concepts,
|
|
meillo@3
|
31 and thus most modern software is limited and does not make use of software leverage.
|
|
meillo@0
|
32 Knowing and following the tenets of the Unix Philosophy makes software more valuable.
|
|
meillo@0
|
33 .AE
|
|
meillo@0
|
34
|
|
meillo@2
|
35 .if t .2C
|
|
meillo@2
|
36
|
|
meillo@2
|
37 .FS
|
|
meillo@2
|
38 .ps -1
|
|
meillo@2
|
39 This paper was prepared for the seminar ``Software Analysis'' at University Ulm.
|
|
meillo@2
|
40 Mentor was professor Schweiggert. 2010-02-05
|
|
meillo@2
|
41 .br
|
|
meillo@2
|
42 You may get this document from my website
|
|
meillo@2
|
43 .CW \s-1http://marmaro.de/docs
|
|
meillo@2
|
44 .FE
|
|
meillo@2
|
45
|
|
meillo@0
|
46 .NH 1
|
|
meillo@0
|
47 Introduction
|
|
meillo@0
|
48 .LP
|
|
meillo@0
|
49 Building a software is a process from an idea of the purpose of the software
|
|
meillo@3
|
50 to its release.
|
|
meillo@0
|
51 No matter \fIhow\fP the process is run, two things are common:
|
|
meillo@0
|
52 the initial idea and the release.
|
|
meillo@3
|
53 The process inbetween can be of any shape.
|
|
meillo@3
|
54 The the maintainance work after the release is ignored for the moment.
|
|
meillo@1
|
55 .PP
|
|
meillo@0
|
56 The process of building splits mainly in two parts:
|
|
meillo@0
|
57 the planning of what and how to build, and implementing the plan by writing code.
|
|
meillo@3
|
58 This paper focuses on the planning part \(en the designing of the software.
|
|
meillo@3
|
59 .PP
|
|
meillo@3
|
60 Software design is the plan of how the internals and externals of the software should look like,
|
|
meillo@3
|
61 based on the requirements.
|
|
meillo@3
|
62 This paper discusses the recommendations of the Unix Philosphy about software design.
|
|
meillo@3
|
63 .PP
|
|
meillo@3
|
64 The here discussed ideas can get applied by any development process.
|
|
meillo@3
|
65 The Unix Philosphy does recommend how the software development process should look like,
|
|
meillo@3
|
66 but this shall not be of matter here.
|
|
meillo@0
|
67 Similar, the question of how to write the code is out of focus.
|
|
meillo@1
|
68 .PP
|
|
meillo@3
|
69 The name ``Unix Philosophy'' was already mentioned several times, but it was not explained yet.
|
|
meillo@1
|
70 The Unix Philosophy is the essence of how the Unix operating system and its toolchest was designed.
|
|
meillo@3
|
71 It is no limited set of rules, but what people see to be common to typical Unix software.
|
|
meillo@1
|
72 Several people stated their view on the Unix Philosophy.
|
|
meillo@1
|
73 Best known are:
|
|
meillo@1
|
74 .IP \(bu
|
|
meillo@1
|
75 Doug McIlroy's summary: ``Write programs that do one thing and do it well.''
|
|
meillo@1
|
76 .[
|
|
meillo@1
|
77 %A M. D. McIlroy
|
|
meillo@1
|
78 %A E. N. Pinson
|
|
meillo@1
|
79 %A B. A. Taque
|
|
meillo@1
|
80 %T UNIX Time-Sharing System Forward
|
|
meillo@1
|
81 %J The Bell System Technical Journal
|
|
meillo@1
|
82 %D 1978
|
|
meillo@1
|
83 %V 57
|
|
meillo@1
|
84 %N 6
|
|
meillo@1
|
85 %P 1902
|
|
meillo@1
|
86 .]
|
|
meillo@1
|
87 .IP \(bu
|
|
meillo@1
|
88 Mike Gancarz' book ``The UNIX Philosophy''.
|
|
meillo@1
|
89 .[
|
|
meillo@1
|
90 %A Mike Gancarz
|
|
meillo@1
|
91 %T The UNIX Philosophy
|
|
meillo@1
|
92 %D 1995
|
|
meillo@1
|
93 %I Digital Press
|
|
meillo@1
|
94 .]
|
|
meillo@1
|
95 .IP \(bu
|
|
meillo@1
|
96 Eric S. Raymond's book ``The Art of UNIX Programming''.
|
|
meillo@1
|
97 .[
|
|
meillo@1
|
98 %A Eric S. Raymond
|
|
meillo@1
|
99 %T The Art of UNIX Programming
|
|
meillo@1
|
100 %D 2003
|
|
meillo@1
|
101 %I Addison-Wesley
|
|
meillo@2
|
102 %O .CW \s-1http://www.faqs.org/docs/artu/
|
|
meillo@1
|
103 .]
|
|
meillo@0
|
104 .LP
|
|
meillo@1
|
105 These different views on the Unix Philosophy have much in common.
|
|
meillo@3
|
106 Especially, the main concepts are similar for all of them.
|
|
meillo@1
|
107 But there are also points on which they differ.
|
|
meillo@1
|
108 This only underlines what the Unix Philosophy is:
|
|
meillo@1
|
109 A retrospective view on the main concepts of Unix software;
|
|
meillo@1
|
110 especially those that were sucessful and unique to Unix.
|
|
meillo@1
|
111 .PP
|
|
meillo@1
|
112 Before we will have a look at concrete concepts,
|
|
meillo@1
|
113 we discuss why software design is important
|
|
meillo@1
|
114 and what problems bad design introduces.
|
|
meillo@0
|
115
|
|
meillo@0
|
116
|
|
meillo@0
|
117 .NH 1
|
|
meillo@0
|
118 Importance of software design
|
|
meillo@0
|
119 .LP
|
|
meillo@2
|
120 Why should we design software at all?
|
|
meillo@3
|
121 It is general knowledge, that a bad plan is better than no plan.
|
|
meillo@2
|
122 As stated earlier in this document, the process of building a software
|
|
meillo@2
|
123 means going from an idea to a release.
|
|
meillo@2
|
124 The development process tells how to get from the idea to the release.
|
|
meillo@3
|
125 Software design is the shape of the built software.
|
|
meillo@3
|
126 This means, that different designs of a software would be different target points to go to.
|
|
meillo@3
|
127 Thus, the design of a software defines the global direction the development goes.
|
|
meillo@2
|
128 .PP
|
|
meillo@2
|
129 It is not enough that the released software offers all requested functionality.
|
|
meillo@2
|
130 It is a misbelief that only function matters.
|
|
meillo@2
|
131 Building a software the first time is only a small part of the overall work.
|
|
meillo@2
|
132 The larger part begins when the software is released for the first time
|
|
meillo@2
|
133 \(en maintainance and extending work..
|
|
meillo@2
|
134 This part soon covers more time than the time which was needed to build the software the first time.
|
|
meillo@2
|
135 .\" cf. brooks?
|
|
meillo@2
|
136 .PP
|
|
meillo@2
|
137 The extendability and maitainability of a software highly depends on its design.
|
|
meillo@2
|
138 Good design eases these tasks much.
|
|
meillo@2
|
139 Bad design, in contrast, requires much more effort for maintaining and
|
|
meillo@2
|
140 extending the software.
|
|
meillo@2
|
141 Developers should, for their own best, have maintainability and extendability in mind
|
|
meillo@2
|
142 when they design the software.
|
|
meillo@2
|
143 .PP
|
|
meillo@3
|
144 Users of the software, in contrast, do not care about maintainability and extendability,
|
|
meillo@2
|
145 at least not directly.
|
|
meillo@2
|
146 They care about usability and flexibility.
|
|
meillo@2
|
147 They want the software to directly solve their problems.
|
|
meillo@2
|
148 They want to be able to to use all its functions if they learned a few of them.
|
|
meillo@2
|
149 They want to use the software for similar tasks.
|
|
meillo@2
|
150 Software is successful if users enjoy using it.
|
|
meillo@2
|
151 Good software design can offer great flexibility and usability.
|
|
meillo@2
|
152 .PP
|
|
meillo@2
|
153 Good design matters for developers \fIand\fP for users.
|
|
meillo@2
|
154 Hence both groups should care about good software design.
|
|
meillo@2
|
155 Bad design limits the software in some way.
|
|
meillo@2
|
156 It may still provide all requested function, but it will have worse quality,
|
|
meillo@2
|
157 and thus require more work effort for developers or frustrate users.
|
|
meillo@2
|
158 .PP
|
|
meillo@2
|
159 Good software design is to the implementation like data structures are to algorithms
|
|
meillo@2
|
160 \(en if you get the former right, then you do not need to care about the latter,
|
|
meillo@2
|
161 it will simply go the right way.
|
|
meillo@2
|
162 .\" cf. ??? ``good data, bad algos''
|
|
meillo@0
|
163
|
|
meillo@0
|
164
|
|
meillo@0
|
165
|
|
meillo@0
|
166
|
|
meillo@0
|
167 .NH 1
|
|
meillo@0
|
168 The Unix Philosophy
|
|
meillo@0
|
169
|
|
meillo@0
|
170 .NH 2
|
|
meillo@0
|
171 what it is
|
|
meillo@0
|
172 .LP
|
|
meillo@0
|
173 definitions by McIlroy, Gancarz, ESR (maybe already in the intro)
|
|
meillo@0
|
174 .LP
|
|
meillo@0
|
175 cf. unix tool chain
|
|
meillo@0
|
176 .LP
|
|
meillo@0
|
177 enabler pipe
|
|
meillo@0
|
178
|
|
meillo@0
|
179 .NH 2
|
|
meillo@2
|
180 Architecture
|
|
meillo@2
|
181 .LP
|
|
meillo@2
|
182 the most important design decision.
|
|
meillo@2
|
183
|
|
meillo@2
|
184 the topic here
|
|
meillo@2
|
185
|
|
meillo@2
|
186 .NH 2
|
|
meillo@0
|
187 Interface architecture
|
|
meillo@0
|
188 .LP
|
|
meillo@0
|
189 standalone vs. tool chain
|
|
meillo@0
|
190 .LP
|
|
meillo@0
|
191 software leverage
|
|
meillo@0
|
192 .LP
|
|
meillo@0
|
193 possiblities
|
|
meillo@0
|
194
|
|
meillo@0
|
195 .NH 2
|
|
meillo@0
|
196 Results
|
|
meillo@0
|
197 .LP
|
|
meillo@0
|
198 The unix phil is an answer to the sw design question
|
|
meillo@0
|
199 .LP
|
|
meillo@0
|
200 tool chains empower the uses of sw
|
|
meillo@0
|
201
|
|
meillo@0
|
202 .NH 1
|
|
meillo@0
|
203 Case study: nmh
|
|
meillo@0
|
204
|
|
meillo@0
|
205 .NH 2
|
|
meillo@0
|
206 History
|
|
meillo@0
|
207 .LP
|
|
meillo@0
|
208 MH, nmh.
|
|
meillo@0
|
209 They are old.
|
|
meillo@0
|
210
|
|
meillo@0
|
211 .NH 2
|
|
meillo@0
|
212 Contrasts to similar sw
|
|
meillo@0
|
213 .LP
|
|
meillo@0
|
214 vs. Thunderbird, mutt, mailx, pine
|
|
meillo@0
|
215 .LP
|
|
meillo@0
|
216 flexibility, no redundancy, use the shell
|
|
meillo@0
|
217
|
|
meillo@0
|
218 .NH 2
|
|
meillo@0
|
219 Gains of the design
|
|
meillo@0
|
220 .LP
|
|
meillo@0
|
221
|
|
meillo@0
|
222 .NH 2
|
|
meillo@0
|
223 Problems
|
|
meillo@0
|
224 .LP
|
|
meillo@0
|
225
|
|
meillo@0
|
226 .NH 1
|
|
meillo@0
|
227 Case study: uzbl
|
|
meillo@0
|
228
|
|
meillo@0
|
229 .NH 2
|
|
meillo@0
|
230 History
|
|
meillo@0
|
231 .LP
|
|
meillo@0
|
232 uzbl is young
|
|
meillo@0
|
233
|
|
meillo@0
|
234 .NH 2
|
|
meillo@0
|
235 Contrasts to similar sw
|
|
meillo@0
|
236 .LP
|
|
meillo@0
|
237 like with nmh
|
|
meillo@0
|
238 .LP
|
|
meillo@0
|
239 addons, plugins, modules
|
|
meillo@0
|
240
|
|
meillo@0
|
241 .NH 2
|
|
meillo@0
|
242 Gains of the design
|
|
meillo@0
|
243 .LP
|
|
meillo@0
|
244
|
|
meillo@0
|
245 .NH 2
|
|
meillo@0
|
246 Problems
|
|
meillo@0
|
247 .LP
|
|
meillo@0
|
248 broken web
|
|
meillo@0
|
249
|
|
meillo@0
|
250 .NH 1
|
|
meillo@0
|
251 Final thoughts
|
|
meillo@0
|
252
|
|
meillo@0
|
253 .NH 2
|
|
meillo@0
|
254 Quick summary
|
|
meillo@0
|
255 .LP
|
|
meillo@0
|
256 good design
|
|
meillo@0
|
257 .LP
|
|
meillo@0
|
258 unix phil
|
|
meillo@0
|
259 .LP
|
|
meillo@0
|
260 case studies
|
|
meillo@0
|
261
|
|
meillo@0
|
262 .NH 2
|
|
meillo@0
|
263 Why people should choose
|
|
meillo@0
|
264 .LP
|
|
meillo@0
|
265 Make the right choice!
|
|
meillo@0
|
266
|
|
meillo@0
|
267 .nr PI .5i
|
|
meillo@0
|
268 .rm ]<
|
|
meillo@0
|
269 .de ]<
|
|
meillo@0
|
270 .LP
|
|
meillo@0
|
271 .de FP
|
|
meillo@0
|
272 .IP \\\\$1.
|
|
meillo@0
|
273 \\..
|
|
meillo@0
|
274 .rm FS FE
|
|
meillo@0
|
275 ..
|
|
meillo@0
|
276 .SH
|
|
meillo@0
|
277 References
|
|
meillo@0
|
278 .[
|
|
meillo@0
|
279 $LIST$
|
|
meillo@0
|
280 .]
|
|
meillo@0
|
281 .wh -1p
|
