Mercurial > docs > unix-phil

comparison unix-phil.ms @ 57:840cbc667009

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
applied corrections by Andrew Antle
author meillo@marmaro.de
date Fri, 16 Apr 2010 11:48:38 +0200
parents acd63ecc3606
children 733f4fb03071
comparison
equal deleted inserted replaced
56:7678e37ceffc 57:840cbc667009
25 25
26 .H 1 Introduction 26 .H 1 Introduction
27 .LP 27 .LP
28 The Unix Philosophy is the essence of how the Unix operating system, 28 The Unix Philosophy is the essence of how the Unix operating system,
29 especially its toolchest, was designed. 29 especially its toolchest, was designed.
30 It is no limited set of fixed rules, 30 It is not a limited set of fixed rules,
31 but a loose set of guidelines which tell how to write software that 31 but a loose set of guidelines which tell how to write software that
32 suites well into Unix. 32 suites Unix well.
33 Actually, the Unix Philosophy describes what is common to typical Unix software. 33 Actually, the Unix Philosophy describes what is common in typical Unix software.
34 The Wikipedia has an accurate definition: 34 The Wikipedia has an accurate definition:
35 .[ 35 .[
36 wikipedia 36 wikipedia
37 unix philosophy 37 unix philosophy
38 .] 38 .]
64 .] 64 .]
65 .LP 65 .LP
66 These different views on the Unix Philosophy have much in common. 66 These different views on the Unix Philosophy have much in common.
67 Especially, the main concepts are similar in all of them. 67 Especially, the main concepts are similar in all of them.
68 McIlroy's definition can surely be called the core of the Unix Philosophy, 68 McIlroy's definition can surely be called the core of the Unix Philosophy,
69 but the fundamental idea behind it all, is ``small is beautiful''. 69 but the fundamental idea behind it all is ``small is beautiful''.
70 70
71 .PP 71 .PP
72 The Unix Philosophy explains how to design good software for Unix. 72 The Unix Philosophy explains how to design good software for Unix.
73 Many concepts described here, base on facilities of Unix. 73 Many concepts described here are based on Unix facilities.
74 Other operating systems may not offer such facilities, 74 Other operating systems may not offer such facilities,
75 hence it may not be possible to design software in the way of the 75 hence it may not be possible to design software for such systems
76 Unix Philosophy for them. 76 according to the Unix Philosophy.
77 .PP 77 .PP
78 The Unix Philosophy has an idea of how the process of software development 78 The Unix Philosophy has an idea of what the process of software development
79 should look like, but large parts of the philosophy are quite independent 79 should look like, but large parts of the philosophy are quite independent
80 from a concrete development process. 80 from a concrete development process.
81 However, one will soon recognize that some development processes work well 81 However, one will soon recognize that some development processes work well
82 with the ideas of the Unix Philosophy and support them, while others are 82 with the ideas of the Unix Philosophy and support them, while others are
83 at cross-purposes. 83 at cross-purposes.
84 Kent Beck's books about Extreme Programming are valuable supplemental 84 Kent Beck's books about Extreme Programming are valuable supplemental
85 resources on this topic. 85 resources on this topic.
86 .PP 86 .PP
87 The question of how to actually write code and how the code should looks 87 The question of how to actually write code and how the code should look
88 like in detail, are out of focus here. 88 in detail, are beyond the scope of this paper.
89 ``The Practice of Programming'' by Kernighan and Pike, 89 Kernighan and Pike's book ``The Practice of Programming''
90 .[ 90 .[
91 kernighan pike 91 kernighan pike
92 practice of programming 92 practice of programming
93 .] 93 .]
94 is a good book that covers this topic. 94 covers this topic.
95 Its point of view matches to the one of this paper. 95 Its point of view corresponds to the one espoused in this paper.
96 96
97 .H 1 "Importance of software design in general 97 .H 1 "Importance of software design in general
98 .LP 98 .LP
99 Software design is the planning of how the internal structure 99 Software design consists of planning how the internal structure
100 and external interfaces of software should look like. 100 and external interfaces of software should look.
101 It has nothing to do with visual appearance. 101 It has nothing to do with visual appearance.
102 If we take a program as a car, then its color is of no matter. 102 If we were to compare a program to a car, then its color would not matter.
103 Its design would be the car's size, its shape, the locations of doors, 103 Its design would be the car's size, its shape, the locations of doors,
104 the passenger/space ratio, the available controls and instruments, 104 the passenger/space ratio, the available controls and instruments,
105 and so forth. 105 and so forth.
106 .PP 106 .PP
107 Why should software get designed at all? 107 Why should software be designed at all?
108 It is general knowledge, that even a bad plan is better than no plan. 108 It is accepted as general knowledge,
109 Not designing software means programming without plan. 109 that even a bad plan is better than no plan.
110 This will pretty sure lead to horrible results. 110 Not designing software means programming without a plan.
111 Software that is horrible to use and horrible to maintain. 111 This will surely lead to horrible results,
112 being horrible to use and horrible to maintain.
112 These two aspects are the visible ones. 113 These two aspects are the visible ones.
113 Often invisible though, are the wasted possible gains. 114 Often invisible though, are the wasted possible gains.
114 Good software design can make these gains available. 115 Good software design can make these gains available.
115 .PP 116 .PP
116 Software design deals with quality properties. 117 A software's design deals with qualitative properties.
117 Good design leads to good quality, and quality is important. 118 Good design leads to good quality, and quality is important.
118 Any car may be able to drive from A to B, 119 Any car may be able to drive from point A to point B,
119 but it depends on the car's properties whether it is a good choice 120 but it depends on the qualitative decisions made in the design of the vehicle,
120 for passenger transport or not. 121 whether it is a good choice for passenger transport or not,
121 It depends on its properties if it is a good choice 122 whether it is a good choice for a rough mountain area,
122 for a rough mountain area. 123 and whether the ride will be fun.
123 And it depends on its properties if the ride will be fun. 124
124 125 .PP
125 .PP 126 Requirements for a piece of software are twofold:
126 Requirements for software are twofold:
127 functional and non-functional. 127 functional and non-functional.
128 .IP \(bu 128 .IP \(bu
129 Functional requirements define directly the software's functions. 129 Functional requirements directly define the software's functions.
130 They are the reason why software gets written. 130 They are the reason why software gets written.
131 Someone has a problem and needs a tool to solve it. 131 Someone has a problem and needs a tool to solve it.
132 Being able to solve the problem is the main functional goal. 132 Being able to solve the problem is the main functional goal.
133 It is the driving force behind all programming effort. 133 This is the driving force behind all programming effort.
134 Functional requirements are easier to define and to verify. 134 Functional requirements are easier to define and to verify.
135 .IP \(bu 135 .IP \(bu
136 Non-functional requirements are called \fIquality\fP requirements, too. 136 Non-functional requirements are called \fIquality\fP requirements, too.
137 The quality of software are the properties that are not directly related to 137 The quality of software shows through the properties that are not directly
138 the software's basic functions. 138 related to the software's basic functions.
139 Tools of bad quality often do solve the problems they were written for, 139 Tools of bad quality often do solve the problems they were written for,
140 but introduce problems and difficulties for usage and development, later on. 140 but introduce problems and difficulties for usage and development later on.
141 Quality aspects are often overlooked at first sight, 141 Qualitative aspects are often overlooked at first sight,
142 and are often difficult to define clearly and to verify. 142 and are often difficult to define clearly and to verify.
143 .PP 143 .PP
144 Quality is hardly interesting when software gets built initially, 144 Quality is hardly interesting when software gets built initially,
145 but it has a high impact on usability and maintenance, later. 145 but it has a high impact on usability and maintenance of the software later.
146 A short-sighted might see in developing software, mainly building something up. 146 A short-sighted person might see the process of developing software as
147 But experience shows, that building software the first time is 147 one mainly concerned with building something up.
148 only a small amount of the overall work. 148 But, experience shows that building software the first time is
149 only a small portion of the overall work involved.
149 Bug fixing, extending, rebuilding of parts \(en maintenance work \(en 150 Bug fixing, extending, rebuilding of parts \(en maintenance work \(en
150 does soon take over the major part of the time spent on a software project. 151 soon take a large part of the time spent on a software project.
151 And of course, the time spent actually using the software. 152 And of course, the time spent actually using the software.
152 These processes are highly influenced by the software's quality. 153 These processes are highly influenced by the software's quality.
153 Thus, quality must not be neglected. 154 Thus, quality must not be neglected.
154 However, the problem with quality is that you hardly ``stumble over'' 155 However, the problem with quality is that you hardly ``stumble over''
155 bad quality during the first build, 156 bad quality during the first build,
156 although this is the time when you should care about good quality most. 157 although this is the time when you should care about good quality most.
157 .PP 158 .PP
158 Software design has little to do with the basic function of software \(en 159 Software design has little to do with the basic function of software \(en
159 this requirement will get satisfied anyway. 160 this requirement will get satisfied anyway.
160 Software design is more about quality aspects of software. 161 Software design is more about quality aspects.
161 Good design leads to good quality, bad design to bad quality. 162 Good design leads to good quality, bad design to bad quality.
162 The primary functions of software will be affected modestly by bad quality, 163 The primary functions of software will be affected modestly by bad quality,
163 but good quality can provide a lot of additional gain, 164 but good quality can provide a lot of additional benefits,
164 even at places where one never expected it. 165 even at places one never expected it.
165 .PP 166 .PP
166 The ISO/IEC\|9126-1 standard, part\|1, 167 The ISO/IEC\|9126-1 standard, part\|1,
167 .[ 168 .[
168 iso product quality 169 iso product quality
169 .] 170 .]
170 defines the quality model as consisting out of: 171 defines the quality model as consisting of:
171 .IP \(bu 172 .IP \(bu
172 .I Functionality 173 .I Functionality
173 (suitability, accuracy, inter\%operability, security) 174 (suitability, accuracy, inter\%operability, security)
174 .IP \(bu 175 .IP \(bu
175 .I Reliability 176 .I Reliability
185 (analyzability, changeability, stability, testability) 186 (analyzability, changeability, stability, testability)
186 .IP \(bu 187 .IP \(bu
187 .I Portability 188 .I Portability
188 (adaptability, installability, co-existence, replaceability) 189 (adaptability, installability, co-existence, replaceability)
189 .LP 190 .LP
190 Good design can improve these properties of software, 191 Good design can improve these properties in software;
191 bad designed software likely suffers in these points. 192 poorly designed software likely suffers in these areas.
192 .PP 193 .PP
193 One further goal of software design is consistency. 194 One further goal of software design is consistency.
194 Consistency eases understanding, working on, and using things. 195 Consistency eases understanding, using, and working on things.
195 Consistent internal structure and consistent interfaces to the outside 196 Consistent internal structure and consistent external interfaces
196 can be provided by good design. 197 can be provided by good design.
197 .PP 198 .PP
198 Software should be well designed because good design avoids many 199 Software should be well designed because good design avoids many
199 problems during a software project's lifetime. 200 problems during its lifetime.
200 And software should be well designed because good design can offer 201 Also, because good design can offer much additional gain.
201 much additional gain. 202 Indeed, much effort should be spent on good design to make software more valuable.
202 Indeed, much effort should be spent into good design to make software more valuable. 203 The Unix Philosophy provides a way to design software well.
203 The Unix Philosophy shows a way of how to design software well.
204 It offers guidelines to achieve good quality and high gain for the effort spent. 204 It offers guidelines to achieve good quality and high gain for the effort spent.
205 205
206 206
207 .H 1 "The Unix Philosophy 207 .H 1 "The Unix Philosophy
208 .LP 208 .LP