基于用例的面向方面软件开发（英文影印版）
[特价中]
点击看大图基本信息
- 作者： （美）Ivar Jacobson,Pan-Wei Ng [作译者介绍]
- 丛书名： 经典原版书库
- 出版社：机械工业出版社
- ISBN：7111177711
- 上架时间：2005-12-5
- 出版日期：2006 年1月
- 开本：16开
- 页码：418
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 面向对象
内容简介回到顶部↑
书籍
计算机书籍
aspect-oriented programming (aop) is a revolutionary new way to think about software engineering.aop was introduced to address crosscutting concerns such as security, logging, persistence, debugging, tracing, distribution, performance monitoring, and exception handling in a more effective manner. unlike conventional development techniques, which scatter the implementation of each concern into multiple classes, aspect-oriented programming localizes them..
aspect-oriented software development (aosd) uses this approach to create a better modularity for functional and nonfunctional requirements, platform specifics, and more, allowing you to build more understandable systems that are easier to configure and extend to meet the evolving needs of stakeholders.in this highly anticipated new book, ivar jacobson and pan-wei ng demonstrate how to apply use cases--a mature and systematic approach to focusing on stakeholder concerns--and aspect-orientation in building robust and extensible systems. throughout the book, the authors employ a single, real-world example of a hotel management information system to make the described theories and practices concrete and understandable.
the authors show how to identify, design, implement, test, and refactor use-case modules, as well as extend them. they also demonstrate how to design use-case modules with the unified modeling language (uml)--emphasizing enhancements made in uml 2.0--and how to achieve use-case modularity using aspect technologies, notably aspectj...
key topics include
·making the case for use cases and aspects
·capturing and modeling concerns with use cases
·keeping concerns separate with use-case modules
·modeling use-cases slices and aspects using the newest extensions to the uml notation
·applying use cases and aspects in projects...
whatever your level of experience with aspect-oriented programming, aspect-oriented software development with use cases will teach you how to develop better software by embracing the paradigm shift to aosd.
计算机书籍
aspect-oriented programming (aop) is a revolutionary new way to think about software engineering.aop was introduced to address crosscutting concerns such as security, logging, persistence, debugging, tracing, distribution, performance monitoring, and exception handling in a more effective manner. unlike conventional development techniques, which scatter the implementation of each concern into multiple classes, aspect-oriented programming localizes them..
aspect-oriented software development (aosd) uses this approach to create a better modularity for functional and nonfunctional requirements, platform specifics, and more, allowing you to build more understandable systems that are easier to configure and extend to meet the evolving needs of stakeholders.in this highly anticipated new book, ivar jacobson and pan-wei ng demonstrate how to apply use cases--a mature and systematic approach to focusing on stakeholder concerns--and aspect-orientation in building robust and extensible systems. throughout the book, the authors employ a single, real-world example of a hotel management information system to make the described theories and practices concrete and understandable.
the authors show how to identify, design, implement, test, and refactor use-case modules, as well as extend them. they also demonstrate how to design use-case modules with the unified modeling language (uml)--emphasizing enhancements made in uml 2.0--and how to achieve use-case modularity using aspect technologies, notably aspectj...
key topics include
·making the case for use cases and aspects
·capturing and modeling concerns with use cases
·keeping concerns separate with use-case modules
·modeling use-cases slices and aspects using the newest extensions to the uml notation
·applying use cases and aspects in projects...
whatever your level of experience with aspect-oriented programming, aspect-oriented software development with use cases will teach you how to develop better software by embracing the paradigm shift to aosd.
作译者回到顶部↑
本书提供作译者介绍
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 Modeliog 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.. << 查看详细
目录回到顶部↑
preface vii
acknowledgments xxi.
part i the case for use cases and aspects
chapter 1 problem to attack
1.1 the use of components today
1.1.1 building a system with components
1.1.2 benefits of components
1.2 limitation of components
1.2.1 inability to keep peers separate
1.2.2 inability to keep extensions separate
1.3 approaching a solution
1.3.1 early support for extensions
1.3.2 support for extensions in uml
1.4 keeping concerns separate
chapter 2 attacking the problem with aspects
2.1 approaching a solution with aspects
2.2 keeping peers separate with aspects
2.3 keeping extensions separate with aspects
2.4 need for methodological guidance
chapter 3 today with use cases
acknowledgments xxi.
part i the case for use cases and aspects
chapter 1 problem to attack
1.1 the use of components today
1.1.1 building a system with components
1.1.2 benefits of components
1.2 limitation of components
1.2.1 inability to keep peers separate
1.2.2 inability to keep extensions separate
1.3 approaching a solution
1.3.1 early support for extensions
1.3.2 support for extensions in uml
1.4 keeping concerns separate
chapter 2 attacking the problem with aspects
2.1 approaching a solution with aspects
2.2 keeping peers separate with aspects
2.3 keeping extensions separate with aspects
2.4 need for methodological guidance
chapter 3 today with use cases
前言回到顶部↑
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 tasks-some 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 code-your
classes, your operations, your procedures—must perform many functions, which may lead to spaghetti code, an indication of poor design. So,you need to improve design—improve modularity and provide better separation 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 as crosscutting concerns because you find these code fragments in many operations and classes in your system--they cut across operations 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 into aspects. 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 aspectsfrom 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 kinds---better modularity for functional require ments, nonfunctional requirements, platform specifiC, si and so on--and 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 object orientation, component-based development, design patterns, object-oriented frameworks such as J2EE and .NET, and more. AOSD does not compete with existing techniques but is built on top of them.
AOSD with Use Cases
How do you conduct AOSD? How do you identify aspects? When do you use classes as opposed to aspects? How do you specify aspects? You need a sound and systematic approach to help you conduct AOSD. The development community is crying out for this kind of systematic approach to software development.
In fact, there is such a systematic approach--and a mature one too. It is called the use-case-driven approach. It provides a sound method for developing applications by focusing on realizing stakeholder concernsand delivering value to the user.
It is well known that aspect orientation helps modularize crosscutting concerns during implementation, but there is a need to modularize crosscutting concerns much earlier, even during requirements. Use-cases are an excellent technique for this purpose. Use-cases are crosscutting concerns, since the realization of use cases touches several classes. In fact, you can model most crosscutting concerns with use-cases, and we demonstrate use-case modeling in the book...
The underlying concept in aspect orientation is similar to the concept of use-case-driven development. This means that you get a seamless transition from expressing requirements of stakeholder concerns with use-casesto implementing them with aspects.
Briefly, you conduct AOSD with use-cases as follows: You model crosscutting concerns with use-cases. You design use-cases in terms of overlays on top of classes--overlays called use-case slices and use-case modules. You use aspect technology to compose use-cases slices and use-case modules to form the complete model for the system.
We use a home-construction analogy to explain the approach further. Let's say you have a new house, butit is just an empty house with no fixtures--no lights, no phone lines, no wiring, no gas, and no Internet! Each missing fixture or service is a distinct concern, evidenced by the fact that you need to call different specialists to install each fixture or service. The fixtures and services are crosscutting concerns--they cut across different rooms(i.e., objects). They are analogous to use-cases. To determine how he or she will go about his or her job, each specialist must design a plan, often in terms of a diagram based on the floor plan. The floor plan shows where the rooms and the walls are. The electrician makes a photocopy of the floor plan and draws how she intends to install electric wiring; the plumber sketches out how he plans to run water pipes around the house;and so on. Each specialist can work separately, but all of them base their work on the same floor plan. The overall work to be done is the sum of all these diagrams.
If each specialist were to draw his or her diagram on a transparency, the transparencies could be merged by overlaying them on a projector. These overlays are analogous to what we call use-case slices and use-case modules. As long as the overlays are based on the same dimensions of the floor plan, you can get a perfect image on the screen showing all the work to be done. If there is a need to change the laying of Internet lines, you just rework the overlay that describes that plan and update the merged model.When you project it with the other overlays, you get the updated image of the house. You can easily stack more overlays on the picture or swap in and out overlays. You get a coherent image provided that the dimensions correspond to each other. This represents the architectural work involved.Systems developed using use-case slices and use-case modules have a
clear separation of crosscutting concerns. You can evolve them and extend them. It is easier to make each slice reusable. You can automatically generate certain slices because they do not interfere with other slices. You get better maintainability, better extensibility, and greater productivity with this approach.
The development community can gain even more from conducting AOSD with use-cases. We believe that the adoption of aspect orientation will accelerate significantly by basing it on the use-case-driven approach because this approach has already been widely accepted as a means to drive system development, testing, and delivery. Much literature on the use-case-driven approach is readily available for the development community. A good number of professionals, even companies; exist primarily to instruct and promote its use. Project teams both large and small have been successful in adopting the approach. Thus, it is attractive and even natural to base AOSD on the use-case-driven approach.
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 tasks-some 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 code-your
classes, your operations, your procedures—must perform many functions, which may lead to spaghetti code, an indication of poor design. So,you need to improve design—improve modularity and provide better separation 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 as crosscutting concerns because you find these code fragments in many operations and classes in your system--they cut across operations 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 into aspects. 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 aspectsfrom 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 kinds---better modularity for functional require ments, nonfunctional requirements, platform specifiC, si and so on--and 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 object orientation, component-based development, design patterns, object-oriented frameworks such as J2EE and .NET, and more. AOSD does not compete with existing techniques but is built on top of them.
AOSD with Use Cases
How do you conduct AOSD? How do you identify aspects? When do you use classes as opposed to aspects? How do you specify aspects? You need a sound and systematic approach to help you conduct AOSD. The development community is crying out for this kind of systematic approach to software development.
In fact, there is such a systematic approach--and a mature one too. It is called the use-case-driven approach. It provides a sound method for developing applications by focusing on realizing stakeholder concernsand delivering value to the user.
It is well known that aspect orientation helps modularize crosscutting concerns during implementation, but there is a need to modularize crosscutting concerns much earlier, even during requirements. Use-cases are an excellent technique for this purpose. Use-cases are crosscutting concerns, since the realization of use cases touches several classes. In fact, you can model most crosscutting concerns with use-cases, and we demonstrate use-case modeling in the book...
The underlying concept in aspect orientation is similar to the concept of use-case-driven development. This means that you get a seamless transition from expressing requirements of stakeholder concerns with use-casesto implementing them with aspects.
Briefly, you conduct AOSD with use-cases as follows: You model crosscutting concerns with use-cases. You design use-cases in terms of overlays on top of classes--overlays called use-case slices and use-case modules. You use aspect technology to compose use-cases slices and use-case modules to form the complete model for the system.
We use a home-construction analogy to explain the approach further. Let's say you have a new house, butit is just an empty house with no fixtures--no lights, no phone lines, no wiring, no gas, and no Internet! Each missing fixture or service is a distinct concern, evidenced by the fact that you need to call different specialists to install each fixture or service. The fixtures and services are crosscutting concerns--they cut across different rooms(i.e., objects). They are analogous to use-cases. To determine how he or she will go about his or her job, each specialist must design a plan, often in terms of a diagram based on the floor plan. The floor plan shows where the rooms and the walls are. The electrician makes a photocopy of the floor plan and draws how she intends to install electric wiring; the plumber sketches out how he plans to run water pipes around the house;and so on. Each specialist can work separately, but all of them base their work on the same floor plan. The overall work to be done is the sum of all these diagrams.
If each specialist were to draw his or her diagram on a transparency, the transparencies could be merged by overlaying them on a projector. These overlays are analogous to what we call use-case slices and use-case modules. As long as the overlays are based on the same dimensions of the floor plan, you can get a perfect image on the screen showing all the work to be done. If there is a need to change the laying of Internet lines, you just rework the overlay that describes that plan and update the merged model.When you project it with the other overlays, you get the updated image of the house. You can easily stack more overlays on the picture or swap in and out overlays. You get a coherent image provided that the dimensions correspond to each other. This represents the architectural work involved.Systems developed using use-case slices and use-case modules have a
clear separation of crosscutting concerns. You can evolve them and extend them. It is easier to make each slice reusable. You can automatically generate certain slices because they do not interfere with other slices. You get better maintainability, better extensibility, and greater productivity with this approach.
The development community can gain even more from conducting AOSD with use-cases. We believe that the adoption of aspect orientation will accelerate significantly by basing it on the use-case-driven approach because this approach has already been widely accepted as a means to drive system development, testing, and delivery. Much literature on the use-case-driven approach is readily available for the development community. A good number of professionals, even companies; exist primarily to instruct and promote its use. Project teams both large and small have been successful in adopting the approach. Thus, it is attractive and even natural to base AOSD on the use-case-driven approach.
加载中...
