Mercurial > docs > unix-phil

comparison unix-phil.ms @ 6:a6b837d822b7

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
rewrote ch02
author meillo@marmaro.de
date Thu, 18 Feb 2010 11:24:36 +0100
parents 48f1f3465550
children 606f0ffca834
comparison
equal deleted inserted replaced
5:48f1f3465550 6:a6b837d822b7
19 .. 19 ..
20 .ds [. \ [ 20 .ds [. \ [
21 .ds .] ] 21 .ds .] ]
22 .\"---------------------------------------- 22 .\"----------------------------------------
23 .TL 23 .TL
24 Why the Unix Philosophy matters 24 Why the Unix Philosophy still matters
25 .AU 25 .AU
26 markus schnalke <meillo@marmaro.de> 26 markus schnalke <meillo@marmaro.de>
27 .AB 27 .AB
28 .ti \n(.iu 28 .ti \n(.iu
29 This paper discusses the importance of the Unix Philosophy in software design. 29 This paper discusses the importance of the Unix Philosophy in software design.
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 sucessful and unique to Unix.
111 .\" really?
111 .PP 112 .PP
112 Before we will have a look at concrete concepts, 113 Before we will have a look at concrete concepts,
113 we discuss why software design is important 114 we discuss why software design is important
114 and what problems bad design introduces. 115 and what problems bad design introduces.
115 116
116 117
117 .NH 1 118 .NH 1
118 Importance of software design 119 Importance of software design in general
119 .LP 120 .LP
120 Why should we design software at all? 121 Why should we design software at all?
121 It is general knowledge, that a bad plan is better than no plan. 122 It is general knowledge, that even a bad plan is better than no plan.
122 As stated earlier in this document, the process of building a software 123 Ignoring software design is programming without a plan.
123 means going from an idea to a release. 124 This will lead pretty sure to horrible results.
124 The development process tells how to get from the idea to the release. 125 .PP
125 Software design is the shape of the built software. 126 The design of a software is its internal and external shape.
126 This means, that different designs of a software would be different target points to go to. 127 The design talked about here has nothing to do with visual appearance.
127 Thus, the design of a software defines the global direction the development goes. 128 If we see a program as a car, then its color is of no matter.
128 .PP 129 Its design would be the car's size, its shape, the number and position of doors,
129 It is not enough that the released software offers all requested functionality. 130 the ratio of passenger and cargo transport, and so forth.
130 It is a misbelief that only function matters. 131 .PP
131 Building a software the first time is only a small part of the overall work. 132 A software's design is about quality properties.
132 The larger part begins when the software is released for the first time 133 Each of the cars may be able to drive from A to B,
133 \(en maintainance and extending work.. 134 but it depends on its properties whether it is a good car for passenger transport or not.
134 This part soon covers more time than the time which was needed to build the software the first time. 135 It also depends on its properties if it is a good choice for a rough mountain area.
135 .\" cf. brooks? 136 .PP
136 .PP 137 Requirements to a software are twofold: functional and non-functional.
137 The extendability and maitainability of a software highly depends on its design. 138 Functional requirements are easier to define and to verify.
138 Good design eases these tasks much. 139 They are directly the software's functions.
139 Bad design, in contrast, requires much more effort for maintaining and 140 Functional requirements are the reason why software gets written.
140 extending the software. 141 Someone has a problem and needs a tool to solve it.
141 Developers should, for their own best, have maintainability and extendability in mind 142 Being able to solve the problem is the main functional requirement.
142 when they design the software. 143 It is the driving force behind all programming effort.
143 .PP 144 .PP
144 Users of the software, in contrast, do not care about maintainability and extendability, 145 On the other hand, there are also non-functional requirements.
145 at least not directly. 146 They are called \fIquality\fP requirements, too.
146 They care about usability and flexibility. 147 The quality of a software is about properties that are not directly related to
147 They want the software to directly solve their problems. 148 the software's basic functions.
148 They want to be able to to use all its functions if they learned a few of them. 149 Quality aspects are about the properties that are overlooked at first sight.
149 They want to use the software for similar tasks. 150 .PP
150 Software is successful if users enjoy using it. 151 Quality is of few matter when the software gets initially built,
151 Good software design can offer great flexibility and usability. 152 but it will be of matter in usage and maintainance of the software.
152 .PP 153 A short-sighted might see in developing a software mainly building something up.
153 Good design matters for developers \fIand\fP for users. 154 Reality shows, that building the software the first time is only a small amount
154 Hence both groups should care about good software design. 155 of the overall work.
155 Bad design limits the software in some way. 156 Bug fixing, extending, rebuiling of parts \(en short: maintainance work \(en
156 It may still provide all requested function, but it will have worse quality, 157 does soon take over the major part of the time spent on a software.
157 and thus require more work effort for developers or frustrate users. 158 Not to forget the usage of the software.
158 .PP 159 These processes are highly influenced by the software's quality.
159 Good software design is to the implementation like data structures are to algorithms 160 Thus, quality should never be neglected.
160 \(en if you get the former right, then you do not need to care about the latter, 161 The problem is that you hardly ``stumble over'' bad quality during the first build,
161 it will simply go the right way. 162 but this is the time when you should care about good quality most.
162 .\" cf. ??? ``good data, bad algos'' 163 .PP
163 164 Software design is not about the basic function of a software;
164 165 this requirement will get satisfied anyway, as it is the main driving force behind the development.
166 Software design is about quality aspects of the software.
167 Good design will lead to good quality, bad design to bad quality.
168 The primary functions of the software will be affected modestly by bad quality,
169 but good quality can provide a lot of additional gain from the software,
170 even at places where one never expected it.
171 .PP
172 The ISO/IEC 9126-1 standard, part 1,
173 .[
174 %I International Organization for Standarization
175 %T ISO Standard 9126: Software Engineering \(en Product Quality, part 1
176 %C Geneve
177 %D 2001
178 .]
179 defines the quality model as consisting out of:
180 .IP \(bu
181 .I Functionality
182 (suitability, accuracy, inter\%operability, security)
183 .IP \(bu
184 .I Reliability
185 (maturity, fault tolerance, recoverability)
186 .IP \(bu
187 .I Usability
188 (understandability, learnability, operability, attractiveness)
189 .IP \(bu
190 .I Efficiency
191 (time behaviour, resource utilisation)
192 .IP \(bu
193 .I Maintainability
194 (analysability, changeability, stability, testability)
195 .IP \(bu
196 .I Portability
197 (adaptability, installability, co-existence, replaceability)
198 .LP
199 These goals are parts of a software's design.
200 Good design can give these properties to a software,
201 bad designed software will miss them.
165 202
166 203
167 .NH 1 204 .NH 1
168 The Unix Philosophy 205 The Unix Philosophy
169 .LP 206 .LP