다중혈관 관상동맥 환자에서 y-문합을 이용하여 양쪽 내흉동맥만을 사용한 우회술의 조기 성적

The network structure of a hyperlinked environment can be a rich source of information about the content of the environment, provided we have effective means for understanding it. We develop a set of algorithmic tools for extracting information from the link structures of such environments, and report on experiments that demonstrate their effectiveness in a variety of context on the World Wide Web. The central issue we address within our framework is the distillation of broad search topics, through the discovery of “authorative” information sources on such topics. We propose and test an algorithmic formulation of the notion of authority, based on the relationship between a set of relevant authoritative pages and the set of “hub pages” that join them together in the link structure. Our formulation has connections to the eigenvectors of certain matrices associated with the link graph; these connections in turn motivate additional heuristrics for link-based analysis.

/pdf/authoritative-sources-in-a-hyperlinked-environment-1p23r698i9.pdf

Authoritative sources in a hyperlinked environment

How has Japan become a major economic power, a world leader in the automotive and electronics industries? What is the secret of their success? The consensus has been that, though the Japanese are not particularly innovative, they are exceptionally skilful at imitation, at improving products that already exist. But now two leading Japanese business experts, Ikujiro Nonaka and Hiro Takeuchi, turn this conventional wisdom on its head: Japanese firms are successful, they contend, precisely because they are innovative, because they create new knowledge and use it to produce successful products and technologies. Examining case studies drawn from such firms as Honda, Canon, Matsushita, NEC, 3M, GE, and the U.S. Marines, this book reveals how Japanese companies translate tacit to explicit knowledge and use it to produce new processes, products, and services.

The knowledge-creating company : how Japanese companies create the dynamics of innovation

A useful starting point for designing advanced graphical user interfaces is the visual information seeking Mantra: overview first, zoom and filter, then details on demand. But this is only a starting point in trying to understand the rich and varied set of information visualizations that have been proposed in recent years. The paper offers a task by data type taxonomy with seven data types (one, two, three dimensional data, temporal and multi dimensional data, and tree and network data) and seven tasks (overview, zoom, filter, details-on-demand, relate, history, and extracts).

/pdf/the-eyes-have-it-a-task-by-data-type-taxonomy-for-1u82t2ua1m.pdf

The eyes have it: a task by data type taxonomy for information visualizations

物件導向軟體之架構(Object-Oriented Software Construction)探討

From the Book:

Our goals for the first edition were threefold. First, we wanted to show through authentic case studies actual examples of software architectures solving real-world problems. Second, we wanted to establish and show the strong connection between an architecture and an organization's business goals. And third, we wanted to explain the importance of software architecture in achieving the quality goals for a system. 

Our goals for this second edition are the same, but the passage of time since the writing of the first edition has brought new developments in the field and new understanding of the important underpinnings of software architecture. We reflect the new developments with new case studies and the new understanding both through new chapters and through additions to and elaboration of the existing chapters.

Architecture analysis, design, reconstruction, and documentation have all had major developments since the first edition. Architecture analysis has developed into a mature field with industrial-strength methods. This is reflected by a new chapter about the architecture tradeoff analysis method (ATAM). The ATAM has been adopted by industrial organizations as a technique for evaluating their software architectures.

Architecture design has also had major developments since the first edition. The capturing of quality requirements, the achievement of those requirements through small-scale and large-scale architectural approaches (tactics and patterns, respectively), and a design method that reflects knowledge of how to achieve qualities are all captured in various chapters. Three new chapters treat understanding quality requirements, achieving qualities, and theattribute driven design (ADD) method, respectively.

Architecture reconstruction or reverse engineering is an essential activity for capturing undocumented architectures. It can be used as a portion of a design project, an analysis project, or to provide input into a decision process to determine what to use as a basis for reconstructing an existing system. In the first edition, we briefly mentioned a tool set (Dali) and its uses in the re-engineering context; in in this edition the topic merits its own chapter.

Documenting software architectures is another topic that has matured considerably in the recent past. When the first edition was published, the Unified Modeling Language (UML) was just arriving on the scene. Now it is firmly entrenched, a reality reflected by all-new diagrams. But more important, an understanding of what kind of information to capture about an architecture, beyond what notation to use, has emerged. A new chapter covers architecture documentation.

The understanding of the application of software architecture to enable organizations to efficiently produce a variety of systems based on a single architecture is summarized in a totally rewritten chapter on software product lines. The chapter reinforces the link between architecture and an organization's business goals, as product lines, based around a software architecture, can enable order-of-magnitude improvements in cost, quality, and time to market. 

