Mercurial > docs > unix-phil
comparison unix-phil.ms @ 2:fbd7baf6a61f
added content about sw design; some formating
author | meillo@marmaro.de |
---|---|
date | Fri, 05 Feb 2010 16:40:51 +0100 |
parents | 9b555c009f19 |
children | aebbe3e76f5e |
comparison
equal
deleted
inserted
replaced
1:9b555c009f19 | 2:fbd7baf6a61f |
---|---|
1 .if n .pl 1000i | 1 .\".if n .pl 1000i |
2 .de XX | 2 .de XX |
3 .pl 1v | 3 .pl 1v |
4 .. | 4 .. |
5 .em XX | 5 .em XX |
6 .\".nr PI 0 | 6 .\".nr PI 0 |
22 .\"---------------------------------------- | 22 .\"---------------------------------------- |
23 .TL | 23 .TL |
24 Why the Unix Philosophy matters | 24 Why the Unix Philosophy matters |
25 .AU | 25 .AU |
26 markus schnalke <meillo@marmaro.de> | 26 markus schnalke <meillo@marmaro.de> |
27 .AI | |
28 .ce 0 | |
29 University Ulm | |
30 .AB | 27 .AB |
31 .ti \n(.iu | 28 .ti \n(.iu |
32 This term paper discusses the importance of the Unix Philosophy in software design. | 29 This paper discusses the importance of the Unix Philosophy in software design. |
33 Today, few software designers are aware of these concepts, | 30 Today, few software designers are aware of these concepts, |
34 and thus most modern software is limited and does not use software leverage. | 31 and thus most modern software is limited and does not use software leverage. |
35 Knowing and following the tenets of the Unix Philosophy makes software more valuable. | 32 Knowing and following the tenets of the Unix Philosophy makes software more valuable. |
36 .AE | 33 .AE |
37 | 34 |
38 .2C | 35 .if t .2C |
36 | |
37 .FS | |
38 .ps -1 | |
39 This paper was prepared for the seminar ``Software Analysis'' at University Ulm. | |
40 Mentor was professor Schweiggert. 2010-02-05 | |
41 .br | |
42 You may get this document from my website | |
43 .CW \s-1http://marmaro.de/docs | |
44 .FE | |
45 | |
39 .NH 1 | 46 .NH 1 |
40 Introduction | 47 Introduction |
41 .LP | 48 .LP |
42 Building a software is a process from an idea of the purpose of the software | 49 Building a software is a process from an idea of the purpose of the software |
43 to the finished program. | 50 to the finished program. |
89 .[ | 96 .[ |
90 %A Eric S. Raymond | 97 %A Eric S. Raymond |
91 %T The Art of UNIX Programming | 98 %T The Art of UNIX Programming |
92 %D 2003 | 99 %D 2003 |
93 %I Addison-Wesley | 100 %I Addison-Wesley |
94 %O .CW \s-2http://www.faqs.org/docs/artu/ | 101 %O .CW \s-1http://www.faqs.org/docs/artu/ |
95 .] | 102 .] |
96 .LP | 103 .LP |
97 These different views on the Unix Philosophy have much in common. | 104 These different views on the Unix Philosophy have much in common. |
98 Especially, the main concepts are seen by all of them. | 105 Especially, the main concepts are seen by all of them. |
99 But there are also points on which they differ. | 106 But there are also points on which they differ. |
107 | 114 |
108 | 115 |
109 .NH 1 | 116 .NH 1 |
110 Importance of software design | 117 Importance of software design |
111 .LP | 118 .LP |
112 why design at all | 119 Why should we design software at all? |
113 | 120 It should be general knowledge, that a bad plan is better than no plan. |
114 - for dev mainly: extendability and maintainability | 121 As stated earlier in this document, the process of building a software |
115 | 122 means going from an idea to a release. |
116 - for users: usability and flexibility (but you need to learn how to use it) | 123 The development process tells how to get from the idea to the release. |
117 | 124 Software design tells how the built software should look like. |
118 no design and bad design limit the use of software | 125 .PP |
126 It is not enough that the released software offers all requested functionality. | |
127 It is a misbelief that only function matters. | |
128 Building a software the first time is only a small part of the overall work. | |
129 The larger part begins when the software is released for the first time | |
130 \(en maintainance and extending work.. | |
131 This part soon covers more time than the time which was needed to build the software the first time. | |
132 .\" cf. brooks? | |
133 .PP | |
134 The extendability and maitainability of a software highly depends on its design. | |
135 Good design eases these tasks much. | |
136 Bad design, in contrast, requires much more effort for maintaining and | |
137 extending the software. | |
138 Developers should, for their own best, have maintainability and extendability in mind | |
139 when they design the software. | |
140 .PP | |
141 Users of the software do not care about maintainability and extendability, | |
142 at least not directly. | |
143 They care about usability and flexibility. | |
144 They want the software to directly solve their problems. | |
145 They want to be able to to use all its functions if they learned a few of them. | |
146 They want to use the software for similar tasks. | |
147 Software is successful if users enjoy using it. | |
148 Good software design can offer great flexibility and usability. | |
149 .PP | |
150 Good design matters for developers \fIand\fP for users. | |
151 Hence both groups should care about good software design. | |
152 Bad design limits the software in some way. | |
153 It may still provide all requested function, but it will have worse quality, | |
154 and thus require more work effort for developers or frustrate users. | |
155 .PP | |
156 Good software design is to the implementation like data structures are to algorithms | |
157 \(en if you get the former right, then you do not need to care about the latter, | |
158 it will simply go the right way. | |
159 .\" cf. ??? ``good data, bad algos'' | |
160 | |
161 | |
162 | |
163 | |
164 .NH 1 | |
165 The Unix Philosophy | |
166 | |
167 .NH 2 | |
168 what it is | |
169 .LP | |
170 definitions by McIlroy, Gancarz, ESR (maybe already in the intro) | |
171 .LP | |
172 cf. unix tool chain | |
173 .LP | |
174 enabler pipe | |
119 | 175 |
120 .NH 2 | 176 .NH 2 |
121 Architecture | 177 Architecture |
122 .LP | 178 .LP |
123 the most important design decision. | 179 the most important design decision. |
124 | 180 |
125 the topic here | 181 the topic here |
126 | |
127 .NH 1 | |
128 The Unix Philosophy | |
129 | |
130 .NH 2 | |
131 what it is | |
132 .LP | |
133 definitions by McIlroy, Gancarz, ESR (maybe already in the intro) | |
134 .LP | |
135 cf. unix tool chain | |
136 .LP | |
137 enabler pipe | |
138 | 182 |
139 .NH 2 | 183 .NH 2 |
140 Interface architecture | 184 Interface architecture |
141 .LP | 185 .LP |
142 standalone vs. tool chain | 186 standalone vs. tool chain |