design for dummies (still looking for a better name!)
michelle neuringer, cs190

introduction

write a program that solves a real problem
	+inspired by debates in cs32 ta camp - "are we gonna make them use
rose again?"
	+a large percentage of students in cs32 last year (determined by a
20 person random sampling performed by yours truly) found rose not only
unhelpful, but rather painful to use (unintuitive interface, program
crashed a lot)
	+regardless, all the TAs agreed on the following:  using a tool
similar to rose (i.e., with the same goals) is integral to the software
engineering process - especially when designing your first program as a
team
	+since we couldn't find an alternative to rose, this year's cs32
students are going to have to learn to use it - even though they will only
utilize 10% of its functionality (if that) throughout the semester

so rose is huge.  big deal.  what's the real problem?
	+the real problem with rose is that it's made for experienced team
programmers and large projects - that's its target audience.  that's why
rose is the design tool most popularly used in industry.  
	+the brown cs department teaches good object-oriented design from
the beginning (cs15) and continues with the same philosophy as students
progress up the cs ladder.  what the department needs is a design tool
that's geared towards its own audience - fool-proof enough for beginners,
powerful enough for budding hackers.

this is a design tool with a different target audience
	+geared specifically toward smaller or relatively novice
software/product teams (such as cs32/190 students, or teams designing more
compact software solutions - as at consulting firms and the like) 
	+easier and more intuitive to use, specifically addresses the
problems of smaller teams (design, communication, presentation of ideas to
professors, classmates, clients).  from an engineering/time standpoint, 
the lack of a hefty requirement such as code generation allows more time
to sharpen up the presentation aspect of the program, work on an
intuitive, simple and fast interface, and perform stability tests (the
latter is extremely important if the program is to be used within the
department).
	+smaller in size and thus less intimidating to students

requirements and features

first, a look at all the major features in rational rose (for those
interested)
	+UML modeling
		activity diagrams
		use-case diagrams
		sequence diagrams
		collaboration diagrams
		class diagrams
		component diagrams
		deployment diagrams
	+component modeling - drag and drop components from a file system 
onto the diagram; enables you to reuse and adapt components
	+multilanguage development - build components in mixed languages
	+round-trip engineering - support all phases of a project's
lifecycle
	+full-team support - supports teams of programmers by enabling
each to operate in a private workspace that contains an individual view of
the entire model.  engineers can work on complex problems concurrently.
	+drag-and-drop unit manipulation
	+model integrator - a visual model difference and merge tool
	+framework wizard - a library of frameworks that can be used as
templates when creating new models.  can initialize new model with a
predefined architecture and a set of reusable model elements.
	+customizable - menus, automate rose functions with rose scripts
	+report generation
	+more: IDL (interface design language) code generation, database
schema generation, MS Repository integration

now, a look at the features that smaller groups need 
	+generating UML diagrams from graphical input 
	+generating C/C++ header files (variable lists, function lists,
comments) or .java files (variable declarations and empty methods) from
UML diagrams and vice versa. 
	+model updating - easy to adjust diagram when design is
augmented/changed
	+message board and/or timeline/project scheduling 
	+team support - enable each member of the team to operate in a
private workspace that contains an individual view of the entire model.
ability to merge multiple files into a single document.  ability to
constrain each user so that they only manipulate things that won't screw
other people up.  (this last one would be difficult)
	+a presentation element - diagrams/documentaion could be easily
incorporated into various presentation formats, like slideshows (helpful
for project teams to present to managers or clients), HTML documents
	+intuitive, attractive interface

feature footnotes and tradeoffs

diagram generation: 
	+graphical input would include point+click=box, like rose, as
well as fields in a form
	+file generation wouldn't be difficult as long as the
representation of the UML information was general enough (see XML section,
below)
	+generating UML from code is a very hard problem.  apparently,
rose isn't very good at it.  i don't think this feature is at all
necessary for smaller teams, therefore i didn't include it in my
feature list.

message board, timeline, scheduling calendar:
	+lower priority, but still would be mighty helpful to teams.
we could take a look at groupware and scheduling programs for ideas.
students could use the timeline and calendar to post due-dates and
integration milestones.  they could the have the program generate HTML
project pages for them in order to read their schedule and design 
online.

presentation:
	+if we all agree on its necessity, the strength of this program
could lie in its presentation generation.  on the simpler side, we have
basic HTML generation.  on the more complicated, yet much cooler side, we
have...

didn't you always want to learn XML?
	+if we represent UML using XML, then using an XSL style sheet, we
could generate UML diagrams or code or HTML or PDF or whatever from our
XML database.
	+tradeoff is that most people in the class have not worked with
XML (including myself).  on the pro side, it's yet another learning
experience.

yay, design!