Aspect-oriented Software Development With Use Cases

by ;
Edition: 1st
Format: Paperback
Pub. Date: 2004-12-30
Publisher(s): Addison-Wesley Professional
  • Free Shipping Icon

    This Item Qualifies for Free Shipping!*

    *Excludes marketplace orders.

List Price: $62.99

Rent Book

Select for Price
There was a problem. Please try again later.

New Book

We're Sorry
Sold Out

Used Book

We're Sorry
Sold Out

eBook

We're Sorry
Not Available

How Marketplace Works:

  • This item is offered by an independent seller and not shipped from our warehouse
  • Item details like edition and cover design may differ from our description; see seller's comments before ordering.
  • Sellers much confirm and ship within two business days; otherwise, the order will be cancelled and refunded.
  • Marketplace purchases cannot be returned to eCampus.com. Contact the seller directly for inquiries; if no response within two days, contact customer service.
  • Additional shipping costs apply to Marketplace purchases. Review shipping costs at checkout.

Summary

Learn how to apply the proven concept of use cases within the rising paradigm of aspect orientation to build robust and extensible software.

Author Biography

Ivar Jacobson, Ph.D., is “the father” of many technologies, including components and component architecture, use cases, modern business engineering, and the Rational Unified Process. He was one of the three amigos who originally developed the Unified Modeling Language. He is the principal author of five best-selling books on these methods and technologies, in addition to being the coauthor of the two leading books on the Unified Modeling Language. Ivar is a founder of Jaczone AB, where he and his daughter and cofounder, Agneta Jacobson, are developing a ground-breaking new product that includes intelligent agents to support software development. Ivar also founded Ivar Jacobson Consulting (IJC) with the goal of promoting good software development practices throughout teams worldwide.

Pan-Wei Ng, Ph.D., plays multiple roles within Ivar Jacobson Consulting (IJC). Pan-Wei defines and develops materials for best practices in architecture, use cases, iterative development, aspects, and the like. This work is often done alongside practitioners to ensure that the best practices developed are both relevant and practical. Pan-Wei also actively works with customer accounts to enable companies and project teams to adopt these best practices quickly and safely.



Table of Contents

