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