有没有像Jsp图这样的东西？
我正在开发一个现有的网络应用程序。它充分利用了 jsp 重用（通过 include 甚至自定义标签）。我涉及的任务之一是对这些文件进行更改，现在受影响的文件已攀升至 10 多个，我在管理它们时遇到了一些麻烦。我正在考虑绘制 jsps 甚至（js 和 ajax 脚本）的关联图，是否有官方的方法（例如 UML 类图）。
我需要将它们可视化，这样当我重新访问这些时，我就能一目了然地知道哪些屏幕受到影响，而不是通过重新阅读代码来重新学习关联（如果这有意义的话）。
I am working on an existing web application. It makes good use of jsp reuse (via include or even custom tags). One of my tasks invovled make changes to these, now the affected files has climbed to more than 10, I am having a bit of trouble managing them. I was thinking to diagramming the associations of jsps and maybe even the (js and ajax scripts), is there an official way of doing it (such as UML class diagram).
I need to visualize them so that when I revisit these, I would know which screens are affected in a glance, and not relearn the associations via code rereading (if that makes any sense).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这个问题可以有一个非常简单的答案，也可以有一个复杂的答案。
简单的：
使用构造型 <> 或 <> 的类对它们进行建模。正如斯瓦拉杰所建议的那样。尽管恕我直言，实际上并不需要对它们进行构造型，因为您只需让它们实现 HttpServlet 或 HttpJspPage 接口即可表明它们是 servlet 或 jsp 页面。由于当今大多数建模工具对于构造型的使用都相当吝啬（只允许使用一个 - 即使最新的规范允许多个），因此我喜欢为无法以任何其他方式表达的事物保留使用构造型 - 并且对模型的理解产生深远的影响。
复杂的：
警告：我最近把这个话题作为我职业生涯的焦点，所以我在这个领域的观点相当强烈——所以不要太认真地对待我写的内容:-)。
当我第一次从客户端服务器过渡到 Web 应用程序时，我想应用我经过验证且成功的 OO 最佳实践，但在设计建模网页（当时是 MS ASP）时遇到了一个小障碍。主要问题是存在一个概念性网页，但它在服务器和客户端上的表现却截然不同。例如，任何给定的网页都包含在服务器上构建时填充其动态内容的代码以及在客户端上表征它的客户端脚本和超链接。在 UML 模型中的同一个类中混合这两个在我看来非常令人困惑。
我不能忽视客户端的东西，因为它（恕我直言）在架构上很重要。作为一名架构师和设计师，导航路线、客户端脚本、表单/字段、小程序等对我来说都很重要，并且需要成为设计模型的一部分。那么，最大的问题就变成了如何正确地对这些类型的内容以及页面创建内容（JSP 和 Servlet 与服务器端资源的交互）进行建模？该解决方案需要与当前的 Java 建模技术保持一致，最重要的是保持相同的抽象和细节级别（两个关键建模概念）。
我提出的解决方案的关键是将网页的这些单独方面建模为单独的类（一个用于客户端层，一个用于服务器层）。它们都是由同一个组件实现的，正是通过这个组件的实现，页面的概念才清晰地呈现为单个实体。 URL也是通过组件来实现的。
因为这是一个复杂的解决方案，所以我最好只向您指出我最近为《软件开发杂志》一月版（2001 年 1 月）撰写的一篇介绍性文章。或者来自 ACM 通信（第 42 卷，第 10 期）的旧版本（显然可以在网上以 PDF 形式获得。）最后是无耻的插件，我写了一本书，进一步详细介绍了这一点：“构建 Web 应用程序与 UML”，在 Addison Wesley 对象技术系列中。虽然本书主要关注 ASP 技术，但这些概念可以应用于 JSP/Servlet、PHP 甚至 CFM。我目前正在开发下一版本，其中将包括（甚至重点关注）J2EE 实现。
礼貌 - http://www.jguru.com/faq/view。 jsp?EID=334159
This question can either have a very simple answer or a complicated one.
Simple:
Model them with classes stereotyped <>, or <> as swarraj suggested. Although imho, there isn't really much need to stereotype them since you could indicate that they were servlet or jsp pages just by having them realize the HttpServlet or HttpJspPage interfaces. Since most modeling tools today are rather stingy about the use of stereotypes (only one allowed - even though the most current spec allows multiple), I like to reserve the use of stereotypes for things that can not be expressed in any other way - and that have profound impact on the understanding of the model.
Complex:
Warning: I have made this topic a focus of my career lately and so my opinions are rather strong in this area - so don't take what I write too seriously :-).
When I first made the transistion to web applications from client server I wanted to apply my proven and sucessful OO best practices, but hit a minor stumbling block when it came to desgin modeling web pages (MS ASP at the time). The principal issue is that there is one conceptual web page, yet it manifests itself very differently on the server and the client. For example any given web page contains both the code to fill its dynamic content while being built on the server as well as the client scripts and hyperlinks that characterize it on the client. Mixing these two in the same class in a UML model seemed to me very confusing.
I couldn't just ignore the client side stuff, since it was (imho) architecturally significant. Navigational routes, client side scripts, forms/fields, applets, etc. were all important to me as an architect and designer - and needed to be part of the design model. The big question then became how do you properly model these types of things alongside the page creational stuff (JSP and Servlet interactions with server side resources)? The solution needed to be consistent with current Java modeling techniques, and most important at the same leve of abstraction and detail (two key modeling concepts).
The crux of the solution that I've put forward is to model these separate aspects of the web page as separate classes (one for client tier and one for server tier). They are both realized by the same component, and it is through this component realization that the concept of a page makes itself clear as a single entity. It is also through the component that URLs are realized.
Because it is a complex solution it's best that I just point you to a recent introductory article I wrote for the Jan edition of Software Development Magazine (Jan 2001). Or this older one from the Communications of the ACM (vol 42, No. 10) (which is apparently available on the net as a PDF.) Finally the shamless plug, I have written a book detailing this much further: "Building Web Applications with UML", in the Addison Wesley Object Technology Series. Although this book is pretty much focused on ASP techologies the concepts can be applied to JSP/Servlet, PHP and even CFM. I am presently working on the next edition that will include (and even focus on) J2EE imlementations.
Courtesy- http://www.jguru.com/faq/view.jsp?EID=334159