Preface xvii
Acknowledgments xxxi
PART I The Case for Use Cases and Aspects 1(48)
Chapter 1 Problem to Attack
3(14)
1.1 The Use of Components Today
3(3)
1.1.1 Building a System with Components
4(2)
1.1.2 Benefits of Components
6(1)
1.2 Limitation of Components
6(5)
1.2.1 Inability to Keep Peers Separate
8(1)
1.2.2 Inability to Keep Extensions Separate
9(2)
1.3 Approaching a Solution
11(5)
1.3.1 Early Support for Extensions
12(3)
1.3.2 Support for Extensions in UML
15(1)
1.4 Keeping Concerns Separate
16(1)
Chapter 2 Attacking the Problem with Aspects
17(12)
2.1 Approaching a Solution with Aspects
17(2)
2.2 Keeping Peers Separate with Aspects
19(2)
2.3 Keeping Extensions Separate with Aspects
21(5)
2.4 Need for Methodological Guidance
26(3)
Chapter 3 Today with Use Cases
29(8)
3.1 Use Cases in Brief
29(3)
3.2 Use-Case-Driven Development
32(2)
3.3 Roles and Benefits of Use Cases
34(1)
3.4 Gaps in the Use-Case Technique
34(1)
3.5 Bridging the Gaps with Aspects
35(2)
Chapter 4 Tomorrow with Use-Case Modules
37(12)
4.1 Building Systems in Overlays with Use-Case Slices
38(2)
4.2 Keeping Peer Use Cases Separate
40(2)
4.3 Keeping Extension Use Cases Separate
42(3)
4.4 Developing with Use-Case Modules
45(4)
PART II Modeling and Capturing Concerns with Use Cases 49(54)
Chapter 5 Modeling Concerns with Use Cases
51(10)
5.1 Use-Case Modeling
51(2)
5.2 Use-Case Instances and Flows of Events
53(1)
5.3 Describing Use Cases
54(3)
5.4 Visualizing Use-Case Flows
57(3)
5.5 Summary and Highlights
60(1)
Chapter 6 Structuring Use Cases
61(20)
6.1 Use-Case Relationships
61(2)
6.2 Use-Case Extend Relationship
63(7)
6.3 Use-Case Include Relationship
70(3)
6.4 Use-Case Generalization
73(4)
6.5 Utility Use Cases
77(2)
6.6 Summary and Highlights
79(2)
Chapter 7 Capturing Concerns with Use Cases
81(22)
7.1 Understanding Stakeholder Concerns
81(5)
7.1.1 Understanding the Problem Domain
82(1)
7.1.2 Eliciting System Features
83(1)
7.1.3 Dealing with Functional and Nonfunctional Requirements
84(2)
7.2 Capturing Application Use Cases
86(7)
7.2.1 Identifying Use-Case Variability
87(1)
7.2.2 Handling Use-Case Variability
88(3)
7.2.3 Dealing with Extension Use Cases
91(2)
7.3 Capturing Infrastructure Use Cases
93(8)
7.3.1 The Perform Transaction Use Case
94(2)
7.3.2 Structuring Infrastructure Use Cases
96(2)
7.3.3 Describing Infrastructure Use Cases
98(2)
7.3.4 Dealing with Systemwide Concerns
100(1)
7.4 Summary and Highlights
101(2)
PART III Keeping Concerns Separate with Use-Case Modules 103(60)
Chapter 8 Keeping Peer Use-Case Realizations Separate with Aspects
105(22)
8.1 Realizing Peer Use Cases
106(5)
8.1.1 Collaborations
106(2)
8.1.2 Realizing a Use Case
108(2)
8.1.3 Overlap between Peer Use-Case Realizations
110(1)
8.2 Keeping Use-Case Specifics Separate
111(7)
8.2.1 Composing Use-Case-Specific Classes
113(2)
8.2.2 Composing Use-Case-Specific Class Extensions
115(2)
8.2.3 Collaborations in Use-Case Slices
117(1)
8.3 Dealing with Overlap
118(7)
8.3.1 Included Use-Case Slice
119(2)
8.3.2 Generalized Use-Case Slice
121(2)
8.3.3 Non-Use-Case-Specific Slice
123(2)
8.4 Summary and Highlights
125(2)
Chapter 9 Keeping Extensions Separate with Pointcuts
127(18)
9.1 Realizing Extension Use Cases
128(1)
9.2 Keeping Modularity of Extension Use-Case Realizations
129(6)
9.2.1 Operation Extensions
130(3)
9.2.2 Pointcuts
133(2)
9.3 Parameterizing Pointcuts
135(4)
9.3.1 Identifying Parameters
136(1)
9.3.2 Defining Parameters
137(1)
9.3.3 Parameterizing Pointcuts in AOP
138(1)
9.4 Generalizing Extension Use-Case Realizations
139(3)
9.5 Templating Use-Case Slices
142(2)
9.6 Summary and Highlights
144(1)
Chapter 10 Building Systems with Use-Case Modules
145(18)
10.1 A System Comprises Models
146(1)
10.2 Use-Case Model
147(1)
10.3 Analysis Model
148(4)
10.3.1 Language of Analysis
149(1)
10.3.2 Conducting Analysis
150(2)
10.4 Design and Implementation Models
152(2)
10.4.1 Language of Design and Implementation
152(2)
10.4.2 Conducting Design and Implementation
154(1)
10.5 Use-Case Modules Cut Across Models
154(5)
10.5.1 Preserving the Structure of the Use-Case Model
155(2)
10.5.2 A Use-Case Module Contains Use-Case Slices
157(1)
10.5.3 Use-Case Module Relationships
158(1)
10.6 Composing and Configuring Use-Case Modules
159(2)
10.7 Summary and Highlights
161(2)
PART IV Establishing an Architecture Based on Use Cases and Aspects 163(192)
Chapter 11 Road to a Resilient Architecture
167(20)
11.1 What Is Architecture?
168(1)
11.2 What Is a Good Architecture?
168(2)
11.3 Steps to Establish an Architecture Baseline
170(4)
11.4 Begin with a Platform-Independent Structure
174(5)
11.4.1 Element Structure
174(3)
11.4.2 Use-Case Structure
177(2)
11.5 Overlay Platform Specifics on Top
179(5)
11.5.1 Choosing the Platform
179(2)
11.5.2 Keeping Platform Specifics Separate
181(3)
11.6 Summary and Highlights
184(3)
Chapter 12 Separating Functional Requirements with Application Peer Use Cases
187(26)
12.1 Analyzing Application Use Cases
188(7)
12.1.1 Identifying Classes
189(1)
12.1.2 Allocating Use-Case Behavior to Classes
190(5)
12.2 Keeping Application Use Cases Separate
195(4)
12.2.1 Element Structure
195(1)
12.2.2 Use-Case Structure
196(3)
12.3 Designing Application Use Cases
199(6)
12.3.1 Identifying Design Elements
200(3)
12.3.2 Identifying Components and Interfaces
203(2)
12.4 Refining Design Elements
205(6)
12.4.1 Keeping Class Extensions Separate
205(2)
12.4.2 Keeping Operation Extensions Separate
207(2)
12.4.3 Keeping State Transitions Separate
209(2)
12.5 Summary and Highlights
211(2)
Chapter 13 Separating Functional Requirements with Application-Extension Use Cases
213(26)
13.1 Analyzing Application-Extension Use Cases
214(6)
13.1.1 Identifying Classes
215(1)
13.1.2 Identifying Pointcuts
216(2)
13.1.3 Allocating Use-Case Behavior to Classes
218(2)
13.2 Keeping Application-Extension Use Cases Separate
220(4)
13.2.1 Structuring Alternate Flows
221(1)
13.2.2 Keeping Alternate Flows Separate
222(2)
13.3 Designing Application-Extension Use Cases
224(6)
13.3.1 Designing Operation Extensions
224(1)
13.3.2 Identifying Component Interfaces from Use-Case Extensions
225(1)
13.3.3 Dealing with Multiple Extensions to a Use Case
226(3)
13.3.4 Extending Multiple Use Cases
229(1)
13.4 Dealing with Changes in the Base
230(6)
13.4.1 Applying Reflection
232(1)
13.4.2 Applying Design Patterns
232(3)
13.4.3 Applying Adaptive Programming
235(1)
13.5 Summary and Highlights
236(3)
Chapter 14 Separating Nonfunctional Requirements with Infrastructure Use Cases
239(24)
14.1 Analyzing an Infrastructure Use Case
240(7)
14.1.1 Identifying Classes
241(1)
14.1.2 Identifying Pointcuts
242(3)
14.1.3 Allocating Use-Case Behavior to Classes
245(2)
14.2 Keeping Infrastructure Use Cases Separate
247(3)
14.3 Designing Infrastructure Use Cases
250(6)
14.3.1 Applying the Infrastructure Use-Case Slice with Aspects
251(1)
14.3.2 Applying the Infrastructure Use-Case Slice with Filters
252(3)
14.3.3 Identifying Components in the Infrastructure Layer
255(1)
14.4 Dealing with Multiple Infrastructure Use Cases
256(5)
14.5 Summary and Highlights
261(2)
Chapter 15 Separating Platform Specifics with Platform-Specific Use-Case Slices
263(38)
15.1 Keeping Platform Specifics Separate
264(5)
15.1.1 Three-Tier Systems
264(2)
15.1.2 Tier Packages
266(2)
15.1.3 Modeling Tiers with Infrastructure Use Cases
268(1)
15.2 Overlaying User Interfaces
269(7)
15.2.1 Minimal Use-Case Design without Presentation Specifics
270(1)
15.2.2 A Web Presentation Mechanism in J2EE
271(2)
15.2.3 Designing the Presentation Mechanism
273(2)
15.2.4 Applying the Presentation Mechanism
275(1)
15.3 Overlaying Distribution
276(14)
15.3.1 Minimal Use-Case Design without Distribution
277(1)
15.3.2 An EJB Distribution Mechanism
278(3)
15.3.3 Designing the Distribution Mechanism
281(5)
15.3.4 Applying the Distribution Mechanism
286(4)
15.4 Overlaying Persistency
290(8)
15.4.1 Minimal Use-Case Design without Persistence
291(1)
15.4.2 A Relational Persistency Mechanism in J2EE
292(1)
15.4.3 Designing Persistency Mechanism
293(4)
15.4.4 Applying the Persistency Mechanism
297(1)
15.5 Preserving the Use-Case Structure
298(1)
15.6 Summary and Highlights
299(2)
Chapter 16 Separating Tests with Use-Case Test Slices
301(18)
16.1 Test-First Approach
301(2)
16.2 Identifying Test Cases from Use Cases
303(5)
16.2.1 Identifying Test Cases from Use-Case Flows
304(1)
16.2.2 Identifying Test Cases from Use-Case Variables
305(1)
16.2.3 Identifying Test Cases across Multiple Application Use Cases
306(1)
16.2.4 Identifying Test Cases for the Infrastructure and the Platform Specifics
306(1)
16.2.5 Identifying Performance Test Cases
307(1)
16.3 Identifying Elements to Be Tested
308(2)
16.4 Designing and Implementing Tests
310(7)
16.4.1 Designing a Test Infrastructure
312(4)
16.4.2 Designing a Test Case
316(1)
16.5 Summary and Highlights
317(2)
Chapter 17 Evaluating the Architecture
319(20)
17.1 Putting It Together
319(5)
17.2 Evaluating Separation of Concerns
324(8)
17.2.1 Evaluating Design Elements
325(1)
17.2.2 Evaluating Design Packages
325(2)
17.2.3 Evaluating Use-Case Structures
327(2)
17.2.4 Automating the Evaluation
329(1)
17.2.5 Enforcing the Separation of Concerns
330(2)
17.3 Evaluating and Achieving Systemwide Concerns
332(4)
17.3.1 Evaluating and Achieving Maintainability
332(1)
17.3.2 Evaluating and Achieving Extensibility
332(1)
17.3.3 Evaluating and Achieving Portability
333(1)
17.3.4 Evaluating and Achieving Reusability
334(1)
17.3.5 Evaluating and Achieving Performance and Reliability
334(2)
17.4 Summary and Highlights
336(3)
Chapter 18 Describing the Architecture
339(16)
18.1 Architecture Description Comprises Architectural Views
340(2)
18.2 Architectural View of the Use-Case Model
342(2)
18.3 Architectural View of the Analysis Model
344(3)
18.3.1 Architecturally Significant Analysis Elements
344(2)
18.3.2 Architecturally Significant Use-Case Analysis Slices
346(1)
18.4 Architectural View of the Design Model
347(5)
18.4.1 Architecturally Significant Deployment Elements
348(1)
18.4.2 Architecturally Significant Process Elements
348(1)
18.4.3 Architecturally Significant Design Elements
349(2)
18.4.4 Architecturally Significant Use-Case Design Slices
351(1)
18.5 Summary and Highlights
352(3)
PART V Applying Use Cases and Aspects in a Project 355(24)
Chapter 19 Running a Project
357(12)
19.1 Iterative Development
357(2)
19.1.1 Phases in a Project
358(1)
19.1.2 Activities in an Iteration
359(1)
19.2 Estimating Development Effort
359(4)
19.2.1 Estimation at the Beginning of a Project
360(2)
19.2.2 Refining the Estimates
362(1)
19.3 Planning and Controlling the Project
363(2)
19.3.1 Estimating Project Delays
363(1)
19.3.2 Keeping the Project on Track
364(1)
19.4 Productivity Gains by Keeping Concerns Separate
365(2)
19.5 Summary and Highlights
367(2)
Chapter 20 Tailoring the Approach
369(6)
20.1 Achieving the Right Balance
369(1)
20.2 Selecting Disciplines to Apply
370(3)
20.3 Adopting at Different Phases of a Project
373(1)
20.4 Summary and Highlights
374(1)
Chapter 21 Aspects and Beyond
375(4)
21.1 Building a System in Extensions
375(1)
21.2 Balancing Best Practices
376(1)
21.3 The Road Ahead
377(2)
Appendix A Modeling Aspects and Use-Case Slices in UML 379(8)
Appendix B Notation Guide 387(8)
References 395(4)
Glossary 399(8)
Index 407

