|
|
1
3
似乎没有其他人对这件事有意见,所以我会的。 我必须首先告诉你一些不受欢迎的消息——做一个好的分析师就像做一个好的开发人员——不是每个人都能做到。我认识很多人,他们擅长编写复杂的Windows应用程序代码,而这些代码在发现用户需要什么、缩小需求范围以及提出设计方案方面毫无用处。所以,如果你觉得很难,不要难过。 这就引出了第二点——你不能把分析和分析分开 设计,特别是对于现代OO系统,两者是连续统一体的一部分。所以你必须为此做好准备。 我的第三点是不要太拘泥于UML。这是一个向其他人解释你的想法的好工具(前提是他们也知道UML),但在实际设计中却是一个相当糟糕的工具。例如,用例可以很容易地维护在一个文本文件中,而不是UML使用的那些粘人图。我用简单的方框图代替UML来显示对象、组件和关系,通常在纸上和白板上绘制。 最后一点是A&D不是一个人的活动。找别人 参与其中,你可以从中获得灵感。如果你能找一位经验丰富的分析师/设计师帮你一天左右,那就更好了。 希望这是有用的,不要太消极! |
|
2
2
为了缓和尼尔的坏消息,我想说你问自己这些问题可能是个好迹象。 如果你与你的客户(和你的管理层)有着良好的关系,也许值得考虑一些敏捷方法的变体。这可能有助于减轻试图看得太远的风险。 记住 “只有当你满足客户的要求时,客户才会意识到他想要什么” :) 分析时 当你分析客户的需求时,以及当你为新系统在他看来是什么样的想法时,尽量避免像开发人员那样思考。技术“考虑因素”(“这将更容易编码”,“我可以使用新技术X”)确实会妨碍设计有用的东西。 不要惊慌。将工作分成可管理的部分。不是每个人都会同意这一点,但如果你发现自己有一块无法管理的区域,你就无法恢复理智, just start coding
|
|
3
1
你不应该用没有人能理解的微小细节使你的图表过载。至于我,我避免使用像Rational Rose和类似的极客丑陋的图表,我自己用图形工具绘制它们,否则你可以使用一些有趣的东西,比如 yUML.me (一个免费的在线UML工具),你的用户应该喜欢它。 我甚至在YUMLSL之上为业务分析师开发了一种用户友好的语言,这样用户就可以直接用简单的英语表达,并将其翻译成类似UML的语言
源代码可在以下位置获得: http://reboltutorial.com/blog/easy-yuml-dialect-for-mere-mortals/ 关键是保持事情简单。许多人过度复杂的图表,这就是为什么UML有一些坏名声。 |
|
|
4
1
我发表了几篇文章,目的是让新设计师有一个良好的开端。所有帖子都可以在这里找到: http://aviadezra.blogspot.com/search/label/UML 在大多数情况下,您从使用部署图对系统的物理体系结构进行建模开始,“系统物理体系结构建模”一文从简单使用部署图开始,在部署图中,我们仅显示节点及其相互关系,并通过包含在节点中运行的组件和应用程序来完成此图。 在下一阶段中,我们使用组件图描述系统的逻辑架构,“系统逻辑架构建模”一文从显示逻辑组件的简单布线开始,并通过包括组件公开/需要的接口以及说明它们连接在一起的方式来完成该图。 如果您正在设计并行应用程序,首先使用活动图显示并行工作流,然后使用序列图和类图完成该图,“建模并行应用程序”一文将引导您完成整个过程。 进入详细设计阶段时,您使用类图以不同方式相互关联的对象(类)类型来描述问题域,“关联、聚合和组合”一文解释了类图中使用的关联连接器的3种变体。 接下来,使用序列图显示不同对象如何相互作用;序列图的一个常见问题是如何显示条件和迭代,POST“交互片段”解释了如何使用交互片段操作符(ALT、OPT、PAR、循环和区域)。 |