1.1 --- a/unix-phil.ms	Thu Apr 15 23:04:07 2010 +0200
     1.2 +++ b/unix-phil.ms	Fri Apr 16 11:48:38 2010 +0200
     1.3 @@ -27,10 +27,10 @@
     1.4  .LP
     1.5  The Unix Philosophy is the essence of how the Unix operating system,
     1.6  especially its toolchest, was designed.
     1.7 -It is no limited set of fixed rules,
     1.8 +It is not a limited set of fixed rules,
     1.9  but a loose set of guidelines which tell how to write software that
    1.10 -suites well into Unix.
    1.11 -Actually, the Unix Philosophy describes what is common to typical Unix software.
    1.12 +suites Unix well.
    1.13 +Actually, the Unix Philosophy describes what is common in typical Unix software.
    1.14  The Wikipedia has an accurate definition:
    1.15  .[
    1.16  wikipedia
    1.17 @@ -66,16 +66,16 @@
    1.18  These different views on the Unix Philosophy have much in common.
    1.19  Especially, the main concepts are similar in all of them.
    1.20  McIlroy's definition can surely be called the core of the Unix Philosophy,
    1.21 -but the fundamental idea behind it all, is ``small is beautiful''.
    1.22 +but the fundamental idea behind it all is ``small is beautiful''.
    1.23  
    1.24  .PP
    1.25  The Unix Philosophy explains how to design good software for Unix.
    1.26 -Many concepts described here, base on facilities of Unix.
    1.27 +Many concepts described here are based on Unix facilities.
    1.28  Other operating systems may not offer such facilities,
    1.29 -hence it may not be possible to design software in the way of the
    1.30 -Unix Philosophy for them.
    1.31 +hence it may not be possible to design software for such systems
    1.32 +according to the Unix Philosophy.
    1.33  .PP
    1.34 -The Unix Philosophy has an idea of how the process of software development
    1.35 +The Unix Philosophy has an idea of what the process of software development
    1.36  should look like, but large parts of the philosophy are quite independent
    1.37  from a concrete development process.
    1.38  However, one will soon recognize that some development processes work well
    1.39 @@ -84,70 +84,71 @@
    1.40  Kent Beck's books about Extreme Programming are valuable supplemental
    1.41  resources on this topic.
    1.42  .PP
    1.43 -The question of how to actually write code and how the code should looks
    1.44 -like in detail, are out of focus here.
    1.45 -``The Practice of Programming'' by Kernighan and Pike,
    1.46 +The question of how to actually write code and how the code should look
    1.47 +in detail, are beyond the scope of this paper.
    1.48 +Kernighan and Pike's book ``The Practice of Programming''
    1.49  .[
    1.50  kernighan pike
    1.51  practice of programming
    1.52  .]
    1.53 -is a good book that covers this topic.
    1.54 -Its point of view matches to the one of this paper.
    1.55 +covers this topic.
    1.56 +Its point of view corresponds to the one espoused in this paper.
    1.57  
    1.58  .H 1 "Importance of software design in general
    1.59  .LP
    1.60 -Software design is the planning of how the internal structure
    1.61 -and external interfaces of software should look like.
    1.62 +Software design consists of planning how the internal structure
    1.63 +and external interfaces of software should look.
    1.64  It has nothing to do with visual appearance.
    1.65 -If we take a program as a car, then its color is of no matter.
    1.66 +If we were to compare a program to a car, then its color would not matter.
    1.67  Its design would be the car's size, its shape, the locations of doors,
    1.68  the passenger/space ratio, the available controls and instruments,
    1.69  and so forth.
    1.70  .PP
    1.71 -Why should software get designed at all?
    1.72 -It is general knowledge, that even a bad plan is better than no plan.
    1.73 -Not designing software means programming without plan.
    1.74 -This will pretty sure lead to horrible results.
    1.75 -Software that is horrible to use and horrible to maintain.
    1.76 +Why should software be designed at all?
    1.77 +It is accepted as general knowledge,
    1.78 +that even a bad plan is better than no plan.
    1.79 +Not designing software means programming without a plan.
    1.80 +This will surely lead to horrible results,
    1.81 +being horrible to use and horrible to maintain.
    1.82  These two aspects are the visible ones.
    1.83  Often invisible though, are the wasted possible gains.
    1.84  Good software design can make these gains available.
    1.85  .PP
    1.86 -Software design deals with quality properties.
    1.87 +A software's design deals with qualitative properties.
    1.88  Good design leads to good quality, and quality is important.
    1.89 -Any car may be able to drive from A to B,
    1.90 -but it depends on the car's properties whether it is a good choice
    1.91 -for passenger transport or not.
    1.92 -It depends on its  properties if it is a good choice
    1.93 -for a rough mountain area.
    1.94 -And it depends on its properties if the ride will be fun.
    1.95 +Any car may be able to drive from point A to point B,
    1.96 +but it depends on the qualitative decisions made in the design of the vehicle,
    1.97 +whether it is a good choice for passenger transport or not,
    1.98 +whether it is a good choice for a rough mountain area,
    1.99 +and whether the ride will be fun.
   1.100  
   1.101  .PP
   1.102 -Requirements for software are twofold:
   1.103 +Requirements for a piece of software are twofold:
   1.104  functional and non-functional.
   1.105  .IP \(bu
   1.106 -Functional requirements define directly the software's functions.
   1.107 +Functional requirements directly define the software's functions.
   1.108  They are the reason why software gets written.
   1.109  Someone has a problem and needs a tool to solve it.
   1.110  Being able to solve the problem is the main functional goal.
   1.111 -It is the driving force behind all programming effort.
   1.112 +This is the driving force behind all programming effort.
   1.113  Functional requirements are easier to define and to verify.
   1.114  .IP \(bu
   1.115  Non-functional requirements are called \fIquality\fP requirements, too.
   1.116 -The quality of software are the properties that are not directly related to
   1.117 -the software's basic functions.
   1.118 +The quality of software shows through the properties that are not directly
   1.119 +related to the software's basic functions.
   1.120  Tools of bad quality often do solve the problems they were written for,
   1.121 -but introduce problems and difficulties for usage and development, later on.
   1.122 -Quality aspects are often overlooked at first sight,
   1.123 +but introduce problems and difficulties for usage and development later on.
   1.124 +Qualitative aspects are often overlooked at first sight,
   1.125  and are often difficult to define clearly and to verify.
   1.126  .PP
   1.127  Quality is hardly interesting when software gets built initially,
   1.128 -but it has a high impact on usability and maintenance, later.
   1.129 -A short-sighted might see in developing software, mainly building something up.
   1.130 -But experience shows, that building software the first time is
   1.131 -only a small amount of the overall work.
   1.132 +but it has a high impact on usability and maintenance of the software later.
   1.133 +A short-sighted person might see the process of developing software as
   1.134 +one mainly concerned with building something up.
   1.135 +But, experience shows that building software the first time is
   1.136 +only a small portion of the overall work involved.
   1.137  Bug fixing, extending, rebuilding of parts \(en maintenance work \(en
   1.138 -does soon take over the major part of the time spent on a software project.
   1.139 +soon take a large part of the time spent on a software project.
   1.140  And of course, the time spent actually using the software.
   1.141  These processes are highly influenced by the software's quality.
   1.142  Thus, quality must not be neglected.
   1.143 @@ -157,17 +158,17 @@
   1.144  .PP
   1.145  Software design has little to do with the basic function of software \(en
   1.146  this requirement will get satisfied anyway.
   1.147 -Software design is more about quality aspects of software.
   1.148 +Software design is more about quality aspects.
   1.149  Good design leads to good quality, bad design to bad quality.
   1.150  The primary functions of software will be affected modestly by bad quality,
   1.151 -but good quality can provide a lot of additional gain,
   1.152 -even at places where one never expected it.
   1.153 +but good quality can provide a lot of additional benefits,
   1.154 +even at places one never expected it.
   1.155  .PP
   1.156  The ISO/IEC\|9126-1 standard, part\|1,
   1.157  .[
   1.158  iso product quality
   1.159  .]
   1.160 -defines the quality model as consisting out of:
   1.161 +defines the quality model as consisting of:
   1.162  .IP \(bu
   1.163  .I Functionality
   1.164  (suitability, accuracy, inter\%operability, security)
   1.165 @@ -187,20 +188,19 @@
   1.166  .I Portability
   1.167  (adaptability, installability, co-existence, replaceability)
   1.168  .LP
   1.169 -Good design can improve these properties of software,
   1.170 -bad designed software likely suffers in these points.
   1.171 +Good design can improve these properties in software;
   1.172 +poorly designed software likely suffers in these areas.
   1.173  .PP
   1.174  One further goal of software design is consistency.
   1.175 -Consistency eases understanding, working on, and using things.
   1.176 -Consistent internal structure and consistent interfaces to the outside
   1.177 +Consistency eases understanding, using, and working on things.
   1.178 +Consistent internal structure and consistent external interfaces
   1.179  can be provided by good design.
   1.180  .PP
   1.181  Software should be well designed because good design avoids many
   1.182 -problems during a software project's lifetime.
   1.183 -And software should be well designed because good design can offer
   1.184 -much additional gain.
   1.185 -Indeed, much effort should be spent into good design to make software more valuable.
   1.186 -The Unix Philosophy shows a way of how to design software well.
   1.187 +problems during its lifetime.
   1.188 +Also, because good design can offer much additional gain.
   1.189 +Indeed, much effort should be spent on good design to make software more valuable.
   1.190 +The Unix Philosophy provides a way to design software well.
   1.191  It offers guidelines to achieve good quality and high gain for the effort spent.
   1.192  
   1.193