/[gzz]/manuscripts/UMLLink/article.rst
ViewVC logotype

Diff of /manuscripts/UMLLink/article.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.28 by tuukkah, Fri Feb 14 16:52:09 2003 UTC revision 1.29 by humppake, Fri Feb 14 17:02:29 2003 UTC
# Line 148  describe software constructs in diagrams Line 148  describe software constructs in diagrams
148  [booch-jacobson-rumbaugh98uml-user-guide]_. It was originally  [booch-jacobson-rumbaugh98uml-user-guide]_. It was originally
149  developed for descriptions on an abstract level (many constructs  developed for descriptions on an abstract level (many constructs
150  cannot be directly expressed in any programming language)  cannot be directly expressed in any programming language)
151  [booch-jacobson-rumbaugh98uml-user-guide]_ (pp12), but current trend is to  [booch-jacobson-rumbaugh98uml-user-guide-onpage-12]_, but current
152  use it also on the concrete level, as to fully unify the architectural  trend is to use it also on the concrete level, as to fully unify the
153  documentation and program code: the program code might be generated  architectural documentation and program code: the program code might
154  from highly detailed diagrams  be generated from highly detailed diagrams
155  [harrison-barton-raghavachari00uml-to-java]_, or exact diagrams be  [harrison-barton-raghavachari00uml-to-java]_, or exact diagrams be
156  produced from the source code  produced from the source code
157  [pierce-tilley02connecting-documentation-rose]_.  [pierce-tilley02connecting-documentation-rose]_.
# Line 167  every detail: Line 167  every detail:
167     perspectives, so a diagram is a projection into a system.     perspectives, so a diagram is a projection into a system.
168     For all but the most trivial systems, a diagram represents an elided     For all but the most trivial systems, a diagram represents an elided
169     view of the elements that make up a system."     view of the elements that make up a system."
170     [booch-jacobson-rumbaugh98uml-user-guide]_ (pp24)     [booch-jacobson-rumbaugh98uml-user-guide-onpage-24]_
171    
172  .. (could other stakeholders be identified and described to some  .. (could other stakeholders be identified and described to some
173     extent somewhere? it might be interesting to think also towards     extent somewhere? it might be interesting to think also towards
# Line 211  In their article "A rational design proc Line 211  In their article "A rational design proc
211  software design process is not generally possible, but acceptable  software design process is not generally possible, but acceptable
212  results could be achieved by faking "the ideal process". Their ideal  results could be achieved by faking "the ideal process". Their ideal
213  software design process contains the following steps  software design process contains the following steps
214  [parnas-clements86rational]_ (pp252--255):  [parnas-clements86rational-onpage-252-255]_:
215    
216    a) establish and document requirements    a) establish and document requirements
217    b) design and document the module structure    b) design and document the module structure
# Line 233  lot of mentoring by other group members, Line 233  lot of mentoring by other group members,
233  productive for the project. Sometimes sufficient mentoring could not  productive for the project. Sometimes sufficient mentoring could not
234  even be possible, because members of such a projects could be  even be possible, because members of such a projects could be
235  geographically widely scattered. This results in the Mythical Man  geographically widely scattered. This results in the Mythical Man
236  Month effect [brooks75mythical-man-month]_ (pp16): adding a new member  Month effect [brooks75mythical-man-month-onpage-16]_: adding a new member
237  into software design process could rather delay than speed up the  into software design process could rather delay than speed up the
238  project.  project.
239    
240    "Men and months are interchangeable commodities only when a task can be    "Men and months are interchangeable commodities only when a task can be
241    partitioned among many workers with no communication."    partitioned among many workers with no communication."
242    [brooks75mythical-man-month]_ (pp18)    [brooks75mythical-man-month-onpage-18]_
243    
244    "The added burden of communication is made up of two    "The added burden of communication is made up of two
245    parts, training and intercommunication. Each worker must be trained    parts, training and intercommunication. Each worker must be trained
246    in the technology, the goal of the effort, the overall strategy, and    in the technology, the goal of the effort, the overall strategy, and
247    the plan of work.-- --Intercommunication is worse."    the plan of work.-- --Intercommunication is worse."
248    [brooks75mythical-man-month]_ (pp18)    [brooks75mythical-man-month-onpage-18]_
249    
250  Eventually, the greater is the amount of programmers or higher the  Eventually, the greater is the amount of programmers or higher the
251  turnover within them, the more important it is to have a good  turnover within them, the more important it is to have a good
# Line 253  documentation.  When new programmers joi Line 253  documentation.  When new programmers joi
253  have to depend completely on the old staff for their information. An  have to depend completely on the old staff for their information. An
254  up to date and rational set of documents available for them could  up to date and rational set of documents available for them could
255  ameliorate the Mythical Man Month effect  ameliorate the Mythical Man Month effect
256  [parnas-clements86rational]_ (pp255).  [parnas-clements86rational-onpage-255]_.
257    
258  Because our group is doing experimental research with a rather small  Because our group is doing experimental research with a rather small
259  group and as an open Free Software project, we need a flexible model  group and as an open Free Software project, we need a flexible model
# Line 262  development process models, ours reminds Line 262  development process models, ours reminds
262  of software development and enhancement [boehm88spiral-model]_. From  of software development and enhancement [boehm88spiral-model]_. From
263  the modern models our development process is influenced by Extreme  the modern models our development process is influenced by Extreme
264  Programming [beck99xp]_. The Spiral Model is cyclic and repetitive,  Programming [beck99xp]_. The Spiral Model is cyclic and repetitive,
265  and every cycle has the following phases [boehm88spiral-model]_ (pp64):  and every cycle has the following phases [boehm88spiral-model-onpage-64]_:
266    
267   * analysis: determining objectives, alternatives, constraints   * analysis: determining objectives, alternatives, constraints
268   * design: evaluating alternatives, identifying and resolving risks   * design: evaluating alternatives, identifying and resolving risks
# Line 383  XXX Hypertext blaablaa something... Line 383  XXX Hypertext blaablaa something...
383    
384  The usability of hypertext-based documentation may suffer from user's  The usability of hypertext-based documentation may suffer from user's
385  disorientation: the tendency to lose one's sense of location and  disorientation: the tendency to lose one's sense of location and
386  direction in a nonlinear document [conklin87hypertext]_  direction in a nonlinear document
387  (pp38--40). That means, users don't know where they are in the  [conklin87hypertext-onpage-38-40]_. That means, users don't know where
388  documentation network or how to get to some other place that they know  they are in the documentation network or how to get to some other
389  to exist in the network. In our documentation this gets even more  place that they know to exist in the network. In our documentation
390  complex, because we have two distinct pieces of documentation, which  this gets even more complex, because we have two distinct pieces of
391  should have somehow unified navigation.  documentation, which should have somehow unified navigation.
392    
393  Edwards and Hardman [edwards-hardman89lost-in-hyperspace]_ argue that  Edwards and Hardman [edwards-hardman89lost-in-hyperspace]_ argue that
394  the most appropriate types of navigation devices would be based on  the most appropriate types of navigation devices would be based on
# Line 397  attempting to create cognitive represent Line 397  attempting to create cognitive represent
397  in the form of a survey-type map. They conlude that users should be  in the form of a survey-type map. They conlude that users should be
398  allowed to develop a cognitive map of one view of the data structure  allowed to develop a cognitive map of one view of the data structure
399  before being given the opinion of navigating through the data some  before being given the opinion of navigating through the data some
400  other way. [edwards-hardman89lost-in-hyperspace]_ (pp123)  other way. [edwards-hardman89lost-in-hyperspace-onpage-123]_
401            
402  We didn't need to look long for a common navigational metaphor to  We didn't need to look long for a common navigational metaphor to
403  unify the two distinct pieces. Since the most of our UML diagrams  unify the two distinct pieces. Since the most of our UML diagrams
# Line 610  tool. Line 610  tool.
610         and been reduced to pointing at objects in the immediate         and been reduced to pointing at objects in the immediate
611         environment.-- --We have lost all the power of language, and         environment.-- --We have lost all the power of language, and
612         can no longer talk about objects that are not immidiately         can no longer talk about objects that are not immidiately
613         visible." [gentner-nielsen96anti-mac]_ (pp74)         visible." [gentner-nielsen96anti-mac-onpage-74]_
614    
615  The direct manipulation user interface do not necessarily improve  The direct manipulation user interface do not necessarily improve
616  performance: users must learn the meaning of the graphical components,  performance: users must learn the meaning of the graphical components,
617  graphic presentation could be misleading, graphical presentation could  graphic presentation could be misleading, graphical presentation could
618  take excessive screen display space  take excessive screen display space
619  [shneiderman83direct-manipulation]_ (pp64). The direct manipulation  [shneiderman83direct-manipulation-onpage-64]_. The direct manipulation
620  interfaces could be also rather slow to use, since in a such interface  interfaces could be also rather slow to use, since in a such interface
621  user have to directly manipulate everything. Instead of an executive  user have to directly manipulate everything. Instead of an executive
622  who gives high-level instructions, the user is reduced to an assembly  who gives high-level instructions, the user is reduced to an assembly
623  line worker who must carry out the same task over and over  line worker who must carry out the same task over and over
624  [gentner-nielsen96anti-mac]_ (pp74). The UML langage has XXX different  [gentner-nielsen96anti-mac-onpage-74]_. The UML langage has XXX different
625  symbols and XXX different connections between them. It is a quite  symbols and XXX different connections between them. It is a quite
626  challanging for a direct manipulation interface to make all these  challanging for a direct manipulation interface to make all these
627  alternatives as easily available as they could be typed within lexical  alternatives as easily available as they could be typed within lexical

Legend:
Removed from v.1.28  
changed lines
  Added in v.1.29

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26