没有合适的资源?快使用搜索试试~ 我知道了~
首页The Object Primer - Introduction to Techniques for Agile Modeling.pdf
资源详情
资源评论
资源推荐
Copyright 2001Ronin International
Visit http://www.ronin-intl.com for more development white papers
The Object Primer:
Introduction to Techniques for Agile Modeling
A Ronin International White Paper
Scott W. Ambler
President, Ronin International
Portions of this white paper have been modified from Scott W. Ambler’s book,
The Object Primer 2
nd
Edition
This Version: June 22, 2001
Copyright 2001Ronin International
Visit http://www.ronin-intl.com for more development white papers
Table Of Contents
1. YOU HAVE MULTIPLE MODELS IN YOUR DEVELOPMENT TOOLKIT................................. 2
2. POTENTIAL TECHNIQUES FOR AGILE MODELING ................................................................... 3
2.1 ACTIVITY DIAGRAM (UML) ................................................................................................................... 3
2.2 BUSINESS RULES...................................................................................................................................... 4
2.3 CHANGE CASES ....................................................................................................................................... 5
2.4 CLASS MODEL (UML)............................................................................................................................ 6
2.5 CLASS RESPONSIBILITY COLLABORATOR (CRC) CARDS.......................................................................10
2.6 COLLABORATION DIAGRAM (UML).....................................................................................................11
2.7 COMPONENT DIAGRAM (UML)............................................................................................................13
2.8 CONSTRAINTS .......................................................................................................................................15
2.9 DATA/PERSISTENCE MODEL..................................................................................................................16
2.10 DEPLOYMENT DIAGRAM (UML).......................................................................................................18
2.11 ESSENTIAL USER INTERFACE PROTOTYPES ........................................................................................20
2.12 NON-FUNCTIONAL REQUIREMENTS...................................................................................................24
2.13 SEQUENCE DIAGRAMS (UML) ..........................................................................................................24
2.14 STATE CHART DIAGRAM (UML) .....................................................................................................27
2.15 USE CASE DIAGRAM (UML) ............................................................................................................29
2.15.1 Reuse in Use-Case Diagrams: <<extend>>, <<include>>, and Inheritance.................30
2.16 USE CASES: ESSENTIAL AND SYSTEM ...............................................................................................31
2.17 USER INTERFACE FLOW DIAGRAMS...................................................................................................35
2.18 USER INTERFACE PROTOTYPE............................................................................................................36
3. SUMMARY.................................................................................................................................................38
4. BLATANT ADVERTISING......................................................................................................................38
5. REFERENCES AND RECOMMENDED READING.........................................................................39
5.1 WEB-BASED RESOURCES.......................................................................................................................43
6. ABOUT THE AUTHOR............................................................................................................................44
7. INDEX.........................................................................................................................................................45
Copyright 2001 Ronin International
Visit http://www.ronin-intl.com for more development white papers
1
The purpose of this white paper is to present a brief overview of possible modeling techniques
1
for
object-oriented and component-based development, techniques that you could apply as an agile modeler.
Although you will not become an expert at any of these techniques by reading this paper, my hope is that
you will at least gain an understanding of what techniques you have available to you and how they fit
together.
There are several important messages that you want to take away from this paper:
1. The Unified Modeling Language (UML) is not yet sufficient for the development of business
software. As you see in Figure 1-1, modified from The Object Primer 2
nd
Edition,
http://www.ambysoft.com/theObjectPrimer.html, you have a wide range of models available to you.
Although this list is not complete, for example Robustness Diagrams or simple documentation tables
are not indicated, you see that there are many non-UML artifacts indicated.
2. You don’t need to apply all these modeling techniques on every project. I’m a firm believer that
you should have a wide range of techniques in your development toolkit so you can apply the right
technique to the job at hand. A good analogy is that of a home-repair job. Some home repairs require
me to use a hammer and screwdriver whereas others require a screwdriver, wrench, and soldering
iron. Different projects, different tool needs, therefore to be successful at home repairs I would
need a wide range of tools in my toolkit. Similarly, with software development projects sometimes I
need to apply CRC cards, user stories, and physical data models (persistence models) whereas on
other projects I need to apply user interface prototypes, UML class diagrams, and physical data
models. Different projects, different modeling needs.
3. You should take an agile approach to modeling. I am currently working on a methodology called
Agile Modeling (AM), the details for which are posted at www.agilemodeling.com. Simply put, AM is
a collection of values, principles, and practices for modeling software that can be applied on a
software development project in an effective and light-weight manner. AM recognizes that the values
of agile development, as promoted by the Agile Alliance, are key to your being effective. These
values are the promotion of individuals and interactions over processes and tools, working software
over comprehensive documentation, customer collaboration over contract negotiation, and
responding to change over following a plan. I invite you to get involved with the AM mailing list, visit
www.agilemodeling.com/feedback.htm for details.
1
The techniques are described in detail in The Object Primer 2/e (Ambler, 2001).
Copyright 2001 Ronin International
Visit http://www.ronin-intl.com for more development white papers
1
Figure 1-1. Suggested models for developing business software.
Essential
Use Case
Model
UML
Change Cases
Business Rules
Non-Functional
Requirements
CRC Model
Essential
User Interface
Prototype
Constraints
User Interface
Flow Diagram
Sequence
Diagram
UML
Class Model
(Analysis)
UML
Use Case
Model
UML
Activity
Diagram
UML
User Interface
Prototype
Class Model
(Design)
UML
Collaboration
Diagram
UML
State Chart
Diagram
UML
Persistence
Model
Source
Code
Component
Diagram
UML
Deployment
Diagram
UML
Copyright 2001 Ronin International
Visit http://www.ronin-intl.com for more development white papers
2
1. You Have Multiple Models in Your Development Toolkit
AM’s principle multiple models tells you that you have many modeling artifacts at your disposal – change
cases, user stories, business rules, UML activity diagrams, UML class diagrams, data models, and
business rules – to name a few. Figure 1-1 shows that you have a wide range of modeling options open to
you, a box represents an artifact that you may choose to create during a software project. Lines indicate
major “iteration” relationships between the artifacts (more on this in a bit). An interesting observation is
that you have far more than just the diagrams of the UML at your disposal, and when you consider the
number of non-UML models depicted in Figure 1-1 you quickly realize that the UML very likely isn’t yet
sufficient for business application development. By the way, Figure 1-1 isn’t complete itself – it doesn’t
include robustness diagrams, XP’s user stories, or structure charts – so please don’t assume that these are
the only models at your disposal.
Naturally, with a wide range of models at your disposal you will want to follow AM’s practice of apply
the right artifact(s) to be successful. For example, you wouldn’t develop a use case model to describe
your database schema, nor would you develop an data model to describe your user interface design.
Agile modelers will iterate to another artifact whenever they become stuck working on their current
model. This immediately gets the modeler moving again, improving their short-term productivity.
Hopefully the change of perspective will provide insight into whatever it was that got them stuck in the
first place because it gives them an opportunity to go at the same problem from another direction. But
what model to iterate to? That’s where the lines of Figure 1-1 come in, they provide a good indication
what other artifact you should consider jumping to. For example, if you’re working on an component
diagram and find you’re not making progress consider working on your deployment model to explore how
you will distribute the software components across your hardware, working on a design class model to
understand the inner workings of one or more components, or a collaboration diagram to explore how the
components will interoperate.
An interesting result of this practice is that you often find you are more productive following the AM
practice create several models simultaneously than you are by focusing on the creation of a single
artifact. Because each type of model has its strengths and weaknesses no single model is sufficient for
your modeling needs. For example, when you are exploring requirements you may need to develop some
essential use cases, some essential UI prototypes, and some business rules. By working on these artifacts
simultaneously you can quickly evolve your understanding of the requirements for your system, by
working them one at a time you can only evolve your understanding of a single aspect of the requirements.
The implication is that you should question the viability of modeling sessions that focus on a single
artifact, such as a use-case model, a class model, or a data model. The RUP certainly doesn’t prevent such
an approach, but the near-serial flow in the activity diagrams presented for each major modeling activity
doesn’t communicate this concept well.
Agile Modeling’s principles of iterate to another artifact and create several models simultaneously can
be tough ones for experienced modelers to adopt. Traditional modeling techniques often promoted a
single artifact approach, such as use-case modeling or user-interface prototyping sessions, and often even
modelers that focused, for example data modelers. These concepts were great in theory, focusing on a
single artifact at a time should have allowed the modelers to get it right quickly, but unfortunately practice
shows this not to be the case. A good way to ease into these practices is instead of use-case modeling
sessions instead run requirements modeling sessions where you work on use cases, Class Responsibility
Collaborator (CRC) cards, business rules, and user interface prototypes simultaneously. Similarly, hold
analysis sessions where you are use case modeling, sequence diagramming, user interface prototyping,
and class modeling may make sense, and design sessions where you are class modeling, state chart
modeling, data modeling, component modeling, user interface prototyping, and hopefully even developing
business code. Once you are comfortable with these practices the next step is to then merge your
剩余48页未读,继续阅读
guru4tw
- 粉丝: 0
- 资源: 2
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- 2022年中国足球球迷营销价值报告.pdf
- 房地产培训 -营销总每天在干嘛.pptx
- 黄色简约实用介绍_汇报PPT模板.pptx
- 嵌入式系统原理及应用:第三章 ARM编程简介_3.pdf
- 多媒体应用系统.pptx
- 黄灰配色简约设计精美大气商务汇报PPT模板.pptx
- 用matlab绘制差分方程Z变换-反变换-zplane-residuez-tf2zp-zp2tf-tf2sos-sos2tf-幅相频谱等等.docx
- 网络营销策略-网络营销团队的建立.docx
- 电子商务示范企业申请报告.doc
- 淡雅灰低面风背景完整框架创业商业计划书PPT模板.pptx
- 计算模型与算法技术:10-Iterative Improvement.ppt
- 计算模型与算法技术:9-Greedy Technique.ppt
- 计算模型与算法技术:6-Transform-and-Conquer.ppt
- 云服务安全风险分析研究.pdf
- 软件工程笔记(完整版).doc
- 电子商务网项目实例规划书.doc
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论1