docs/unix-phil
changeset 6:a6b837d822b7
rewrote ch02
author | meillo@marmaro.de |
---|---|
date | Thu, 18 Feb 2010 11:24:36 +0100 |
parents | 48f1f3465550 |
children | 606f0ffca834 |
files | unix-phil.ms |
diffstat | 1 files changed, 78 insertions(+), 41 deletions(-) [+] |
line diff
1.1 --- a/unix-phil.ms Sat Feb 13 11:37:50 2010 +0100 1.2 +++ b/unix-phil.ms Thu Feb 18 11:24:36 2010 +0100 1.3 @@ -21,7 +21,7 @@ 1.4 .ds .] ] 1.5 .\"---------------------------------------- 1.6 .TL 1.7 -Why the Unix Philosophy matters 1.8 +Why the Unix Philosophy still matters 1.9 .AU 1.10 markus schnalke <meillo@marmaro.de> 1.11 .AB 1.12 @@ -108,6 +108,7 @@ 1.13 This only underlines what the Unix Philosophy is: 1.14 A retrospective view on the main concepts of Unix software; 1.15 especially those that were sucessful and unique to Unix. 1.16 +.\" really? 1.17 .PP 1.18 Before we will have a look at concrete concepts, 1.19 we discuss why software design is important 1.20 @@ -115,53 +116,89 @@ 1.21 1.22 1.23 .NH 1 1.24 -Importance of software design 1.25 +Importance of software design in general 1.26 .LP 1.27 Why should we design software at all? 1.28 -It is general knowledge, that a bad plan is better than no plan. 1.29 -As stated earlier in this document, the process of building a software 1.30 -means going from an idea to a release. 1.31 -The development process tells how to get from the idea to the release. 1.32 -Software design is the shape of the built software. 1.33 -This means, that different designs of a software would be different target points to go to. 1.34 -Thus, the design of a software defines the global direction the development goes. 1.35 +It is general knowledge, that even a bad plan is better than no plan. 1.36 +Ignoring software design is programming without a plan. 1.37 +This will lead pretty sure to horrible results. 1.38 .PP 1.39 -It is not enough that the released software offers all requested functionality. 1.40 -It is a misbelief that only function matters. 1.41 -Building a software the first time is only a small part of the overall work. 1.42 -The larger part begins when the software is released for the first time 1.43 -\(en maintainance and extending work.. 1.44 -This part soon covers more time than the time which was needed to build the software the first time. 1.45 -.\" cf. brooks? 1.46 +The design of a software is its internal and external shape. 1.47 +The design talked about here has nothing to do with visual appearance. 1.48 +If we see a program as a car, then its color is of no matter. 1.49 +Its design would be the car's size, its shape, the number and position of doors, 1.50 +the ratio of passenger and cargo transport, and so forth. 1.51 .PP 1.52 -The extendability and maitainability of a software highly depends on its design. 1.53 -Good design eases these tasks much. 1.54 -Bad design, in contrast, requires much more effort for maintaining and 1.55 -extending the software. 1.56 -Developers should, for their own best, have maintainability and extendability in mind 1.57 -when they design the software. 1.58 +A software's design is about quality properties. 1.59 +Each of the cars may be able to drive from A to B, 1.60 +but it depends on its properties whether it is a good car for passenger transport or not. 1.61 +It also depends on its properties if it is a good choice for a rough mountain area. 1.62 .PP 1.63 -Users of the software, in contrast, do not care about maintainability and extendability, 1.64 -at least not directly. 1.65 -They care about usability and flexibility. 1.66 -They want the software to directly solve their problems. 1.67 -They want to be able to to use all its functions if they learned a few of them. 1.68 -They want to use the software for similar tasks. 1.69 -Software is successful if users enjoy using it. 1.70 -Good software design can offer great flexibility and usability. 1.71 +Requirements to a software are twofold: functional and non-functional. 1.72 +Functional requirements are easier to define and to verify. 1.73 +They are directly the software's functions. 1.74 +Functional requirements are the reason why software gets written. 1.75 +Someone has a problem and needs a tool to solve it. 1.76 +Being able to solve the problem is the main functional requirement. 1.77 +It is the driving force behind all programming effort. 1.78 .PP 1.79 -Good design matters for developers \fIand\fP for users. 1.80 -Hence both groups should care about good software design. 1.81 -Bad design limits the software in some way. 1.82 -It may still provide all requested function, but it will have worse quality, 1.83 -and thus require more work effort for developers or frustrate users. 1.84 +On the other hand, there are also non-functional requirements. 1.85 +They are called \fIquality\fP requirements, too. 1.86 +The quality of a software is about properties that are not directly related to 1.87 +the software's basic functions. 1.88 +Quality aspects are about the properties that are overlooked at first sight. 1.89 .PP 1.90 -Good software design is to the implementation like data structures are to algorithms 1.91 -\(en if you get the former right, then you do not need to care about the latter, 1.92 -it will simply go the right way. 1.93 -.\" cf. ??? ``good data, bad algos'' 1.94 - 1.95 - 1.96 +Quality is of few matter when the software gets initially built, 1.97 +but it will be of matter in usage and maintainance of the software. 1.98 +A short-sighted might see in developing a software mainly building something up. 1.99 +Reality shows, that building the software the first time is only a small amount 1.100 +of the overall work. 1.101 +Bug fixing, extending, rebuiling of parts \(en short: maintainance work \(en 1.102 +does soon take over the major part of the time spent on a software. 1.103 +Not to forget the usage of the software. 1.104 +These processes are highly influenced by the software's quality. 1.105 +Thus, quality should never be neglected. 1.106 +The problem is that you hardly ``stumble over'' bad quality during the first build, 1.107 +but this is the time when you should care about good quality most. 1.108 +.PP 1.109 +Software design is not about the basic function of a software; 1.110 +this requirement will get satisfied anyway, as it is the main driving force behind the development. 1.111 +Software design is about quality aspects of the software. 1.112 +Good design will lead to good quality, bad design to bad quality. 1.113 +The primary functions of the software will be affected modestly by bad quality, 1.114 +but good quality can provide a lot of additional gain from the software, 1.115 +even at places where one never expected it. 1.116 +.PP 1.117 +The ISO/IEC 9126-1 standard, part 1, 1.118 +.[ 1.119 +%I International Organization for Standarization 1.120 +%T ISO Standard 9126: Software Engineering \(en Product Quality, part 1 1.121 +%C Geneve 1.122 +%D 2001 1.123 +.] 1.124 +defines the quality model as consisting out of: 1.125 +.IP \(bu 1.126 +.I Functionality 1.127 +(suitability, accuracy, inter\%operability, security) 1.128 +.IP \(bu 1.129 +.I Reliability 1.130 +(maturity, fault tolerance, recoverability) 1.131 +.IP \(bu 1.132 +.I Usability 1.133 +(understandability, learnability, operability, attractiveness) 1.134 +.IP \(bu 1.135 +.I Efficiency 1.136 +(time behaviour, resource utilisation) 1.137 +.IP \(bu 1.138 +.I Maintainability 1.139 +(analysability, changeability, stability, testability) 1.140 +.IP \(bu 1.141 +.I Portability 1.142 +(adaptability, installability, co-existence, replaceability) 1.143 +.LP 1.144 +These goals are parts of a software's design. 1.145 +Good design can give these properties to a software, 1.146 +bad designed software will miss them. 1.147 1.148 1.149 .NH 1