Mercurial > docs > unix-phil
comparison unix-phil.ms @ 6:a6b837d822b7
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 |