Mercurial > docs > unix-phil

comparison unix-phil.ms @ 39:c87143793d82

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
a lot of rework in ch02
author meillo@marmaro.de
date Thu, 08 Apr 2010 16:47:11 +0200
parents 3628e9649046
children 422679bdf384
comparison
equal deleted inserted replaced
38:3628e9649046 39:c87143793d82
26 Why the Unix Philosophy still matters 26 Why the Unix Philosophy still matters
27 .AU 27 .AU
28 markus schnalke <meillo@marmaro.de> 28 markus schnalke <meillo@marmaro.de>
29 .AB 29 .AB
30 .ti \n(.iu 30 .ti \n(.iu
31 This paper discusses the importance of the Unix Philosophy in software design. 31 This paper explains the importance of the Unix Philosophy for software design.
32 Today, few software designers are aware of these concepts, 32 Today, few software designers are aware of these concepts,
33 and thus most modern software is limited and does not make use of software leverage. 33 and thus a lot of modern software is more limited than necessary
34 and makes less use of software leverage than possible.
34 Knowing and following the guidelines of the Unix Philosophy makes software more valuable. 35 Knowing and following the guidelines of the Unix Philosophy makes software more valuable.
35 .AE 36 .AE
36 37
37 .\".if t .2C 38 .\".if t .2C
38 39
39 .FS 40 .FS
40 .ps -1 41 .ps -1
41 This paper was prepared for the seminar ``Software Analysis'' at University Ulm. 42 This paper was prepared for the ``Software Analysis'' seminar at University Ulm.
42 Mentor was professor Schweiggert. 2010-02-05 43 Mentor was professor Schweiggert. 2010-04-05
43 .br 44 .br
44 You may get this document from my website 45 You may retrieve this document from
45 .CW \s-1http://marmaro.de/docs 46 .CW \s-1http://marmaro.de/docs \ .
46 .FE 47 .FE
47 48
48 .NH 1 49 .NH 1
49 Introduction 50 Introduction
50 .LP 51 .LP
118 119
119 120
120 .NH 1 121 .NH 1
121 Importance of software design in general 122 Importance of software design in general
122 .LP 123 .LP
123 Why should we design software at all? 124 The design of a software describes its internal and external shape,
125 meaning structure and interfaces.
126 It has nothing to do with visual appearance.
127 If we take a program as a car, then its color is of no matter.
128 Its design would be the car's size, its shape, the locations of doors,
129 the passenger/space ratio, the luggage capacity, and so forth.
130 .PP
131 Why should software get designed at all?
124 It is general knowledge, that even a bad plan is better than no plan. 132 It is general knowledge, that even a bad plan is better than no plan.
125 Ignoring software design is programming without a plan. 133 Not designing software means programming without plan.
126 This will lead pretty sure to horrible results. 134 This will pretty sure lead to horrible results.
127 .PP 135 Horrible to use and horrible to maintain.
128 The design of a software is its internal and external shape. 136 These two aspects are the visible ones.
129 The design talked about here has nothing to do with visual appearance. 137 Often invisible are the wasted possible gains.
130 If we see a program as a car, then its color is of no matter. 138 Good software design can make these gains available.
131 Its design would be the car's size, its shape, the number and position of doors, 139 .PP
132 the ratio of passenger and cargo transport, and so forth. 140 A software's design deals with quality properties.
133 .PP 141 Good design leads to good quality, and quality is important.
134 A software's design is about quality properties. 142 Any car may be able to drive from A to B,
135 Each of the cars may be able to drive from A to B, 143 but it depends on the car's properties whether it is a good choice
136 but it depends on its properties whether it is a good car for passenger transport or not. 144 for passenger transport or not.
137 It also depends on its properties if it is a good choice for a rough mountain area. 145 It depends on its properties if it is a good choice
138 .PP 146 for a rough mountain area.
139 Requirements to a software are twofold: functional and non-functional. 147 And it depends on its properties if the ride will be fun.
148
149 .PP
150 Requirements for a software are twofold:
151 functional and non-functional.
152 .IP \(bu
153 Functional requirements define directly the software's functions.
154 They are the reason why software gets written.
155 Someone has a problem and needs a tool to solve it.
156 Being able to solve the problem is the main functional goal.
157 It is the driving force behind all programming effort.
140 Functional requirements are easier to define and to verify. 158 Functional requirements are easier to define and to verify.
141 They are directly the software's functions. 159 .IP \(bu
142 Functional requirements are the reason why software gets written. 160 Non-functional requirements are also called \fIquality\fP requirements.
143 Someone has a problem and needs a tool to solve it. 161 The quality of a software are the properties that are not directly related to
144 Being able to solve the problem is the main functional requirement.
145 It is the driving force behind all programming effort.
146 .PP
147 On the other hand, there are also non-functional requirements.
148 They are called \fIquality\fP requirements, too.
149 The quality of a software is about properties that are not directly related to
150 the software's basic functions. 162 the software's basic functions.
151 Quality aspects are about the properties that are overlooked at first sight. 163 Tools of bad quality often solve the problems they were written for,
152 .PP 164 but introduce problems and difficulties for usage and development, later on.
153 Quality is of few matter when the software gets initially built, 165 Quality aspects are often overlooked at first sight,
154 but it will be of matter in usage and maintenance of the software. 166 and they are often difficult to define clearly and to verify.
167 .PP
168 Quality is of few matter when the software gets built initially,
169 but it is of matter for usage and maintenance of the software.
155 A short-sighted might see in developing a software mainly building something up. 170 A short-sighted might see in developing a software mainly building something up.
156 Reality shows, that building the software the first time is only a small amount 171 But experience shows, that building the software the first time is
157 of the overall work. 172 only a small amount of the overall work.
158 Bug fixing, extending, rebuilding of parts \(en short: maintenance work \(en 173 Bug fixing, extending, rebuilding of parts
174 \(en maintenance work, for short \(en
159 does soon take over the major part of the time spent on a software. 175 does soon take over the major part of the time spent on a software.
160 Not to forget the usage of the software. 176 Not to forget the usage of the software.
161 These processes are highly influenced by the software's quality. 177 These processes are highly influenced by the software's quality.
162 Thus, quality should never be neglected. 178 Thus, quality must not be neglected.
163 The problem is that you hardly ``stumble over'' bad quality during the first build, 179 The problem with quality is that you hardly ``stumble over''
180 bad quality during the first build,
164 but this is the time when you should care about good quality most. 181 but this is the time when you should care about good quality most.
165 .PP 182 .PP
166 Software design is not about the basic function of a software; 183 Software design is less the basic function of a software \(en
167 this requirement will get satisfied anyway, as it is the main driving force behind the development. 184 this requirement will get satisfied anyway.
168 Software design is about quality aspects of the software. 185 Software design is more about quality aspects of the software.
169 Good design will lead to good quality, bad design to bad quality. 186 Good design leads to good quality, bad design to bad quality.
170 The primary functions of the software will be affected modestly by bad quality, 187 The primary functions of the software will be affected modestly by bad quality,
171 but good quality can provide a lot of additional gain from the software, 188 but good quality can provide a lot of additional gain,
172 even at places where one never expected it. 189 even at places where one never expected it.
173 .PP 190 .PP
174 The ISO/IEC 9126-1 standard, part 1, 191 The ISO/IEC 9126-1 standard, part 1,
175 .[ 192 .[
176 %I International Organization for Standardization 193 %I International Organization for Standardization
196 (analyzability, changeability, stability, testability) 213 (analyzability, changeability, stability, testability)
197 .IP \(bu 214 .IP \(bu
198 .I Portability 215 .I Portability
199 (adaptability, installability, co-existence, replaceability) 216 (adaptability, installability, co-existence, replaceability)
200 .LP 217 .LP
201 These goals are parts of a software's design. 218 Good design can improve these properties of a software,
202 Good design can give these properties to a software, 219 bad designed software probably suffers from not having them.
203 bad designed software will miss them.
204 .PP 220 .PP
205 One further goal of software design is consistency. 221 One further goal of software design is consistency.
206 Consistency eases understanding, working on, and using things. 222 Consistency eases understanding, working on, and using things.
207 Consistent internals and consistent interfaces to the outside can be provided by good design. 223 Consistent internal structure and consistent interfaces to the outside
208 .PP 224 can be provided by good design.
209 We should design software because good design avoids many problems during a software's lifetime. 225 .PP
210 And we should design software because good design can offer much gain, 226 Software should be well designed because good design avoids many
211 that can be unrelated to the software main intend. 227 problems during the software's lifetime.
212 Indeed, we should spend much effort into good design to make the software more valuable. 228 And software should be well designed because good design can offer
213 The Unix Philosophy shows how to design software well. 229 much additional gain.
230 Indeed, much effort should be spent into good design to make software more valuable.
231 The Unix Philosophy shows a way of how to design software well.
214 It offers guidelines to achieve good quality and high gain for the effort spent. 232 It offers guidelines to achieve good quality and high gain for the effort spent.
215 233
216 234
217 .NH 1 235 .NH 1
218 The Unix Philosophy 236 The Unix Philosophy