Excerpts

What Is Aspect-Oriented Programming?That you have picked up this book tells us that you are a member of the software development community: a tester, a developer, a project leader, a project manager, an architect, an analyst, or a member involved in one of the many other aspects of developing. We also know that you are someone who wants to improve the way you develop software. You want your system to be more maintainable, more extensible, more reusable, and if you are a project leader, you want your team to be more productive. You know that these goals are not always easy to achieve.Why is software development so difficult? One reason is that there are many things to watch out for. On the human side, you have to watch out for time, budget, resources, skills, and so forth. Frequently, as a team member, you have many taskssome of them beyond what you are paid for. You report to two different people and each expects 100 percent from you, so you must give 200 percent to your work. As the developer, you must understand the application, the domain, and the idiosyncrasies of the platform. When you design the system, you need to deal with and balance many difficult concerns: how the system meets its intended functionality, how it achieves performance and reliability, how it deals with platform specifics, and so forth. You may find that your codeyour classes, your operations, your proceduresmust perform many functions, which may lead to spaghetti code, an indication of poor design. So, you need to improve designimprove modularity and provide betterseparation of concerns.Just as each team member must be clearly focused on his or her work, each component, each class, each operation must be focused on what is its specific purpose.But there is a limit to what you can do with existing techniques. No matter how far you go, you find that many parts of your system have code fragments that have to do with logging, authorization, persistence, debugging, tracing, distribution, exception handling, and other such tasks. Sometimes, a sizeable portion of an operation or class has nothing to do with what it is supposed to do. Aspect-oriented programming (AOP) refers to such redundancy ascrosscutting concernsbecause you find these code fragments in many operations and classes in your systemtheycut acrossoperations and classes. Crosscutting concerns are not limited to the technical concerns such as authorization and persistence. They include system and application functionality, and you find that a change in functionality often results in changes in many classes too.AOP gives you the means to separate code that implements crosscutting concerns and modularize it intoaspects.Aspect-orientation provides the mechanism to compose crosscutting behaviors into the desired operations and classes during compile time and even during execution. The source code for your operations and classes can be free of crosscutting concerns and therefore easier to understand and maintain. What Is Aspect-Oriented Software Development?In order to progress beyond AOP, you need a holistic approach to developing software systems with aspects from requirements, to analysis and design, to implementation and test. This is aspect-oriented software development (AOSD).AOSD is about better modularity for the entire system, encompassing concerns of many different kindsbetter modularity for functional requirements, nonfunctional requirements, platform specifics, and so onand keeping them separate from each other. Keeping all concerns separate allows you to construct systems that have a more understandable structure and are easily configured and extended to meet the evolving needs of stakeholders.AOSD is not just AOP. It encompasses a whole range of techniques to help you achieve better modularity. These techniques include objec

An electronic version of this book is available through VitalSource.

This book is viewable on PC, Mac, iPhone, iPad, iPod Touch, and most smartphones.

By purchasing, you will be able to view this book online, as well as download it, for the chosen number of days.

Digital License

You are licensing a digital product for a set duration. Durations are set forth in the product description, with "Lifetime" typically meaning five (5) years of online access and permanent download to a supported device. All licenses are non-transferable.

More details can be found here.

A downloadable version of this book is available through the eCampus Reader or compatible Adobe readers.

Applications are available on iOS, Android, PC, Mac, and Windows Mobile platforms.

Please view the compatibility matrix prior to purchase.