Mercurial > docs > unix-phil
comparison unix-phil.ms @ 9:529168f49f29
corrected spelling
author | meillo@marmaro.de |
---|---|
date | Fri, 19 Feb 2010 23:11:09 +0100 |
parents | 924b2ac2d477 |
children | 355ed69a34a8 |
comparison
equal
deleted
inserted
replaced
8:924b2ac2d477 | 9:529168f49f29 |
---|---|
48 .LP | 48 .LP |
49 Building a software is a process from an idea of the purpose of the software | 49 Building a software is a process from an idea of the purpose of the software |
50 to its release. | 50 to its release. |
51 No matter \fIhow\fP the process is run, two things are common: | 51 No matter \fIhow\fP the process is run, two things are common: |
52 the initial idea and the release. | 52 the initial idea and the release. |
53 The process inbetween can be of any shape. | 53 The process in between can be of any shape. |
54 The the maintainance work after the release is ignored for the moment. | 54 The the maintenance work after the release is ignored for the moment. |
55 .PP | 55 .PP |
56 The process of building splits mainly in two parts: | 56 The process of building splits mainly in two parts: |
57 the planning of what and how to build, and implementing the plan by writing code. | 57 the planning of what and how to build, and implementing the plan by writing code. |
58 This paper focuses on the planning part \(en the designing of the software. | 58 This paper focuses on the planning part \(en the designing of the software. |
59 .PP | 59 .PP |
60 Software design is the plan of how the internals and externals of the software should look like, | 60 Software design is the plan of how the internals and externals of the software should look like, |
61 based on the requirements. | 61 based on the requirements. |
62 This paper discusses the recommendations of the Unix Philosphy about software design. | 62 This paper discusses the recommendations of the Unix Philosophy about software design. |
63 .PP | 63 .PP |
64 The here discussed ideas can get applied by any development process. | 64 The here discussed ideas can get applied by any development process. |
65 The Unix Philosphy does recommend how the software development process should look like, | 65 The Unix Philosophy does recommend how the software development process should look like, |
66 but this shall not be of matter here. | 66 but this shall not be of matter here. |
67 Similar, the question of how to write the code is out of focus. | 67 Similar, the question of how to write the code is out of focus. |
68 .PP | 68 .PP |
69 The name ``Unix Philosophy'' was already mentioned several times, but it was not explained yet. | 69 The name ``Unix Philosophy'' was already mentioned several times, but it was not explained yet. |
70 The Unix Philosophy is the essence of how the Unix operating system and its toolchest was designed. | 70 The Unix Philosophy is the essence of how the Unix operating system and its toolchest was designed. |
105 These different views on the Unix Philosophy have much in common. | 105 These different views on the Unix Philosophy have much in common. |
106 Especially, the main concepts are similar for all of them. | 106 Especially, the main concepts are similar for all of them. |
107 But there are also points on which they differ. | 107 But there are also points on which they differ. |
108 This only underlines what the Unix Philosophy is: | 108 This only underlines what the Unix Philosophy is: |
109 A retrospective view on the main concepts of Unix software; | 109 A retrospective view on the main concepts of Unix software; |
110 especially those that were sucessful and unique to Unix. | 110 especially those that were successful and unique to Unix. |
111 .\" really? | 111 .\" really? |
112 .PP | 112 .PP |
113 Before we will have a look at concrete concepts, | 113 Before we will have a look at concrete concepts, |
114 we discuss why software design is important | 114 we discuss why software design is important |
115 and what problems bad design introduces. | 115 and what problems bad design introduces. |
147 The quality of a software is about properties that are not directly related to | 147 The quality of a software is about properties that are not directly related to |
148 the software's basic functions. | 148 the software's basic functions. |
149 Quality aspects are about the properties that are overlooked at first sight. | 149 Quality aspects are about the properties that are overlooked at first sight. |
150 .PP | 150 .PP |
151 Quality is of few matter when the software gets initially built, | 151 Quality is of few matter when the software gets initially built, |
152 but it will be of matter in usage and maintainance of the software. | 152 but it will be of matter in usage and maintenance of the software. |
153 A short-sighted might see in developing a software mainly building something up. | 153 A short-sighted might see in developing a software mainly building something up. |
154 Reality shows, that building the software the first time is only a small amount | 154 Reality shows, that building the software the first time is only a small amount |
155 of the overall work. | 155 of the overall work. |
156 Bug fixing, extending, rebuiling of parts \(en short: maintainance work \(en | 156 Bug fixing, extending, rebuilding of parts \(en short: maintenance work \(en |
157 does soon take over the major part of the time spent on a software. | 157 does soon take over the major part of the time spent on a software. |
158 Not to forget the usage of the software. | 158 Not to forget the usage of the software. |
159 These processes are highly influenced by the software's quality. | 159 These processes are highly influenced by the software's quality. |
160 Thus, quality should never be neglected. | 160 Thus, quality should never be neglected. |
161 The problem is that you hardly ``stumble over'' bad quality during the first build, | 161 The problem is that you hardly ``stumble over'' bad quality during the first build, |
169 but good quality can provide a lot of additional gain from the software, | 169 but good quality can provide a lot of additional gain from the software, |
170 even at places where one never expected it. | 170 even at places where one never expected it. |
171 .PP | 171 .PP |
172 The ISO/IEC 9126-1 standard, part 1, | 172 The ISO/IEC 9126-1 standard, part 1, |
173 .[ | 173 .[ |
174 %I International Organization for Standarization | 174 %I International Organization for Standardization |
175 %T ISO Standard 9126: Software Engineering \(en Product Quality, part 1 | 175 %T ISO Standard 9126: Software Engineering \(en Product Quality, part 1 |
176 %C Geneve | 176 %C Geneve |
177 %D 2001 | 177 %D 2001 |
178 .] | 178 .] |
179 defines the quality model as consisting out of: | 179 defines the quality model as consisting out of: |
186 .IP \(bu | 186 .IP \(bu |
187 .I Usability | 187 .I Usability |
188 (understandability, learnability, operability, attractiveness) | 188 (understandability, learnability, operability, attractiveness) |
189 .IP \(bu | 189 .IP \(bu |
190 .I Efficiency | 190 .I Efficiency |
191 (time behaviour, resource utilisation) | 191 (time behavior, resource utilization) |
192 .IP \(bu | 192 .IP \(bu |
193 .I Maintainability | 193 .I Maintainability |
194 (analysability, changeability, stability, testability) | 194 (analysability, changeability, stability, testability) |
195 .IP \(bu | 195 .IP \(bu |
196 .I Portability | 196 .I Portability |
224 .LP | 224 .LP |
225 Following are some examples to demonstrate how applied Unix Philosophy feels like. | 225 Following are some examples to demonstrate how applied Unix Philosophy feels like. |
226 Knowledge of using the Unix shell is assumed. | 226 Knowledge of using the Unix shell is assumed. |
227 .PP | 227 .PP |
228 Counting the number of files in the current directory: | 228 Counting the number of files in the current directory: |
229 .DS | 229 .DS I 2n |
230 .CW | 230 .CW |
231 .ps -1 | |
231 ls | wc -l | 232 ls | wc -l |
232 .DE | 233 .DE |
233 The | 234 The |
234 .CW ls | 235 .CW ls |
235 command lists all files in the current directory, one per line, | 236 command lists all files in the current directory, one per line, |
236 and | 237 and |
237 .CW "wc -l | 238 .CW "wc -l |
238 counts the number of lines. | 239 counts the number of lines. |
239 .PP | 240 .PP |
240 Counting the number of files that do not contain ``foo'' in their name: | 241 Counting the number of files that do not contain ``foo'' in their name: |
241 .DS | 242 .DS I 2n |
242 .CW | 243 .CW |
244 .ps -1 | |
243 ls | grep -v foo | wc -l | 245 ls | grep -v foo | wc -l |
244 .DE | 246 .DE |
245 Here, the list of files is filtered by | 247 Here, the list of files is filtered by |
246 .CW grep | 248 .CW grep |
247 to remove all that contain ``foo''. | 249 to remove all that contain ``foo''. |
248 The rest is the same as in the previous example. | 250 The rest is the same as in the previous example. |
249 .PP | 251 .PP |
250 Finding the five largest entries in the current directory. | 252 Finding the five largest entries in the current directory. |
251 .DS | 253 .DS I 2n |
252 .CW | 254 .CW |
255 .ps -1 | |
253 du -s * | sort -nr | sed 5q | 256 du -s * | sort -nr | sed 5q |
254 .DE | 257 .DE |
255 .CW "du -s * | 258 .CW "du -s * |
256 returns the recursively summed sizes of all files | 259 returns the recursively summed sizes of all files |
257 \(en no matter if they are regular files or directories. | 260 \(en no matter if they are regular files or directories. |
334 .PP | 337 .PP |
335 There are two drawbacks of the toolchest approach. | 338 There are two drawbacks of the toolchest approach. |
336 First, one simple, standardized, unidirectional interface has to be sufficient. | 339 First, one simple, standardized, unidirectional interface has to be sufficient. |
337 If one feels the need for more ``logic'' than a stream of bytes, | 340 If one feels the need for more ``logic'' than a stream of bytes, |
338 then a different approach might be of need. | 341 then a different approach might be of need. |
339 But it is also possbile, that he just can not imaging a design where | 342 But it is also possible, that he just can not imaging a design where |
340 a stream of bytes is sufficient. | 343 a stream of bytes is sufficient. |
341 By becoming more familiar with the ``Unix style of thinking'', | 344 By becoming more familiar with the ``Unix style of thinking'', |
342 developers will more often and easier find simple designs where | 345 developers will more often and easier find simple designs where |
343 a stream of bytes is a sufficient interface. | 346 a stream of bytes is a sufficient interface. |
344 .PP | 347 .PP |
345 The second drawback of a toolchest affects the users. | 348 The second drawback of a toolchest affects the users. |
346 A toolchest is often more difficult to use for novices. | 349 A toolchest is often more difficult to use for novices. |
347 It is neccessary to become familiar with each of the tools, | 350 It is necessary to become familiar with each of the tools, |
348 to be able to use the right one in a given situation. | 351 to be able to use the right one in a given situation. |
349 Additinally, one needs to combine the tools in a senseful way on its own. | 352 Additionally, one needs to combine the tools in a senseful way on its own. |
350 This is like a sharp knive \(en it is a powerful tool in the hand of a master, | 353 This is like a sharp knife \(en it is a powerful tool in the hand of a master, |
351 but of no good value in the hand of an unskilled. | 354 but of no good value in the hand of an unskilled. |
352 .PP | 355 .PP |
353 However, learning single, small tool of the toolchest is easier than | 356 However, learning single, small tool of the toolchest is easier than |
354 learning a complex tool. | 357 learning a complex tool. |
355 The user will have a basic understanding of a yet unknown tool, | 358 The user will have a basic understanding of a yet unknown tool, |
365 No complexity is added this way, | 368 No complexity is added this way, |
366 but new programs can get created out of existing one with very low effort. | 369 but new programs can get created out of existing one with very low effort. |
367 .PP | 370 .PP |
368 A wrapper script for finding the five largest entries in the current directory | 371 A wrapper script for finding the five largest entries in the current directory |
369 could look like this: | 372 could look like this: |
370 .DS | 373 .DS I 2n |
371 .CW | 374 .CW |
375 .ps -1 | |
372 #!/bin/sh | 376 #!/bin/sh |
373 du -s * | sort -nr | sed 5q | 377 du -s * | sort -nr | sed 5q |
374 .DE | 378 .DE |
375 The script itself is just a text file that calls the command line | 379 The script itself is just a text file that calls the command line |
376 a professional user would type in directly. | 380 a professional user would type in directly. |
377 Making the program flexible on the number of entries it prints, | 381 Making the program flexible on the number of entries it prints, |
378 is easily possible: | 382 is easily possible: |
379 .DS | 383 .DS I 2n |
380 .CW | 384 .CW |
385 .ps -1 | |
381 #!/bin/sh | 386 #!/bin/sh |
382 num=5 | 387 num=5 |
383 [ $# -eq 1 ] && num="$1" | 388 [ $# -eq 1 ] && num="$1" |
384 du -sh * | sort -nr | sed "${num}q" | 389 du -sh * | sort -nr | sed "${num}q" |
385 .DE | 390 .DE |