In addition to the architectural developments, the technology for constructing distributed and Web-based systems has become prominent in today's economy. We reflect this trend by updating the World Wide Web chapter, by using Web-based examples for the ATAM chapter and the chapter on building systems from components, by replacing the CORBA case study with one on Enterprise JavaBeans (EJB), and by introducing a case study on a wireless EJB system designed to support wearable computers for maintenance technicians.

Finally, we have added a chapter that looks more closely at the financial aspects of architectures. There we introduce a method--the CBAM--for basing architectural decisions on economic criteria, in addition to the technical criteria that we had focused on previously.

As in the first edition, we use the architecture business cycle as a unifying motif and all of the case studies are described in terms of the quality goals that motivated the system design and how the architecture for the system achieves those quality goals.

In this edition, as in the first, we were very aware that our primary audience is practitioners, so we focus on presenting material that has been found useful in many industrial applications, as well as what we expect practice to be in the near future.

We hope that you enjoy reading it at least as much as we enjoyed writing it.


0321154959P12162002

/pdf/software-architecture-in-practice-1msttzulix.pdf

Software Architecture in Practice

List of Figures. List of Tables. Preface. Acknowledgments. Reader's Guide. 1. What Is Software Architecture? Architecture as a Vehicle for Communication among Stakeholders. Architecture and Its Effects on Stakeholders. Architectural Views. Architecture Description Languages. Architecture as the Manifestation of the Earliest Design Decisions. Architectural Styles. Architecture as a Reusable, Transferable Abstraction of a System. Summary. For Further Reading. Discussion Questions. 2. Evaluating a Software Architecture. Why Evaluate an Architecture? When Can an Architecture Be Evaluated? Who's Involved? What Result Does an Architecture Evaluation Produce? For What Qualities Can We Evaluate an Architecture? Why Are Quality Attributes Too Vague for Analysis? What Are the Outputs of an Architecture Evaluation? Outputs from the ATAM, the SAAM, and ARID. Outputs Only from the ATAM. What Are the Benefits and Costs of Performing an Architecture Evaluation? For Further Reading. Discussion Questions. 3. The ATAM-A Method for Architecture Evaluation. Summary of the ATAM Steps. Detailed Description of the ATAM Steps. Step 1: Present the ATAM. Step 2: Present the Business Drivers. Step 3: Present the Architecture. Step 4: Identify the Architectural Approaches. Step 5: Generate the Quality Attribute Utility Tree. Step 6: Analyze the Architectural Approaches. Step 7: Brainstorm and Prioritize Scenarios. Step 8: Analyze the Architectural Approaches. Step 9: Present the Results. The Phases of the ATAM. Phase 0 Activities. Phase 1 Activities. Phase 2 Activities. Phase 3 Activities. For Further Reading. Discussion Questions. 4. The Battlefield Control System-The First Case Study in Applying the ATAM. Preparation. Phase 1. Step 1: Present the ATAM. Step 2: Present the Business Drivers. Step 3: Present the Architecture. Step 4: Identify the Architectural Approaches. Step 5: Generate the Quality Attribute Utility Tree. Step 6: Analyze the Architectural Approaches. Phase 2. Step 7: Brainstorm and Prioritize Scenarios. Step 8: Analyze the Architectural Approaches. Step 9: Present the Results. Results of the BCS Evaluation. Documentation. Requirements. Sensitivities and Tradeoffs. Architectural Risks. Summary. Discussion Questions. 5. Understanding Quality Attributes. Quality Attribute Characterizations. Performance. Availability. Modifiability. Characterizations Inspire Questions. Using Quality Attribute Characterizations in the ATAM. Attribute-Based Architectural Styles. Summary. For Further Reading. Discussion Questions. 6. A Case Study in Applying the ATAM. Background. Phase 0: Partnership and Preparation. Phase 0, Step 1: Present the ATAM. Phase 0, Step 2: Describe Candidate System. Phase 0, Step 3: Make a Go/No-Go Decision. Phase 0, Step 4: Negotiate the Statement of Work. Phase 0, Step 5: Form the Core Evaluation Team. Phase 0, Step 6: Hold Evaluation Team Kick-off Meeting. Phase 0, Step 7: Prepare for Phase 1. Phase 0, Step 8: Review the Architecture. Phase 1: Initial Evaluation. Phase 1, Step 1: Present the ATAM. Phase 1, Step 2: Present Business Drivers. Phase 1, Step 3: Present the Architecture. Phase 1, Step 4: Identify Architectural Approaches. Phase 1, Step 5: Generate Quality Attribute Utility Tree. Phase 1, Step 6: Analyze the Architectural Approaches. Hiatus between Phase 1 and Phase 2. Phase 2: Complete Evaluation. Phase 2, Step 0: Prepare for Phase 2. Phase 2, Steps 1-6. Phase 2, Step 7: Brainstorm and Prioritize Scenarios. Phase 2, Step 8: Analyze Architectural Approaches. Phase 2, Step 9: Present Results. Phase 3: Follow-Up. Phase 3, Step 1: Produce the Final Report. Phase 3, Step 2: Hold the Postmortem Meeting. Phase 3, Step 3: Build Portfolio and Update Artifact Repositories. For Further Reading. Discussion Questions. 7. Using the SAAM to Evaluate an Example Architecture. Overview of the SAAM. Inputs to a SAAM Evaluation. Outputs from a SAAM Evaluation. Steps of a SAAM Evaluation. Step 1: Develop Scenarios. Step 2: Describe the Architecture(s). Step 3: Classify and Prioritize the Scenarios. Step 4: Individually Evaluate Indirect Scenarios. Step 5: Assess Scenario Interactions. Step 6: Create the Overall Evaluation. A Sample SAAM Agenda. A SAAM Case Study. ATAT System Overview. Step 1: Develop Scenarios, First Iteration. Step 2: Describe the Architecture(s), First Iteration. Step 1: Develop Scenarios, Second Iteration. Step 2: Describe the Architecture(s), Second Iteration. Step 3: Classify and Prioritize the Scenarios. Step 4: Individually Evaluate Indirect Scenarios. Step 5: Assess Scenario Interactions. Step 6: Create the Overall Evaluation-Results and Recommendations. Summary. For Further Reading. Discussion Questions. 8. ARID-An Evaluation Method for Partial Architectures. Active Design Reviews. ARID: An ADR/ATAM Hybrid. The Steps of ARID. Phase 1: Rehearsal. Phase 2: Review. A Case Study in Applying ARID. Carrying Out the Steps. Results of the Exercise. Summary. For Further Reading. Discussion Questions. 9. Comparing Software Architecture Evaluation Methods. Questioning Techniques. Questionnaires and Checklists. Scenarios and Scenario-Based Methods. Measuring Techniques. Metrics. Simulations, Prototypes, and Experiments. Rate-Monotonic Analysis. Automated Tools and Architecture Description Languages. Hybrid Techniques. Software Performance Engineering. The ATAM. Summary. For Further Reading. Discussion Questions. 10. Growing an Architecture Evaluation Capability in Your Organization. Building Organizational Buy-in. Growing a Pool of Evaluators. Establishing a Corporate Memory. Cost and Benefit Data. Method Guidance. Reusable Artifacts. Summary. Discussion Questions. 11. Conclusions. You Are Now Ready! What Methods Have You Seen? Why Evaluate Architectures? Why Does the ATAM Work? A Parting Message. Appendix A: An Example Attribute-Based Architectural Style. Problem Description. Stimulus/Response. Architectural Style. Analysis. Reasoning. Priority Assignment. Priority Inversion. Blocking Time. For Further Reading. References. Index. 020170482XT10082001

