如何设计/规划Web应用程序开发？
我有兴趣学习如何在多个开发团队场景中设计/规划 Web 应用程序开发。
假设“项目经理/主管”的角色：
- 成功的 Web 应用程序开发需要哪些“文档”？
- 需要哪些 UML 图以及需要到什么程度？
- 在设计/计划阶段，是否需要根据用例对每个类进行图表化？
- 类图应该有多详细（深度和广度）？
如果您有任何有用的书籍/网站推荐，请分享。
后续（2009 年 11 月 18 日添加）： 编码员/开发人员在编码过程中使用什么作为指南，即创建类及其各自的方法和方法。特性？
如果没有完整的（但可变的）类及其方法和属性列表，那么这种模糊性是否会导致对每个编码人员的知识/经验的严重依赖，从而导致代码质量/可用性/可维护性的偏差？
I'm interested in learning how to design/plan for web application development, in a multiple developer team scenario.
Assuming the role of "Project Manager/Lead":
- What "documents" are needed for successful web application development?
- What UML diagrams are needed and to what degree?
- In the design/plan phase does each - as per use case - class need to be diagrammed?
- How detailed (depth and breadth) should the class diagrams be?
If you have any helpful book/website recommendations, please share.
Follow-up (Added 11/18/09):
What do coders/developers use as a guide during coding i.e. creation of classes, and their respective methods & properties?
If there isn't a complete (yet mutable) list of classes with their methods and properties, doesn't that ambiguity cause heavy reliance on each coders' knowledge/experience, resulting in deviations in code quality/usability/maintainability?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
取决于网络应用程序的类型和大小。如果您正在做一个带有购物车的小型电子商务网站，那么您可能会在设计方面花费更多的精力，而在“应用程序”功能上花费更少的精力。相反，如果您正在构建一个具有许多数据输入屏幕的大型内部网站，那么您的大部分时间将花费在业务逻辑和数据规则上。
就我个人而言，我不相信严格的规范格式或流程。我将根据项目和客户进行定制，以实现清晰的沟通。
假设需求已经记录下来，我总是寻求为基于工作流的数据密集型 Web 应用程序生成至少两种类型的文档：
指示屏幕流程、状态更改和主要操作的高级工作流程图。
我发现这作为充实应用程序中主要动作的第一步非常有用。工作流程通常与不同的用例相关。
每个输入屏幕的屏幕规格，详细说明每个字段的格式和行为。
通常包括字段类型、默认值、列表值、数据验证、可见性规则和可以触发的操作等。基本上是一个大表，确保开发人员知道如何构建屏幕。
我还在最近的项目中使用了 Balsamiq Mockups 将 Web 应用程序屏幕和屏幕模型组合在一起已经形成了项目规范的重要组成部分——制作速度非常快，并且它们传达了许多有关屏幕应如何工作的信息，而这些信息很难在文本文档中传达。
最后，Joel 的功能规格系列非常有用。
Depends on the type and size of the web app. If you're doing a small e-commerce website with a shopping cart then you'll probably spend more effort on the design side of things and less on the "app" functionality. Conversely, if you're building a large internal website with many data input screens then most of your time will be spent on the business logic and data rules.
Personally, I'm not a believer in rigid spec formats or processes. I'll customize to suit the project and the client with a view to communicating clearly.
Assuming the requirements are already documented, two types of documents I always seek to produce as a minimum for workflow-based data-intensive web apps are:
High level workflow diagrams indicating screen flow, status changes, and major actions.
I find this very useful as a first step in fleshing out the the major movements within the application. The workflows usually correlate to the different use cases.
Screen specs for each input screen detailing each field's format and behaviour.
Typically including the field type, default value, list values, data validations, visibility rules, and actions which can be triggered, etc. Basically a big table making sure the developers know how to construct the screens.
I've also used Balsamiq Mockups in recent project to whip together web app screens and the screen mockups have formed a vital part of the project specs -- very quick to produce, and they convey a lot of information about how the screens should work that is quite hard to convey in a text document.
Lastly, Joel's series on functional specs is useful reading.
尽可能保持简单。
第一步是制定一份指定核心功能要求的文档。
就我个人而言，由于网络应用程序几乎总是基于数据库的，因此我开始根据功能需求对数据库进行建模。 ERM图中的实体通常与UML图中的类一一对应，并且已经显示了基本关系。
假设 MVC 架构和记录良好的代码，模型类将随着它们的发展而自我记录（例如oxygen phpdocumenter）。
我发现像 wiki 这样简单的东西最适合编写文档，而不是编写正式文档，因为正式文档可能比编写相应的代码花费更长的时间，特别是在敏捷环境中。
Keep it as simple as possible.
A document specifying the core feature requirements is the first step.
Personally speaking, as web apps are nearly always database-based, I start off modelling the database based on the functionality requirements. The entities in the ERM diagram map usually 1-1 with classes in UML diagram, and already shows the basic relations.
Assuming a MVC architecture and well-documented code, the Model classes will be self documenting as they evolve (e.g. oxygen phpdocumenter ).
I find something simple like a wiki works best for writing docs rather than formal documents that can take longer to write than the respective code, particularly in an agile environment.
在我工作的地方，我们倾向于结对工作来创建域对象及其成员、方法和属性。类是根据故事的需要或者我们正在清理或重构一组类而创建的。
没有完整的类列表，但有一些正在使用的设计模式，例如 MVP 和信念，因为一对正在创建某些东西，所以代码将适合当前的风格和指南。随着需求的发展，课程会定期发生变化，但这对我来说似乎是一种自然的做事方式。
我所在环境的背景，以防万一有人想知道：
在我工作的地方，我们有 5 名开发人员、一名 QA 主管、一名业务分析师、一名团队主管、一名架构师和一名项目经理，作为项目的主要人员片刻。我们在工作中使用 Scrum、结对编程和一些 TDD 思想。
我们使用 Visual Studio 2008、Subversion、HP Quality Center、ASP.Net 3.5、Sitecore 6.0 和 MS-SQL Server 2005。
Where I work we tend to work in pairs for creating domain objects and their members, methods and properties. Classes are created as needed for stories or if we are cleaning up or refactoring a set of classes.
There isn't a complete list of classes but there are some design patterns in use like MVP and faith that since a pair is creating something, the code will fit within the current style and guidelines. As requirements evolve there will be changes to the classes quite regularly but this seems like a natural way to do things for me.
Background on the environment where I am just in case anyone wants to know:
Where I work we have 5 developers, a QA lead, a business analyst, a team lead, an architect and a project manager as the main people in the project at the moment. We use Scrum, pair programming and some TDD ideas in our work.
We are using Visual Studio 2008, Subversion, HP Quality Center, ASP.Net 3.5, Sitecore 6.0, and MS-SQL Server 2005.
所有用例必须非常详细，客户的持续合作永远是一个优势，但它仍然可能会出现不可预见的案例。
如果开发不同服务器之间的交互，在不同时间轮询/推送消息，您将需要 序列图 当然。
避免过度设计，在类图中不需要的类往往会如雨后春笋般涌现，减少它们，使用更多方法，跟踪每个类最终将真正运行的环境（有些将运行服务器端，有些将运行客户端） - javascript - 有些将被调度作业并在真实服务器上运行，有些将由网络服务器封装并按需运行，有些将与数据库交互
，使它们清晰。客户端/数据库工作是不同的工作，可能需要不同的时间和人员。
All the Use Cases must be well detailed, continued cooperation from the customer will always be a plus, still it could sprout unforeseen cases.
If developing interaction among different servers that will poll/push messages at different times you will be needing Sequence Diagrams for sure.
Avoid overdesigning it, in Class Diagrams unneeded classes tend to mushroom, cut them down, use more methods, keep track of what environment each class will really end up running (some will run server side, some client side - javascript - some will be scheduled jobs and run on the real server, some wil be cgi (or module) encapsuled by he webserver and run on demand, some will interface with the database.
Define the boundaries, make them clear. Server side/client side/database work are different beasts and may take different times and people.