# HG changeset patch # User meillo@marmaro.de # Date 1266488676 -3600 # Node ID a6b837d822b717b9d411c0cfd59944b7cb2dd526 # Parent 48f1f3465550c96ab1298721df92097ed1842974 rewrote ch02 diff -r 48f1f3465550 -r a6b837d822b7 unix-phil.ms --- a/unix-phil.ms Sat Feb 13 11:37:50 2010 +0100 +++ b/unix-phil.ms Thu Feb 18 11:24:36 2010 +0100 @@ -21,7 +21,7 @@ .ds .] ] .\"---------------------------------------- .TL -Why the Unix Philosophy matters +Why the Unix Philosophy still matters .AU markus schnalke .AB @@ -108,6 +108,7 @@ This only underlines what the Unix Philosophy is: A retrospective view on the main concepts of Unix software; especially those that were sucessful and unique to Unix. +.\" really? .PP Before we will have a look at concrete concepts, we discuss why software design is important @@ -115,53 +116,89 @@ .NH 1 -Importance of software design +Importance of software design in general .LP Why should we design software at all? -It is general knowledge, that a bad plan is better than no plan. -As stated earlier in this document, the process of building a software -means going from an idea to a release. -The development process tells how to get from the idea to the release. -Software design is the shape of the built software. -This means, that different designs of a software would be different target points to go to. -Thus, the design of a software defines the global direction the development goes. +It is general knowledge, that even a bad plan is better than no plan. +Ignoring software design is programming without a plan. +This will lead pretty sure to horrible results. .PP -It is not enough that the released software offers all requested functionality. -It is a misbelief that only function matters. -Building a software the first time is only a small part of the overall work. -The larger part begins when the software is released for the first time -\(en maintainance and extending work.. -This part soon covers more time than the time which was needed to build the software the first time. -.\" cf. brooks? +The design of a software is its internal and external shape. +The design talked about here has nothing to do with visual appearance. +If we see a program as a car, then its color is of no matter. +Its design would be the car's size, its shape, the number and position of doors, +the ratio of passenger and cargo transport, and so forth. .PP -The extendability and maitainability of a software highly depends on its design. -Good design eases these tasks much. -Bad design, in contrast, requires much more effort for maintaining and -extending the software. -Developers should, for their own best, have maintainability and extendability in mind -when they design the software. +A software's design is about quality properties. +Each of the cars may be able to drive from A to B, +but it depends on its properties whether it is a good car for passenger transport or not. +It also depends on its properties if it is a good choice for a rough mountain area. .PP -Users of the software, in contrast, do not care about maintainability and extendability, -at least not directly. -They care about usability and flexibility. -They want the software to directly solve their problems. -They want to be able to to use all its functions if they learned a few of them. -They want to use the software for similar tasks. -Software is successful if users enjoy using it. -Good software design can offer great flexibility and usability. +Requirements to a software are twofold: functional and non-functional. +Functional requirements are easier to define and to verify. +They are directly the software's functions. +Functional requirements are the reason why software gets written. +Someone has a problem and needs a tool to solve it. +Being able to solve the problem is the main functional requirement. +It is the driving force behind all programming effort. .PP -Good design matters for developers \fIand\fP for users. -Hence both groups should care about good software design. -Bad design limits the software in some way. -It may still provide all requested function, but it will have worse quality, -and thus require more work effort for developers or frustrate users. +On the other hand, there are also non-functional requirements. +They are called \fIquality\fP requirements, too. +The quality of a software is about properties that are not directly related to +the software's basic functions. +Quality aspects are about the properties that are overlooked at first sight. .PP -Good software design is to the implementation like data structures are to algorithms -\(en if you get the former right, then you do not need to care about the latter, -it will simply go the right way. -.\" cf. ??? ``good data, bad algos'' - - +Quality is of few matter when the software gets initially built, +but it will be of matter in usage and maintainance of the software. +A short-sighted might see in developing a software mainly building something up. +Reality shows, that building the software the first time is only a small amount +of the overall work. +Bug fixing, extending, rebuiling of parts \(en short: maintainance work \(en +does soon take over the major part of the time spent on a software. +Not to forget the usage of the software. +These processes are highly influenced by the software's quality. +Thus, quality should never be neglected. +The problem is that you hardly ``stumble over'' bad quality during the first build, +but this is the time when you should care about good quality most. +.PP +Software design is not about the basic function of a software; +this requirement will get satisfied anyway, as it is the main driving force behind the development. +Software design is about quality aspects of the software. +Good design will lead to good quality, bad design to bad quality. +The primary functions of the software will be affected modestly by bad quality, +but good quality can provide a lot of additional gain from the software, +even at places where one never expected it. +.PP +The ISO/IEC 9126-1 standard, part 1, +.[ +%I International Organization for Standarization +%T ISO Standard 9126: Software Engineering \(en Product Quality, part 1 +%C Geneve +%D 2001 +.] +defines the quality model as consisting out of: +.IP \(bu +.I Functionality +(suitability, accuracy, inter\%operability, security) +.IP \(bu +.I Reliability +(maturity, fault tolerance, recoverability) +.IP \(bu +.I Usability +(understandability, learnability, operability, attractiveness) +.IP \(bu +.I Efficiency +(time behaviour, resource utilisation) +.IP \(bu +.I Maintainability +(analysability, changeability, stability, testability) +.IP \(bu +.I Portability +(adaptability, installability, co-existence, replaceability) +.LP +These goals are parts of a software's design. +Good design can give these properties to a software, +bad designed software will miss them. .NH 1