Discipline of Software Engineering (eBook)

B. Walraet (Autor)

eBook Download: EPUB

2014 | 1. Auflage
505 Seiten
Elsevier Science (Verlag)
978-1-4832-9421-6 (ISBN)

Infos

This comprehensive approach to the creation of software systems charts a road through system modelling techniques, allowing software engineers to create software meeting two very basic requirements:• that the software system represent a narrow emulation of the organization system that served as its model; • and that the software system display life attributes identical to those of the organization system that it automatizes.The result is a quantum leap increase in software application quality. Such benefit is achieved by the introduction of a fundamental paradigm: the office-floor metaphor which incorporates such well-balanced basic ideas as the functional normalization of tasks and information (in sharp contrast to the classic data normalization) and the principle of tenant-ownership.

Inhalt

Front Cover 1
A Discipline of 
 
4 
Copyright Page 5
Table of Contents 16
Dedication 6
PREFACE 8
TABLE OF INSERT BOXES 22
PART 1: OVERTURE 24
CHAPTER 1: The State of the House 26
Curtains for programming 26
In the methods jungle 28
Not programming but software engineering 30
The life-cycle 31
The state of the union 37
Can quality be achieved 39
Quality: a matter of responsibility 42
Design revisited or divide and conquer 43
The houses of Ret Up Moc 46
Many roads lead to Rome 47
The data-driven world 49
The abstraction rounds 50
So, what is a 
51 
Software Engineering is a social exercise 53
PART 2: ENTITY 1: INFORMATION 56
CHAPTER 2: The Semantics of Data 58
Preamble: Codd's relational model 58
Data has a life of its own 67
Bachman diagramming 68
Bachman example: order entry 76
Subject data-bases go corporate 76
More semantics: Chen modelling 80
E/R example 1: order entry 85
Higher order extensions 86
E/R example 2: The Transportation Company 87
MERISE, entities and relationships à la Française 90
NIAM or data is a prisoner 91
More constraints 102
NIAM example 1: order entry 103
NIAM example 2: a school management 106
Meaning, awareness and visibility 108
Has-part and Is-a networks (ter Bekke 
114 
Example: order processing 119
Object bases 120
The object subjectivism 122
The semantics in frames 125
More power in semantic networks 127
A repository of structures: the meta-model 129
CHAPTER 3: The Fine Art Of Data Modeling 136
Entities and data stores have attributes 136
Environment decomposition: user views 137
How important is meaning 138
All the various keys and attributes 142
Concatenated keys 143
Primary keys: well-behaved creatures 144
Multiple relationships 147
An example and a method 147
The many to many mess 149
Nested structures 149
Key to key relationships 150
Case Study - A transportation company 151
Key-only forms 169
View consistency aspects 171
Suggested repository structures 172
CHAPTER 4: The Makings of a Logical Data Model 178
Putting the parts together 178
Cycles over primary keys 187
The merging process: algorithm 190
Case study: finalization of the transportation company 194
Stability assurance 206
Final logical model: topological 213
Final logical model: tabular 215
Suggested repository structures 218
Responsibility & ownership
PART 3: RELATIONSHIP BETWEEN ENTITY1 AND ENTITY 2: ORGANIZATION 222
CHAPTER 5. Semantic Action Model 224
Getting at the data is half the fun 224
What is a 
227 
Once again: what is a 
229 
Responsibility and ownership 230
APPROACH 1: THE INFORMATION FLOW PARADIGM 231
Processes controlled by messages 231
Information flow is the key 233
Case study: information flow of the transportation company 237
Consistency of the message model 243
Ownership of messages 244
Extensions to the message processing model 245
Cycles in the message processing model 250
X and (START or B-ENDED) 252
Different types of messages 254
Dynamic coherence of a message flow model 255
Processes that store and retrieve data 258
An example: order processing 260
Good behaviour with data stores 261
Ownership of data stores 262
Case study: DFD/MFD of the transportation company 264
APPROACH 2: A WORLD OF FUNCTIONS 266
What is a 
266 
Information architecture 269
APPROACH 3: THE OBJECT-ORIENTED PARADIGM 273
Objects that live through actions 273
Example: object lifecycles in the school management 281
Object-oriented Analysis 283
APPROACH 4: THE SYSTEM STATE MODEL 288
Systems: invariants, actions and states 288
The repository description 292
PART 4: ENTITY 2: ACTIONS 302
CHAPTER 6. Function & Task Design
Tasks: what's in a 
304 
Normalizing the processes 311
Defining data stores and data 
313 
Case study: the transportation company 315
OLTP tasks 319
OLTP tasks have a structure 320
Subtasks and co-tasks 324
Menus: a dinner of dialogs 327
Ownership and sharability 327
Jobs and planned tasks 330
Object-oriented design: what are 
334 
Cooperative processing and the client-server model 335
A world of GUIs in Windows 343
The structure of the task in a window 348
Prototyping: the American way 353
The repository image 357
CHAPTER 7. Program Design 366
Moving towards the programs 366
Batch programs: another paradigm 367
Modular decomposition 369
Component hierarchies rather than networks 371
Common modules 374
Ownership of modules 374
The usage of subroutines 375
Structuring using co-routines 377
Programs and data views 378
View ownership re-visited 383
Decision tables: a matter of 
384 
The case of structured programming 386
Michael Jackson's complaint 387
Michael Jackson's method 390
JSP and the subroutine 400
JSP: a 
400 
Program structure and data-base traversal 401
State-driven programming 403
Entity lifecycles and state diagrams 408
The object-oriented paradigm for programming 410
Suggested repository structures 412
APPENDICES 416
CHAPTER 8: Normalization is with us to stay 418
First normal form 418
Second normal form 420
Third normal form 421
Here comes the fourth 422
And then there was the fifth 424
Normalize versus de-normalize 426
The difficulty of normalizing 427
Other decompositions 428
CHAPTER 9. About the Bill Of 
430 
Recursion in data 
430 
What is a recursive 
430 
The 
432 
Terminology and definitions 434
Explosion & implosion (levels or no levels)
Some examples 436
Trees and networks 438
Example: the road map 440
Example: the marriage 441
Extensions: higher-order BOM 442
The genealogy model 444
Extensions: BOM of BOM 444
The universe is a BOM 446
An incursion into repository technology 446
An example: repository registration of a system 448
Definition of n-ary and nth-order relationships 450
A first extension 450
Conceptual extension of the repository model 451
Gnoson/synergon model: a PROGRAM/FILE example 452
Implementation: A proposal using the basic model 453
Repository: objects that communicate 455
SQL and the BOM 455
Programming the BOM: recursive programs 456
Program group 1: produce explosion/implosion 459
JSP and the BOM 464
Circularity in Recursive Data Structures 464
Program group 2: verify circularity 466
Program group 3: avoid circularity 470
CHAPTER 10. About Structured Programming 476
D-structures and DREC structures 478
Away with duplicate actions 482
FOR X:enumeration PERFORM action(X) 484
PERFORM 
484 
Procedural abstraction: the subroutine 484
Subroutines considered harmful 485
Co-routines: a conversation of cycles 488
Design languages 491
CHAPTER 11. Object-oriented Programming 494
The programming of objects 494
What is a program? 497
Facets of objects 498
Object-oriented programming, once more with flavours 502
Programs are also objects 503
Object-orientedness: the end of the 
506 

Textauszug

PREFACE

Anyone who cares to make up the balance of 30 years of business programming cannot help but notice that the way in which we undertake the construction of software systems must be seriously criticized. “Curtains for programming”? Certainly. Free the stage for Software Engineering. That is where the primary challenge lies. How do you expect a car builder, whatever his craftsmanship qualifications, to build a good car, when the designer gives him incomprehensible or vague blueprints? And what about a car builder who has never learned the technique of building cars?

But what do we observe? A fact that is amazing only to the novice and the naive: the realm of software engineering is just as full of fashion trends and fads as the world of programming. Sometimes, even, programming is seen as the only worthwhile activity in Software Engineering (a good program corrects a bad design, they say!). In the best of cases, we find that most designers are at a loss. Even when they know what is expected from them, they they find it difficult to decide how to conduct their work. More often than not, they have received insufficient training in the methods and they have certainly not been given any insight into the paradigms underlying the methods, so that they are left helpless in the open, with the financial management looking critically at their performance, since analysis and design are the phases that consume money but show nothing usable. To use two neologisms of today: one wants to have perestroika but there is hardly any glasnost …

Accordingly, the results obtained in Software Engineering are poor: NASA (a maker of numerous gigantic “programs”) claims that 75% of their produced programs are mild to total failures! Amazing and appalling. But no one should be so surprised at these poor results. We all know that there is a problem, but we are probably not very aware of its size and dimension. The problem starts with software departments being unable to define software engineering in any usable way. Small wonder then that world-wide statistics display an alarming amount of poor quality software products. The key word of today is quality. Software Systems have a quality that is too low: they are bad performers, resource devourers that display no reliability, no usability, no longevity whatsoever. Maintaining the software systems swallows an incredible amount of effort. More and more the financial decision makers tend to understand the new adage: quality is money! The next step is the understanding and acceptance of the means to reach quality. The older adage time is money must be quickly forgotten, since its application leads only to shortening and shortening and shortening the development process, and in doing so there is no quality gain to be achieved whatsoever (indeed: more time will be needed in maintenance, with the consequence that, seen over the life time of a software system, time is money remains grotesquely true).

The key to making a Software System that displays provable and durable quality lies in the effort and seriousness invested in the analysis and the design. Analysis: understanding what the system is all about (in its essence and in its requirements) with the unambiguous consensus of all parties involved. Design: the definition of ways to solve the requirements, again in an environment of unambiguous consensus. What we need is obvious: analysts/designers with the right profile, the expected training and proven experience. Techniques (agglomerated in methods and methodologies) that allow the cognoscenti to model the system while they are endeavouring to understand it (and subsequently design it). Preferably a choice of alternative techniques, even, so that the most suitable one can be selected for each type of problem. The acceptation that a technique is only a technique: there is no justification for a technique from the technique itself; the justification comes from suitability. Techniques should not call for tricks. They should be simple, encompassing, comprehensible and comprehensive. But simplicity has never been a synonym of sloppiness. Building a wooden desk is not difficult (it is simple even), but one can only undertake it given some basic conditions: the person must be able, he must have been taught the principles of wood assembly and he must have understood them. The same is true for a software engineer: knowing methods is far from sufficient. He must understand them and be able to apply them. Much more important even: he must be able to decide when a method is not applicable.

But above all, the software engineer must never forget the goal: the system that the users are waiting for. He must never forget that he is working for customers: the users. And although it was fashionable in the past to despise the users, the fundamental fact must be clear: the users decree the quality label of a system. The architect who conceives a house, the builder who undertakes to build it, the mason who assembles the bricks into walls are all very conscious of the presence of the controlling user (the owner). How is it that this is not universally accepted for Software Engineering?

Obvious as they are, all these steps cannot improve anything if there is no clear cut decision from the very top: strategic management must be concerned with the true return of the Information Technology investments. They must display the will to receive and assess the fruit of the technology. Middle management must create the logistics for quality engineering to take place. Operations management must be concerned daily with quality flaws, thereby turning an essentially negative situation into a constructive quality culture. Effort will be needed, primarily of a psychological nature. There are no miracles.

One intention of this book, therefore, is to give the reader the insight into and the understanding of the various ways to model (and subsequently design) a system.

My major objective, however, is that of giving the software engineer not a method but an approach and a mental framework so that by using it, any organization can, after suitable decision making, undertake the creation and installation of a quality framework for system development. The approach to quality achievement, covering the complete life-cycle, is established as a red line through the various chapters. Why an approach and why not a method? Because I do not believe in rigid and disciplinary recipes. Software engineering remains an act of creation, with a scientific taste to it, and therefore the specialist must be given freedom within the frame of recognized paradigms. When this freedom is removed, the design of systems becomes very artificial as various realistic exceptions and marginal situations are bent into grotesque shapes of which the only merit is that they fit The Method. The resulting system, of course, becomes a mere caricature of reality.

The activity of programming is merely hinted at, as this is a language dependent ploy, which should not be too difficult, once the algorithms are conceived. And, of course, the interested reader can always read my Programming, the impossible Challenge1 ([B1]). On the other hand, program design is dealt with in some depth, since I have found that in many cases the programmers are not trained in these aspects.

A word of warning and caution: although I deal extensively with the matter of Software Engineering, my main concern is to propose solutions to the problem of quality, specifically in the area of precision and reliability. Therefore, I devote my full attention to the subject of specification and design of the functionality. But there is more, much more, to Software Engineering. In particular, I do not cover such subjects as: testing of a system, fault tolerance and resilience, performance and resource consumption, queueing and scheduling, security, disaster planning, project administration and other such fascinating niceties. Dealing with these topics would have called for a book double this size.

When Software Engineering is undertaken as the intelligent response to a real challenge, then (given the correct means and sufficient insight) it might just be that Programming is no longer that Impossible Challenge.

Part 1 (the overture) contains an introduction chapter which sketches the state of the union and comes up with a worrying balance: there are quality problems in great abundance.

Part 2 is devoted to the information modeling activities. This area is what I believe to be an essential one. Indeed, what a company does is largely determined by the information that it must process. It is not the processes that are primordial. The information must be understood, catalogued, classified, structured. All possible interpretations must be sought and represented. Grasping the semantics of information is the key. Chapter 2 presents the relational model for what it is worth (and what not) and then goes into the depths of semantic modeling, an activity that can very well be termed the analysis of the information model. Chapters 3 and 4 cover the intimate details of data modeling, using case studies of realistic complexity and showing how to achieve a logical data model.

Most of part 2 is based upon a course that I created and...

Produkt-Details

• Erscheint lt. Verlag: 28.6.2014
• Sprache: englisch
• Themenwelt: Mathematik / Informatik ► Informatik ► Software Entwicklung
• ISBN-10: 1-4832-9421-8 / 1483294218
• ISBN-13: 978-1-4832-9421-6 / 9781483294216