Re: Blind software engineers, specifically UML

["Pascal J. Bourguignon" <pjb@xxxxxxxxxxx>]

Daniel Dalton <d.dalton@xxxxxxxxxxx> writes:

> Hi everyone, 
>
> Firstly apologies if this is slightly OT - feel free to respond off
> list if you think that's better, but I know there are a lot of very
> knowledgeable people on here so thought it was a good starting point. 
>
> At University I'm studying computer science. I'm looking to take a
> software engineering subject called "Introduction to software
> engineering". 
>
> The problem: UML diagrams are heavily used throughout this subject
> especially for assessment purposes. Specifically, UML class diagrams and
> UML state active and sequence diagrams. We'll need to both read and
> create these diagrams. I also believe we may need to work in small
> groups with fellow students (who obviously aren't vision
> impaired). Apparently the UML is the language of the subject and it's
> not really avoidable. So does anyone have any ideas about how to handle
> this sort of thing? I'd be interested to hear what other blind software
> engineers may do to get around these problems. 
>
> Finally, just a bit of a general sort of question. I'm currently
> studying bachelor of computer science, but have considered changing into
> bachelor of software engineering. I've been told software engineering is
> much more visual - with more of this UML stuff coming up. Has anyone
> else taken a modern software engineering degree opposed to computer
> science - and how did you find it? 


UML means Unified Modeling Language.  Little scribbles are not
necessarily what comes to mind first when you hear the word "language".

And indeed, while UML specifies a graphical syntax, the same information
can be conveyed textually.

UML CASE tools save UML models as XML files.  There's a standard DTD for
UML.  I guess that XML is as hard to read for you than for me, but you
can write a program to translate the model read from the XML files into
some readable form.  And vice versa.

The notion of diagram corresponds only to a subset of the model,
composed in a way to present it in an easily understandable chunk.


For example, here is a model and a few diagrams:


(defmodel "Windows and Views"

  (defclass window ()
    ((frame :accessor view-frame :type rectangle)
     (title :accessor window-title :type string)))

  (defclass view ()
    ((frame :accessor view-frame :type rectangle)))

  (defassociation window-content-view
      ((window :accessor view-window :type window :multiplicity (0 1))
       (content-view :accessor window-content-view :type view :multiplicity (0 1))))

  (defassociation view-subviews
      ((superview :accessor view-superview :type view :multiplicity (0 1))
       (subviews  :accessor view-subviews  :type list :multiplicity (0 *)))))


(defdiagram :class-diagram "window class diagram" 
  (class window
         (attributes frame title)
         (methods))
  (class view
         (attributes)
         (methods))
  (association window-content-view))

(defdiagram :class-diagram "view hierarchy diagram" 
  (class view
         (attributes frame)
         (methods))
  (association view-subviews))

(defdiagram :sequence-diagram "window redraw"
  (instances (win-1 window)
             (content-view-1 view)
             (subview-1 view))
  (events
   (redraw (from win-1) (to content-view-1))
   (redraw (from content-view-1) (to subview-1))
   (view-frame (from subview-1) (to content-view-1))
   (window-frame (from content-view-1) (to win-1))
   (did-redraw (from subview-1) (to content-view-1))
   (did-redraw (from content-view-1) (to win-1))))



I'm not sure coordinates and graphics add much.  Well, a little in
taking advantage of the parallel processing of the visual cortext, for
more complex diagrams.  But since anyways the brains have short-term
memories limited to about 7 elements, there's little point in
overloading the visual cortex.  Well it's not entirely right: actually
eyes are more an external memory input device than an internal "GPU": it
let the brain leave data in the world, and allows to retrieve it, by
focusing on an element selected in 2D more-or-less-random access, thus
overcoming the limits of short-term memory.  In the case of UML, this is
useful only in limited circumstances, and only helps while learning
about a system.  And notably, static diagrams as provided by most CASE
tools are too limited.  What would be needed, is an automatic generation
of diagrams according to the browsing you want to do of the model.  And
once you know it, you can browse the model more directly with a textual
interface.  And notably, a sexp-form as above, is much more useful,
since you can easily process it (in emacs or other lisp ;-)).


While graphviz can be used to produce "UML" diagrams, it would be quite
a lot of work to fine tune its usage to get graphically correct UML
diagrams.  It would probably be easier to write the lisp code to
generate a UML XML from a sexp OO model definition as above. 

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.  
You know you've been lisping too long when you see a recent picture of George 
Lucas and think "Wait, I thought John McCarthy was dead!" -- Dalek_Baldwin

-----------------------------------------------------------------------------
To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "emacspeak-request@xxxxxxxxxxx" with a
subject of "unsubscribe" or "help".