如何设计/规划Web应用程序开发?

时间:2009-11-18 00:08:48

标签: web-applications oop uml project-planning

我对在多开发人员团队方案中学习如何设计/规划Web应用程序开发感兴趣。

假设“项目经理/主管”的角色:

  1. 成功开发Web应用程序需要哪些“文档”?
  2. 需要什么样的UML图以及程度如何?
  3. 在设计/计划阶段,每个 - 根据用例 - 类需要图表化吗?
  4. 课程图应该有多详细(深度和广度)?
  5. 如果您有任何有用的图书/网站建议,请分享。


    跟进(2009年11月18日添加): 编码器/开发人员在编码期间使用什么作为指导,即创建课程,以及他们各自的方法&属性?

    如果没有完整(但可变)的类列表及其方法和属性,那么这种模糊性是否会导致严重依赖每个编码人员的知识/经验,从而导致代码质量/可用性/可维护性的偏差?

5 个答案:

答案 0 :(得分:10)

  1. 在所有情况下,您必须拥有确切要求的全面和最新记录。这包括functionalnonfunctional要求。它可以是Word文档,电子表格或专门的需求系统。您只需要能够跟踪所有要求以及它们随时间变化的方式。 Here's a good source of info and discussion关于敏捷需求文档。
  2. 根据我的经验,用例图已证明很重要,组件和部署图也很有用。类和序列图也可能有所帮助,但在大多数情况下,我认为这些应该更多地用作基本的可变指导而不是不可变的开发要求。类和方法通常会发生变化(特别是如果你正在使用TDD),如果你真的想要一个图表,最好在开发代码之后更新它,而不是为了使代码适合图表。
  3. 我不认为每个班级都需要图解。我认为模型类图可以用于跟踪数据的位置,有时候一些控制器和视图类图也很有用。但在我的大部分经验中,需求和测试用例一直是设计类的方向的主要来源,并且随着系统的发展和变化而被重构。
  4. 在模型类中,我认为通常不需要任何属性。如果您正在为控制器类建模,那么通常明智的做法是包含主要属性和方法。

答案 1 :(得分:3)

取决于网络应用的类型和大小。如果您正在使用购物车进行小型电子商务网站,那么您可能会在设计方面投入更多精力而不是“应用”功能。相反,如果您正在构建一个包含许多数据输入屏幕的大型内部网站,那么您的大部分时间将花在业务逻辑和数据规则上。

就个人而言,我不是严格规范格式或流程的信徒。我会根据项目和客户进行定制,以便清楚地进行沟通。

假设已经记录了需求,我总是试图为基于工作流的数据密集型Web应用程序生成两种类型的文档:

  1. 高级工作流程图,指示屏幕流程,状态更改和主要操作。 我发现这非常有用,作为充实应用程序中主要动作的第一步。工作流程通常与不同的用例相关。

  2. 每个输入屏幕的屏幕规格,详细说明每个字段的格式和行为。 通常包括字段类型,默认值,列表值,数据验证,可见性规则和可触发的操作等。基本上是一个大表,确保开发人员知道如何构建屏幕。

  3. 我还在最近的项目中使用了Balsamiq Mockups将Web应用程序屏幕组合在一起,屏幕模型已成为项目规范的重要组成部分 - 生成速度非常快,并且它们传达了大量有关屏幕应该如何工作,这在文本文档中很难传达。

    最后,乔尔的series on functional specs是有用的阅读。

答案 2 :(得分:2)

尽量保持简单。

指定核心功能要求的文档是第一步。

就个人而言,由于Web应用程序几乎总是基于数据库,因此我开始根据功能要求对数据库进行建模。 ERM图中的实体通常使用UML图中的1-1来映射,并且已经显示了基本关系。

假设一个MVC架构和记录良好的代码,Model类将随着它们的发展而自我记录(例如,氧气phpdocumenter)。

我发现像wiki这样简单的东西最适合编写文档而不是正式文档,这些文档的编写时间比相应的代码要长,特别是在敏捷环境中。

答案 3 :(得分:1)

  1. 要求是一组文档,可以包括图形,Word文档,电子邮件和其他记录方式。开发环境中的内容列表(IDE,源代码控制,错误跟踪),编码风格和指南是另一组文档,可用于成功的应用程序开发团队。有一个项目计划是一个大的甘特图和发行说明,这是我们创建的更多文档。
  2. 除了Gang of Four在他们的网站上解释一些设计模式之外,我还没有看到很多UML图。
  3. 我们有积压的项目要完成,并估计每个故事的复杂程度。这可能与您使用的方法不同。使用我们的敏捷方法,可能没有您的情况那么多的设计/计划。
  4. 我们很少有类图,尽管Visual Studio确实有一个对象浏览器,可以方便地查看已构建的内容。
  5. 在我工作的地方,我们倾向于成对工作来创建域对象及其成员,方法和属性。根据故事的需要或者如果我们正在清理或重构一组类,就会创建类。

    没有完整的类列表,但有一些设计模式正在使用,如MVP和信仰,因为一对正在创建一些东西,代码将符合当前的风格和指南。随着需求的不断变化,课程会经常发生变化,但这似乎是为我做事的一种自然方式。

    环境背景,以防万一有人想知道:

    在我工作的地方,我们目前有5名开发人员,QA负责人,业务分析师,团队负责人,架构师和项目经理作为项目的主要人员。我们在工作中使用Scrum,结对编程和一些TDD思想。

    我们正在使用Visual Studio 2008,Subversion,HP Quality Center,ASP.Net 3.5,Sitecore 6.0和MS-SQL Server 2005.

答案 4 :(得分:0)

所有用例必须非常详细,来自客户的持续合作将始终是一个优势,它仍然可以发布无法预料的案例。

如果在不同服务器之间开发交互,在不同时间轮询/推送消息,您肯定需要Sequence Diagrams

避免过度设计,在类图中,不需要的类往往会出现问题,减少它们,使用更多方法,跟踪每个类最终将运行的环境(有些将运行服务器端,一些客户端--javascript - 一些将是预定的作业并在真实服务器上运行,一些将由网络服务器封装的cgi(或模块)并按需运行,一些将与数据库连接。

定义边界,明确界限。服务器端/客户端/数据库工作是不同的动物,可能需要不同的时间和人。