Mercurial > docs > unix-phil
comparison unix-phil.ms @ 57:840cbc667009
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 |