将一个矩形设置进选项板中去可下载的 RP 文件已被作为例子包含到最终的产品中去。在此次向导中我们将会从头构造这个例子。添加一个矩形部件到设计区域，右键单击矩形的底边，选择弹出菜单中的选项 Select Shape > Top，改变矩形的形状。在工具栏中点击 Fill Color 按钮来设置默认颜色，确保透明度为 100%。
将内容转换成动态面板首先打开AxureAccordionControl.rp然后打开 Accordion Control 面板。当每个章节包含了许多部件，我们就会让其可以在动态面板中可以自由的隐藏显示。选择中一个章节的内容右键单击 Convert to Dynamic Panel。标记和隐藏内容面板标记动态面板为 Section1Content，Section2Content 和 Section3Content。
打开主菜单编辑 selected 样式首先打开AxureNavigationMenu.rp 然后从 Masters 页面打开 Header – Menu 。按下 Shift 键，逐个选中菜单部件的所有导航项。全选后，对它们右键单击选中 Interaction Styles... 选项，会弹出一个 Set Interaction Styles 对话框。
打开 Rollover Style 对话框首先打开AxureInteractiveButton.rp，然后打开 Interactive Button 页面。右键单击按钮，选中 Interaction Styles... 选项来打开 Interaction Styles 对话框。编辑 MouseOver Style在 MouseOver 选项板中选中 Underline。这会让按钮中的文字显示下划线。点击 OK 关闭对话框。
创建“条件”，以检查一个文本字段中的文本是否是空白，基于输入链接到相应的页面。 使用一个变量来存储文本框输入的文本。然后，使用变量设置部件在下一个页面上的文本上。添加一个文本框和一个 Button Shape1 添加文本框和按钮放置一个文本框部件和一个 Button Shape 部件到设计区域。2 命名文本框将文本框命名为 UserNameTextField。
点击启用一个 Button Shape，使用编辑器获取文本框焦点。然后，当页面加载的时，使用页面的 OnPageLoad 事件把焦点放到文本框上。添加一个 Button Shape 和两个文本框1 添加一个按钮，两个文本框拖放一个 Button Shape 部件和两个文本框部件到设计区域上。2 在按钮上编辑文本在 Button Shape 部件上编辑输入两个单词 Swap Focus。
添加，编辑和设计小部件。然后，把它们（部件）转换到一个 Master， 这样你就能集中管理和重用整个设计。添加一个 Button shape 和设置 MOUSEOVER 风格1 添加一个 Button shape拖动部件库窗口的 Button shape 并将它放在设计区域。2 打开交互风格对话框从“部件属性和风格”选项卡中的“属性”选项卡选择 MouseOver。
在 Sitemap 添加和组织页面，设置网格和辅助线，和设置单个页面或所有页面的样式。调整 Sitemap 里的页面1 拖动“页面 3”单击并轻轻拖动“页面 3”到“页面 2”的右上方一点。2 右键点击“页面 2”删除页面 2在 Sitemap 里选择“页面 2”然后右击选择“删除”3 添加一个新页面选择“页面 3”然后右击。选择“新建 > 子页面”。
添加和设计部件，创建基本链接，浏览器上预览，分享链接然后生成本地 HTML 。如果你在欢迎页面已经看过“准备开始”文档，请跳到页面操作章节。创建一个蓝色的按钮1 拖放一个按钮从部件窗口拖动一个按钮放到设计区域。2 编辑文本为“下一页”选中按钮部件，输入“下一页”即可编辑部件上的文本。
如果父类在执行构造函数的时候调用了一个可以被重写的方法，那么在该方法中可能会使用到未初始化的数据，从而导致运行时异常或者意外结束。
Pull requests 是 Bitbucket 提供的让开发者更方便地进行协作的功能，提供了友好的 Web 界面可以在提议的修改合并到正式项目之前对修改进行讨论。开发者向团队成员通知功能开发已经完成，Pull Requests 是最简单的用法。 开发者完成功能开发后，通过 Bitbucket 账号发起一个 Pull Request 。 这样让涉及这个功能的所有人知道要去做 Code Review 和合并到 master 分支。
在 Forking 工作流中，『官方』仓库的叫法只是一个约定，理解这点很重要。 从技术上来看，各个开发者仓库和正式仓库在 Git 看来没有任何区别。 事实上，让正式仓库之所以正式的唯一原因是它是项目维护者的公开仓库。
维护分支或说是热修复（ hotfix ）分支用于生成快速给产品发布版本（ production releases ）打补丁，这是唯一可以直接从 master 分支 fork 出来的分支。 修复完成，修改应该马上合并回 master 分支和 develop 分支（当前的发布分支），master 分支应该用新的版本号打好 Tag 。为 Bug 修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。
一旦 develop 分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从 develop 分支上 fork 一个发布分支。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做 Bug 修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了，发布分支合并到 master 分支并分配一个版本号打好 Tag 。
每个新功能位于一个自己的分支，这样可以 push到中央仓库以备份和协作。 但功能分支不是从 master 分支上拉出新分支，而是使用 develop 分支作为父分支。当新功能完成时，合并回 develop 分支。 新功能提交应该从不直接与 master 分支交互。注意，从各种含义和目的上来看，功能分支加上 develop 分支就是功能分支工作流的用法。但 Gitflow 工作流没有在这里止步。
相对使用仅有的一个 master 分支，Gitflow 工作流使用 2 个分支来记录项目的历史。master 分支存储了正式发布的历史，而develop 分支作为功能的集成分支。这样也方便 master 分支上的所有提交分配一个版本号。 剩下要说明的问题围绕着这 2 个分支的区别展开。
功能分支除了可以隔离功能的开发，也使得通过 讨论变更成为可能。一旦某个开发完成一个功能，不是立即合并到 master，而是 push 到中央仓库的功能分支上并发起一个 Pull Request 请求去合并修改到 master 。在修改成为主干代码前，这让其它的开发者有机会先去 Review 变更。Code Review 是 Pull Requests 的一个重要的收益，但 Pull Requests 目的是讨论代码一个通用方式。
功能分支工作流以集中式工作流为基础，不同的是为各个新功能分配一个专门的分支来开发。这样可以在把新功能集成到正式项目前，用 Pull Requests 的方式讨论变更。一旦你玩转了集中式工作流，在开发过程中可以很简单地加上功能分支，用来鼓励开发者之间协作和简化交流。功能分支工作流背后的核心思路是所有的功能开发应该在一个专门的分支，而不是在 master 分支上。
中央仓库代表了正式项目，所以提交历史应该被尊重且是稳定不变的。如果开发者本地的提交历史和中央仓库有分歧，Git 会拒绝 push 提交否则会覆盖已经在中央库的正式提交。 在开发者提交自己功能修改到中央库前，需要先 fetch 在中央库的新增提交，rebase 自己提交到中央库提交历史之上。 这样做的意思是在说，『 我要把自己的修改加到别人已经完成的修改上。
机器可读的 JSON 模式提供一个机器可读的模式可以精确的指定你的 API。使用 prmd 来管理你的模式，并确保它能被prmd verify 验证。人类可读的文档提供人类可读的文档让客户端开发人员可以理解你的 API。如果你用 prmd 创建了一个概要并且按上述要求描述，你可以为所有节点很容易的使用prmd doc生成 Markdown文档。
关注时代Java
