Use cases as part of activity diagrams are used by some of mine colleagues, but this is good maybe for some static high level navigation overview.
I am about to develop custom DSL, which will resemble BDD scenario format used in Cucumber with Webrat, IMHO such scenarios contain enough information to create interactionand web page models.
Following Conallen's paper, we defined a new UML entities (stereotypes) to represent a web page or portion of a page so that we could distinguished the server-side code (e.g. Java servlet or JSP] from the client-side HTML/javascript/AJAX that it generated. For example:
[web page]
[nav bar]
[page-content]
[header]
[footer]
There were new associationss such as:
[builds] - relates server-side code to the web page or page fragment it generated
[apparent-link] - used between client pages on sitemap diagram
[link] - URL link, i.e. GET request
[submits] - form post back to server, i.e. POST request
[client-redirect] - client-side redirect
[server-redirect] - duh
Finally, some new diagrams (mostly just specializations of class diagrams) such as:
[sitemap] -> like a class diagram - shows static relationships ([apparent-link]s) between [web page]s from user's point of view
[page-generation] -> like a class diagram - shows the classes statically related to a displaying a specific web page: what code generated it, what code handles the post submission
[page-composition] - like a class diagram - shows the things that make up a given [web-page]
[sequence diagrams] - The only other change was that the sequence diagrams could now include client-side entities as actors.
The good news:
we found Rational Rose icon extensions we needed to make the diagrams look half-decent.
The bad news:
this approach was a lot work - we now had twice as many entities to model with since we were now modeling the client-side entities in addition to the server-side classes.
Read one of the Conallen papers for pictures of what I'm talking about, but as I said, didn't follow his approach strictly - we only took the pieces we needed. Hope this helps.
create something real as soon as possible (ie. create a few html files with links that go to other pages to show how the application will flow
once the flow of the site is set then add the design components and start programming
It's much easier to add programming to something that has already been designed and thought out vs designing an app to work around existing programming (which in most cases requires code to be rewritten to adapt to design/flow issues which were missed at the beginning).
发布评论
评论（4）
我的一些同事使用用例作为活动图的一部分，但这对于一些静态的高级导航概述可能很有用。
我即将开发自定义 DSL，它将类似于 Cucumber 和 Webrat 中使用的 BDD 场景格式，恕我直言，此类场景包含足够的信息来创建交互和网页模型。
Use cases as part of activity diagrams are used by some of mine colleagues, but this is good maybe for some static high level navigation overview.
I am about to develop custom DSL, which will resemble BDD scenario format used in Cucumber with Webrat, IMHO such scenarios contain enough information to create interactionand web page models.
我们使用了 Conallen 文章使用 UML 进行 Web 应用程序设计建模的变体来使用 UML 类图。 您会发现本文已演变为网络上的不同版本甚至已经成为一本书Building-Web-Applications-UML-2nd。
我用 2 美分介绍了我们使用的方法：
按照 Conallen 的论文，我们定义了一个新的 UML 实体（构造型）来表示网页或页面的一部分，以便我们可以区分服务器端代码（例如 Java servlet 或 JSP） ] 来自它生成的客户端 HTML/javascript/AJAX 例如：
有新的关联，例如：
最后，一些新的图表（主要是类图的专门化），例如：
好消息：
坏消息：
阅读科纳伦的一篇论文，了解我正在谈论的内容的图片，但正如我所说，并没有严格遵循他的方法 - 我们只采取了我们需要的部分。 希望这可以帮助。
We used UML class diagrams using a variation of Conallen's essay Modeling Web Application Design with UML. You'll find this essay has evolved into different incarnations around the net and has even become a book Building-Web-Applications-UML-2nd.
My 2-cent tour of the approach we used:
Following Conallen's paper, we defined a new UML entities (stereotypes) to represent a web page or portion of a page so that we could distinguished the server-side code (e.g. Java servlet or JSP] from the client-side HTML/javascript/AJAX that it generated. For example:
There were new associationss such as:
Finally, some new diagrams (mostly just specializations of class diagrams) such as:
The good news:
The bad news:
Read one of the Conallen papers for pictures of what I'm talking about, but as I said, didn't follow his approach strictly - we only took the pieces we needed. Hope this helps.
我过去使用 UML 状态图来记录 Web 应用程序的页面导航。
I used UML state diagrams for documenting page navigation for web apps in the past.
我建议采用 37signals 方法进行应用程序开发。
每个页面都需要有目的。 首先关注这个目的，然后围绕它设计其他一切。
过程：
向某些内容添加编程要容易得多与设计一个应用程序来解决现有编程（在大多数情况下需要重写代码以适应一开始就错过的设计/流程问题）相比，这已经是经过设计和深思熟虑的。
I recommend taking the 37signals approach to application development.
Each page needs to have purpose. Focus on that purpose first and design everything else around it.
Process:
It's much easier to add programming to something that has already been designed and thought out vs designing an app to work around existing programming (which in most cases requires code to be rewritten to adapt to design/flow issues which were missed at the beginning).