SPECIAL OFFERS
Keep up with new releases and promotions. Sign up to hear from us.
Register your product to gain access to bonus material or receive a coupon.
Offers fresh insight on client/server architectures, including hardware tiers, software layers, replication, and the pros and cons of fat clients vs. fat servers.
52175-7
Analysis and design techniques that work: a cogent, complete, and entertaining guide.
This is a practical and witty guide to the core competencies client/server and GUI designers really need—and the analysis and design techniques that really work.
Expert David Ruble introduces a project decision-making framework that helps analysts and users to work together to define measurable, business-focused objectives for new software systems. He brings unprecedented rigor to event modeling, showing how to systematically decompose business events from the conceptual level, all the way down to the mouse-clicks and keystrokes of event-driven applications.
Ruble shows how to choose prototyping techniques that deliver optimal results while allowing project managers to maintain close control. He also shows why written GUI design specifications are critical to effective construction, testing, and project management—and how they can be created quickly. The book includes sample specs that are proven to work and can serve as the basis for your own GUI design specifications.
Ruble offers lucid advice on client/server architectures, including hardware tiers, software layers, replication, and the pros and cons of fat clients versus fat servers. He also shows how mainframe developers can succeed in today's client/server and GUI-based environments, by blending their traditional software engineering competencies with newer techniques.
The book concludes with a start-to-finish case study that brings its techniques to life, through the analysis and design of a real-world order entry system.
Practical Analysis and Design for Client/Server and GUI Systems is essential reading for developers, analysts, project managers, senior IT executives, information architects, and any software professional responsible for the success of a client/server project.
1. What Is Analysis and Design?
2. The Project Charter.
3. The Context Model.
4. The Event Model.
5. The Information Model.
6. The Interface Prototype.
7. Wrapping up the Analysis Phase.
8. The Architecture Model.
9. Relational Database Design.
10. Graphical User Interface Concepts.
11. External Interface Design.
12. Internal Component Design.
13. Ten Myths of Client/Server Development.
Appendix: McVet Case Study.
Glossary.
Bibliography.
Index.
Client/server technology has dramatically changed the way we design and build information systems. In most businesses, the glory days of the single mainframe processor are gone. The one big box has been replaced or augmented by an integrated network of personal computers, communication networks, file servers and database servers. The popularity of the graphical user interface (GUI) has placed ever-increasing demands on information technology professionals to create applications that are complex, yet intuitive and easy to use.
Client/server systems knit together sectors of the business organization into a broad computing fabric that reaches far beyond the boundaries of traditional mainframe systems.
This book offers a practical guide to the core competencies required for analysis and design of today's client/server business information systems. In it, you will find analysis and design techniques which have been employed with success on many large-scale projects. Today's information environment is one of rapidly expanding complexity. Successful client/server project teams must master the design and creation of the graphical user interface, manage and maintain systems using object-oriented programming constructs, design databases capable of serving the needs of multiple business sites, and link geographically-distributed users together, both inside and outside of the enterprise. As if that isn't enough, the ever-expanding scope of today's information systems requires an even more savvy analytical understanding of the business and a well-coordinated partnership with the users and business management teams than in the past.
What is Practical Analysis and Design for Client/Server and GUI Systems?
The reason I call this “Practical Analysis and Design” is because I am an analyst and designer, myself. I don't want to wade through an academic dissertation offering mathematical proof for some hypothetical methodology, and I figure that you don't have the time either. We've got deadlines to meet. So I've included the key analytical techniques and design concepts that I have used to get client/server projects delivered in a timely and sensible manner.
These techniques can be employed using a variety of project-management philosophies, ranging from traditional waterfall to iterative spiral approaches. Some activities presented herein have definite predecessorPsuccessor relationships while others can be conducted concurrently. This is simply the stuff that needs to be done to ensure adequate understanding of the business problem and provide reliable, traceable design specs to build and test a system.
As for the last part of the book's title, “for Client/Server and GUI Systems,” this book assumes your new systems will include at least one, perhaps many computers fulfilling the role of “server,” that your terminals or “clients” are likely to be personal computers with some type of graphical user interface, and that your database will probably be of the relational variety. The amount of object-orientation in your system will vary tremendously, depending on the capabilities of your target development languages. While the analysis and design techniques in this book are not limited to this environment, they are exceptionally well suited to this scenario.
What's this book about?
If this book weighed 100 pounds, about 60 pounds of it would be analysis and 40 pounds would be design. The analysis section starts with a chapter on project charters, which marks the beginning of the analytical process even though this activity is commonly referred to as the “planning” phase of a project. The activities of analyzing the business need are covered in the subsequent five chapters on context modeling, event modeling, information modeling, interface prototyping and resolving business issues. Then the book moves on to system design. The design chapters show how to consume the models created during the analysis phase for making architectural decisions, designing the database, and creating the interface and internal componentry.
That's a lot of stuff! What isn't in this book?
This book is about writing specifications for systems, not about writing code at the line level. There are plenty of programming and technical issues which are well beyond the scope of this work. Computer hardware is something that this book definitely not about. I won't be telling you how to wire up your network or which plug goes in which socket. I do not endeavor to endorse (or deride) any particular brand or type of hardware, language or development tool, and I can't possibly tell you whether to use version 1.342A versus version 2.417B. That kind of advice would be out of date before the ink was dry from the press.
Who needs to know all of this?
Developers, managers, business analysts, programmers . . . a lot of people need to know this stuff. Within these pages are the core competencies that form the foundation of successful software engineering. These techniques have evolved over the last three decades, along with the capabilities of the available technology and the maturity of our industry. Whether you are a traditional mainframe developer, an experienced client/server veteran with many projects under your belt, or a mouse-slinging “PC cowboy” riding the range of the GUI desktop frontier, you should be able to find something useful in this book. Today's information technology professional is becoming more and more specialized. Like the medical field, there is simply too much to learn to know it all. You can carve out a specialized career niche by picking just one or two techniques from this book and getting really good at them. Other readers may opt for a more generalized approach by mastering many of the techniques along with a variety of programming languages and technical skills.
How this book is organized
The first chapter reveals the secret for a successful client/server project. It takes the right people, sensible management, and a sound methodology. (Having a big sack of money doesn't hurt, either.) I discuss the skills required of a good analyst and the skills to look for in a designer. I offer my thoughts on the waterfall versus spiral methodology debate, and then move on to describe the key characteristics to look for in a good methodology. The chapter closes with a brief overview of the techniques covered in the rest of the book.
Chapters 2 through 7 detail the deliverables of planning and analysis. In Chapter 2, The Project Charter, I initiate the analytical process with a technique called the project decision-making framework, which is used to help the business members determine the true objectives of their new system. Chapter 3 covers The Context Model, a venerable yet important technique for exploring and defining system scope and external interfaces. The Event Model is the subject of Chapter 4. The event model defines the system's observable behavior in business terms, and documents the business policy and rules which comprise the process requirements. It is a crucial model which guides the development of the event-driven graphical user interface. The Information Model, covered in Chapter 5, creates an organizational map of the data that the system is required to remember. This is a vital technique for sound relational database design and object modeling. Chapter 6 shifts from building models to consing models. The Interface Prototype is our first foray into design. Prototyping can be used to validate models, design the interface, or even elicit requirements. Chapter 7 rounds out the analysis section with some suggestions on resolving business issues.
Chapters 8 through 12 address the design of a client/server system and graphical user interface. Chapter 8, on The Architecture Model, shows how to use the essential models from analysis to determine the most desirable (or least offensive), technical architecture for your system. Chapter 9 covers the basics of transforming an information model into a Relational Database Design. Chapter 10 introduces key Graphical User Interface Concepts. The written External Interface Design specification is the subject of Chapter 11. A written specification is a vital management tool for partitioning the development work among multiple programmers, and for devising adequate test plans. Chapter 12 is the final technical chapter, covering Internal Component Design, with an emphasis on object-oriented concepts.
In the final chapter, I present Dave's Top Ten Myths of Client/Server Development. This chapter is intended to help separate the fact from the fiction surrounding client/server development. Following the formal chapters, I have included a comprehensive case study which gives you an opportunity to exercise the techniques covered in this book for a fictitious business, rife with many of the same types of problems and issues that you find in real companies.
The philosophy of this book is simple. Building solid software applications requires rigor and discipline. No amount of arm-waving and fad-of-the-year hoopla can eradicate the need for getting into the gory details of the business problem. Techniques for analysis and design need to be sufficiently robust and expressive to articulate the business need and devise a solution, yet they must be practical enough to be practiced with everyday tools in a format that allows analysts and designers to work closely with their users.
By using the techniques in this book, you can build reliable systems which realize the goal of client/server, to exploit the power of micro, mini and mainframe computers by allocating them to their most propitious use. By doing this in an organized and rational manner, you will avoid the anarchy which is unleashed in less disciplined shops, and your efforts will yield information systems that are flexible enough to meet your business' needs while maintaining safe custody of the corporate data asset.
Questions or comments regarding this book can be addressed to the author at
www.ocgworld.com
Author's Note
Several conventions employed in this book are worthy of explanation. The English language lacks a word to express “he or she” in the singular. “They” denotes plural, and “he/she” is awkward. In the interest of readability, I have used the words he and him instead of he/she and him/her. You may take any instance of the word he or him in this book to describe either a male or female person, with the notable exception of my reference to General Eisenhower in Chapter 3, and various methodologists named throughout.
In information modeling, the term entity is formally differentiated from the term entity type. The entity type is the classification of the person, place, thing or abstract idea, and the entity is a member or instance of the classification. Customer represents the entity type. Bob's grocery store represents an entity. This distinction is not always made in the vernacular of common speech among practitioners. In the interest of smooth sentence flow I will use the word entity at times in this book to mean either entity or entity type. The context of the sentence should make it clear what I mean. This disclaimer also applies to my use of the words attribute versus attribute type, and relationship versus relationship type.
The distinction is more clear in object-oriented design where we have entirely different words to distinguish between a class and an object. Objects are the instances that exist at runtime (e.g., Bob). Classes are the templates from which the objects are wrought (e.g., Customer). Since class can have different meanings in our language, I will sometimes use the term object class instead of simply class to make it clear that I am referring to an object-oriented construct.