I am interesting in a diagramming methodology that can capture user-interaction in a way that will incorporate the "screens" along with the "actions", and how those are driven by controllers,views and services.
views:
363answers:
2You could read this interesting article http://37signals.com/svn/posts/1926-a-shorthand-for-designing-ui-flows from 37 signals (the firm that brought Rails to life).
I hoppe it helps you.
Diagrams for your business models can easily be acquired using a tool like this handy Ruby script for dumping your current ActiveRecord schema into UML. It produces XMI 1.1 for UML 1.3 (viewable, for instance, in StarUML.)
A simple rake task utilizing it might look something like:
namespace :uml do
desc "Generates db/schema.xml file describing the current DB as seen by AR."
task :schema => :environment do
require 'lib/uml_dumper.rb'
File.open("db/schema.xml", "w") do |file|
ActiveRecord::UmlDumper.dump(ActiveRecord::Base.connection, file)
end
puts "Done. Schema XMI created as db/schema.xml."
end
end
Once you've got your models in there, it's just a matter of creating relationships describing the relationships between your data layer (your models' design pattern) and the business logic/presentation layer (view-controller design patterns).
However, unless your project has some truly extraordinary requirements, you are almost certainly over-engineering your interface. The presentation/action diagrams mentioned earlier and championed by 37signals are ideal for capturing 80% of user stories.
In short: if a lot of your interactions are growing so labyrinthine you feel the need for a secondary modelling language to describe them, it might be time to think about why they are so complicated in the first place.