Evaluating Software Architectures: Methods and Case Studies

Software Architecture in Practice: Addison-Wesley

: If a software architecture is a key business asset for an organization, then architectural analysis must also be a key practice for that organization. Why? Because architectures are complex and involve many design tradeoffs. Without undertaking a formal analysis process, the organization cannot ensure that the architectural decisions made-particularly those which affect the achievement of quality attribute such as performance, availability, security, and modifiability-are advisable ones that appropriately mitigate risks. In this report, some of the technical and organizational foundations for performing architectural analysis are discussed, the Architecture Tradeoff Analysis Method (ATAM), is presented. The ATAM is a technique for analyzing software architectures that has been developed and refined in practice over the past three years.

/pdf/atam-method-for-architecture-evaluation-28lm8ttd0a.pdf

ATAM: Method for Architecture Evaluation

This paper presents the Architecture Tradeoff Analysis Method (ATAM), a structured technique for understanding the tradeoffs inherent in the architectures of software-intensive systems. This method was developed to provide a principled way to evaluate a software architecture's fitness with respect to multiple competing quality attributes: modifiability, security, performance, availability, and so forth. These attributes interact-improving one often comes at the price of worsening one or more of the others-as is shown in the paper, and the method helps us to reason about architectural decisions that affect quality attribute interactions. The ATAM is a spiral model of design: one of postulating candidate architectures followed by analysis and risk mitigation, leading to refined architectures.

/pdf/the-architecture-tradeoff-analysis-method-29qfwacjhz.pdf

Rick Kazman

Papers

Software Architecture in Practice

Evaluating Software Architectures: Methods and Case Studies

Software Architecture in Practice: Addison-Wesley

ATAM: Method for Architecture Evaluation

The architecture tradeoff analysis method