1.1 --- a/unix-phil.ms	Sat Apr 03 12:56:38 2010 +0200
     1.2 +++ b/unix-phil.ms	Thu Apr 08 16:47:11 2010 +0200
     1.3 @@ -28,9 +28,10 @@
     1.4  markus schnalke <meillo@marmaro.de>
     1.5  .AB
     1.6  .ti \n(.iu
     1.7 -This paper discusses the importance of the Unix Philosophy in software design.
     1.8 +This paper explains the importance of the Unix Philosophy for software design.
     1.9  Today, few software designers are aware of these concepts,
    1.10 -and thus most modern software is limited and does not make use of software leverage.
    1.11 +and thus a lot of modern software is more limited than necessary
    1.12 +and makes less use of software leverage than possible.
    1.13  Knowing and following the guidelines of the Unix Philosophy makes software more valuable.
    1.14  .AE
    1.15  
    1.16 @@ -38,11 +39,11 @@
    1.17  
    1.18  .FS
    1.19  .ps -1
    1.20 -This paper was prepared for the seminar ``Software Analysis'' at University Ulm.
    1.21 -Mentor was professor Schweiggert. 2010-02-05
    1.22 +This paper was prepared for the ``Software Analysis'' seminar at University Ulm.
    1.23 +Mentor was professor Schweiggert. 2010-04-05
    1.24  .br
    1.25 -You may get this document from my website
    1.26 -.CW \s-1http://marmaro.de/docs
    1.27 +You may retrieve this document from
    1.28 +.CW \s-1http://marmaro.de/docs \ .
    1.29  .FE
    1.30  
    1.31  .NH 1
    1.32 @@ -120,55 +121,71 @@
    1.33  .NH 1
    1.34  Importance of software design in general
    1.35  .LP
    1.36 -Why should we design software at all?
    1.37 +The design of a software describes its internal and external shape,
    1.38 +meaning structure and interfaces.
    1.39 +It has nothing to do with visual appearance.
    1.40 +If we take a program as a car, then its color is of no matter.
    1.41 +Its design would be the car's size, its shape, the locations of doors,
    1.42 +the passenger/space ratio, the luggage capacity, and so forth.
    1.43 +.PP
    1.44 +Why should software get designed at all?
    1.45  It is general knowledge, that even a bad plan is better than no plan.
    1.46 -Ignoring software design is programming without a plan.
    1.47 -This will lead pretty sure to horrible results.
    1.48 +Not designing software means programming without plan.
    1.49 +This will pretty sure lead to horrible results.
    1.50 +Horrible to use and horrible to maintain.
    1.51 +These two aspects are the visible ones.
    1.52 +Often invisible are the wasted possible gains.
    1.53 +Good software design can make these gains available.
    1.54  .PP
    1.55 -The design of a software is its internal and external shape.
    1.56 -The design talked about here has nothing to do with visual appearance.
    1.57 -If we see a program as a car, then its color is of no matter.
    1.58 -Its design would be the car's size, its shape, the number and position of doors,
    1.59 -the ratio of passenger and cargo transport, and so forth.
    1.60 +A software's design deals with quality properties.
    1.61 +Good design leads to good quality, and quality is important.
    1.62 +Any car may be able to drive from A to B,
    1.63 +but it depends on the car's properties whether it is a good choice
    1.64 +for passenger transport or not.
    1.65 +It depends on its  properties if it is a good choice
    1.66 +for a rough mountain area.
    1.67 +And it depends on its properties if the ride will be fun.
    1.68 +
    1.69  .PP
    1.70 -A software's design is about quality properties.
    1.71 -Each of the cars may be able to drive from A to B,
    1.72 -but it depends on its properties whether it is a good car for passenger transport or not.
    1.73 -It also depends on its properties if it is a good choice for a rough mountain area.
    1.74 +Requirements for a software are twofold:
    1.75 +functional and non-functional.
    1.76 +.IP \(bu
    1.77 +Functional requirements define directly the software's functions.
    1.78 +They are the reason why software gets written.
    1.79 +Someone has a problem and needs a tool to solve it.
    1.80 +Being able to solve the problem is the main functional goal.
    1.81 +It is the driving force behind all programming effort.
    1.82 +Functional requirements are easier to define and to verify.
    1.83 +.IP \(bu
    1.84 +Non-functional requirements are also called \fIquality\fP requirements.
    1.85 +The quality of a software are the properties that are not directly related to
    1.86 +the software's basic functions.
    1.87 +Tools of bad quality often solve the problems they were written for,
    1.88 +but introduce problems and difficulties for usage and development, later on.
    1.89 +Quality aspects are often overlooked at first sight,
    1.90 +and they are often difficult to define clearly and to verify.
    1.91  .PP
    1.92 -Requirements to a software are twofold: functional and non-functional.
    1.93 -Functional requirements are easier to define and to verify.
    1.94 -They are directly the software's functions.
    1.95 -Functional requirements are the reason why software gets written.
    1.96 -Someone has a problem and needs a tool to solve it.
    1.97 -Being able to solve the problem is the main functional requirement.
    1.98 -It is the driving force behind all programming effort.
    1.99 -.PP
   1.100 -On the other hand, there are also non-functional requirements.
   1.101 -They are called \fIquality\fP requirements, too.
   1.102 -The quality of a software is about properties that are not directly related to
   1.103 -the software's basic functions.
   1.104 -Quality aspects are about the properties that are overlooked at first sight.
   1.105 -.PP
   1.106 -Quality is of few matter when the software gets initially built,
   1.107 -but it will be of matter in usage and maintenance of the software.
   1.108 +Quality is of few matter when the software gets built initially,
   1.109 +but it is of matter for usage and maintenance of the software.
   1.110  A short-sighted might see in developing a software mainly building something up.
   1.111 -Reality shows, that building the software the first time is only a small amount
   1.112 -of the overall work.
   1.113 -Bug fixing, extending, rebuilding of parts \(en short: maintenance work \(en
   1.114 +But experience shows, that building the software the first time is
   1.115 +only a small amount of the overall work.
   1.116 +Bug fixing, extending, rebuilding of parts
   1.117 +\(en maintenance work, for short \(en
   1.118  does soon take over the major part of the time spent on a software.
   1.119  Not to forget the usage of the software.
   1.120  These processes are highly influenced by the software's quality.
   1.121 -Thus, quality should never be neglected.
   1.122 -The problem is that you hardly ``stumble over'' bad quality during the first build,
   1.123 +Thus, quality must not be neglected.
   1.124 +The problem with quality is that you hardly ``stumble over''
   1.125 +bad quality during the first build,
   1.126  but this is the time when you should care about good quality most.
   1.127  .PP
   1.128 -Software design is not about the basic function of a software;
   1.129 -this requirement will get satisfied anyway, as it is the main driving force behind the development.
   1.130 -Software design is about quality aspects of the software.
   1.131 -Good design will lead to good quality, bad design to bad quality.
   1.132 +Software design is less the basic function of a software \(en
   1.133 +this requirement will get satisfied anyway.
   1.134 +Software design is more about quality aspects of the software.
   1.135 +Good design leads to good quality, bad design to bad quality.
   1.136  The primary functions of the software will be affected modestly by bad quality,
   1.137 -but good quality can provide a lot of additional gain from the software,
   1.138 +but good quality can provide a lot of additional gain,
   1.139  even at places where one never expected it.
   1.140  .PP
   1.141  The ISO/IEC 9126-1 standard, part 1,
   1.142 @@ -198,19 +215,20 @@
   1.143  .I Portability
   1.144  (adaptability, installability, co-existence, replaceability)
   1.145  .LP
   1.146 -These goals are parts of a software's design.
   1.147 -Good design can give these properties to a software,
   1.148 -bad designed software will miss them.
   1.149 +Good design can improve these properties of a software,
   1.150 +bad designed software probably suffers from not having them.
   1.151  .PP
   1.152  One further goal of software design is consistency.
   1.153  Consistency eases understanding, working on, and using things.
   1.154 -Consistent internals and consistent interfaces to the outside can be provided by good design.
   1.155 +Consistent internal structure and consistent interfaces to the outside
   1.156 +can be provided by good design.
   1.157  .PP
   1.158 -We should design software because good design avoids many problems during a software's lifetime.
   1.159 -And we should design software because good design can offer much gain,
   1.160 -that can be unrelated to the software main intend.
   1.161 -Indeed, we should spend much effort into good design to make the software more valuable.
   1.162 -The Unix Philosophy shows how to design software well.
   1.163 +Software should be well designed because good design avoids many
   1.164 +problems during the software's lifetime.
   1.165 +And software should be well designed because good design can offer
   1.166 +much additional gain.
   1.167 +Indeed, much effort should be spent into good design to make software more valuable.
   1.168 +The Unix Philosophy shows a way of how to design software well.
   1.169  It offers guidelines to achieve good quality and high gain for the effort spent.
   1.170  
   1.171