SCSF. Chapter 1. A. Problem Background

Chapter 1. Introduction

Problem Background

Solution Architecture: Loose Coupling with CAB

Smart Client Software Factory (SCSF)

Simplest Application Walkthrough, Classic CAB

Tracing and Visualization

Chapter 1 Lab Exercise Introduction

 

1. The superiority 优势 of rich client applications over browser-based applications for dedicated 专注的 users has been proven time and again. I once did a study for a health care client in which I calculated that every extra 额外的 mouse click in a user interface, when multiplied 并联的 by the number of PCs in the enterprise 企业 and the frequency 频率 of their usage 使用, cost the client $125,000 per year in extra employee time. Every. Single. Click. (Bang! just went a third of a million dollars in those last three words.) So optimizing 优化 the user interface is not optional 可选的 for an industrial-strength 产业优势 line-of-business 一条龙产业 application.

   Even more important than lowering this constant 不变的 friction 摩擦, a better user interface lowers the chance of a catastrophic 灾难性的 error. Consider the case of a hospital system, where a doctor wants to view information about a specific 特殊的 patient. An individual 个别的 patient's data is probably scattered 分散的 in separate silos仓储—the pharmacy 药房 system, the X-ray system, the surgery 外科 scheduling 行程安排 system, etc. Each of these has its own data, its own storage and retrieval 检索 system, its own user application, its own jealously 猜疑的 guarded 谨慎的 fiefdom 领地. The doctor has to use a separate application to access each silo仓储, according to each application's rules, with little or no coordination 协调 among them, using his own brain to string together these separate pieces of information into his own mental 脑力的 context 上下文 describing 描述 one specific patient. At best, this system consumes 消耗 time and mental energy that the doctor would rather use for thinking about what's wrong with the patient and how to fix it. At worst, it leads to 导致 catastrophic 灾难性的 errors, as you can see about to happen in Figure 1-1. Possibly a cut or paste 粘贴 operation 操作 failed and the doctor didn't notice. ("Oops. Dang. Sorry. Do you want us to try to sew that leg back on?")

    

   Figure 1-1. Separate hospital applications.

   

    

    

2. The doctor needs a rich client application that ties together data from all of these separate silos 仓储 and presents it in a coherent whole, organized and optimized 最佳化的 according to the doctor's own thought processes 进程 rather than the internal 内部的 implementations 实现 produced by the back-end silo owners. The sample program shown in Figure 1-2, from (Rolling Thunder) 电影符碌奇兵 Hospital ("We help the blind to walk and the lame to see"), illustrates 举例说明 these principles 原则. The user selects a patient from the left side of the screen, and the patient's details, such as sex and date of birth, appear in that panel 面板, reassuring 使放心的 the doctor that he's selected the right patient. Each data silo is represented in a tab on the right side of the screen. Each tab automatically knows which patient the doctor selected and automatically displays the data from its own silo that describes the current patient. The doctor/user sees a coherent 连贯的 whole 整体. He doesn't waste time or mental energy switching between applications and having to memorize 记住 the behavior 行为, often contradictory 相反的, of all the separate applications. And the sort 种 of error that he made in the previous example is much harder (not impossible, nothing's impossible that involves 涉及 human error, but hardER) to make than it was before. The world is a better place. That's what we need.

    

   Figure 1-2. Integrated hospital application.

    

   [View full size image]
   
   

    

3. OK, that's the sort of application that we need to produce. From a software design standpoint 观点, what do we need to accomplish 完成 it?

   From a user standpoint, the requirements are relatively 相当的 easy to state 陈述. They are

   • Common and consistent 连贯的 user interfaces, reducing mistakes and their costs, which can be extremely 极端 high in medical and financial 财务的 applications. A consistent user interface also reduces end-user 最终用户 training needs and support calls, and increases user throughput 生产力. Automatic sharing of data between application parts, removing the need for manual 手动 copy-and-paste techniques 技巧, improving throughput 生产力 and reducing errors. You want users thinking about their business logic ("That sounds like a lot of morphine 吗啡. Maybe I'd better double-check") rather than the application ("Dang, what's the key combo again?").

   An architectural team will want

   • A consistent and predictable 可预言的 way of developing, packaging, rolling out 上线, and updating business components to enforce 执行 architectural standards independent 独立的 of business logic.

   • A way to scale design techniques 技术 and guidance 指导 enterprise-wide, hence 因此 multiplying 增加 the benefits of expensive specialists 专家.

   Those crazy programmer geeks will appreciate 增值

   • A framework that hides complexity 复杂性 and boosts 推动 productivity 生产力.

   • The abstraction 抽象 and separation of concerns 关注点, meaning that developers can focus solely 唯一的 on business logic or user interface (UI) design or infrastructure 基础设施 services without requiring knowledge of other parts of the overall 全部的 application.

   Operations teams, the people (charged with) 使承担(任务、责任) deploying, administering 管理, and supporting applications, often feel that they get the short end 劣势的一方. To some extent 范围, this feeling is justified 有正当理由的. Programmers don't like thinking about that kind of stuff 东西 because to them it isn't fun. But as the combat 战斗 infantryman 步兵 always says, "You're just as dead." Money spent on operations staff 雇佣人员 is just as spent 浪费; errors and downtime 停工期 caused by operations issues 问题 are just as erroneous 错误的 and just as down as those caused by programming bugs. Like losing weight or getting exercise or having money left in your wallet at the end of the month, operational efficiency 功效 is a very good thing, and it doesn't just happen on its own. You have to go out and make it happen; otherwise 否则, it won't.

   Operations 运营 teams would like

   • The consolidation 合并 of shell applications resulting in the need for only one executable 可执行 file to be shipped 发货, reducing the number of potential 潜在的 common language runtime (CLR) versioning issues 问题.

   • Easier rollout 上线 of common business elements and modules, resulting in consistent configuration management and instrumentation 使用仪器implementations 实现 across a suite 套 of applications.

   • A pluggable architecture that enables basic services (such as authentication 身份验证 and catalog 登记 provisioning 服务开通) to be driven from server-side infrastructures, which, in turn, enables central management of many smart client applications at a time.

4. Now that we see what the application needs, what sort of design would best produce it? There's an awful 可怕的 lot of stuff going on inside it. The main screen contains multiple 多重的 collaborating 协作 parts, each one addressing 处理 a specific 特殊的 aspect 方面 of a business 业务 process: patient selection, X-rays, surgery 外科手术 scheduling, and so on. We need the parts to be integrated visually 看得见的 to provide a consistent user experience 经历, and we need to share information with each other (to some extent) 某种程度上 .

   Ten years ago, the classic design would have been to build a monolithic 完全统一的 application in which every part knew about every other part at compile 编译 time. But that design doesn't work well in today's enterprise, because the difficulty of development increases 增加 exponentially as program size increases. The application quickly gets so complicated that no one can keep track of all the side effects and back channels, and it becomes unmaintainable, unextendable, and unusable. Microsoft Office is the classic example of a complex monolithic application.

   Instead, it would be better to separate the parts of the program and reduce their dependencies on each other to a minimum. They'd be developed by different teams. Since each part knows less about the other parts, the side effects would be minimized, and the development effort would approach linearity to size of the program. The parts would interact independently with their own back-end systems and could be independently versioned, deployed, and updated.

   Consider the evolution of program design in the past 30 or so years. We went from GoTo statements to functions and then from functions to objects. With each step, we knew less about each piece of the program so that we could effectively deal with more pieces. We've gone about as far as we can go with tightly coupled objects, and we now need to take the next step.