Login | Register
My pages Projects Community openCollabNet

ArgoUML: Manual de Usuario

Tutorial y descripci??n de referencia

Alejandro Ramirez

Philippe Vanpeperstraete

Andreas Rueckert

Kunle Odutola

Jeremy Bennett

Linus Tolke

Michiel van der Wulp

Este material puede ser distribuido solo sujeto a los terminos y condiciones establecidos en la Open Publication License, v1.0 o posterior. Una copia de esta licencia est?? incluida en la secci??n Open Publication License. La ??ltima versi??n est?? actualmente disponible en http://www.opencontent.org/openpub/.

Abstract

Esta version de el manual est?? planeado para describir la versi??n ${argo.core.version} de ArgoUML.


1. Prefacio
1. Introducci??n
1.1. Origenes y Visi??n General de ArgoUML
1.1.1. Analisis Orientado a Objeto y Dise??o
1.1.2. El Desarrollo de ArgoUML
1.1.3. Encontrando Mas Sobre el Proyecto ArgoUML
1.2. Alcance de Este Manual de Usuario
1.2.1. Audiencia Objetivo
1.2.2. Alcance
1.3. Visi??n General del Manual de Usuario
1.3.1. Estructura del Manual Tutorial
1.3.2. Estructura del Manual de Referencia
1.3.3. Retroalimentaci??n por el Usuario
1.4. Supuestos
1. Tutorial
2. Introducci??n (escribiendose)
3. OOA&D basada en UML
3.1. Antecedentes para UML
3.2. Procesos Basados en UML para OOA&D
3.2.1. Tipos de Procesos
3.2.2. Un Proceso de Desarrollo para este Manual
3.3. Por que ArgoUML es Diferente
3.3.1. Psicolog??a Cognitiva
3.3.2. Estandares Abiertos
3.3.3. 100% Java Puro
3.3.4. Codigo Abierto
3.4. Fundamentos de ArgoUML
3.4.1. Empezando
3.4.2. El Interfaz de Usuario de ArgoUML
3.4.3. Salida
3.4.4. Trabajando Con Criticas de Dise??o
3.5. El Casos de Estudio (A escribir)
4. Captura de Requerimientos
4.1. Introducci??n
4.2. El Prodeso de Captura de Requerimientos
4.2.1. Pasos del Proceso
4.3. Salida del Proceso de Captura de Requerimientos
4.3.1. Documento de Visi??n
4.3.2. Diagrama de Casos de Uso
4.3.3. La Especificaci??n de Casos de Uso
4.3.4. Supplementary Requirement Specification
4.4. Using Use Cases in ArgoUML
4.4.1. Actors
4.4.2. Use Cases
4.4.3. Associations
4.4.4. Hierarchical Use Cases
4.4.5. Stereotypes
4.4.6. Documentation
4.4.7. System Boundary Box
4.5. Case Study
4.5.1. Vision Document
4.5.2. Identifying Actors and Use Cases
4.5.3. Associations (To be written)
4.5.4. Advanced Diagram Features (To be written)
4.5.5. Use Case Specifications (To be written)
4.5.6. Supplementary Requirements Specification (To be written)
5. Analysis
5.1. The Analysis Process
5.1.1. Class, Responsibilities, and Collaborators (CRC) Cards
5.1.2. Concept Diagram (To be written)
5.1.3. System Sequence Diagram (To be written)
5.1.4. System Statechart Diagram (To be written)
5.1.5. Realization Use Case Diagram (To be written)
5.1.6. Documents (To be written)
5.2. Class Diagrams (To be written)
5.2.1. The Class Diagram (To be written)
5.2.2. Advanced Class Diagrams (To be written)
5.3. Creating Class Diagrams in ArgoUML
5.3.1. Classes
5.3.2. Associations (To be written)
5.3.3. Class Attributes and Operations (To be written)
5.3.4. Advanced Class Features (To be written)
5.4. Sequence Diagrams (To be written)
5.4.1. The Sequence Diagram (To be written)
5.4.2. Identifying Actions (To be written)
5.4.3. Advanced Sequence Diagrams (To be written)
5.5. Creating Sequence Diagrams in ArgoUML
5.5.1. Sequence Diagrams
5.5.2. Actions (To be written)
5.5.3. Advanced Sequence Diagrams (To be written)
5.6. Statechart Diagrams (To be written)
5.6.1. The Statechart Diagram (To be written)
5.6.2. Advanced Statechart Diagrams (To be written)
5.7. Creating Statechart Diagrams in ArgoUML
5.7.1. Statechart Diagrams (To be written)
5.7.2. States (To be written)
5.7.3. Transitions (To be written)
5.7.4. Actions (To be written)
5.7.5. Advanced Statechart Diagrams (To be written)
5.8. Realization Use Cases (To be written)
5.9. Creating Realization Use Cases in ArgoUML (To be written)
5.10. Case Study (To be written)
5.10.1. CRC Cards
5.10.2. Concept Class Diagrams (To be written)
5.10.3. System Sequence Diagrams (To be written)
5.10.4. System Statechart Diagrams (To be written)
5.10.5. Realization Use Cases (To be written)
6. Design
6.1. The Design Process (To be written)
6.1.1. Class, Responsibilities, and Collaborators (CRC) Cards
6.1.2. Package Diagram (To be written)
6.1.3. Realization Class Diagrams (To be written)
6.1.4. Sequence Diagrams and Collaboration Diagrams (To be written)
6.1.5. Statechart Diagrams and Activity Diagrams (To be written)
6.1.6. Deployment Diagram (To be written)
6.1.7. Documents (To be written)
6.2. Package Diagrams (To be written)
6.2.1. The Package Diagram (To be written)
6.2.2. Advanced Package Diagrams (To be written)
6.3. Creating Package Diagrams in ArgoUML
6.3.1. Packages
6.3.2. Relationships between packages (To be written)
6.3.3. Advanced Package Features (To be written)
6.4. More on Class Diagrams (To be written)
6.4.1. The Class Diagram (To be written)
6.4.2. Advanced Class Diagrams (To be written)
6.5. More on Class Diagrams in ArgoUML (To be written)
6.5.1. Classes (To be written)
6.5.2. Class Attributes and Operations (To be written)
6.5.3. Advanced Class Features
6.6. Sequence and Collaboration Diagrams (To be written)
6.6.1. More on the Sequence Diagram (To be written)
6.6.2. The Collaboration Diagram (To be written)
6.6.3. Advanced Collaboration Diagrams (To be written)
6.7. Creating Collaboration Diagrams in ArgoUML (To be written)
6.7.1. Collaboration Diagrams (To be written)
6.7.2. Messages (To be written)
6.7.3. Advanced Collaboration Diagrams (To be written)
6.8. Statechart Diagrams (To be written)
6.8.1. The Statechart Diagram (To be written)
6.8.2. Advanced Statechart Diagrams (To be written)
6.9. Creating Statechart Diagrams in ArgoUML (To be written)
6.9.1. Statechart Diagrams (To be written)
6.9.2. States (To be written)
6.9.3. Transitions (To be written)
6.9.4. Actions (To be written)
6.9.5. Advanced Statechart Diagrams (To be written)
6.10. Activity Diagrams (To be written)
6.10.1. The Activity Diagram (To be written)
6.11. Creating Activity Diagrams in ArgoUML (To be written)
6.11.1. Activity Diagrams (To be written)
6.11.2. Action States (To be written)
6.12. Deployment Diagrams (To be written)
6.12.1. The Deployment Diagram (To be written)
6.13. Creating Deployment Diagrams in ArgoUML (To be written)
6.13.1. Nodes (To be written)
6.13.2. Components (To be written)
6.13.3. Relationships between nodes and components (To be written)
6.14. System Architecture (To be written)
6.15. Case Study (To be written)
6.15.1. CRC Cards (To be written)
6.15.2. Packages (To be written)
6.15.3. Class Diagrams (To be written)
6.15.4. Sequence Diagrams (To be written)
6.15.5. Collaboration Diagrams (To be written)
6.15.6. Statechart Diagrams (To be written)
6.15.7. Activity Diagrams (To be written)
6.15.8. The Deployment Diagram (To be written)
6.15.9. The System Architecture (To be written)
7. Code Generation, Reverse Engineering, and Round Trip Engineering
7.1. Introduction
7.2. Code Generation
7.2.1. Generating Code from the Static Structure
7.2.2. Generating code from interactions and state machines
7.3. Code Generation in ArgoUML
7.3.1. Static Structure
7.3.2. Interactions and statechart diagrams
7.4. Reverse Engineering
7.5. Round-Trip Engineering
2. User Interface Reference
8. Introduction
8.1. Overview of the Window
8.2. General Mouse Behavior in ArgoUML
8.2.1. Mouse Button Terminology
8.2.2. Button 1 Click
8.2.3. Button 1 Double Click
8.2.4. Button 1 Motion
8.2.5. Shift and Ctrl modifiers with Button 1
8.2.6. Alt with Button 1: Panning
8.2.7. Ctrl with Button 1: Constrained Drag
8.2.8. Button 2 Actions
8.2.9. Button 2 Double Click
8.2.10. Button 2 Motion
8.3. General Information About Panes
8.3.1. Re-sizing Panes
8.4. The status bar
9. The Toolbar
9.1. File operations
9.2. Edit operations
9.3. View operations
9.4. Create operations
10. The Menu bar
10.1. Introduction
10.2. Mouse Behavior in the Menu Bar
10.3. The File Menu
10.3.1. New
10.3.2. Open Project...
10.3.3. Save Project
10.3.4. Save Project As...
10.3.5. Revert to Saved
10.3.6. Import XMI...
10.3.7. Export XMI...
10.3.8. Import Sources...
10.3.9. Page Setup...
10.3.10. Print...
10.3.11. Export Graphics...
10.3.12. Export All Graphics...
10.3.13. Notation
10.3.14. Properties
10.3.15. Save Configuration
10.3.16. Most Recent Used Files
10.3.17. Exit
10.4. The Edit Menu
10.4.1. Select
10.4.2. Remove From Diagram
10.4.3. Delete From Model
10.4.4. Configure Perspectives...
10.4.5. Settings...
10.5. The View Menu
10.5.1. Goto Diagram...
10.5.2. Find...
10.5.3. Zoom
10.5.4. Adjust Grid
10.5.5. Adjust Grid Snap
10.5.6. Page Breaks
10.6. The Create Menu
10.6.1. New Use Case Diagram
10.6.2. New Class Diagram
10.6.3. New Sequence Diagram
10.6.4. New Collaboration Diagram
10.6.5. New Statechart Diagram
10.6.6. New Activity Diagram
10.6.7. New Deployment Diagram
10.7. The Arrange Menu
10.7.1. Align
10.7.2. Distribute
10.7.3. Reorder
10.7.4. Nudge
10.7.5. Set Preferred Size
10.7.6. Toggle Auto Resizing
10.7.7. Layout
10.8. The Generation Menu
10.8.1. Generate Selected Classes ...
10.8.2. Generate All Classes...
10.8.3. Generate Code for Project... (To be Written)
10.8.4. Settings for Generate for Project... (To be Written)
10.9. The Critique Menu
10.9.1. Toggle Auto-Critique
10.9.2. Design Issues...
10.9.3. Design Goals...
10.9.4. Browse Critics...
10.10. The Tools Menu
10.11. The Help Menu
10.11.1. System Information
10.11.2. About ArgoUML
11. The Explorer
11.1. Introduction
11.2. Mouse Behavior in the Explorer
11.2.1. Button 1 Click
11.2.2. Button 1 Double Click
11.2.3. Button 1 Motion
11.2.4. Button 2 Actions
11.2.5. Button 2 Double Click
11.3. Keyboard Behavior in the Explorer
11.4. Perspective Selection
11.5. Configuring Perspectives
11.5.1. The Configure Perspectives dialog
11.6. Context Sensitive Menu
11.6.1. Add to Diagram
11.6.2. Delete From Model
11.6.3. Set Source Path... (To be written)
11.6.4. Add Package
11.6.5. Add All Classes in Namespace
12. The Editing Pane
12.1. Introduction
12.2. Mouse Behavior in the Editing Pane
12.2.1. Button 1 Click
12.2.2. Button 1 Double Click
12.2.3. Button 1 Motion
12.2.4. Shift and Ctrl modifiers with Button 1
12.2.5. Alt with Button 1 motion
12.2.6. Button 2 Actions
12.2.7. Button 2 Double Click
12.2.8. Button 2 Motion
12.3. The tool bar
12.3.1. Layout Tools
12.3.2. Annotation Tools
12.3.3. Drawing Tools
12.3.4. Use Case Diagram Specific Tools
12.3.5. Class Diagram Specific Tools
12.3.6. Sequence Diagram Specific Tools
12.3.7. Collaboration Diagram Specific Tools
12.3.8. Statechart Diagram Specific Tools
12.3.9. Activity Diagram Specific Tools
12.3.10. Deployment Diagram Specific Tools
12.4. The Broom
12.5. Selection Action Buttons
12.6. Clarifiers
12.7. The Drawing Grid
12.8. The Diagram Tab
12.9. Pop-Up Menus
12.9.1. Critiques
12.9.2. Ordering
12.9.3. Add
12.9.4. Show
12.9.5. Modifiers
12.9.6. Multiplicity
12.9.7. Aggregation
12.9.8. Navigability
12.10. Notation
12.10.1. Notation Languages
12.10.2. Notation Editing on the diagram
12.10.3. Notation Parsing
13. The Details Pane
13.1. Introduction
13.2. To Do Item Tab
13.2.1. Wizards
13.2.2. The Help Button
13.3. Properties Tab
13.4. Documentation Tab
13.5. Presentation Tab
13.6. Source Tab
13.7. Constraints Tab
13.7.1. The Constraint Editor
13.8. Stereotype Tab
13.9. Tagged Values Tab
13.10. Checklist Tab
14. The To-Do Pane
14.1. Introduction
14.2. Mouse Behavior in the To-Do Pane
14.2.1. Button 1 Click
14.2.2. Button 1 Double Click
14.2.3. Button 2 Actions
14.2.4. Button 2 Double Click
14.3. Presentation Selection
14.4. Item Count
15. The Critics
15.1. Introduction
15.1.1. Terminology
15.1.2. Design Issues
15.2. Uncategorized
15.3. Class Selection
15.3.1. Wrap DataType
15.3.2. Reduce Classes in diagram <diagram>
15.3.3. Clean Up Diagram
15.4. Naming
15.4.1. Resolve Association Name Conflict
15.4.2. Revise Attribute Names to Avoid Conflict
15.4.3. Change Names or Signatures in an Artifact
15.4.4. Duplicate End (Role) Names for an Association
15.4.5. Role name conflicts with member
15.4.6. Choose a Name (Classes and Interfaces)
15.4.7. Choose a Unique Name for an Artifact (Classes and Interfaces)
15.4.8. Choose a Name (Attributes)
15.4.9. Choose a Name (Operations)
15.4.10. Choose a Name (States)
15.4.11. Choose a Unique Name for a (State related) Artifact
15.4.12. Revise Name to Avoid Confusion
15.4.13. Choose a Legal Name
15.4.14. Change an Artifact to a Non-Reserved Word
15.4.15. Choose a Better Operation Name
15.4.16. Choose a Better Attribute Name
15.4.17. Capitalize Class Name
15.4.18. Revise Package Name
15.5. Storage
15.5.1. Revise Attribute Names to Avoid Conflict
15.5.2. Add Instance Variables to a Class
15.5.3. Add a Constructor to a Class
15.5.4. Reduce Attributes on a Class
15.6. Planned Extensions
15.6.1. Operations in Interfaces must be public
15.6.2. Interfaces may only have operations
15.6.3. Remove Reference to Specific Subclass
15.7. State Machines
15.7.1. Reduce Transitions on <state>
15.7.2. Reduce States in machine <machine>
15.7.3. Add Transitions to <state>
15.7.4. Add Incoming Transitions to <artifact>
15.7.5. Add Outgoing Transitions from <artifact>
15.7.6. Remove Extra Initial States
15.7.7. Place an Initial State
15.7.8. Add Trigger or Guard to Transition
15.7.9. Change Join Transitions
15.7.10. Change Fork Transitions
15.7.11. Add Choice/Junction Transitions
15.7.12. Add Guard to Transition
15.7.13. Clean Up Diagram
15.7.14. Make Edge More Visible
15.7.15. Composite Association End with Multiplicity > 1
15.8. Design Patterns
15.8.1. Consider using Singleton Pattern for <class>
15.8.2. Singleton Stereotype Violated in <class>
15.8.3. Nodes normally have no enclosers
15.8.4. NodeInstances normally have no enclosers
15.8.5. Components normally are inside nodes
15.8.6. ComponentInstances normally are inside nodes
15.8.7. Classes normally are inside components
15.8.8. Interfaces normally are inside components
15.8.9. Objects normally are inside components
15.8.10. LinkEnds have not the same locations
15.8.11. Set classifier (Deployment Diagram)
15.8.12. Missing return-actions
15.8.13. Missing call(send)-action
15.8.14. No Stimuli on these links
15.8.15. Set Classifier (Sequence Diagram)
15.8.16. Wrong position of these stimuli
15.9. Relationships
15.9.1. Circular Association
15.9.2. Make <association> Navigable
15.9.3. Remove Navigation from Interface via <association>
15.9.4. Add Associations to <artifact>
15.9.5. Remove Reference to Specific Subclass
15.9.6. Reduce Associations on <artifact>
15.9.7. Make Edge More Visible
15.10. Instantiation
15.11. Modularity
15.11.1. Classifier not in Namespace of its Association
15.11.2. Add Elements to Package <package>
15.12. Expected Usage
15.12.1. Clean Up Diagram
15.13. Methods
15.13.1. Change Names or Signatures in <artifact>
15.13.2. Class Must be Abstract
15.13.3. Add Operations to <class>
15.13.4. Reduce Operations on <artifact>
15.14. Code Generation
15.14.1. Change Multiple Inheritance to interfaces
15.15. Stereotypes
15.16. Inheritance
15.16.1. Revise Attribute Names to Avoid Conflict
15.16.2. Remove <class>'s Circular Inheritance
15.16.3. Class Must be Abstract
15.16.4. Remove final keyword or remove subclasses
15.16.5. Illegal Generalization
15.16.6. Remove Unneeded Realizes from <class>
15.16.7. Define Concrete (Sub)Class
15.16.8. Define Class to Implement <interface>
15.16.9. Change Multiple Inheritance to interfaces
15.16.10. Make Edge More Visible
15.17. Containment
15.17.1. Remove Circular Composition
15.17.2. Duplicate Parameter Name
15.17.3. Two Aggregate Ends (Roles) in Binary Association
15.17.4. Aggregate End (Role) in 3-way (or More) Association
15.17.5. Wrap DataType
3. Model Reference
16. Top Level Artifact Reference
16.1. Introduction
16.2. The Model
16.2.1. Model Details Tabs
16.2.2. Model Property Toolbar
16.2.3. Property Fields For The Model
16.3. Datatype
16.3.1. Datatype Details Tabs
16.3.2. Datatype Property Toolbar
16.3.3. Property Fields For Datatype
16.4. Enumeration
16.4.1. Enumeration Details Tabs
16.4.2. Enumeration Property Toolbar
16.4.3. Property Fields For Enumeration
16.5. Stereotype
16.5.1. Stereotype Details Tabs
16.5.2. Stereotype Property Toolbar
16.5.3. Property Fields For Stereotype
16.6. Diagram
16.6.1. Diagram Details Tabs
16.6.2. Diagram Property Toolbar
16.6.3. Property Fields For Diagram
17. Use Case Diagram Artifact Reference
17.1. Introduction
17.1.1. ArgoUML Limitations Concerning Use Case Diagrams
17.2. Actor
17.2.1. Actor Details Tabs
17.2.2. Actor Property Toolbar
17.2.3. Property Fields For Actor
17.3. Use Case
17.3.1. Use Case Details Tabs
17.3.2. Use Case Property Toolbar
17.3.3. Property Fields For Use Case
17.4. Extension Point
17.4.1. Extension Point Details Tabs
17.4.2. Extension Point Property Toolbar
17.4.3. Property Fields For Extension Point
17.5. Association
17.6. Association End
17.7. Dependency
17.8. Generalization
17.8.1. Generalization Details Tabs
17.8.2. Generalization Property Toolbar
17.8.3. Property Fields For Generalization
17.9. Extend
17.9.1. Extend Details Tabs
17.9.2. Extend Property Toolbar
17.9.3. Property Fields For Extend
17.10. Include
17.10.1. Include Details Tabs
17.10.2. Include Property Toolbar
17.10.3. Property Fields For Include
18. Class Diagram Artifact Reference
18.1. Introduction
18.1.1. Limitations Concerning Class Diagrams in ArgoUML
18.2. Package
18.2.1. Package Details Tabs
18.2.2. Package Property Toolbar
18.2.3. Property Fields For Package
18.3. Datatype
18.4. Stereotype
18.5. Class
18.5.1. Class Details Tabs
18.5.2. Class Property Toolbar
18.5.3. Property Fields For Class
18.6. Attribute
18.6.1. Attribute Details Tabs
18.6.2. Attribute Property Toolbar
18.6.3. Property Fields For Attribute
18.7. Operation
18.7.1. Operation Details Tabs
18.7.2. Operation Property Toolbar
18.7.3. Property Fields For Operation
18.8. Parameter
18.8.1. Parameter Details Tabs
18.8.2. Parameter Property Toolbar
18.8.3. Property Fields For Parameter
18.9. Signal
18.9.1. Signal Details Tabs
18.9.2. Signal Property Toolbar
18.9.3. Property Fields For Signal
18.10. Reception (to be written)
18.11. Association
18.11.1. Three-way and Greater Associations and Association Classes
18.11.2. Association Details Tabs
18.11.3. Association Property Toolbar
18.11.4. Property Fields For Association
18.12. Association End
18.12.1. Association End Details Tabs
18.12.2. Association End Property Toolbar
18.12.3. Property Fields For Association End
18.13. Dependency
18.13.1. Dependency Details Tabs
18.13.2. Dependency Property Toolbar
18.13.3. Property Fields For Dependency
18.14. Generalization
18.15. Interface
18.15.1. Interface Details Tabs
18.15.2. Interface Property Toolbar
18.15.3. Property Fields For Interface
18.16. Abstraction
18.16.1. Abstraction Details Tabs
18.16.2. Abstraction Property Toolbar
18.16.3. Property Fields For Abstraction
19. Sequence Diagram Artifact Reference
19.1. Introduction
19.1.1. Limitations Concerning Sequence Diagrams in ArgoUML
19.2. Object
19.2.1. Object Details Tabs
19.2.2. Object Property Toolbar
19.2.3. Property Fields For Object
19.3. Stimulus
19.3.1. Stimulus Details Tabs
19.3.2. Stimulus Property Toolbar
19.3.3. Property Fields For Stimulus
19.4. Stimulus Call
19.5. Stimulus Create
19.6. Stimulus Destroy
19.7. Stimulus Send
19.8. Stimulus Return
19.9. Link
19.9.1. Link Details Tabs
19.9.2. Link Property Toolbar
19.9.3. Property Fields For Link
20. Statechart Diagram Artifact Reference
20.1. Introduction
20.1.1. Limitations Concerning Statechart Diagrams in ArgoUML
20.2. State
20.2.1. State Details Tabs
20.2.2. State Property Toolbar
20.2.3. Property Fields For State
20.3. Action
20.3.1. Action Details Tabs
20.3.2. Action Property Toolbar
20.3.3. Property Fields For Action
20.4. Composite State
20.5. Concurrent Region
20.6. Submachine State
20.7. Stub State
20.8. Transition
20.8.1. Transition Details Tabs
20.8.2. Transition Property Toolbar
20.8.3. Property Fields For Transition
20.9. Event
20.9.1. Event Details Tabs
20.9.2. Event Property Toolbar
20.9.3. Property Fields For Event
20.10. Guard
20.10.1. Guard Details Tabs
20.10.2. Guard Property Toolbar
20.10.3. Property Fields For Guard
20.11. Pseudostate
20.11.1. Pseudostate Details Tabs
20.11.2. Pseudostate Property Toolbar
20.11.3. Property Fields For Pseudostate
20.12. Initial State
20.13. Final State
20.13.1. Final State Details Tabs
20.13.2. Final State Property Toolbar
20.13.3. Property Fields For Final State
20.14. Junction
20.15. Choice
20.16. Fork
20.17. Join
20.18. Shallow History
20.19. Deep History
20.20. Synch State
20.20.1. Synch State Details Tabs
20.20.2. Synch State Property Toolbar
20.20.3. Property Fields For Synch State
21. Collaboration Diagram Artifact Reference
21.1. Introduction
21.1.1. Limitations Concerning Collaboration Diagrams in ArgoUML
21.2. Classifier Role
21.2.1. Classifier Role Details Tabs
21.2.2. Classifier Role Property Toolbar
21.2.3. Property Fields For Classifier Role
21.3. Association Role
21.3.1. Association Role Details Tabs
21.3.2. Association Role Property Toolbar
21.3.3. Property Fields For Association Role
21.4. Association End Role
21.4.1. Association End Role Details Tabs
21.4.2. Association End Role Property Toolbar
21.4.3. Property Fields For Association End Role
21.5. Message
21.5.1. Message Details Tabs
21.5.2. Message Property Toolbar
21.5.3. Property Fields For Message
22. Activity Diagram Artifact Reference
22.1. Introduction
22.1.1. Limitations Concerning Activity Diagrams in ArgoUML
22.2. Action State
22.2.1. Action State Details Tabs
22.2.2. Action State Property ToolBar
22.2.3. Property fields for action state
22.3. Action
22.4. Transition
22.5. Guard
22.6. Initial State
22.7. Final State
22.8. Junction (Decision)
22.9. Fork
22.10. Join
22.11. ObjectFlowState
23. Deployment Diagram Artifact Reference
23.1. Introduction
23.1.1. Limitations Concerning Deployment Diagrams in ArgoUML
23.2. Node
23.2.1. Node Details Tabs
23.2.2. Node Property Toolbar
23.2.3. Property Fields For Node
23.3. Node Instance
23.3.1. Node Instance Details Tabs
23.3.2. Node Instance Property Toolbar
23.3.3. Property Fields For Node Instance
23.4. Component
23.4.1. Component Details Tabs
23.4.2. Component Property Toolbar
23.4.3. Property Fields For Component
23.5. Component Instance
23.5.1. Component Instance Details Tabs
23.5.2. Component Instance Property Toolbar
23.5.3. Property Fields For Component Instance
23.6. Dependency
23.7. Class
23.8. Interface
23.9. Association
23.10. Object
23.11. Link
24. Built In DataTypes, Classes, Interfaces and Stereotypes
24.1. Introduction
24.1.1. Package Structure
24.1.2. Exposure in the model
24.2. Built In Datatypes
24.3. Built In Classes
24.3.1. Built In Classes From java.lang
24.3.2. Built In Classes From java.math
24.3.3. Built In Classes From java.net
24.3.4. Built In Classes From java.util
24.4. Built In Interfaces
24.5. Built In Stereotypes
Glossary
A. Supplementary Material for the Case Study
A.1. Introduction
A.2. Requirements Documents (To be written)
A.2.1. Vision Document (To be written)
A.2.2. Use Case Specifications (To be written)
A.2.3. Supplementary Requirements Specification (To be written)
B. UML resources
B.1. The UML specs (To be written)
B.2. UML related papers (To be written)
B.2.1. UML action specifications (To be written)
B.3. UML related websites (To be written)
C. UML Conforming CASE Tools
C.1. Other Open Source Projects (To be written)
C.2. Commercial Tools (To be written)
D. The C++ Module
D.1. Modeling for C++
D.1.1. Class tagged values
D.1.2. Attribute tagged values
D.1.3. Parameters
D.1.4. Preserved sections
E. Limits and Shortcomings
E.1. Diagram Canvas Size
E.2. Missing functions
F. Open Publication License
F.1. Requirements On Both Unmodified And Modified Versions
F.2. Copyright
F.3. Scope Of License
F.4. Requirements On Modified Works
F.5. Good-Practice Recommendations
F.6. License Options
F.7. Open Publication Policy Appendix:
G. The CRC Card Methodology
G.1. The Card
G.2. The Group
G.3. The Session
G.4. The Process
Index

Prefacio

El dise??o de software es una tarea cognitiva dificil. Los dise??adores deben construir manualmente dise??os, pero la dificultad principal es la toma de decisiones en lugar de la entrada de datos. Si los dise??adores mejoran sus capacidades de toma de decisiones, ello resultar??a en mejores dise??os.

Las herramientas CASE actuales proporcionan automatizaci??n e interfaces gr??ficos de usuario que reducen el trabajo manual de construir un dise??o y transformar un dise??o en codigo. Ayudan a los dise??adores en la toma de decisiones principalmente proporcionando visualizaci??n de los diagramas de dise??o y comprobaciones sintacticas simples.. Adenas muchas herramientas CASE proporcionan beneficios sustanciales en el area de control de versiones y mecanismos de dise??o concurrente. Un area de soporte de dise??o que no ha sido bien soportada es el analisis de decisiones de dise??o.

Las herramientas CASE actuales son utiles en que proporcionan una GUI (Graphic User Interface; Interfaz Grafica de Usuario) que permite a los dise??adores acceder a todas las caracteristicas proporcionadas por la herramienta. Y soportan el proceso de dise??o en que permiten al dise??ador construir diagramas en el estilo de metodologias de dise??o populares. Pero tipicamente no porporcionan soporte de proceso para guiar al dise??ador a traves de la tarea de dise??o. En su lugar, los dise??adores tipicamente comienzan con una p??gina en blanco y deben recordar cubrir todos los aspectos del dise??o.

ArgoUML es un entorno de dise??o orientado a dominio que proporciona soporte cognitivo de dise??o orientado a objetos. ArgoUML proporciona algunas de las mismas caracteristicas de automatizaci??n de una herramienta CASE comercial, pero esta enfocado en caracteristicas que soportan las necesidades cognitivas de los dise??adores. Estas necesidades cognitivas estan descritas por tres teorias cognitivas.

  1. reflection-in-action;

  2. opportunistic design; and

  3. comprehension and problem solving.

ArgoUML esta basado en la especificaci??n UML 1.4 . El nucleo del modelo de repositorio es una implementaci??n de el Java Metadata Interface (JMI) que directamente soporta MOF y usa la versi??n legible por maquina de la especificaci??n UML 1.4 proporcionada por OMG.

Ademas, es nuestra meta proporcionar soporte exhaustivo para OCL (el Object Constraint Language) y XMI (el formato XML Model Interchange).

ArgoUML fue originariamente desarrollado por un peque??o grupo de gente como un proyecto de investigaci??n. ArgoUML tiene muchas caracteristicas que lo hacen especial, pero no implementa todas las caracteristicas que una herramienta CASE comercial proporciona.

La publicaci??n V0.20 actual de ArgoUML, implementa todos los tipos de diagramas de UML 1.4 standard (versiones de ArgoUML anteriores a 0.20 implementaban la UML 1.3 standard). Est?? escrito en Java y funciona en todo sistema que proporcione una plataforma Java 2 de Java 1.4 o posterior. Usa formatos de archivo abiertos XMI (formato XML Metadata Interchange) (para la informaci??n de modelos) y PGML (Precision Graphics Markup Language) (para informaci??n gr??fica) para almacenamiento. Cuando ArgoUML implemente UML 2.0, PGML sera sustituido por la especificaci??n UML Diagram Interchange.

Este manual es el trabajo acumulativo de muchas personas y ha estado evolucionando durante muchos a??os. Conectado con la publicaci??n 0.10 de ArgoUML, Jeremy Bennett, escribi?? gran cantidad de nuevo material que fue a??adido a las vestiones anteriores por Alejandro Ramirez, Philippe Vanpeperstraete y Andreas Rueckert. El ademas a??adi?? cosas de algunos de los otros documentos como el libro de cocina de los desarrolladores por Markus Klink y Linus Tolke, la Guia R??pida por Kunle Odutola, y el FAQ (Preguntas frecuentes) por Dennis Daniels. Conectado con la publicaci??n 0.14 se realizaron cambios por Linus Tolke, y Michiel van der Wulp. Estos cambios fueron mayoritariamente adaptar el manual a las nuevas funciones y apariencia de la version 0.14 de ArgoUML, y la introducci??n del indice. Los usuarios y desarrolladores que han contribuido proporcionando ayuda valiosa, como revisiones, comentarios y observaciones mientras leen y usan este manual son demasiados para ser nombrados.

ArgoUML esta disponible gratuitamente y puede ser usado en entornos comerciales. Para los terminos de uso, mira el acuerdo de licencia presentado cuando tu descargas ArgoUML. Estamos proporcionando el codigo fuente de ArgoUML para que puedas revisarlo, adecuarlo a tus necesidades y mejorarlo. Pasado el tiempo, esperamos que ArgoUML evolucione en una poderosa y util herramienta que todos puedan usar.

Este Manual de Usuario esta orientado al dise??ador, quien desea hacer uso de ArgoUML. El manual esta escrito asumiendo familiaridad con UML, pero eventualmente puede ayudar a aquellos nuevos en UML.

El manual esta escrito en DocBook/XML y esta disponible como HTML y PDF.

El proyecto ArgoUML da la bienvenida a aquellos que quieren estar mas involucrados. Mira en project website para encontrar mas informaci??n.

??Dinos que piensas sobre este Manual de Usuario! Tus comentarios nos ayudaran a mejorar cosas. Mira Section 1.3.3, “Retroalimentaci??n por el Usuario” .

Chapter 1. Introducci??n

1.1. Origenes y Visi??n General de ArgoUML

1.1.1. Analisis Orientado a Objeto y Dise??o

Durante la ??ltima decada, el Analisis Orientado a Objeto y Dise??o (Object Oriented Analysis and Design; OOA&D) se ha convertido en el paradigma de desarrollo de software dominante. Con ello se ha conseguido un gran avance en los procesos de pensamiento de todos los involucrados en el ciclo de vida del desarrollo des software.

El soporte de objetos en un lenguaje de programaci??n empez?? con Simula 67, pero fue la aparici??n en la decada de 1980 de los lenguajes h??bridos, como es C++, Ada y Object Pascal lo que permiti?? a OOA&D despegar. Estos lenguajes proporcionaban soporte para OO ademas de para programaci??n procedural. La programaci??n Orientada a Objeto se convirti?? en la corriente dominante.

Un sistema OO est?? dise??ado y implementado como una simulaci??n del mundo real usando artefactos software. Esta premisa es tan potente como simple. Usando un acercamiento OO para dise??ar un sistema puede ser dise??ado y testeado (o mas correctamente simulado) sin tener que construir el sistema real primero.

Es el desarrollo durante la decada de 1990 de herramientas para soportar analisis Orientado a Objeto y dise??o lo que coloco este enfoque en la corriente dominante. Cuando se combina con la capacidad de dise??ar sistemas a muy alto nivel, una herramienta basada en el enfoque OOA&D ha permitido la implementaci??n de sistemas mas complejos que los posibles previamente.

El ??ltimo factor que ha propulsado OOA&D ha sido su idoneidad para modelar interfaces graficos de usuario. La popularidad de lenguajes graficos orientados a objeto y basados en objeto como Visual Basic y Java refleja la efectividad de este enfoque.

1.1.2. El Desarrollo de ArgoUML

Durante la decada de 1980 un n??mero de metodolog??as de procesos OOA&D y notaciones fueron desarrolladas por diferentes equipos de investigaci??n. Se hizo patente que habia muchos temas comunes y, durante la decada de 1990, un enfoque unificado para la notaci??n OOA&D fu?? desarrollado bajo el auspicio del Object Management Group. Este estandar se hizo conocido como el Unified Modeling Language (UML), y ahora es el lenguaje estandar para comunicar conceptos OO.

ArgoUML fu?? concebido como un entorno y herramienta para usar en el analisis y dise??o de sistemas de software orientados a objeto. En este sentido es similar a muchos de las herramientas CASE comerciales que son vendidas como herramientas para modelar sistemas software. ArgoUML tiene un n??mero de distinciones muy importantes de muchas de esas herramientas.

  1. ArgoUML se enfoca en investigaci??n en psicolog??a cognitiva para proporcionar nuevas caracteristicas que incrementen la productividad soportando las necesidades cognitivas de dise??adores y arquitectos de software orientado a objeto.

  2. ArgoUML soporta estandares abiertos extensivamente???UML, XMI, SVG, OCL y otros.

  3. ArgoUML es una aplicaci??n Java pura 100%. Esto permite a ArgoUML funcionar en todas las plataformas para las cuales un puerto fiable de la plataforma Java 2 esta disponible.

  4. ArgoUML es un proyecto de codigo abierto. La disponibilidad del codigo fuente asegura que una nueva generaci??n de dise??adores de software e investigadores ahora tienen un entorno de trabajo probado desde el que pueden conducir el desarrollo y evoluci??n de tecnolog??as de herramientas CASE.

UML es el lengueje de modelado OO mas prevalente y java es una de las plataformas de desarrollo OO mas productivas. Jason Robbins y el resto de su equipo de investigaci??n en la universidad de California, Irvine potenciaron estos beneficios creando ArgoUML. El resultado es un entorno y una herramienta de desarrollo s??lida para dise??o de sistemas OO. Es mas, proporciona un campo de de pruebas para la evoluci??n del desarrollo e investigaci??n de herramientas CASE orientadas a objeto.

Una primera publicaci??n de ArgoUML fue disponible en 1998 y mas de 100,000 descargas a mediados de 2001 demostr?? el impacto que este proyecto ha provocado, siendo popular en campos educacionales y comerciales.

1.1.3. Encontrando Mas Sobre el Proyecto ArgoUML

1.1.3.1. Como est?? desarrollado ArgoUML

Jason Elliot Robbins fund?? el Proyecto Argo y proporciono un liderazgo temprano al proyecto. Mientras Jason permanece activo en el proyecto, ??l ha dejado el liderazgo. El proyecto continua avanzando fuertemente. Hay mas de 300 miembros en la lista de correo de desarrollador (mira http://argouml.tigris.org/servlets/ProjectMailingListList), Con un par de docenas de ellos formando el nucleo del grupo de desarrollo..

La lista de correo del desarrollador es el lugar donde toda la discusi??n sobre las ultimas tareas toma lugar, y los desarrolladores discuten las direcciones que el proyecto deber??a tomar. Aunque controvertido a veces, estas discusiones son mantenidas siempre correctas y amigables (sin flame-wars y esas cosas), as?? que los novatos (newbies) no deberian dudar y participar en ellas. Siempre tendras una calurosa bienvenida all??.

Si quires aprender como se gestiona el proyecto y como contribuir a ??l, vete a ArgoUML Web Site Developer Zone y busca a traves de la documentaci??n all?? expuesta.. El Libro de Cocina del Desarrollador (Developers' Cookbook) fu?? escrito especificamente para este proposito.

1.1.3.2. Mas sobre la Infraestructura

Ademas de la lista de correo del desarrollador, existe tambien una lista de correo para usuarios (mira The ArgoUML Mailing List List ), donde podemos discutir problemas desde la perspectiva del usuario. Los desarrolladores tambien leen esa lista, as?? que generalmente se proporciona ayuda altamente cualificada.

Antes de postear en esta lista, deberias echar un vistazo al user FAQ mantenido por Ewan R. Grantham.

Mas informaci??n sobre ArgoUML y otros asuntos relacionados con UML est?? tambien disponible en el ArgoUML website, mantenido por Linus Tolke.

1.2. Alcance de Este Manual de Usuario

1.2.1. Audiencia Objetivo

La publicaci??n altual de este documento esta dirigida a usuarios experimentados de UML en OOA&D (quizas con otras herramientas) que desean cambiar a ArgoUML.

Publicaciones futuras soportaran dise??adores que conocen OOA&D, y desean adoptar la notaci??n UML dentro de su proceso de desarrollo.

Un objetivo a largo plazo es soportar i) aquellos que est??n aprendiendo dise??o y desean empezar con un proceso OOA&D que usa notaci??n UML, y ii) gente interesada en dise??o de codigo modularizado con un GUI.

1.2.2. Alcance

La intenci??n es que este documento proporcionar?? una guia exhaustiva, permitiendo a los dise??adores usar ArgoUML en toda su extensi??n. Esto es en dos partes.

  • Un manual tutorial, mostrando como trabajar con ArgoUML

  • Un manual de referencia completo, registrando todo lo que puedes hacer con ArgoUML.

La version 0.22 de este documento lleva a cabo la segunda de ellas.

En esta guia hay algunas cosas que no encontraras, porque est??n cubiertas en otro lugar.

  • Descripciones de como ArgoUML funciona internamente.

  • Como mejorar ArgoUML con nuevas caracteristicas y funciones.

  • Una guia de soluci??n de problemas.

  • Un indice de referencia r??pida para usar ArgoUML.

Estos est??n cubiertos en the Developers Cookbook, el FAQ, y la Quick Guide.

1.3. Visi??n General del Manual de Usuario

1.3.1. Estructura del Manual Tutorial

Chapter 2, Introducci??n (escribiendose) proporciona una visi??n general de OOA&D basada en UML, incluyendo una guia para obtener ArgoUML instalado y funcionando.

Desde Chapter 4, Captura de Requerimientos hasta Chapter 7, Code Generation, Reverse Engineering, and Round Trip Engineering se introduce en cada parte de el dise??o de procesos desde la captura de los requerimientos inicial hasta el desarrollo y construcci??n del proyecto final.

Cuando cada concepto UML es encontrado, su uso es explicado. Su uso dentro de ArgoUML es descrito. Finalmente un caso de estudio es usado para dar ejemplos de los conceptos en uso.

1.3.2. Estructura del Manual de Referencia

Chapter 8, Introduction es una visi??n general del interfaz de usuario y proporciona un resumen del soporte para los varios tipos de diagrama UML en ArgoUML. Chapter 10, The Menu bar y Chapter 11, The Explorer describen la barra de menu, y cada una de las subventanas de la interfaz de usuario, conocidas como Paneles.

Chapter 15, The Critics da detalles de todas las criticas cognitivas dentro del sistema.Finalmente ArgoUML enlazar?? directamente con este manual cuando se de notificaci??n de las criticas.

Chapter 16, Top Level Artifact Reference es una visi??n general de los artefactos (p.e. las entidades UML que pueden ser colocadas en diagramas) dentro de ArgoUML. Los siguientes cap??tulos ( Chapter 17, Use Case Diagram Artifact Reference hasta Chapter 24, Built In DataTypes, Classes, Interfaces and Stereotypes) describen los artefactos que pueden ser creados por medio de cada diagrama de ArgoUML, y sus propiedades, tambien como algunos artefactos estandar proporcionados con el sistema.

Se proporciona un Glossary completo. Appendix A, Supplementary Material for the Case Study proporciona material para suplementar el estudio de caso usado a lo largo del documento. Appendix B, UML resources y Appendix C, UML Conforming CASE Tools identifican la informaci??n subyacente en UML y las herramientas CASE UML. Appendix F, Open Publication License es una copia de la GNU Free Documentation License.

Una ambici??n futura es proporcionar un indice exhaustivo.

1.3.3. Retroalimentaci??n por el Usuario

Por favor, cuentanos que piensas sobre el Manual de Usuario. Tus comentarios nos ayudar??n a hacer mejoras. Envia por e-mail tus ideas a la Lista de Correo de Usuarios de ArgoUML. En caso de que quisieras a??adir en los capitulos sin desarrollar deberias contactar la Lista de Correo de Desarrollador de ArgoUML para comprobar que nadie mas est?? trabajando en esa parte. Te puedes subscribir a cualquiera de las listas de correo a traves de el Sitio Web de ArgoUML.

1.4. Supuestos

Esta publicaci??n del manual asume que el lector esta ya muy familiarizado con UML. Esto est?? reflejado en la sobriedad en la descripci??n de los conceptos UML en el tutorial.

El caso de estudio est?? descrito, pero a??n no totalmente a traves del tutorial. Esto ser?? realizado en futuras publicaciones del manual.

Part 1. Tutorial

Chapter 2. Introducci??n (escribiendose)

Este tutorial te llevar?? a traves de un tour sobre el uso de ArgoUML para modelar un sistema.

Un proyecto de ATM (automated teller machine; cajero automatico) ha sido escogido como caso de estudio para demostrar los varios aspectos de modelado que ArgoUML ofrece. En subsiguientes secciones vamos a desarrollar el ejemplo de Cajero Automatico en una descripci??n completa en UML. El tutorial, sin embargo, solo te guiar?? a traves de parte de ello.

En este punto deberias crear un directorio para contener tu proyecto. Nombra el directorio de forma consistente con el resto de tu sistema de archivos. Deberias nombrar los contenidos y cualquier subdirectorio de forma equivalente por razones que se haran evidentes.

El estado del modelo al final de las secciones clave estar?? disponible en archivos .zargo . Estos est??n disponibles de forma que puedes jugar con varias alternativas y restaurar al estado apropiado del modelo en tu area de trabajo. Estos archivos .zargo ser??n identificados al final de las secciones cuyo trabajo representan.

El caso de estudio ser?? un sistema de Cajero Automatico. Tu compa??oa es FlyByNight Industries. T?? vas a jugar dos papeles. El de Gestor de Proyecto (Project Manager) y el de Analista Dise??ador (Designer Analyst).

No vamos a construir ning??n Cajero Automatico fisicamente, por supuesto.

Primero te familiarizaras con el producto y luego iremos a traves de un proceso de analisis y desarrollo para un caso de prueba.

La forma en como tu compa??ia organiza su trabajo en proyectos est?? determinada normalmente por asuntos de politicas y demas cosas por el estilo, por tanto, fuera del ??mbito de este documento. Iremos dentro de como estructuras el proyecto en s?? mismo una vez que ha sido definido.

Chapter 3. OOA&D basada en UML

En este capitulo, miramos como UML como notaci??n es usado dentro de OOA&D.

3.1. Antecedentes para UML

La orientacion a Objeto como concepto ha existido desde la decada de 1960, y como concepto de dise??o desde 1972. Sin embargo fu?? en la decada de 1980 que empez?? a desarrollarse como una alternativa creible a el enfoque funcional en analisis y dise??o. Podemos idientificar un numero de factores.

  1. La aparici??n como corriente dominante de lenguajes de programaci??n OO como SmallTalk y particularmente C++. C++ fu?? un lenguaje OO pragmatico derivado de C, ampliamente usado por causa de su asociaci??n con Unix.

  2. El desarrollo de potentes estaciones de trabajo (workstations), y con ellas la aparici??n dentro de la corriente dominante de entornos de ventanas para los usuarios. Los Interfaces Graficos de Usuario (Graphical User Interfaces; GUI) tienen una estructura de objetos inherente.

  3. Un n??mero de proyectos fallidos muy publicitados, sugiriendo que el enfoque actual no era satisfactorio.

Un numero de investigadores propusieron procesos OOA&D, y con ellos notaciones. Aquellas que alcanzaron cierto exito incluyen Coad-Yourdon, Booch, Rumbaugh OMT, OOSE/Jacobson, Shlaer-Mellor, ROOM (para dise??o de tiempo real) y el hibrido Jackson Structured Development.

Durante los tempranos 1990 se hizo claro que estos enfoques tenian muchas buenas ideas, a menudo muy similares. Un gran obstaculo fu?? la diversidad de notaci??n, significando que los ingenieros tendian a tener familiaridad con una metodologia OOA&D, en lugar de el enfoque en general.

UML fu?? concevido como una notacion com??n, que ser??a de interes para todos los involucrados. El estandar original fu?? gestionado por Rational Software ( www.rational.com, en el cual tres de los investigadores clave en el campo (Booch, Jacobson y Rumbaugh estuvieron involucrados). Produjeron documentos describiendo UML v0.9 y v0.91 durante 1996. El esfuerzo fu?? tomado ampliamente por la industria a traves del Object Management Group (OMG), ya bien conocido por el estandar CORBA. Una primera propuesta, 1.0 fu?? publicada al comienzo de 1997, con una mejorada versi??n 1.1 aprobada ese oto??o.

ArgoUML est?? basado en UML v1.4, la cual fu?? adoptada por OMG en Marzo del 2000. La versi??n oficial actual es UML v1.5 fechada en Marzo del 2003, para ser reemplazada pronto por una revisi??n mayor, UML v2.0, la cual esta en sus etapas finales de estandarizaci??n y se espera completa en 2006.

3.2. Procesos Basados en UML para OOA&D

Es importante comprender que UML es una notaci??n para OOA&D. No describe ning??un proceso en particular. Cualquier proceso adoptado, llevar?? al sistema por un n??mero de fases para ser construido.

  1. Captura de Requerimientos. Esto es donde identificamos los requerimientos para el sistema, usando el lenguaje del dominio del probrema. En otras palabras, describimos el problema en los terminos del “cliente”.

  2. Analisis. Tomamos los requerimientos y empezamos a refundirlos en el lenguaje de la soluci??n???el dominio de la solution. En esta etapa, aunque pensando en terminos de una soluci??n, aseguramos mantener las cosas a un alto nivel, lejos de detalles concretos de una soluci??n especifica-lo que es conocido como abstracci??n.

  3. Dise??o. Tomamos la especificaci??n de la fase de Analisis y construimos la soluci??n con todo detalle. Nos estamos moviendo de la abstracci??n del problema a su realizaci??n en terminos concretos.

  4. Fase de Construcci??n. Tomamos el dise??o actual y lo escribimos en un lenguaje de programaci??n real. Esto incluye no solo la programaci??n, si no tambien la prueba de que el programa cumple los requerimientos (verificaci??n), probando que el programa realmente resuelve el problema del cliente (validacion) y escribiendo toda la documentaci??n de usuario.

3.2.1. Tipos de Procesos

En esta secci??n miramos a los dos tipos principales de procesos en us por la ingenier??a del software. Hay otros, pero son menos ampliamente usados.

En a??os recientes ha habido tambien un movimiento para reducir el esfuerzo requerido en desarrollar software. Esto ha llevado al desarrollo de un numero de variantes ligeras de procesos (a menudo conocidas como computacion agil o programaci??n extrema) que son apropiadas para equipos muy peque??os de ingenieros.

3.2.1.1. El Proceso en Cascada

En este proceso, cada etapa del proceso-requerimientos, analisis y construccion (codigo y prueba) es completada antes que la siguiente comienze. Esto se ilustra en Figure 3.1, “El Proceso en Cascada”.

Figure 3.1. El Proceso en Cascada

El Proceso en Cascada


Este es un proceso muy satisfactorio donde los requerimientos est??n bien dise??ados no se espera que cambien, por ejemplo automatizar un sistema manual bien probado.

La debilidad de este enfoque se muestra problemas menos bien definidos. Invaliablemente algunas de las incertidumbres en los requerimientos no ser??n clarificados hasta bien entrado el analisis y el dise??o, o incluso en fases de codificaci??n, requiriendo volver atras para rehacer trabajo.

El peor aspecto de esto, es que no cuentas con codigo que funcione hasta cerca del final del proyecto, y muy a menudo es solo en esta etapa en la que los problemas con los requerimientos originales (por ejemplo con la interfaz de usuario) se hacen visibles.

Esto est?? exacerbado, por cada etapa sucesiva requiriendo mas esfuerzo que la anterior, as?? que los costos del decubrimiento de un problema tard??o son enormemente caros. Esto esta ilustrado por la piramide en Figure 3.2, “Esfuerzo Involucrado en los Pasos del Proceso en Cascada”.

Figure 3.2. Esfuerzo Involucrado en los Pasos del Proceso en Cascada

Esfuerzo Involucrado en los Pasos del Proceso en Cascada


El proceso en cascada es probablemente a??n el proceso de dise??o dominante. Sin embargo debido a sus limitaciones esta cada vez mas siendo sustituido por procesos iterativos, particularmente por proyectos donde los requerimientos nos est??n bien definidos.

3.2.1.2. Procesos de Desarrollo Iterativo

En a??os recientes un nuevo enfoque ha sido usado, el cual anima a conseguir al menos una parte del codigo funcionando tan pronto como sea posible, para conseguir descubrir problemas antes en el ciclo de desarrollo.

Estos procesos usan unas series de “mini-cascadas”, definiendo unos pocos requerimientos (los mas importantes) primero, llevandolos a traves del analisis, dise??o y construcci??n para obtener una version temprana del producto, con funcionalidad limitada, relacionada con los requerimientos mas importantes. La retroalimentaci??n de este c??digo puede ser usada para refinar los requerimientos, apuntar problemas, etc antes de hacer mas trabajo.

El proceso es entonces repetido para requerimientos adiciones para construir un producto con un paso mas en funcionalidad. Otra vez retroalimentaci??n adicional puede ser aplicada a los requerimientos.

El proceso es repetido, hasta que finalmente todos los requerimientos han sido implementados y el producto est?? completo. Es esta iteraci??n lo que da a estos procesos su nombre. Figure 3.3, “Esfuerzo Involucrado en los Pasos de un Proceso Iterativo ” muestra como este proceso se compara con la structura piramidal del Proceso en Cascada.

Figure 3.3. Esfuerzo Involucrado en los Pasos de un Proceso Iterativo

Esfuerzo Involucrado en los Pasos de un Proceso Iterativo


El crecimiento en popularidad de los procesos iterativos est?? estrechamente unido a el crecimiento de OOA&D. Es la encapsulai??n limpia de objetos lo que permite a una parte del sistema ser contruida con trozos para el codigo restante claramente definidos.

3.2.1.2.1. El Proceso Racional Unificado

Quizas el Proceso Iterativo mejor conocido es el Proceso Racional Unificado (Rational Unified Process; RUP) de Rational Software (www.rational.com).

Este proceso reconoce que nuestra vista piramidal de porciones iguales de la cascada no es realista. En la practica las iteraciones tempranas tienden a ser pesadas en los asuntos de requerimientos de cosas (necesitas definir una cantidad razonable incluso para comenzar), mientras las iteraciones posteriores tienen mas esfuerzo en las areas de dise??o y construcci??n.

RUP reconoce que las iteraciones pueden ser agrupadas en un numero de fases deacuerdo a su etapa en el proyecto global. Cada fase puede tener una o mas iteraciones.

  • En la fase del principio (inception phase) las iteraciones tienden a ser pesadas en asuntos de requerimientos/analisis, mientras que cualquier actividad de construcci??n debe estar limitada a la emulaci??n del dise??o dentro de una herramienta CASE.

  • En la fase de elaboraci??n (elaboration phase) las iteraciones tienden a ser completar la especificaci??n de los requerimientos, y comenzar a centrarse en el analisis y el dise??o, y posiblemente la construcci??n del primer codigo real.

  • En la fase de construcci??n (construction phase) los requerimientos y analisis est??n mas o menos completos, y el esfuerzo de las iteraciones esta mayormente en dise??o y construcci??n.

  • Finalmente, en la fase de desarrollo (deployment phase) las iteraciones est??n centradas sobre la actividad de la contrucci??n, y en particular la prueba del software.

[Note]Note

Deber??a estar claro que la prueba es una parte integral de todas las fases. Incluso en las fases tempranas los requerimientos y el dise??o deberian ser probados, y esto es facilitado por una buena herramienta CASE.

Usaremos un proceso iterativo en este manual, que est?? ligeramente basado en RUP.

3.2.1.2.2. Tama??o de Iteraci??n

Una buena regla a primera vista es que una iteraci??n deber??a tomar entre seis y diez semanas para proyectos comerciales tipicos. Mas largo y probablemente habras abarcado demasiados requerimientos para hacerlos de una vez. Ademas pierdes enfoque en tener la siguiente iteraci??n completa. Mas corto y probablemente no has tomado en cuenta suficientes requerimientos para hacer un avance significativo. En este caso la sobrecarga adicional asociada con una iteraci??n puede hacerse un problema.

El n??mero total de iteraciones depende del tama??o del proyecto. Toma el tiempo estimado (trabajando fuera/adivinando que es un tema completo en si mismo), y dividelo en trozos de 8 semanas. La experiencia parece sugerir que las iteraciones se dividiran en una proporcion de alrededor de 1:2:3:3 dentro del estilo RUP de fases de inception, elaboration, construction y deployment. Un proyecto que tiene una gran imprecisi??n en su especificaci??n (algunos proyectos de investigaci??n avanzada por ejemplo) tenderan a ser mas pesados en sus fases tempranas.

Cuande se construlle un producto por contrato para un cliente el punto final esta bien definido. Sin embargo, cuando se desarrolla un nuevo producto para el mercado, una estrategia que puede se usada es decidir la fecha de lanzamiento del producto, y por tanto la fecha final para completar las labore de ingenieria (alg??n tiempo antes). El tiempo est?? entonces dividido en iteraciones, y la cantidad del producto que puede ser construido en el tiempo desarrollado. El processo iterativo es muy efectivo donde el timepo para la comercializaci??n es mas importante que la funcionalidad exacta.

3.2.1.3. Procesos de Desarrollo Recursivo

Muy pocos sistemas software est??n concevidos como artefactos monoliticos. Est??n divididos en subsistemas, modulos, etc.

Los procesos de Software son iguales, con partes tempranas del proceso definiendo una estructura de alto nivel, y reaplicando el proceso para partes de la estructura en turnos para definir cada vez mayores detalles.

Por ejemplo, el dise??o inicial de un sistema telefonico puede identificar objetos para i) manejar las lineas de telefono, ii) procesar las llamadas, iii) manejar el sistema y iv) facturar al cliente. Los procesos de software pueden entonces ser reaplicados a cada uno de esos cuatro componentes para identificar su dise??o.

OOA&D con sus limites claros a los objetos, soporta naturalmente este enfoque. Esta clase de OOA&D con desarrollo recursivo se abrevia a veces como OOA&D/RD.

El desarrollo Recursivo puede ser aplicado igualmente bien a procesos de cascada o iterativos. No es una alternativa a ellos.

3.2.2. Un Proceso de Desarrollo para este Manual

Para el proposito de este manual usaremos un proceso iterativo descendente con desarrollo recursivo, ligeramente semejante a RUP. El caso de estudio nos llevar?? a traves de la primera iteraci??n, aunque al final de la secci??n de tutorial del manual miraremos a como el proyecto se desarrollar?? hasta su finalizaci??n.

Dentro de la primera iteraci??n, abordaremos cada uno de las actividades de captura de requerimientos, analisis, dise??o y construcci??n por turno. No todas las partes del procesos est??n basadas en UML o ArgoUML. Miraremos a que otro material es necesario.

Dentro de este proceso tendremos una oportunidad para ver los varios diagramas UML en uso. El rango completo de diagramas UML y como est??n soportados est?? descrito en el manual de referencia (mira Section 16.6, “Diagram” ).

3.2.2.1. Captura de Requerimientos

Nuestra captura de requerimientos usar?? el concepto UML de Casos de Uso. Empezando con un Vision Document veremos como los Casos de Uso pueden ser desarrollados para describir todos los aspectos del comportamiento del sistema en el dominio del problema.

3.2.2.2. Analisis

Durante la etapa de analisis, introduciremos el concepto de UML de clases para permitirnos construir una visi??n de alto nivel de los objetos que conformaran la soluci??n???a veces conocida como diagrama de concepto.

Introduciremos el diagrama de sequencia y diagrama de estados para capturar requerimientos por el comportamiento global del sistema.

Finalmente, tomaremos los Casos de Uso de la etapa de captura de requerimientos, y remoldearlos en el lenguaje del dominio de la soluci??n. Esto ilustrar?? las ideas UML de estereotipado y realizaci??n.

3.2.2.3. Dise??o

Usamos el diagrama de paquetes UML para organizar los componentes del proyecto. Luego revisaremos el diagrama de clases, diagrama de secuencia y diagrama de estados, para mostrar como pueden ser usados recursivamente para dise??ar la soluci??n completa.

Durante esta parte del proceso, necesitamos desarrollar nuestra arquitectura del sistema, para definir como todos los componentes ajustaran juntos y funcionaran.

Aunque no es estrictamente parte de nuestro proceso, miraremos a como el diagrama de colaboraci??n UML puede ser usado como una alternativa para, o complementar el diagrama de secuencia. Similarmente miraremos al diagrama de actividades UML como una alternativa o complemento para el diagrama de estado.

Finalmente usaremos el diagrama de despliege UML para especificar como el sistema ser?? finalmente realizado.

3.2.2.4. Construcci??n

UML no est?? realmente afectado con la escritura de codigo. Sin embargo, en esta etapa mostraremos como ArgoUML puede ser usado para generaci??n de codigo.

Tambien miraremos a como el Diagrama de Casos de Uso UML y la Especificaci??n de Casos de Uso son herramientas invalorables para un programa de prueba.

3.3. Por que ArgoUML es Diferente

En la introducci??n, listamos las cuatro aspectos clave que hacen a ArgoUML diferente: i) hace uso de ideas de psicologia cognitiva, ii) est?? basado en estandares abiertos; iii) es 100% Java puro; y iv) es un proyecto de codigo abierto.

3.3.1. Psicolog??a Cognitiva

3.3.1.1. Teor??a

ArgoUML est?? particularmente inspirado en tres teorias dentro de la psicolog??a cognitiva: i) reflexi??n-en-acci??n, ii) dise??o oportunista iii) y comprensi??n y resoluci??n de problemas.

  • Reflexi??n-en-Acci??n

    Esta teor??a observa que los dise??adores de sistemas complejos no conciven un dise??o totalmete formado. En su lugar, deben construir un dise??o parcial, evaluarlo, reflexionar en el, y revisarlo, hasta que est??n listos para extenderlo mas all??.

    Como los desrrolladores trabajan directamete sobre el dise??o, sus modelos mentales de la situaci??n del problema mejoran, por lo tanto mejoran sus dise??os.

  • Dise??o Oportunista

    Una teor??a dentro de la psicolog??a cognitiva sugiere que aunque los dise??adores planean y describen su trabajo de una forma jerarquica ordenada, en realidad, escogen tareas sucesivas basados en el criterio de costo cognitivo.

    Explicado simplemente, los dise??adores no sigue incluso sus propios planes en orden, si no que escogen pasos que son mentalmente menos caros entre las alternativas.

  • Comprensi??n y Resoluci??n de Problemas

    Una teor??a de visualizaci??n de dise??o dentro de la psicolog??a cognitiva. La teor??a expone que los dise??adores deben cubrir un hueco entre su modelo mental del problema o situaci??n y el modelo formal de una soluci??n o sistema.

    Esta teor??a sugiere que los programadores de beneficiaran de:

    1. Representaciones multiples como descomposici??n sintactica del programa, transiciones de estado, flujo de control, y flujo de datos. Estos permiten al programador identificar mejor elementos y relaciones en el problema y soluci??n y por lo tanto mas facilmente crear un mapeo entre sus modelos de situaci??n y modelos del funcionamiento del sistema.

    2. Aspectos familiares de un modelo de situaci??n, que mejoran las abilidades de los dise??adores para formular soluciones.

3.3.1.2. Aplicaci??n Practica en ArgoUML

ArgoUML implementa estas teor??as usando un numero de tecnicas .

  1. El dise??o de un interfaz de usuario que permite al usuario ver el dise??o desde un numero de perspectivas diferentes, y permite al usuario alcanzar objetivos a traves de un numero de rutas alternativas.

  2. El uso de procesos ejecutandose en paralelo con la herramienta de dise??o, evaluando el dise??o actual contra modelos de como un dise??o de la “mejor practica” puede funcionar. Estos procesos son conocidos como criticos de dise??o.

  3. El uso de listas de tareas pendientes (to-do lists) para comunicar sugerencias desde los criticos de dise??o al usuario, ademas de permitir al usuario registrar areas para acciones futuras.

  4. El uso de listas de validaci??n, para guiar al usuario a traves de un proceso complejo.

3.3.2. Estandares Abiertos

UML es en si mismo un estandar abierto. ArgoUML sobre todo ha intentado usar estandares abiertos para todas sus interfaces.

La ventaja clave de la adherencia a los estandares abiertos es que ello permite un facil inter-funcionamiento entre aplicaciones, y la abilidad de moverse de una aplicaci??n a otra como sea necesario.

3.3.2.1. XML Metadata Interchange (XMI)

XML Metadata Interchange (XMI) es el estandar para guardar los meta-datos que confeccionan un modelo UML particular. En principio esto te permitir?? tomar el modelo que has creado en ArgoUML y importarlo dentro de otra herramienta.

Esto claramente tiene ventajas in permitir al UML alcanzar su meta de ser un estandar para la comunicaci??n entre dise??adores.

La realidad no es tan buena. Anteriormente a UML 2.0 el archivo XMI no incluye informaci??n sobre la representaci??n grafica de los modelos, as?? que el dise??o del diagrama est?? perdido. ArgoUML rodea este problema guardando la informaci??n grafica separada del modelo (mira Section 3.4.3.1, “Cargando y Guardando”).

3.3.2.2. Formatos Graficos - EPS, GIF, PGML, PNG, PS, SVG

  • Encapsulated PostScript (EPS) es un archivo PostScript que satisface restricciones adicionales. Estas restricciones estan previstas para hacer mas facil para el software incrustar un archivo EPS dentro de otro documento PostScript.

  • Graphics Interchange Format (GIF) es un formato cubierto por patente, aunque las patentes se agotaran en Agosto del 2006.

  • Precision Graphics Markup Language (PGML) es un lenguaje basado en XML para representar graficos vectoriales. Fu?? un borrador de la W3C, pero no fu?? adoptado como recomendaci??n. PGML y VML, otro lenguaje basado en XML para graficos vectoriales, fueron luego fusionados y mejorados para crear juntos el formato SVG.

  • Portable Network Graphics (PNG) es un estandar de ISO/IEC (15948:2004) y es tambien una recomendaci??n de la W3C. PNG es un formato de imagen de mapa de bits que emplea compresi??n de baja perdida. PNG fu?? creado para mejorar y sustituir el formato GIF con un formato de archivos de imagen que no requiriera de una licencia de patense para ser usado. PNG es oficialmente pronunciado "ping" pero a menudo es simplemente deletreado ??? probablemente para evitar confusi??n con la utilidad de red ping. PNG est?? soportado por la librer??a de referencia libpng, una librer??a independiente de la plataforma que contiene funciones C para el manejo de imagenes PNG.

  • PostScript (PS) es un lenguaje de descripci??n de pagina y lenguaje de programaci??n usado primeramente en la areas de publicaci??n asistida por ordenador y electronica.

  • Scalable Vector Graphics (SVG) es un lenguaje de marcado XML para describir graficos vectoriales bidimensionales, estaticos y animados, y de forma declarativa o mediante scrip. Es un estandar abierto creado por el World Wide Web Consortium. El uso de SVG en la web esta en sus primeros pasos. Hay un gran problema en la inercia debida al largo tiempo de uso de formatos basados en mapas de bits y otros formatos como Macromedia Flash or Java applets, pero ademas el soporte por navegadores web es todav??a desigual, con soporte nativo en Opera y Firefox, pero Safari y Internet Explorer necesitan un plugin. Mira PGML mas arriba.

3.3.2.3. Object Constraint Language (OCL)

Object Constraint Language (OCL) es un lenguaje declarativo para describir reglas que se aplican a modelos UML. Fu?? desarrollado en IBM y ahora es parte del estandar UML. Inicialmente OCL fu?? solo una especificaci??n formal de una extensi??n de lenguaje para UML. OCL puede ahora ser usado con cualquier metamodelo compatible con Meta-Object Facility (MOF), incluyendo UML. El Object Constraint Language es un lenguaje de texto preciso que proporciona limitaci??n y expresiones de acceso a objeto en cualquier modelo MOF o metamodelo que de otra forma no puede ser expresado por notaci??n diagramatical.

3.3.3. 100% Java Puro

Java fu?? concevido como un lenguaje interpretado. No ten??a un compilador para producir codigo para cuaquier maquina particular. Compila codigo para su propio sistema, la Maquina Virtual Java (Java Virtual Machine; JVM).

Escribir un interprete para una JVM es mucho mas facil que escribir un compilador, y estas maquinas virtuales est??n ahora incorporadas dentro de casi todo Navegador Web. Como resultado, la mayoria de las maquinas pueden ejecutar Java, sin trabajo adicional.

(En caso de que te preguntes porque todos los lenguajes no son como este, es por que los lenguajes interpretados tienden a ser mas lentos que los compilados. Sin embargo, con el alto rendimiento de los modernos PCs, la ganancia en portabilidad merece la pena para muchas aplicaciones. Mas a??n, las modernas caches multinivel pueden suponer que los lenguajes interpretados, que producen un codigo mas denso, pueden realmente no ser tan lentas de todas formas.)

Mediante la elecci??n de escribir ArgoUML en Java puro, se hace inmediatamete disponible para el mayor numero de usuarios con la minima cantidad de esfuerzo.

3.3.4. Codigo Abierto

ArgoUML es un proyecto de c??digo abierto. Esto significa que cualquiera puede tener una copia gratis del c??digo fuente, cambiarlo, usarlo para nuevos propositos y cosas as??. La ??nica (gran) obligaci??n es que t?? pases tu c??digo de la misma forma a otros. La naturaleza precisa de que puedes hacer y que no puede varia de un proyecto a otro, pero el principio es el mismo.

La ventaja es que un proyecto peque??o como ArgoUML subitamente se abre a una gran cantidad de ayuda adicional de aquellos que pueden indagar en sus ideas sobre como el programa puede ser mejorado. En cualquier momento pueden ser 10, 15, 20 o mas personas haciendo contribuciones significantes a ArgoUML. Hacer esto comercialmente costar??a mas de 1 millon de $ al a??o.

No es solo un espiritu de puro altruismo. Contribuir en un camino para aprender “con las manos en la masa” sobre software puntero. Es una forma de adquirir visibilidad (mas de 100,000 personas han descargado ArgoUML hasta la primavera de 2001). Esto es una gran cantidad de buena esperiencia en suma ??y muchos empleadores potenciales est??n viendote!

Y es genial para el ego!

El C??digo Abierto no excluye ganar dinero. Gentleware www.gentleware.com vende una versi??n comercial de ArgoUML, Poseidon. Su propuesta de valor no es un trozo de c??dogo privativo. Es el refinamiento comercial y el soporte para librarse de riesgos usando ArgoUML en un desarrollo commercial, permitiendo a los clientes tomar ventaja de la tecnolog??a puntera de ArgoUML.

3.4. Fundamentos de ArgoUML

El objeto de esta secci??n es ponerte en marcha con ArgoUML. Te llevar?? a traves de obtener el c??digo y conseguirlo ejecutar.

3.4.1. Empezando

3.4.1.1. Requerimientos del Sistema

Puesto que ArgoUML est?? escrito en Java puro 100%, deber??a funcionar en cualquier maquina con Java instalado. Es necesaria una versi??n 1.4 o posterior de Java. Puedes tenerlo disponible, pero si no, puede ser descargada gratis de www.java.com. Ten en cuenta que solo necesitas el Java Runtime Environment (JRE), no hay necesidad de descargar el Java Development Kit (JDK) completo.

ArgoUML necesita una cantidad razonable de recursos. Un PC con 200MHz de procesador, 64Mb de RAM y 10Mb de espacio disponible en un disco duro deber??a ser adecuado. Descarga el c??digo de la secci??n de Descargas de sitio web del proyecto argouml.tigris.org. Escoje la versi??n que se ajusta a tus necesidades como se describe en la siguiente secci??n.

3.4.1.2. Opciones de Descarga

Tienes tres opciones para obtener ArgoUML.

  1. Ejecutar ArgoUML directamente desde el Sitio Web usando Java Web Start. Esta el la opci??n mas facil.

  2. Descargar el c??digo binario ejecutable. Esta es la opci??n correcta si pretendes usar ArgoUML regularmente y no es muy dificil.

  3. Descargar el c??digo fuente usando CVS y compilar tu propia versi??n. Escoge esta opci??n si quieres mirar el funcionamiento interno de ArgoUML, o quieres unirte como desarrollador. Esta opci??n requiere el JDK completo (mira Section 3.4.1.1, “Requerimientos del Sistema”).

Las tres opciones est??n libremente disponibles a traves del sitio web del proyecto, argouml.tigris.org.

3.4.1.3. ArgoUML Usando Java Web Start

Hay dos pasos para esto.

  1. Instalar Java Web Start en tu maquina. Est?? disponible en java.sun.com/products/javawebstart, o a traves del enlace Java Web Start en la pagina webde ArgoUML.

  2. Haz click en el enlace Launch latest stable release de la pagina webde ArgoUML.

Java Web Start descargar?? ArgoUML, lo cachear?? y lo iniciar?? por primera vez, luego en subsiguientes inicios, comprueba si ArgoUML est?? actualizado y solo descarga cualquier parte actualizada y luego lo inicia. La pagina web de ArgoUML tambien proporciona detalles iniciando ArgoUML desde la consola de Java Web Start.

3.4.1.4. Descargando el Binario Ejecutable

Si escoges descargar el binario ejecutable, tendras la elecci??n de descargar la ultima versi??n estable del c??digo (la cual ser?? mas fiable, pero no tiene todas las ultimas caracteristicas), o la versi??n actual (la cual ser?? menos fiable, pero tiene mas caracteristicas). Escoge deacuerdo con tu situaci??n.

ArgoUML est?? disponible en formatos .zip o tar.gz. Escoge el primero si eres un usuario de Microsoft Windows, y el ultimo si est??s ejecutando alguna variedad de Unix. Desempaquetandolo como sigue.

  • En Windows. Descomprime el archivo .zip con WinZip, o en ultimas versiones of Windows (ME, XP) copia los archivos fuera de la carpeta comprimida y ponlos en un directorio de tu elecci??n.

  • En Unix. Usa GNU tar para descomprimir y desempaquetar los archivos en un directorio de tu elecci??n tar zxvf <file>.tar.gz. Si tienes una versi??n antigual de tar, la opci??n z puede no estar disponible, as?? que usa gunzip < file.tar.gz | tar xvf -.

Deber??as tener un directorio conteniendo un numero de archivos .jar y un README.txt.

3.4.1.5. Problemas Descargando

Si te quedas completamente atascado y no tienes asistencia local, intenta el sitio web, particularmente el FAQ. Si esto a??n no resuelve el problema, intentalo en la lista de correo de usuarios de ArgoUML.

Te puedes subscribir a traves de la secci??n de listas de correo del sitio web del proyecto argouml.tigris.org, o envia un mensaje vacio a users@argouml.org con el asunto subscribe (en ingles).

Puedes entonces enviar tu problema a users@argouml.org (en ingles) and ver como otros usuarios son capaces de ayudar.

La lista de correo de usuarios es una excelente introducci??n a la actividad vital del poryecto. Si quieres estar mas involucrado hay listas de correo adicionales que cubren el desarrollo del producto y problemas en la versi??n actual y futuras.

3.4.1.6. Ejecutando ArgoUML

Como ejecutar ArgoUML depende de si usas Microsoft Windows o alguna variedad de Unix.

  • En Windows. Inicia una interfaz MSDOS por ejemplo usando Inicio/Ejecutar con “command” en el texto texto de la ventana. En la ventana, colocate en el directorio que contiene tus archivos de ArgoUML y teclea java -jar argouml.jar. Este metodo tiene la ventaja de que la informaci??n de progreso y depuraci??n es visible en la ventana DOS. De forma alternativa crea un archivo de proceso por lotes (.bat) conteniendo el comando anterior, con un acceso directo a el en el Escritorio. El archivo bat deber??a terminar con una sentencia de "pause" en caso de que se cree informaci??n de depuraci??n durante la ejecuci??n. En algunos sistemas, simplemente haciendo doble click en el archivo argouml.jar funciona. En otros hacer esto inicia un programa de compresion de archivos. Acude a las instrucciones de tu sistema operativo o busca ayuda para determinar como configurar esto.

  • En Unix. Inicia una ventana de terminal y teclea java -jar argouml.jar

3.4.1.7. Problemas Ejecutando ArgoUML

Es inusual encontrar problemas si has tenido una descarga exitosa. Si no puedes resolver el problema, prueba la lista de correo de usuario (mira Section 3.4.1.5, “Problemas Descargando”).

  • JRE equivocada. El problema mas com??n es no tener una versi??n de Java Runtime Environment suficientemente moderna (debe ser 1.4 o posterior).

  • Lenguaje equivocado. Si el producto aparece en un idioma que no sabes o no quieres leer, vete a el segundo item de menu por la izquierda en la parte superio de la pantalla. Selecciona la entrada de menu mas baja en la lista desplegada. Figure 3.5, “Estableciendo Idioma en el Panel de Apariencia” muestra esto en Ruso. Luego haz click en la segunda solapa por abajo en la columna de solapas de la izquierda. Despliega la lista como se muestra en Figure 3.5, “Estableciendo Idioma en el Panel de Apariencia”. y selecciona un idioma. Puedes ver que los idiomas esta listados en ellos mismos. El idioma seleccionado en la muestra es Alem??n donde la palabra para “Alem??n” es “Deutsch”. Tendras que salir de ArgoUML y reiniciarlo para que los cambios hagan efecto. Usa el boton X de arriba a la derecha.

Figure 3.4. Encontrando el Asistente de Configuraci??n

Encontrando el Asistente de Configuraci??n


Figure 3.5. Estableciendo Idioma en el Panel de Apariencia

Estableciendo Idioma en el Panel de Apariencia


3.4.2. El Interfaz de Usuario de ArgoUML

Antes de empezar el Caso de Estudio, necesitas familiarizarte con el interfaz de usuario. Comienza leyendo la introducci??n a la Referenc??a de la Interfaz de Usuario. Mira Chapter 8, Introduction.

Mientras pasas a traves de este tutorial se te dira que hacer, y cuando hacerlo pero como hacerlo a menudo ser?? dejado a la Referencia de la Interfaz de Usuario. No es necesario en este punto leerse toda la Referencia, pero deber??as echarle un vistazo hasta familiarizarte con como encontrar cosas en ella. Todo intento ser?? hecho para dirigirte a la parte apropiada de la Referencia en donde se aplican esos puntos en el tutorial.

Figure 3.6, “Ventana inicial de ArgoUML”, muestra la ventana principal de ArgoUML como aparece cuando es entra por primera vez en ArgoUML.

Figure 3.6. Ventana inicial de ArgoUML

Ventana inicial de ArgoUML


Agarra la barra divisoria vertical y muevela atras y adelante. Agarra la barra divisoria horizontal y muevela arriba y abajo. Juega un poco por ah?? con las peque??as flechas a la izquierda o arriba de las barras divisorias. Mira Section 8.3, “General Information About Panes”;.

3.4.2.1. El Panel Explorador

En este momento deber??as tomarte tiempo para leer Chapter 11, The Explorer. No hay mucho que puedas hacer en este punto con el Panel Explorador ya que no hay nada in el salvo la raiz del arbol (actualmente "untitledModel") y dos diagramas vac??os. Sin embargo, el Panel Explorador es fundamental para casi todo lo que haces y volveremos atras a ??l una y otra vez en lo sucesivo.

Hay un control de expansi??n y contracci??n delante del s??mbolo del paquete para “untitledModel” en el Panel Explorador y el s??mbolo de paquete para “Medium” en el Panel de Tareas Pendientes. Haz click en esos controles y observa que esos paneles son tres widgets que se comportan de forma muy parecida a como se esperar??a que hicieran. El control de expansi??n o contracci??n es un signo de mas (+)/menos (-) o un pomo dirigido a la derecha o abajo dependiendo del look and feel que has escogido como apariencia.

En este punto deber??as probar las varias opciones disponibles para un look and feel (apariencia). Usaste el editor que establece el look and feel cuando estabas seleccionando el idioma, sin embargo, solo lo viste en Ruso. Si miras la versi??n Espa??ola (Inglesa en la imagen) Section 10.4.5.4, “Appearance Tab” veras que la combobox de la zona mas alta es para seleccionar el look and feel. Cuando el panel se abre por primera vez la caja contiene el valor actual. Selecciona otra, sal de ArgoUML y reinicialo.

Seleciona alternativamente Diagrama de clase 1 y Diagrama Use Case 1 observando que el panel de detalle cambia siguiendo los objetos seleccionados en el Explorador. El panel de detalle est?? descrito en el Capitulo 12. No es necesario leer el capitulo 12 en este punto, pero tampoco te hara da??o.

3.4.2.2. El Panel de Edici??n

[Note]Note
  • Tar??a de Lectura.
  • Pasa a traves de un par de cambios.
  • A??ade algunas cosas.
  • Elimina algunas cosas.
  • Redimensiona cosas.
  • Selecciona cosas con arrastrar y soltar.
  • Seleciona cosas con click y ctrl click.
  • Edita nombres integrados.
  • Elimina "images/tutorial/editoverview.gif" del sistema de archivos.

3.4.2.3. El Panel de Detalles

[Note]Note
  • Tar??a de Lectura.
  • Item Tar??as Pendientes. Trata las diferencias con otras etiquetas sobre localizaciones de items seleccionados. Mantiene detalles para tratarlos en el Panel de Tar??as Pendientes.
  • Propiedades,
  • Documentaci??n,
  • Presentaci??n,
  • Fuente,
  • Constantes,
  • Estereotipo,
  • Valores Etiquetados,
  • Lista de Validaci??n.
  • Elimina "images/tutorial/detailsoverview.gif" del sistema de archivos.

3.4.2.4. El Panel de Tar??as Pendientes

[Note]Note
  • Tar??a de Lectura.
  • Describe prioridades.
  • Resolver items.
  • Relationa a una etiqueta de Item Pendiente en el panel de detalles.
  • Elimina "images/tutorial/todooverview.gif" del sistema de archivos.

3.4.2.5. La Barra de Men?? y Barras de Herramientas

La barra de men?? y las barras de herramientas dan acceso a todas las caracteristicas principales de ArgoUML. As?? las opciones de men??, convencionales y de la barra de herramientas que no est??n disponibles estan sombreadas y los items de men?? que invocan un cuadro de dialogo est??n seguidos por una elipsis (...).

  • Men?? Archivo. Te permite crear un nuevo proyecto, guardar y abrir poryectos, importar fuentes desde cualquier sitio, cargar y guardar el modelo en y desde una base de datos, imprimir el modelo, guardar los gr??ficos del modelo, guardar la configuraci??n del modelo y salir de ArgoUML

  • Men?? Editar. Te permite seleccionar uno o mas elementos UML en un diagrama, deshacer y rehacer ediciones, eliminar elementos de diagramas o el modelo completo, vaciar la papelera y cambiar la configuraci??n.

  • Men?? Visualizar. Te permite cambiar entre diagramas, encontras objetos en el modelo, hacer zoom en un diagrama, seleccionar una representaci??n de diagrama particular (aunque en este momento solo hay una), seleccionar una etiqueta particular en el men?? de detalles, ajustar la rejilla, ver botones en una selecci??n, y cambiar entre notaci??n UML y Java.

  • Men?? Crear Diagrama. Te permite crear cualquiera de los siete tipos de diagrama UML (clases, casos de uso, estados, actividad, colaboraci??n, desarrollo y secuencia) soportados porArgoUML.

    Los diagramas de estado y actividad solo pueden ser creados cuando una clase o actor es seleccionado, incluso las entradas relevantes del men?? estar??n sombreadas si esto no se ha realizado.

  • Men?? Colocar (Arreglo). Te permite alinear, distribuir, reordenar y desplazar objetos en un diagrama y establecer la estrategia de distribuci??n del diagrama.

  • Men?? Generar. Te permite generar c??digo Java para las clases seleccionadas o para todas las clases.

  • Men?? Cr??tica. Te permite cambiar el estado de la funci??n de auto-cr??tica entre activado y desactivado, establecer el nivel de importancia de los problemas de dise??o y metas de dise??o y inspeccionar las cr??ticas disponibles.

  • Men?? Herramientas. Este men?? est?? sombreado permanentemente a menos que halla alguna herramienta disponible en tu versi??n de ArgoUML.

  • Men?? Ayuda. Este men?? te da acceso a detalles de aquellos que crearon el sistema, y donde se puede encontrar ayuda adicional.

  • Barra de Herramientas de Archivo. Esta barra de herramientas contiene algunas de las herramientas del men?? Archivo.

  • Barra de Herramientas de Edici??n. Esta barra de herramientas contiene algunas de las herramientas de men?? Edici??n.

  • Barra de Herramientas de Visualizar. Esta barra de herramientas contiene algunas de las herramientas del men?? Visualizar.

  • Barra de Herramientas de Crear Diagrama. Esta barra de herramientas contiene algunas de las herramientas del men?? Crear Diagrama.

3.4.2.6. El Rat??n

El rat??n y los botones del rat??n (o sus equivalentes con dispositivos de entrada alternativos) son usados en una amplia variedad de formas. En esta secci??n miraremos a los modos comunes de uso.

ArgoUML asume el uso de un rat??n de dos botones. Nos referiremos a los botones como “boton 1” y “boton 2”. El boton 1 es el boton mas a la izquierda en un rat??n de diestro, y a veces llamado como el boton “selecci??n”. El boton 2 es llamado a veces como el boton “ajuste”.

  1. Click boton 1. Esta acci??n es usada generalmente para seleccionar un elemento para operaciones subsiguientes. Si el elemento es un objeto en el explorador o en el panel de edici??n ser?? resaltado.

    En el caso de la Barra de Herramientas del Panel de Edici??n, ese objeto es seleccionado como el siguiente para ser a??adido al diagrama (pero solo uno, haz doble click para a??adir multiples objetos). Puedes a??adir al diagrama moviendo el rat??n al area de edici??n y haciendo click otra vez.

  2. Doble click boton 1. Esta acci??n es identica a la de un solo click excepto, cuando es usado con la barra de herramientas del panel de edici??n. Bajo estas circunstancias el objeto seleccionado ser?? a??adido multiples veces al area de dibujado, una por cada click del boton, hasta que la herramienta es seleccionada de nuevo o se escoge otra herramienta.

  3. Click boton 2. Cuando se usa sobre elementos de texto en los paneles del explorador o de detalles, o objetos gr??ficos en el panel de edici??n, esto desplegar?? un men?? dependiente del contexto.

    Si el elemento no ha sido seleccionado a??n ser?? tambien seleccionado.

  4. Movimiento boton 1. Donde el click con boton 1 ha sido usado para desplegar un men?? de la barra de men??, el movimiento con boton 1 es usado para seleccionar elementos en ese men??.

    El movimiento con boton 1 tambien tiene un efecto en el panel de edici??n. Sobre objetos gr??ficos mover?? el objeto a una nueva posici??n. Los objetos gr??ficos son seleccionados muestran asas, y estos pueden ser usados para reescalarlo.

    Donde el objeto es alguna forma de conector entre otros elementos, otro movimiento boton 1 que no sea en una asa causar?? que se cree una nueva asa, permitiendo al conector ser articulado en ese punto. Estos nuevas asas pueden ser eliminadas moviendolas al final del conector.

  5. Movimiento boton 2. Este es usado para seleccionar elementos en un men?? sensible al contexto mostrado por el uso de un click del boton 2.

Hay otros comportamientos mas especificos que ser??n encontrados bajo los casos especificos donde son usados.

3.4.2.7. Dibujando Diagramas

En general los diagramas son dibujados usando la barra de herramientas del panel de edici??n para seleccionar el objeto deseado y haciendo click en el diagrama en la posici??n requerida como se describe en Section 3.4.2.6, “El Rat??n”. Esa secci??n tambien explica el uso del rat??n para redimensionar objetos.

Los objetos que ya est??n en el modelo, pero no en un diagrama, pueden ser a??adidos a un diagrama seleccionando el objeto en el explorador, usando Agregar al Diagrama del men?? desplegado (boton 2) sobre ese objeto, y entonces haciendo click button 1 en la posici??n deseada en el diagrama.

Ademas de objetos UML, la barra de herramaientas del panel Edici??n proporciona para los objetos de dibujados generales (rectangulos, circulos, lineas, poligonos, curvas, texto) formas de proporcionar informaci??n suplementaria para los diagramas.

3.4.2.7.1. Moviendo Elementos de Diagrama

Hay muchas maneras para mover elementos de diagrama.

3.4.2.7.1.1. Usando Teclas del Rat??n

Seleciona los elementos que quieres mover. Presionando la tecla Ctrl mientras seleccionas puedes seleccionar muchos elementos para mover el mismo tiempo.

Ahora presiona tus teclas de flecha. Los elementos seleccionados se mueven un poco con cada tecleo.

Si ademas mantienes presionada la tecla Mayusculas (Shift), se moveran un poco mas r??pido.

3.4.2.7.1.2. Usando la Barra de Herramientas del Panel de Edici??n

Haz click en el boton escoba en la barra de herramientas. Mueve tu rat??n al panel de diagrama, haz click derecho y mantenlo. Ahora mover tu rat??n alinear?? los elementos.

3.4.2.7.2. Colocando Elementos

El elemento de men?? Colocar (Arreglo) te permite alinear, agrupar, o desplazar elementos.

3.4.2.8. Trabajando con Proyectos

3.4.2.8.1. La Ventana de Inicio

Figure 3.6, “Ventana inicial de ArgoUML” muestra la ventana principal de ArgoUML como aparece justo despues de iniciar

El area de cliente de la ventana principal, debajo del men?? y la barra de herramientas, est?? subdividida en cuatro paneles. Empezando con el panel superior mas a la izquierda, y funcionando continuamente, puedes ver el Explorador, mostrando una vista de arbol de tu modelo UML, el Panel de Edici??n con su barra de herramientas, dos barras de desplazamiento y un area de gris de dibujado, el Panel de Detalles con la solapa de Tareas Pendientes seleccionada, y el Panel de Tareas Pendientes con una vista de arbol de los tareas pendientes, ordenadas de distintas maneras seleccionadas via la lista desplegable en lo alto del panel.

Cada vez que ArgoUML es iniciado sin un archivo de proyecto como argumento, un nuevo proyecto en blanco es creado. Este proyecto contiene un modelo llamado untitledModel. Este modelo contiene un Diagrama de Clases en blanco, llamado Diagrama de clase 1, y un Diagrama de Casos de Uso llamado Diagrama use case 1.

El modelo y los dos diagramas vacios se pueden ver en el explorador, que es la herramienta principal para navegar a traves de tu modelo.

Asumamos por un momento que este el el punto donde quieres empezar a modelar un nuevo sistema de compras. T?? quieres darle el nombre “purchasingmodel” a tu modelo, y quieres almacenarlo en un archivo llamado FirstProject.

3.4.2.8.2. Guardando un Proyecto - El Men?? Archivo

Por ahora ArgoUML; guarda diagramas usando un estandar propuesto recientemente, Precision Graphics Markup Language (PGML). Sin embargo, tiene la opci??n de exportar datos gr??ficos como SVG para aquellos que quieran hacer uso de ello. Cuando ArgoUML; soporte UML 2.0, almacenar?? diagramas usando el UML 2.0 Diagram Interchange format.

Primero, salva el modelo en su estado (vacio y sin nombre) actual. En la barra de men??, haz click en Archivo, luego en Guardar Proyecto como... como se muestra en Figure 3.7, “Invocando Guardar Proyecto como...”.

Figure 3.7. Invocando Guardar Proyecto como...

Invocando Guardar Proyecto como...


Por favor, date cuenta que el menu Archivo contiene las opciones usuales para crear un nuevo proyecto, para abrir un proyecto existente, para guardar un proyector bajo un nuevo nombre, para imprimir del diagrama actualmente mostrado, para guardar el diagrama mostrado actualmente como archivo, y para salir del programa.

Algunos de estos commandos de men?? pueden ser invocados presionando combinaciones, como se indica en el men?? desplegable. Por ejemplo, manteniendo presionana la tecla “Ctrl”, y presionando “N”, crearas un nuevo proyecto.

En la versi??n actual, ArgoUML solo puede contener un proyecto activo al mismo tiempo. Ademas, un poryecto solo puede contener un modelo UML. Puesto que un modelo UML puede contener un n??mero ilimitado de elementos y diagramas, esto no deber??a presentar ninguna limitaci??n seria, incluso modelando sistemas bastante grandes y complejos.

3.4.2.8.3. El Di??logo de Elecci??n de Archivo

Pero volvamos a guardar nuestro proyecto. Despues de hacer click en el comando de men?? Guardar Proyecto como..., obtenemos el dialogo de elecci??n de archivo para introducir el nomvre del archivo que deseamos usar como se muestra en Figure 3.8, “Di??logo de Elecci??n de Archivo”.

Figure 3.8. Di??logo de Elecci??n de Archivo

Di??logo de Elecci??n de Archivo


Este es un FileChooser Java estandar. Vayamos sobre ello con alg??n detalle.

La caracteristica principal y destacada, es la lista de carpetas con barras de desplazamiento en el centro del di??logo. Usando la barra de desplazamiento en la derecha, puedes moverte arriba y abajo en la lista de carpetas contenida dentro de la carpeta actualmente seleccionada. Si puedes desplazarte o no, depende de la cantidad de archivos y carpetas mostradas y ademas como est??n mostradas. Si todo ajusta, entonces la ventana no es desplazable como se ve en la ilustraci??n.

Haciendo Doble Click en una de las carpetas mostradas te introduce hace navegar dentro de esa carpeta, permitiendote navegar rapidamante entre la jerarquia de carpetas de tu disco duro.

Date cuenta que solo los nombres de carpetas, y no nombres de archivo son mostrados en el area navegable. De echo, el di??logo est?? actualmente dispuesto deacuerdo para mostrar solo archivos de proyecto ArgoUML con la extension .zargo, como puede verse en el control de la parte baja de la ventana etiquetado como Archivos de Tipo:.

Ten en cuenta tambien que el nombre de carpeta seleccionado actualmente es mostrado en el control desplegable de la parte alta de la ventana etiquetado como Buscar en:. Un unico click en una carpeta dentro del area navegable selecciona la carpeta en la pantalla pero no selecciona la carpeta para guardar.

En la parte superior del di??logo, sobre el area navegable de selecci??n de carpet??s, hay algunas herramientas mas para navegar entre carpetas.

  • El control desplegable de Carpeta. Haciendo click en la flecha hacia abajo se muestra una vista en arbol de la jerarquia de la carpeta, permitiendote navegar rapidamente en la jerarquia, y al mismo tiempo determinar rapidamente donde nos encontramos posicionados en ella.

  • El icono de Subir un Nivel. Haciendo click en este icono nos desplazaremos a la carpeta padre de la carpeta actual.

  • El icono de Principal. Haciendo click en este icono nos desplazaremos a nuestro directorio home.

  • El icono Nueva Carpeta. Haciendo click en este icono crearemos una nueva carpeta llamada "Carpeta nueva" bajo la carpeta actual. Despues de que la carpeta est?? creada puedes seleccionarla y hacer click en su nombre para cambiarle el nombre a tu elecci??n.

  • El icono de Presentaci??n de Carpetas.

De acuerdo, ahora navegamos al directorio donde queremos guardar nuestro proyecto ArgoUML, rellena el Nombre  de Archivo: con un nombre apropiado, como “PrimerProyecto” y haz click en el boton Guardar.

Ahora tienes un poryecto activo llamado PrimerProyecto, conectado al archivo PrimerProyecto.zargo.

3.4.3. Salida

3.4.3.1. Cargando y Guardando

3.4.3.1.1. Guardar archivos XMI en ArgoUML

ArgoUML guarda la informaci??n de diagrama en un archivo PGML (con extensi??n .pgml, la informaci??n del modelo en un archivo XMI (con extensi??n .xmi y la informaci??n sobre el proyecto en un archivo con extensi??n .argo. Mira Section 3.4.3.2.2, “Precision Graphics Markup Language (PGML)” y Section 3.4.3.3, “XMI” para ver mas acerca de PGML and XMI respectivamente.

Todos estos son luego comprimidos en zip en un archivo con extensi??n .zargo. Puedes extraer facilmente el archivo .xmi del archivo .zargo usando cualquier aplicaci??n generica ZIP. Intentalo y mira dentro de la magia de.

[Warning]Warning

Seguramente hacer doble click lanzara una utilidad ZIP, si una est?? instalada, y NO Argo.

3.4.3.2. Gr??ficos e Impresi??n

3.4.3.2.1. El Graph Editing Framework (GEF)

GEF es el paquete de software que es el fundamento de los diagramas que aparecen en el Panel de Edici??n. GEF fu?? una parte integral de ArgoUML pero ha sido separada. Al igual que ArgoUML es un proyecto de c??digo abierto disponible via Tigris.

3.4.3.2.2. Precision Graphics Markup Language (PGML)

PGML es el formato de almacenamiento actual para la informaci??n de diagrama usado en ArgoUML. En el futuro, PGML ser?? sustituido por el formato UML 2.0 Diagram Interchange.

3.4.3.2.3. Aplicaciones Que Abren PGML

PGML is un predecesor de SVG (mira Section 3.4.3.2.5, “Scalable Vector Graphics (SVG)”. Fu?? abandonado por el W3C Consortium.

Actualmente no hay otras herramientas que conozcamos trabajando en PGML.

3.4.3.2.4. Imprimiendo Diagramas

Seleciona un diagrama, luego vete a Archivo???Exportar Diagramas. Puedes generar formatos GIF, PostScript, Encapsulated PostScript o SVG.

3.4.3.2.5. Scalable Vector Graphics (SVG)

Un formato de gr??ficos vectoriales estandar del World Wide Web Consortium (W3C) ( http://www.w3.org/TR/SVG/).

Est?? soportado por los navegadores modernos, pero tambien puedes conseguir un plugin para navegadores antiguos en adobe.com.

3.4.3.2.6. Guardando Diagramas como SVG
  1. Seleciona .svg como el tipo de archivo.

  2. Teclea el nombre del archivo que quieras con la etiqueta .svg al final. Ejemplo midiagramauml.svg

Et viola! SVG! Pruebalo y juega con el zoom un poco... No son perfectos, as?? que si conoces algo sobre representar bonitos SVG haznoslo saber.

La mayor??a de los navegadores modernos soportan SVG. Si el tuyo no lo hace, prueba Firefox o consigue un plugin para tu navegador actual en adobe.com

[Note]Note

No tendras barras de desplazamiento para tu SVG a menos que este embebido en HTML. ??Buena suerte y haznos saber que encuentras!

3.4.3.3. XMI

ArgoUML soporta archivos XMI 1.0, 1.1, y 1.2 que contengan modelos UML 1.3 y UML 1.4. Para una mejor compatibilidad con ArgoUML, exporta tus modelos usando UML 1.4 y XMI 1.1 o 1.2. Asegurate de desactivar cualquier extensi??n propietaria (tal como datos de diagrama de Poseidon).

Con versiones UML anteriores a UML 2.0, no es posible salvar informaci??n de diagrama, asi que no ser??n transferidos diagramas.

Existe tambien una herramienta que convierte XMI a HTML. Para mas informaci??n, mira http://www.objectsbydesign.com/projects/xmi_to_html_2.html.

3.4.3.3.1. Usando XMI de Rational Rose

...

3.4.3.3.2. Usando Models Creados por Poseidon

En el di??logo Exportar proyecto a XMI, asegurate de dejar en blanco la selecci??n de Guardar con datos de diagrama.

3.4.3.3.3. Usando Modelos Creados por MagicDraw

...

3.4.3.3.4. XMI Compatibilidad con otras versiones de ArgoUML

Las versiones de ArgoUML anteriores a 0.19.7 soportaban UML 1.3/XMI 1.0. Despues de este tiempo, el formato de almacenamiento es UML 1.4/XMI 1.2 el cual no es compatible hacia atras. Posteriores versiones de ArgoUML leer??n proyectos escritos con versiones antiguas, pero no vice versa. Si puedes necesitar volver a una version antigua de ArgoUML deber??as ser cuidadoso de guardar una copia de seguridad de tus viejos proyectos.

Adicionalmente, si escribes archivos XMI que necesitan ser leidos por otras herramientas, deber??as tomar en cuenta las diferentes versiones. Las herramientas de modelado UML mas modernas deber??an leer 1.4, pero puedes tener generadores de c??digo integrados o otras herramientas que est??n atadas a UML 1.3.

3.4.3.3.5. Importando Otros Formatos XMI dentro de ArgoUML

La compatibilidad XMI entre herramientas de modelado UML ha mejorado con los a??os, pero puedes tener a??n problemas ocasionalmente.

ArgoUML no leer?? archivos XMI files que contengan modelos UML 1.5 o UML 2.0, pero deber??a ser capaz de abrir la mayor??a de los archivos UML 1.4 y UML 1.3. Si encuentras uno que no puede abrir, por favor informa del bug para que un desarrollador pueda investigar.

3.4.3.3.6. Generando Formato XMI

Selecciona el comando Exportar??? Archivo como XMI y escoge un nombre de archivo.

3.4.3.4. Generaci??n de C??digo

3.4.3.4.1. C??digo Generado por ArgoUML

Es posible compilar tu c??digo generado con ArgoUML, si bien a??n necesitas implementar los cuerpos de metodos, para obtener resultados utiles.

3.4.3.4.2. Generando C??digo para M??todos

Hasta el momento no puedes escribir c??digo para m??todos (operaciones) dentro de ArgoUML. El panel de fuentes es editable, pero los cambios son ignorados. ArgoUML es una herramienta de dise??o puro por ahora, no hay funcionalidad IDE pero el deseo est?? ah??. Puedes considerar usar Forte y ArgoUML juntos?????Es un buen rodeo del problema!

Puedes ayudarnos aqu?? si quisieras!

3.4.4. Trabajando Con Criticas de Dise??o

3.4.4.1. Los Mensajes del Panel de Tar??as Pendientes de las Criticas de dise??o

??Donde estamos ahora? Un nuevo proyecto ha sido creado, y est?? conectado al archivo PrimerProyecto.argo. Figure 3.9, “Ventana de ArgoUML Habiendo Guardado PrimerProyecto.zargo” muestra como tu ventana de ArgoUML deber??a aparecer en est?? etapa.

Figure 3.9. Ventana de ArgoUML Habiendo Guardado PrimerProyecto.zargo

Ventana de ArgoUML Habiendo Guardado PrimerProyecto.zargo


El proyecto contiene un paquete de alto nivel llamado untitledModel, el cual contiene un diagrama de clases y un diagrama de casos de uso.

Si miramos cuidadosamente a la pantalla, podemos ver que la carpeta "Medium" en el panel de Tar??as Pendientes (el panel de abajo a la izquierda) debe contener algunos elementos, ya que su icono de activaci??n est?? representado.

Hacer click en este icono abrir?? la carpeta "Medium". Una carpeta abierta es indicada por el icono .

Pero que es este Panel de “Tar??as Pendientes” de todas formas. No has grabado nada a??n que ha de ser hecho, as?? que donde se originan esos elementos.

La respuesta el simple, y es al mismo tiempo uno de los puntos fuertes de ArgoUML. Mientras estas trabajando en tu modelo UML, tu trabajo es monitorizado continuamente y de forma invisible por un trozo de c??digo llamado una cr??tica de dise??o. Esto es como un mentor personal que vigila por encima de tu hombro y te notifica cada vez que ve algo cuestionable en tu dise??o.

Las criticas son bastante poco entrometidas. Te dan una advertencia amigable, pero no te fuerzan dentro de principios de dise??o que no quieres o no te gusta seguir. Tomemos un vistazo de que nos est??n diciendo las cr??ticas. Haz click en el icono cerca de la carpeta Medium, y haz click en el elemento Revisa el nombre del paquete UntitledModel .

Figure 3.10, “Ventana ArgoUML Mostrando el Elemento de Cr??tica Revisa el Nombre del paquete UntitledModel” muestra como deber??a verse tu pantalla ahora.

Figure 3.10. Ventana ArgoUML Mostrando el Elemento de Cr??tica Revisa el Nombre del paquete UntitledModel

Ventana ArgoUML Mostrando el Elemento de Cr??tica Revisa el Nombre del paquete UntitledModel


Observa que tu selecci??n est?? destacada en rojo en el Panel de Tar??as Pendientes, y que una explicaci??n completa aparece ahora en el Panel de Detalles (el panel de abajo a la derecha). Puedes tener que redimensionar tu Panel de Detalles o desplazarloa hacia abajo para ver el mensaje completo como se muestra en nuestro ejemplo.

Lo que ArgoUML est?? intentando decirte es que normalmente, los nombres de paquetes est??n escritos en minusculas. El paquete principal por defecto creado por ArgoUML se llama untitledModel y por tanto viola un principio de dise??o. (Realmente, este podr??a ser considerado como un bug dentro de ArgoUML, pero es adecuado para demostrar el funcionamiento de las cr??ticas).

En este punto, puedes escoger cambiar el nombre del paquete manualmente, para imponer silencio en la cr??tica de dise??o por alg??n tiempo o permanentemente, o para requerir una explicaci??n mas extensa por e-mail de un experto.

No haremos nada de esto (volveremos a ello cuando hablemos sobre las cr??ticas de dise??o con mas detalle) pero usaremos otra pr??ctica caracteristica de ArgoUML???una caracteristica de autocorrecci??n.

Para hacerlo, solo hac click en el boton Siguiente (Pr??ximo) del Panel de Detalles. Esto causara que un aistente de renombar sea mostrado dentro del panel de propiedades, proponiendo usar el nombre untitledmodel (todo en minusculas).

3.4.4.2. Cr??ticas de Dise??o Funcionando: El Asistente de Renombrar Paquete

Sustitulye el nombre untitledmodel con purchasingmodel, y haz click el el botton Terminar. Figure 3.11, “Ventana de ArgoUML Mostrando el Asistente de Cr??tica para Renombrar el Paquete” muestra como la ventana de ArgoUML aparecer?? ahora.

Figure 3.11. Ventana de ArgoUML Mostrando el Asistente de Cr??tica para Renombrar el Paquete

Ventana de ArgoUML Mostrando el Asistente de Cr??tica para Renombrar el Paquete


Observa ahora como la nota de la cr??tica de dise??o en el panel de Tar??as Pendientes desaparece, dejando solo la nota A??ade elementos al paquete purchasingmodel en la lista de Tar??as Pendientes.

Si esto no ocurre al momento, espera algunos segundos. ArgoUML hace uso intensivo de muchos hilos de ejecuci??n que se ejecutan en paralelo. Esto puede causar demoras de algunos segundos antes de que la informaci??n se actualize en la pantalla.

El cambio del nombre del paquete deber??a ser reflejado en el explorador, en la esquina superior izquierda de tu ventana de ArgoUML.

Ahora estamos preparados para crear nuestro primer diagrama UML, un diagrama de Casos de Uso, pero primero guardemos lo que hemos hecho hasta ahora.

Haz click en el elemento de men?? Archivo, y seleciona Guardar Proyecto. Ahora puedes salir de forma segura de ArgoUML sin perder tu trabajo hasta el momento, o seguir creando tu primer diagrama.

3.5. El Casos de Estudio (A escribir)

A escribir...

Chapter 4. Captura de Requerimientos

4.1. Introducci??n

La captura de requerimientos el el proceso de identificar que quiere el “cliente” del sistema propuesto.

La clave en esta etapa es que estamos en el dominio de problema. En esta etapa debemos describir todo desde la perspectiva del “cliente” y en el lenguaje del “customer”.

El mayor riesgo que tenemos en la caputra de requerimientos es empezar pensando en terminos de posibles soluciones. Eso debe esperar hasta la Fase de Analisis (mira Chapter 5, Analysis). Uno de los pasos de la Fase de Analisis ser?? tomar los resultados de la Fase de Requerimientos y refundirlos en el lenguaje de la soluci??n estimada.

Recuerda que estamos usando un proceso incremental y iterativo.

Podemos tranquilamente volver atras otra vez al proceso de requerimientos mientras desmontamos el problema en trozos mas peque??os, cada uno de los cuales debe tener sus requerimientos capturados.

Ciertamente volveremos atras a traves de la fase de requerimientos en cada iteraci??n mientras buscamos definir los requerimientos del sistema mas y mas.

[Note]Note

La unica parte de la notaci??n de los requerimientos especificada por el estandar UML es el diagrama de casos de uso. El resto es especifico del proceso. El proceso descrito en este capitulo est?? muy inspirado en el Rational Unified Process.

4.2. El Prodeso de Captura de Requerimientos

Empezamos con una visi??n general del problema que estamos resolviendo y las areas clave de funcionalidad que debemos tratar en cualquier soluci??n. Este es nuestro documento de visi??n, y deber??a ser de solo algunas p??ginas de longitud.

Por ejemplo la visi??n general de un cajero automatico (automated teller machine; ATM) puede ser que deber??a soportar lo siguiente.

  1. Depositos monetarios, reembolsos monetarios y consultas de cuenta por los clientes.

  2. Mantenimiento del equipamiento por los ingenieros del banco, y descarga de depositos y carga de dinero por la sucursal local del banco.

  3. Auditorias de todas las actividades enviadas al sistema central del banco.

Desde esta visi??n general podemos extraer las actividades principales del sistema, y los agentes externos (personas, equipamiento) que est??n involucradas en estas actividades. Estas actividades son conocidad como casos de uso y los agentes externos son conocidos como actores.

Los actores pueden ser personas o maquinas. Desde un punto de vista practico es beneficioso conocer la parte implicada detras de cada maquina, puesto que solo ellos ser??n capaces de tratar con el proceso de captura de requerimientos.

Los casos de uso deber??as ser actividades significativas para el sistema. Por ejemplo el uso por el cliente del Cajero Automatico es un caso de uso. Introducir un numero PIN no lo es.

Hay una zona intermedia entre estos dos extremos. Como veremos a menudo es util dividir casos de uso muy grandes en peque??os subcasos de uso. Por ejemplo podemos tener subcasos de uso cubriendo depositos de dinero, retiradas de dinero y consultas de cuenta.

No hay una regla clara y r??pida. Algunos arquitectos preferir??n un peque??o numero de casos de uso relativamente grandes, otros en en cambio preferir??n un gr??n n??mero de peque??os casos de uso. Una regla util a primera vista es que cualquier proyecto practico deber??a requerir no mas de alrededor de 30 casos de uso (si necesita mas, deber??a ser dividido en proyectos separados).

Luego mostramos la relaci??n entre casos de uso y actores en uno o mas diagramas de casos de uso. Para un proyecto grande puede ser necesario mas de un diagrama. Normalmente los grupos de casos de uso relacionados son mostrados en un mismo diagrama.

Debemos luego dar una especificaci??n mas detallada de cada caso de uso. Esto cubre su comportamiento normal, comportamientos alternativos y cualquier precondici??n y postcondici??n. Esto se refleja en un documento conocido como especificaci??n de caso de uso o escenario de caso de uso.

Finalmente, puesto que los casos de uso son funcionales en su naturaleza, necesitamos un documento para capturar los requerimientos no funcionales (capacidad, rendimiento, necesidades de entorno, etc). Estos requerimientos son capturados en un documento conocido como una especificaci??n suplementaria de requerimientos.

4.2.1. Pasos del Proceso

Los pasos en el proceso de captura de requerimientos pueden ser resumidos como sigue.

  1. Captura una vista general del problema, y las caracteristicas deseadas de su soluci??n en el documento de visi??n.

  2. Identificar los casos de uso y actores desde el documento de visi??n y mostrar sus relaciones en uno o mas diagramas de casos de uso.

  3. Da especificaciones de casos de uso detalladas para cada caso de uso, cubriendo el comportamiento normal y alternativo, precondiciones y postcondiciones.

  4. Captura todos los requerimientos no funcionales en una especificaci??n de requerimientos suplementarios.

En cualquier proceso de desarrollo iterativo, priorizaremos, y las iteraciones tempranas se enfocaran en capturar el comportamiento clave del los casos de uso mas importantes.

La mayor??a de los procesos de captura de requerimientos modernos est??n deacuerdo con que es esencial que un representante autorizado del cliente est?? completamente involucrado a traves del proceso.

4.3. Salida del Proceso de Captura de Requerimientos

Casi todo el resultado del proceso de captura de requerimientos es documental. El unico diagrama es el diagrama de casos de uso, mostrando las relaciones entre casos de uso y actores.

4.3.1. Documento de Visi??n

Las secciones tipicas de este documento ser??an como sigue.

  • Resumen. Una declaraci??n del contexto, problema y objetivo de la soluti??n.

  • Objetivos. Que estamos intentando alcanzar (y como deseamos alcanzarlo).

  • Contexto de Mercado o Convenios Contractuales. Para un desarrollo guiado por el mercado, esto deber??a indicar mercados objetivo, diferencidores competitivos, eventos motivadores y cosas as??. Para un desarrollo contractual esto deber??a explicar los factores clave contractuales.

  • Partes Implicadas. Los usuarios (en el sentido m??s amplio) del sistema. Muchos de ellos se mapear??n en actores, o equipamiento de control que se mapea en actores.

  • Caracteristicas clave. Los aspectos funcionales clave de la soluci??n deseada al problema al nivel mas alto. Estos se mapear??n ampliamente en los casos de uso. Es de ayuda poner algo de priorizaci??n aqu??.

  • Limitaci??nes. Una visi??n general de los parametros no funcionales del sistema. Estos ser??n tratados detalle en la especificaci??n de requerimientos suplementarios.

  • Apendice. Un listado de los actores y casos de uso que ser??n necesarios para cumplir esta visi??n. Es util enlazar a estos desde las secciones tempranas para asegurar una cobertura exahustiva.

4.3.2. Diagrama de Casos de Uso

El documento de visi??n ha identificado los casos de uso y los actores. El diagrama de casos de uso captura como interaccionan. En nuestro ejemplo de Cajero Automatico hemos identificado “cliente usa cajero”, “mantener cajero” y “auditar” como los tres casos de uso principales. Hemos identificado “cliente”, ingeniero de mantenimiento“, ”“oficial de sucursal” y “sistema central” como los actores.

Figure 4.1, “Diagrama de casos de uso basico para un sistema de Cajero Automatico” muestra como esto puede ser visualizado en un diagrama de casos de uso. Los casos de uso son mostrados como ovalos, los actores como monigotes (incluso cuando son maquinas), con lineas (conocidas como asociaciones) conectando los casos de uso a los actores que est??n involucrados en ellos. Un cuadro alrededor de los casos de uso enfatiza la frontera entre el sistema (definido por los casos de uso) y los actores que son externos.

[Note]Note

No todos los analisis gustan de usar un cuadro alrededor de los casos de uso. Es un asunto de opci??n personal.

Figure 4.1. Diagrama de casos de uso basico para un sistema de Cajero Automatico

Diagrama de casos de uso basico para un sistema de Cajero Automatico


Las siguientes secciones muestran como el diagrama de casos de uso b??sico puede ser extendido para mostrar informaci??n adicional sobre el sistema que est?? siendo dise??ado.

4.3.2.1. Actores Activos y Pasivos

Los actores Activos inician la interacci??n con el sistema. Esto puede ser mostrado colocando una flecha en la asociaci??n desde el actor apuntando hacia el caso de uso. En le ejemplo del Cajero Automatico, el cliente es un actor activo.

La interacci??n con los actores pasivos es iniciada por el sistema. Esto puede ser mostrado colocando una flecha en la asociaci??n desde el caso de uso apuntando hacia el actor. En el ejemplo del Cajero Automatico el sistema central es un actor pasivo.

Este es un buen ejemplo donde la flecha ayuda, puesto que nos permite distinguir un sistema conducido por eventos (el Cajero Autom??tico inicia la interacci??n con el sistema central) de un sistema de consulta continua (el sistema central interroga al Cajero Autom??tico de tiempo en tiempo).

Donde un actor puede ser, una de dos, activo o pasivo, dependiendo de las circunstancias, la flecha puede ser omitida. En el ejemplo del Cajero Autom??tico el ingeniero del banco se ajusta a esta categor??a. Normalmente el est?? activo, poniendose en funcionamiento en cicles regulares para dar servicio al Cajero. Sin embargo is el Cajero Autom??tico detecta un fallo, puede convocar al ingeniero para repararlo.

El uso de flechas en asociaciones es referido como la navegaci??n de la asociaci??n. Veremos esto usado en otro lugar en UML mas tarde.

Figure 4.2, “Diagrama de casos de uso para un Cajero Autom??tico mostrando navegaci??n.” muestra el diagrama de casos de uso del Cajero Autom??tico con navegaci??n representada.

Figure 4.2. Diagrama de casos de uso para un Cajero Autom??tico mostrando navegaci??n.

Diagrama de casos de uso para un Cajero Autom??tico mostrando navegaci??n.


4.3.2.2. Multiplicidad

Puede ser util mostrar la multiplicidad de asociaciones entre actores y casos de uso. Con esto queremos decir cuantas instancias de un actor interacciona con cuantas instancias del caso de uso.

Po defecto asumimos que una instancia de un actor interacciona con una instancia de un caso de uso. En otros casos podemos etiquetar la multiplicidad de un extremo de la asociaci??n, una de dos con un n??mero para indicar cuantas instancias est??n involucradas, o con un rango separado por dos puntos (..). Un asterisco (*) es usado para indicar un n??mero arbitrario.

En el ejemplo del Cajero Autom??tico, solo hay un sistema central, pero el puede estar gestionando cualquier n??mero de usos de Cajero Autom??tico. Por lo tanto colocamos la etiqueta 0..* en el extremos del caso de uso. No se necesita etiqueta en el otro extremo, ya que por defecto es uno.

Un banco local tendr?? hasta tres oficiales autorizados para cargar y descargar los Cajeros Autom??ticos. Asi en el extremo del actor de la relaci??n con el caso de uso Mantenimiento Cajero Autom??tico, colocamos la etiqueta 1..3. Ellos pueden estar tratando con cualquier n??mero de Cajeros Automaticos, as?? en el otro extremo colocamos la etiqueta 0..*.

Puede haber cualquier n??mero de clientes y puede haber cualquier n??mero de sistemas de Cajero Autom??tico que pueden usar. As?? a cada extremo de la asociaci??n colocamos la etiqueta 0..*.

Figure 4.3, “Diagrama de casos de uso para un sistema de Cajero Autom??tico mostrando multiplicidad.” muestra el diagrama de casos de uso del Cajero Autom??tico con multiplicidad representada.

Figure 4.3. Diagrama de casos de uso para un sistema de Cajero Autom??tico mostrando multiplicidad.

Diagrama de casos de uso para un sistema de Cajero Autom??tico mostrando multiplicidad.


La multiplicidad puede abarrotar un diagrama, y a menudo no se muestra, excepto donde es cr??tico comprenderlo. En el ejemplo de Cajero Automatico solo elegiriamos mostrar 1..3 contra el oficial del banco, ya que todos los demas son obvios por el contexto.

4.3.2.3. Jerarqu??as de Casos de Uso

En nuestro ejemplo de Cajero Automatico hasta ahora tememos solo tres casos de uso para describir el comportamiento del sistema. Mientras los casos de uso siempre deber??an describir un trozo significativo del comportamiento del sistema, si son demasiado generales pueden ser dificiles de describir.

Podr??amos por ejemplo definir el comportamiento del caso de uso “Uso Cajero” en terminos del comportamiento de los tres casos de uso mas simples, “Depositar Dinero”, “Retirar Dinero” y “Consultas de Cuenta”. El caso de uso principal podr??a ser especificado incluyendo el comportamiento de los casos de uso subsidiarios necesarios.

Similarmente el caso de uso “Mantener Cajero” podr??a ser definido en terminos de dos casos de uso “Mantener Equipamiento” y “Recargar Cajero”. En este caso los dos actores involucrados en el caso de uso principal est??n realmente solo involucrados en uno u otro de los dos casos de uso subsidiarios y esto puede ser mostrado en el diagrama.

La descomposici??n de un caso de uso en subcasos de uso mas simples es mostrada en UML usando una relaci??n de inclusi??n, una flecha punteada desde el caso de uso principal hasta el subsidiario, con la etiqueta ??include??.

Figure 4.4. Diagrama de caso de uso para un sistema de Cajero Autom??tico mostrando relaciones de inclusi??n.

Diagrama de caso de uso para un sistema de Cajero Autom??tico mostrando relaciones de inclusi??n.


Las relaciones de inclusi??n son buenas para desmantelar los comportamientos de casos de uso en jerarquias. Sin embargo podemos tambien querer mostrar un caso de uso que es una extensi??n de un caso de uso existente para atender a una circunstancia particular.

En el ejemplo del Cajero tenemos un caso de uso cubriendo la rutina de mantenimiento del Cajero, “Mantener Equipamiento”. Tambien queremos cubrir el caso especial de una reparaci??n no programada causada por la detecci??n de un fallo interno por parte del Cajero.

Esto est?? mostrado en UML por la relaci??n de extensi??n. En el caso de uso principal, especificamos un nombre para un lugar en la descripci??n, donde una extensi??n del comportamiento podr??a ser adjuntada. El nombre y lugar son mostrados en un compartimento separado dentro del ovalo del caso de uso. La representaci??n de relaci??n de extensi??n es la misma que la de la relaci??n de inclusi??n, pero con la etiqueta ??extend??. Paralelamente a la relaci??n de extensi??on, especificamos la condicion bajo la cual ese comportamiento ser?? adjuntado.

Figure 4.5, “Diagrama de casos de uso para un sistema de Cajero Autom??tico mostrando una relaci??n de extensi??n.” muestra el diagrama de casos de uso del Cajero con una relaci??n de extensi??n a un caso de uso para reparaciones no programadas. El diagrama se est?? volviendo bastante complejo, y as?? lo hemos dividido en dos, uno para el lado del mantenimiento, el otro para el uso del cliente y auditor??a.

El caso de uso “Mantener Equipamiento” define un nombre “Unsched”, al comienzo de su descripci??n. El caso de uso extendido “Unscheduled Repair” es adjuntado ah?? cuando el Cajero detecta un error interno.

Figure 4.5. Diagrama de casos de uso para un sistema de Cajero Autom??tico mostrando una relaci??n de extensi??n.

Diagrama de casos de uso para un sistema de Cajero Autom??tico mostrando una relaci??n de extensi??n.


Los casos de uso pueden ser enlazados juntos de una forma adicional. Un caso de uso puede ser una generalizaci??n de un caso de uso subsidiario (o alternativamente el subsidiario es una especializati??n del caso de uso principal).

Esto es muy parecido a la relaci??n de extension, pero sin la limitaci??n de puntos de extensi??n especificos en los cuales el caso de uso principal puede ser extendido, y sin condiciones sobre cuando puede ser usado el caso de uso subsidiario.

La generalizaci??n est?? representada en un diagrama de casos de uso por una flecha con una linea continua y una punta de flecha blanca desde el subsidiario al caso de uso principal.

Esto puede ser util cuando un caso de uso subsidiario especializa el comportamiento del caso de uso principal en un gran n??mero de posiciones y bajo un amplio rango de circunstancias.

Sin embargo la falta de alguna restricci??n hace la generalizaci??n muy dificil de especificar con precisi??n. En general usa una relaci??n de extensi??n en su lugar.

4.3.3. La Especificaci??n de Casos de Uso

Cada caso de uso debe ser documentado para explicar en detalle el comportamiento que est?? especificando. Este documento es conocido por diferentes nombres en diferentes procesos: especificaci??n de caso de uso, escenario de caso de uso o incluso (confusamente) solo caso de uso.

Un caso de uso tipico incluir?? las siguientes secciones.

  • Nombre. El nombre del caso de uso al que esto se refiere.

  • Objetivo. Un resumen de una o dos lineas de que realiza este caso de uso por sus actores.

  • Actores. Los actores involucrados en este caso de uso, y cualquier contexto con respecto a su participaci??n.

    [Note]Note

    Esto no deber??a ser una descripci??n del actor. Eso deber??a estar asociado con el actor en el diagrama de casos de uso.

  • Pre-condici??n. Ser??a mejor llamarlas “pre-asumciones”, pero el termino usado en todos sitios es pre-condiciones. Es una declaraci??n de cualesquiera asumciones de simplificaci??n que podemos hacer al comienzo del caso de uso.

    En el ejempli del Cajero Automatico, podemos hacer la asumci??n para el caso de uso de “Mantener Equipamiento” que un ingeniero est?? siempre disponible, y no necesitamos preocuparnos sobre el caso de que una visita de mantenimiento de rutina se halla dejado pasar.

    [Caution]Caution

    Evita pre-condiciones todo lo posible. Necesitas tener la absoluta certeza de que las pre-condiciones caben bajo todas las posibles circunstancias. Si no tu sistema estar?? debilmente especificado y por lo tanto fallara cuando la pre-condici??n no es cierta. Alternativamente, cuando no tienes la certeza de que la pre-condici??n es siempre cierta, necesitaras especificar un segundo caso de uso para manejar la pre-condici??n siendo falsa. En el primer caso, las pre-condiciones son una fuente de problemas, en el segundo una fuente de mas trabajo.

  • Flujo B??sico. La secuencia lineal de pasos que descruben el comportamiento de el caso de uso en el escenar??o “normal”. Donde un caso de uso tiene un n??mero de escenarios que podr??an ser normales, uno es seleccionado arbitrariamente. Especificar el flujo b??sico est?? descrito con m??s detalle mas Section 4.3.3.1, “Especificando el Flujo Basico” abajo.

  • Flujos Alternativos. Unas series de secuencias lineales describiendo cada uno de los comportamientos alternativos al flujo b??sico. Especificar flujos alternativos est?? descrito con mas detalle en Section 4.3.3.2, “Especificando los Flujos Alternativos”.

  • Post-condiciones. Ser??a mejor llamarlas “post-asumciones”. Esta es una especificaci??n de cualesquiera asumciones que podemos hacer al final del caso de uso. Son mas utiles donde el caso de uso es uno de una serie de casos de uso subsidiarios que estan incluidos en un caso de uso principal, donde pueden formar las pre-condiciones del siguiente caso de uso que va a ser incluido.

    [Caution]Caution

    Como las pre-condiciones, las post-condiciones son mejor evitarlas. Colocan una carga en la especificaci??n de los flujos de caso de uso, para asegurar que la post-condici??n siempre se mantiene. Por lo tanto son tambien una fuente de problemas y trabajo extra.

  • Requerimientos. En un mundo ideal el documento de visi??n, los diagramas de casos de uso, las especificaciones de casos de uso y la especificacion de requerimientos suplementarios formari??n los requerimientos para un proyecto.

    Para la mayor??a de los desarrollos lideres del mercado, donde la propiedad de los requerimientos esta dentro del mismo negocio que el equipo que har?? el desarrollo, este no es normalmente el caso. El departamento de marketing puede aprender captura de requerimientos basada en casos de uso y analisis para enlazar con las actividades primarias de sus consumidores.

    Sin embargo para desarrollos externos por contrato, los consumidores pueden insistir en una “lista de caracteristicas” tradicional como la base del contrato. Cuando este es el caso, esta secci??n de la especificaci??n de casos de uso deber??a enlazar con las caracteristicas del contrato que son cubiertas por el caso de uso.

    Esto es hecho a menudo a traves de una herramienta de terceros que puede enlazar documentos, proporcionando una prueba automatizada de cobertura de requisitos, en tal caso esta secci??n no es necesaria, o puede ser generada automaticamente.

El tama??o final de la especificac??on de caos de uso depender?? de la complejidad del caso de uso. Como peque??a regla, la mayor??a de los casos de uso toman alrededor de 10-15 paginas para especificar, la mayor??a de las cuales son flujos alternativos. Si el tuyo es mucho mas largo que esto, considera simplificar el caso de uso. Si el tuyo es mucho mas peque??o considera que el caso de uso esta describiendo una parte demasiado peque??a del comportamiento.

4.3.3.1. Especificando el Flujo Basico

Todos los flujos en una especificaci??n de casos de uso son lineales (esto es que no hay ramas condicionales). Cualesquiera elecciones en los flujos son manejadas especificando otro flujo alternativo que recoge el punto de elecci??n. Es importante recordar que estamos especificando comportamiento aqui, no programandolo.

Un flujo es especificado como una serie de pasos numerados. Cada paso debe implicar alguna interacci??n con un actor, o al menos generar un cambio que sea observable externamente por un actor. La captura de requerimientos no deber??a estar especificando comportamiento interno y oculto del sistema.

Por ejemplo nosotros podemos dar la siquiente secuencia de pasos para el flujo basico del casos de uso "Retirar Dinero" en nuestro ejemplo de Cajero Automatico.

  1. Consumidor indica que se requiere recibo.

  2. Consumidor introduce cantidad de dinero requerido.

  3. Cajero Automatico verifica con el ordenador central que el consumidor puede realizar esta operaci??n.

  4. Cajero Automatico entrega el dinero a el consumidor.

  5. Cajero Automatico emite recibo al consumidor.

Recuerda que esta es un sub-caso de uso incluido en el caso de uso principal “Usar Cajero Automatico”, el cual presumiblemente manejar?? la verificaci??n de tarjetas y PINs antes de invocar este caso de uso incluido.

[Note]Note

El primer paso no es una condici??n. Tomamos como nuestro flujo b??sico el caso donde el consumidor quiere un recibo. El caso donde de consumidor no quiere un recibo ser?? un flujo alternativo.

4.3.3.2. Especificando los Flujos Alternativos

Esto captura los escenarios alternativos, como flujos lineales, mediante referencia la flujo b??sico. Inicialmente unicamente construimos una lista de los flujos alternativos.

  1. A.1.

    Consumidor no requiere recibo.

    A.2.

    La cuenta del consumidor no soportar?? el retiro de dinero.

    A.3.

    Comunicaci??n con el ordenador central est?? interrumpida.

    A.4.

    El consumidor cancela la transacci??n.

    A.5.

    El consumidor falla a coger el dinero entregado.

Subsequently we flesh out each alternate flow, by reference to the basic flow. For example the first alternate flow might look like.

  1. A.1.

    Customer does not require a receipt.

    A.1.1.

    At step 1 of the basic flow the customer indicates they do not want a receipt.

    A.1.2.

    The basic flow proceeds from step 2 to step 4, and step 5 is not used.

The convention is to number the various alternate flows as A.1, A.2, A.3, etc. The steps within an alternate flow are then numbered from this. So the steps of the first alternate flow would be A.1.1, A.1.2, A.1.3, etc.

4.3.3.3. Iterative Development of Use Case Specifications

Iterative development will prioritize the use cases, and the first iterations will address the most important.

Early iterations will capture the basic flows of the most important use cases with only essential detail and list the headings of the main alternate flows.

Later iterations will address the remaining use cases, flesh out the steps on individual alternate flows and possibly provide more detail on individual steps.

4.3.4. Supplementary Requirement Specification

This captures the non-functional requirements or constraints placed on the system. Since use cases are inherently functional in nature, they cannot capture this sort of information.

[Note]Note

Some analysts like to place non-functional requirements in a section at the end of each use case specification, containing the non-functional requirements relevant to the use case.

I don't like this for two reasons. First key non-functional requirements (for example about performance) may need to appear in many use cases and it is bad practice to replicate information. Secondly there are invariably some non-functional requirements that are system wide and need a system wide document. Hence my preference for a single supplementary requirements specification.

There should be a section for each of the main areas of non-functional requirements. The checklist provided by Ian Sommerville in his book Software Engineering (Third Edn, Addison-Wesley, 1989) is a useful guide.

  • Speed. Processor performance, user/event response times, screen refresh time.

  • Size. Main memory (and possibly caches), disc capacity.

  • Ease of use. Training time, style and detail of help system.

  • Reliability. Mean time to failure, probability of unavailability, rate of failure, availability.

  • Robustness. Time to restart after failure, percentage of events causing failure, probability of data corruption on failure.

  • Portability. Percentage of target-dependent code/classes, number of target systems.

To this we should add sections on environment (temperature, humidity, lightening protection status) and standards compliance.

4.4. Using Use Cases in ArgoUML

ArgoUML allows you to draw use case diagrams. When you create a new project it has a use case diagram created by default, named use case diagram 1. Select this by button 1 click on the diagram name in the explorer (the upper left quadrant of the user screen).

New use case diagrams can be created as needed through Create Diagram on the main menu bar or on the Create Diagram Toolbar. They are edited in the editing pane (the upper right quadrant of the user screen).

4.4.1. Actors

To add an actor to the diagram use button 1 click on the actor icon on the editing pane toolbar ( ) and then button 1 click at the location where you wish to place it. The actor can be moved subsequently by button 1 motion (i.e. button 1 down over the actor to select it, move to the new position and button 1 release to drop the actor in place.

Multiple actors can be added in one go, by using button 1 double click on the actor icon. Each subsequent button 1 click will drop an actor on the diagram. A button 1 click on the select icon ( ) will stop adding actors.

The actors name is set in its property panel. First select the actor (if not already selected) on the editing pane using button 1 click. Then click on the Properties tab in the details pane. The name is entered in the name field, and will appear on the screen.

As a shortcut, double button 1 click on the name of the actor in the editing pane (or just typing on the keyboard when an actor is selected) will allow the name to be edited directly. This is a convenient way to enter a name for a new actor.

Having created the actor, you will see it appear in the explorer (the upper left quadrant of the user screen). This shows all the artifacts created within the UML design. A drop down at the top of the explorer controls the ordering of artifacts in the explorer. The most useful are the Package-centric (default) and Diagram-centric. The latter shows artifacts grouped by the diagram on which they appear.

4.4.2. Use Cases

The procedure for adding use cases is the same as that for adding actors, but using the use case icon on the editing pane toolbar ().

By default use cases in ArgoUML do not display their extension points (for use in extend relationships). You can show the extension point compartment in one of two ways.

  1. Select the use case in the editing pane with button 1 click, then select the Style tab in the details pane and button 1 click on the Display: Extension Points check box.

  2. Use button 2 click over the use case in the editing pane to display a context-sensitive pop-up menu and from that choose Show/Show Extension Point Compartment.

The same approaches can be used to hide the extension point compartment.

4.4.2.1. Adding an Extension Point to a Use Case

There are two ways to add an extension point to a use case.

  1. Select the use case on the editing pane with button 1 click. Then click on the Add Extension Point icon ( ) on the toolbar, and a new extension point with default name and location will be added after any existing extension points.

    [Note]Note

    The Add Extension Point icon is grayed out and unusable until a use case is selected.

  2. Select the use case on the editing pane with button 1 click and then select its property tab in the details pane. A button 2 click over the Extension Points: field will bring up a context-sensitive pop-up menu. Select Add to add a new extension point.

    If any extension points already exist, they will be shown in this field on the property tab. The new extension point will be inserted immediately before the entry over which the pop-up menu was invoked. This ordering can be changed later by using the Move Up and Move Down entries on the pop-up menu.

Whichever method is used, the new extension point is selected, and its property tab can be displayed in the details pane. The name and location of the extension point are free text, set in the corresponding fields of the property tab.

An existing extension point can be edited from its property tab. The property tab can be reached in two ways.

  1. If the extension point compartment for the use case is displayed on the diagram, select the use case with button 1 click and then select the extension point with a further button 1 click. The property tab can then be selected in the details pane.

  2. Otherwise select the use case and its property tab in the details pane. A button 1 click on the desired entry in the Extension Points field will bring up the property tab for the extension point in the details pane.

The name and location fields of the extension point may then be edited.

As a shortcut, where the extension point compartment is displayed, double click on the extension point allows text to be typed in directly. This is parsed to set name and location for the extension point.

Extension points may be deleted, or their ordering changed by using the button 2 pop-up menu over the Extension Points field in the use case property tab.

Having created an extension point, it will appear in the explorer (upper left quadrant of the user screen). Extension points are always shown in a sub-tree beneath their owning use case.

4.4.3. Associations

To join a use case to an actor on the diagram use button 1 click on the association icon on the editing pane toolbar (). Hold button 1 down at the use case, move to the actor and release button 1 (or alternatively start at the actor and finish at the use case).

This will create a straight line between actor and use case. You can segment the line by holding down button 1 down on the line and moving before releasing. A vertex will be added to the line, which you can move by button 1 motion. A vertex can be removed by picking it up and sliding to one end of the line.

Multiple associations can be added in one go, by using button 1 double click on the association icon. Each subsequent button 1 down/motion/release sequence will join an actor to a use case. Use button 1 on the select icon ( ) to stop adding associations.

It is also possible to add associations using small “handles” that appear to the left and right of a use case or actor when it is selected and the mouse is over it. Dragging the handle from a use case to an actor will create an association to that actor (and similarly by dragging a handle from an actor to a use case).

Dragging a handle from a use case into empty space will create a new actor to go on the other end. Similarly dragging a handle from an actor into empty space will create a new use case.

It is possible to give an association a name, describing the relationship of the actor to the use case, although this is not usually necessary. This is done through the property tab of the association. Such a name appears alongside the association near its center.

4.4.3.1. Setting Navigation

There are two ways of setting the navigation of an association.

  1. Use button 2 click on the association to bring up a context-sensitive pop-up menu. The Navigability sub-menu has options for bi-directional navigation (the default, with no arrows) and for navigability Actor???Use Case and Use Case???Actor.

  2. Use button 1 to select the association and select its property tab in the details pane. This shows a field named Association Ends:, with entries for each end labeled by the actor or use case name and its multiplicity. Select the end that should be at the tail of the arrow with button 1 click. This brings up the property tab for the association end. Use button 1 click to uncheck the Navigability box.

    [Note]Note

    This may seem counter-intuitive, but in fact associations by default are navigable in both directions (when no arrows are shown). This process is turning off navigation at one end, rather than turning it on at the other.

You will see it is possible to give an association end a name in its property tab. This name will appear at that end of the association, and can be used to indicate the role being played by an actor or use case in an association.

For example a time management system for a business may have use cases for completing time sheets and for signing off time sheets. An employee actor may be involved in both, one as an employee, but the other in a role as manager.

4.4.3.2. Setting Multiplicity

There are two ways of setting multiplicity at the end of an association.

  1. Button 2 click over the end of an association will cause a context-sensitive pop-up menu to appear with a sub-menu labeled Multiplicity. This allows you to select from 1 (the default), 0..1, 0..* and 1..*.

  2. Bring up the property sheet for the association end as described for setting navigation (see the second option in Section 4.4.3.1, “Setting Navigation” ). A drop down menu gives a range of multiplicity options that may be selected.

The second of these two approaches has a wider range of options, although ArgoUML does not currently allow the user to set an arbitrary multiplicity.

4.4.4. Hierarchical Use Cases

4.4.4.1. Includes

The procedure for adding an include relationship is the same as that for adding an association, but using the include icon from the editing pane toolbar ( ) to join two use cases.

Since include relationships are directional the order in which the two ends are selected is important. The including (main) use case should be selected first (button 1 down) and the included (subsidiary) use case second (button 1 release).

It is possible to name include relationships using the property tab, but this is rarely done, and will not be displayed on the use case diagram.

4.4.4.2. Extends

The procedure for adding an extend relationship is the same as that for adding an include relationship, but using the extend icon from the editing pane toolbar ( ) to join two use cases.

As with include relationships, the order of selection matters. In this case, the extending (subsidiary) use case should be selected first (button 1 down) and the extending (main) use case second (button 1 release).

[Note]Note

This is the reverse of the include relationship, but reflects the way that designer's tend to think. The fact that the extend icon's arrow points upward (the opposite of the include icon) should help remind you of this.

To set a condition for the extend relationship, select the extend relationship in the editing pane (button 1 click) and then bring up its property tab in the details pane ((button 1 click on the tab). The text of the condition may be typed in the Condition field. Long conditions may be split over several lines if desired. The condition is displayed under the ??extend?? label on the diagram.

It is possible to name extend relationships using the property tab, but this is rarely done, and will not be displayed on the use case diagram.

4.4.4.3. Generalization

The procedure for adding generalizations, is the same as for adding extend relationships, but using the generalization icon from the editing pane toolbar ( ).

Since generalization is a directed relationship, the order of selection matters. The specialized use case should be selected first (button 1 down) and the generalized second (button 1 release).

It is also possible to add generalizations using small “handles” that appear to the top and bottom of a use case when it is selected. Dragging the handle at the top to another use case will create a generalization. The original use case is the specializing end, and the use case to which the handle was dragged will be the generalizing end. Dragging into empty space will create a new use case to be the generalizing end.

Similarly dragging on the bottom handle will create a generalization in which the original use case is the generalizing end.

Generalization is also permitted between actors, although its use is beyond the scope of this tutorial. Unlike use cases there are no generalization handles on actors, so generalizations must be created using the toolbar icon.

It is possible to name generalization relationships using the property tab, but this is rarely done. If a name is provided, it will be displayed on the use case diagram.

4.4.5. Stereotypes

UML has the concept of stereotyping as a way of extending the basic notation. It may prove useful for example to model a problem at both the business level and the engineering level. For both of these we will need use cases, but the use cases at the business level hold a different sort of information to those at the engineering level. Very likely they use different language and notation in their underlying use case specifications.

Stereotypes are used to label UML artifacts such as use cases, to indicate that they belong to a certain category. Such labels are shown in guillemots ( ????) above the name of the artifact on the diagram. The UML standard defines a number of standard stereotypes, and the user may define more stereotypes of his own.

You will see that ArgoUML has a drop down selector, Stereotype on every property tab. This is populated with the standard stereotypes, to which you may add your own user defined ones.

The details of stereotyping are beyond the scope of this tutorial. The reference manual (see Section 16.5, “Stereotype”) documents the support provided in ArgoUML.

[Warning]Warning

ArgoUML is missing a few of the standard UML stereotypes. In addition not all artifacts will actually display the stereotype on the diagram. At present this includes use cases and actors.

4.4.6. Documentation

ArgoUML has some simple documentation facilities associated with artifacts on a diagram. In general these should be used only to record the location of material in documents that can be handled by a mainstream editor or word processor, not the actual documentation itself.

Documentation for a particular artifact is recorded through the documentation tab in the details pane (the quadrant of the user screen at the bottom right).

In addition annotation may be added to diagrams using the text icon on the editing pane toolbar ( ).

The recommendation is that a use case diagram should use the documentation tab of actors to record information about the actor, or if the actor is complex to refer to a separate document that holds information about the actor.

The documentation tab of use cases should record the location of the use case specification. The information in a use case specification (for all but the simplest use cases) is too complex to be placed directly in the tab.

The project should also have a separate vision document and supplementary requirements specification. A text annotation on diagrams may be used to refer to these if the user finds this helpful.

[Warning]Warning

The documentation tab includes a Deprecated check box. The state of this flag is not preserved over save and load in the current release of ArgoUML

4.4.7. System Boundary Box

ArgoUML provides a series of tools to provide arbitrary graphical annotation on diagrams (we have already mentioned the text tool). These are found at the right hand end of the editing pane toolbar and are fully documented in the reference manual (see Chapter 12, The Editing Pane ).

The rectangle tool can be used to draw the boundary box. Use the button 2 context-sensitive Ordering pop-up menu to place it behind everything else. However there is no way to change its fill color from the default white. You may therefore prefer to draw the boundary box as four lines. This is the method used for the diagrams in this chapter.

[Note]Note

The editing pane in ArgoUML has a grid to which objects snap to aid in drawing. The size of this grid and its effect may be altered through the View menu (using Adjust Grid and Adjust Grid Snap). This is described fully in the reference manual (see Chapter 10, The Menu bar).

4.5. Case Study

4.5.1. Vision Document

A vision document contains more than those things needed for the modeling effort. It also contains financial and scheduling pertinent information. The following sections are those parts of the Vision Document spelled out in Section 4.3.1, “Documento de Visi??n” above. In practice this format need not be followed religiously, but is used here for consistency.

4.5.1.1. Summary

The company wishes to produce and market a line of ATM devices. The purpose of this project is to produce the hardware and the software to drive it that are both maintainable and robust.

4.5.1.2. Goals

To produce better designed products based on newer technology. Follow the MDA philosophy of the OMG by producing first a Platform Independent Model (PIM). As current modeling technology does not admit of maintaining the integrity of the connection between the PIM and Platform Specific Models (PSMs), the PIM will become comparatively stable before the first iteration of the PSM is produced. The software platform will be Java technology. The system will use a simple userid (from ATM card) and password (or PIN) mechanism.

4.5.1.3. Market Context

Equipment currently on the market is based on older technology for both hardware and software. This technology has not reached the end of its useful life, making it unlikely that the vendors of that gear are going to update it in the near future. On the other hand newer technology is available that would put us at a competitive advantage if implemented now.

4.5.1.4. Stakeholders

Among the stakeholders for this system are the Engineering Department, the Maintenance Department, and the Central Computer Facility. The full list of these stakeholders and the specific individuals representing them are.

  • Engineering.  Bunny, Bugs

  • Maintenance.  Hardy, Oliver

  • Computer Facility.  Laurel, Stanley

  • Chief Executive Officer.  Hun, Atilla The

  • Marketing.  Harry, Oil Can

4.5.1.5. Key Features

Cash deposit, cash withdrawal, and account inquiries by customers. Customers include people who have accounts at the owning bank as well as people who wish to make withdrawals from accounts in other banks or from credit card accounts.

Maintenance of the equipment by the bank's engineers. This action may be initiated by the engineer on a routine basis. It may also be initiated by the equipment that can call the engineer when it detects an internal fault.

Unloading of deposits and loading of cash by officials of the local bank branch. These actions occur either on a scheduled basis or when the central computer determines that the cash supply is low or the deposit receptacle is liable to be getting full.

An audit trail for all activities will be maintained and sent periodically to the bank's central computer. It will be possible for the maintenance engineer to save a copy of the audit trail to a diskette for transporting to the central computer.

Both dialup and leased line support will be provided. The ATM will continue to provide services to customers when communications with the central computer is not available.

4.5.1.6. Constraints

The project must be completed within nine months. It must cost no more than 1,750,000 USD excluding production costs. Components may be contracted out, but the basic architecture as well as the infrastructure will be designed in house. Close liaison must be maintained between the software development and the design, development and production of the hardware. Neither the hardware nor the software shall be considered the independent variable, but rather they shall be considered equal.

4.5.1.7. Appendix

The following are the actors that directly support this vision. Additional actors may be identified later that are needed to support this or that technology. They should not be added to this list unless they are deemed to directly support the vision as described in this document.

  • Central Computer

  • Customer

  • Local Branch Official

  • Maintenance Engineer

The following are the use cases that directly support this vision. Additional use cases may be identified later that are needed to support this or that technology or to support the use cases listed here. They should not be added to this list unless they are deemed to directly support the vision as described in this document.

  • Audit

  • Customer Uses Machine

  • Maintain Machine

4.5.2. Identifying Actors and Use Cases

For the ATM case study, we will elaborate on the examples in Section 4.3, “Salida del Proceso de Captura de Requerimientos”, Figure 4.4, “Diagrama de caso de uso para un sistema de Cajero Autom??tico mostrando relaciones de inclusi??n.” and Figure 4.5, “Diagrama de casos de uso para un sistema de Cajero Autom??tico mostrando una relaci??n de extensi??n.”, and progress to identify additional actors and use cases that comprise our model of the ATM system. Figure 4.4, “Diagrama de caso de uso para un sistema de Cajero Autom??tico mostrando relaciones de inclusi??n.” and Figure 4.5, “Diagrama de casos de uso para un sistema de Cajero Autom??tico mostrando una relaci??n de extensi??n.” exemplified the essential concepts and components of a use case diagram such as, use cases, actors, multiplicity, and include / extend relationships. They showed the relationships between the actors and use cases, and demonstrated how these actors and use cases interact.

In Figure 4.4, “Diagrama de caso de uso para un sistema de Cajero Autom??tico mostrando relaciones de inclusi??n.” we see a use case diagram for an ATM system consisting of ??include?? relationships for the use cases, Maintain ATM and Use ATM. Maintain ATM was further defined by two use cases, "Maintain Equipment" and "Reload ATM". Use ATM was further defined in terms of the behavior of three simpler use cases: "Deposit Cash", "Withdraw Cash" and "Query Account".

More to be written...

4.5.3. Associations (To be written)

To be written...

4.5.4. Advanced Diagram Features (To be written)

To be written...

4.5.5. Use Case Specifications (To be written)

To be written...

4.5.6. Supplementary Requirements Specification (To be written)

To be written...

Chapter 5. Analysis

Analysis is the process of taking the “customer” requirements and re-casting them in the language of, and from the perspective of, a putative solution.

We are not actually trying the flesh out the detailed solution at this stage. That occurs in the Design Phase (see Chapter 6, Design).

Unlike the boundary between Requirements and Analysis Phases, the boundary between Analysis and Design Phases is inherently blurred. The key is that analysis should define the solution no further than is necessary to specify the requirements in the language of the solution. The artifacts in Analysis generally represent a high level of abstraction.

Once again the recursive, and iterative nature of our process means we will come back to the Analysis phase many times in the future.

5.1. The Analysis Process

There are three schools of thought on how Analysis should be approached. The ontologist defines the data (actually the metadata) first and worries about processes later. The true ontologist would prefer not to have to think about processes at all. The phenomenonologist reverses this and favors process over data. The panparadigmist considers both process and data to be equally important and addresses both from the start.

When it comes to being a purist the ontologist has the upper hand. It is possible to define and build a database into which data can be entered and retrieved without concern for what happens to it or is done with it. On the other hand implementing a process without having any data structures for it to operate on is not very meaningful.

5.1.1. Class, Responsibilities, and Collaborators (CRC) Cards

The CRC methodology favors the phenomenonologists preference for analysis. It is the equivalent of starting with the use cases, the process aspects (operations) of the class diagrams, and scenarios from which sequence diagrams can be initiated.

CRC cards and the associated methodology are described in detail in Appendix G, The CRC Card Methodology. They are used again in the design phase and are further discussed in Chapter 6, Design.

The strength of CRC cards during analysis.

  • Common Project Vocabulary -

  • Spread Domain Knowledge -

  • Making the Paradigm Shift -

  • Live Prototyping -

  • Identifying Holes in Requirements -

In this phase the group should consist of two or three domain experts, one object-oriented technology facilitator, and the rest of the group made up of people who are responsible for delivering the system.

The first time that the Analysis phase occurs a special case of the CRC session happens as there are no classes or scenarios to choose from to define a CRC session. At this point a special type of session known as brainstorming is held. During this session you identify the initial set of classes in the problem domain by using the problem statement or requirements document or whatever you know about the desired result for a starting point. The nouns that are found in whatever you are starting from are a good key to an initial set of classes in the system. In a brainstorming session there should be little or no discussion of the ideas. Record them and filter the results after the brainstorming. At this stage the distinction between class and object is blurred.

Once a reasonable set of classes has been defined by the group, responsibilities can be added. Add responsibilities that are obvious from the requirements or the name of the class. You don't need to find them all (or any for that matter). The scenarios will make them more obvious. The advantage of finding some in the beginning is that it helps provide a starting place.

Select the initial scenarios from the requirements document by examining it's verbs in much the same way that we scanned its nouns earlier. Then as many walk through sessions as necessary to complete the analysis phase are performed.

When is enough of the analysis complete that design can begin? When all the different responsibilities are in place and the system has become stable. After all the normal behavior has been covered, exceptional behavior needs to be simulated. When you notice that the responsibilities are all in place to support the new scenarios, and there is little change to the cards, this is a sign the you are ready to start design.

5.1.2. Concept Diagram (To be written)

To be written...

5.1.3. System Sequence Diagram (To be written)

To be written...

5.1.4. System Statechart Diagram (To be written)

To be written...

5.1.5. Realization Use Case Diagram (To be written)

To be written...

5.1.6. Documents (To be written)

Use Case Specifications and Supplementary Requirements Specifications recast in solution language. To be written...

5.2. Class Diagrams (To be written)

To be written...

5.2.1. The Class Diagram (To be written)

To be written...

5.2.2. Advanced Class Diagrams (To be written)

To be written...

5.2.2.1. Association Classes (To be written)

To be written...

5.3. Creating Class Diagrams in ArgoUML

5.3.1. Classes

Identifying class diagrams from existing materials (Vision, Use Cases etc). To be written...

5.3.1.1. Using the Note Icon in the Tool Bar

Click on your target class. Then click on the note icon. ArgoUML will generate the link automatically.

You can also right click to add a note as well! Be aware that you can add an undefined number of notes to any one class!

[Warning]Warning

Be aware that your note will not appear in the source code documentation tab.

5.3.2. Associations (To be written)

To be written...

5.3.2.1. Aggregation (To be written)

To be written...

5.3.3. Class Attributes and Operations (To be written)

To be written...

5.3.3.1. Entering Data Into Attributes and Methods Windows

Click directly in the class artifact and start typing. Do not use the properties window dialog fields???they are not fully functional and liable to cause you a little frustration.

In fact, it would be interesting to see if you can type stereotypes write in the class attribute box for generating XML diagrams.

5.3.3.2. Class Attributes (To be written)

To be written...

5.3.3.3. Class Operations (To be written)

To be written...

5.3.4. Advanced Class Features (To be written)

5.3.4.1. Association Classes (To be written)

To be written...

5.3.4.2. Stereotypes (To be written)

To be written...

5.4. Sequence Diagrams (To be written)

To be written...

5.4.1. The Sequence Diagram (To be written)

To be written...

5.4.2. Identifying Actions (To be written)

To be written...

5.4.3. Advanced Sequence Diagrams (To be written)

To be written...

5.5. Creating Sequence Diagrams in ArgoUML

5.5.1. Sequence Diagrams

5.5.1.1. Creating a Sequence Diagram

Normally, you can just start a sequence diagram right away. On the Create Diagram menu choose Sequence.

5.5.2. Actions (To be written)

To be written...

5.5.3. Advanced Sequence Diagrams (To be written)

To be written...

5.6. Statechart Diagrams (To be written)

To be written...

5.6.1. The Statechart Diagram (To be written)

Types of statechart diagram (Moore, Mealy); Hierarchical diagrams. To be written...

5.6.2. Advanced Statechart Diagrams (To be written)

To be written...

5.6.2.1. Hierarchical Statechart Diagrams (To be written)

To be written...

5.7. Creating Statechart Diagrams in ArgoUML

5.7.1. Statechart Diagrams (To be written)

To be written...

5.7.1.1. Creating a Statechart Diagram

Select a class, then you can create a statechart diagram.

5.7.2. States (To be written)

To be written...

5.7.2.1. Editing a Composite State

When editing a composite state, how do you provide do and event for a composite state?

The answer is to select a class, then you can create a statechart diagram.

5.7.3. Transitions (To be written)

To be written...

5.7.4. Actions (To be written)

To be written...

5.7.5. Advanced Statechart Diagrams (To be written)

To be written...

5.7.5.1. Hierarchical Statechart Diagrams (To be written)

To be written...

5.8. Realization Use Cases (To be written)

To be written...

5.9. Creating Realization Use Cases in ArgoUML (To be written)

To be written...

5.10. Case Study (To be written)

Regardless of which methodology you use, at this time you are undoubtedly going to take the problem statement from Section 4.5, “Case Study” and extract the nouns from it. This list should be compacted to contain only those nouns that are expected to result in a class. This effort results in the following.

  • Account

  • Audit trail

  • Bank

  • Cash

  • Customer

5.10.1. CRC Cards

The project manager convenes a CRC session at which the initial set of classes are to be defined. The facilitator reminds the participants that we are in the analysis phase and are only interested in what needs to be done (at the business level) and are to leave out anything that smacks of how to do it. As a general rule of thumb this means a subset of the nouns from the problem statement (see above). The group starts with a complete list of all of the nouns in the statement, examines each one, and decides which are inappropriate crossing them off the list. Each class is then assigned to one of the participants.

to be continued...

5.10.2. Concept Class Diagrams (To be written)

To be written...

5.10.2.1. Identifying classes (To be written)

To be written...

5.10.2.2. Identifying associations (To be written)

To be written...

5.10.3. System Sequence Diagrams (To be written)

To be written...

5.10.3.1. Identifying actions (To be written)

To be written...

5.10.4. System Statechart Diagrams (To be written)

To be written...

5.10.5. Realization Use Cases (To be written)

To be written...

Chapter 6. Design

We now have the problem we are trying to solve specified in the language of a putative solution. In the Design Phase, we construct all the details of that solution.

The blurred boundary between Analysis and Design is reflected in their use of many of the same UML tools. In this chapter we will mostly be reusing UML technology we have already met once. The big step is casting everything into concrete terms. We move from the abstract concepts of analysis to their concrete realization.

Once again the recursive, and iterative nature of our process means we will come back to the Design phase many times in the future.

6.1. The Design Process (To be written)

To be written...

6.1.1. Class, Responsibilities, and Collaborators (CRC) Cards

Strength of CRC cards during Design

  • Spreading Objet-Oriented Design Expertise

  • Design Reviews

  • Framework for Implementation

  • Informal Notation

  • Choice of supporting software components

  • Performance Requirements

In this phase developers replace some of the domain experts in the group, but there should always be at least one domain expert in the group.

The focus of the group moves from what is to be done to how to do it. The classes from the solution domain are added to those defined in the analysis phase. Think about what classes are needed to make the system work. Do you need a List class to hold objects? Do you need classes to handle exceptions? Do you need wrapper classes for other subsystems? New classes that are looked for in this part, are classes that support the implementation of the system.

During the design phase the distinction between class and object becomes important. Think about the objects in your scenarios. Who creates the objects? What happens when it is created and destroyed? What is the lifetime of the object vs. the lifetime of the information held be the object?

Now is the time to look at what information the objects hold compared to what is requested from other classes or computed on the fly. Use the back of the card to record the attributes found for the classes. Break you responsibilities into subresponsibilities and list the subresponsibilities indented under the main responsibilities. Move the collaborators next to the subresponsibilities that use them.

After the Collaborator class on your card list the responsibility of the used class that is used in the collaboration. After the collaborating responsibilities on your cards, list the data passed back by the collaborating object in parenthesis.

Redo the scenarios you did in the analysis phase, but know take into consideration all of the design heuristics discussed. Make up your own scenarios and try them.

6.1.2. Package Diagram (To be written)

To be written...

6.1.3. Realization Class Diagrams (To be written)

To be written...

6.1.4. Sequence Diagrams and Collaboration Diagrams (To be written)

To be written...

6.1.5. Statechart Diagrams and Activity Diagrams (To be written)

To be written...

6.1.6. Deployment Diagram (To be written)

To be written...

6.1.7. Documents (To be written)

System Architecture. To be written...

6.2. Package Diagrams (To be written)

To be written...

6.2.1. The Package Diagram (To be written)

To be written...

6.2.2. Advanced Package Diagrams (To be written)

To be written...

6.2.2.1. Subpackages (To be written)

To be written...

6.2.2.2. Adding DataTypes (To be written)

To be written...

6.2.2.3. Adding Stereotypes (To be written)

To be written...

6.3. Creating Package Diagrams in ArgoUML

6.3.1. Packages

How to work out what goes in packages. To be written...

6.3.1.1. Subpackages (To be written)

To be written...

6.3.2. Relationships between packages (To be written)

To be written...

6.3.2.1. Dependency (To be written)

To be written...

6.3.2.2. Generalization (To be written)

To be written...

6.3.2.3. Realization and Abstraction (To be written)

To be written...

6.3.3. Advanced Package Features (To be written)

To be written...

6.3.3.1. Creating New Datatypes (To be written)

To be written...

6.3.3.2. Creating New Stereotypes (To be written)

To be written...

6.4. More on Class Diagrams (To be written)

To be written...

6.4.1. The Class Diagram (To be written)

To be written...

6.4.1.1. Class Attributes (To be written)

To be written...

6.4.1.2. Class Operations (To be written)

To be written...

6.4.2. Advanced Class Diagrams (To be written)

To be written...

6.4.2.1. Realization and Abstraction (To be written)

To be written...

6.5. More on Class Diagrams in ArgoUML (To be written)

6.5.1. Classes (To be written)

More on identifying classes from existing materials and use of stereotypes. To be written...

6.5.2. Class Attributes and Operations (To be written)

To be written...

6.5.2.1. Class Attributes (To be written)

To be written...

6.5.2.2. Class Operations (To be written)

To be written...

6.5.3. Advanced Class Features

6.5.3.1. Operations on Interfaces

6.5.3.1.1. Interfaces that extend interfaces

Add a unnamed interface to the current classdiagram by single-clicking on the interface icon in the tool bar and then clicking at the diagram pane (see Figure 6.1, “Selecting the Interface tool”).

Figure 6.1. Selecting the Interface tool

Selecting the Interface tool


Then double click on the interfaces name field to change it's name as shown in Figure 6.2, “Interface artifact on the Class Diagram”.

Figure 6.2. Interface artifact on the Class Diagram

Interface artifact on the Class Diagram


and type a name for it (like TestInterface in this case). Press “Enter” when the name is complete. (You could also enter the name by going to the Properties Tab in the Details Pane after adding the interface.)

Add another interface with a different by repeating the last 2 steps. Then single-click on the Generalization icon in the tool bar as shown in Figure 6.3, “Generalization on the Class Diagram tool bar”.

Figure 6.3. Generalization on the Class Diagram tool bar

Generalization on the Class Diagram tool bar


move the mouse pointer to the subinterface, press the left mouse button and drag the generalization to the superinterface, where you release the mouse button. Figure Figure 6.4, “Generalization between two Interfaces.” shows how your diagram should look now.

Figure 6.4. Generalization between two Interfaces.

Generalization between two Interfaces.


By clicking on the subinterface and the source tab properties pane, and then selecting Java Notation for the source tab, you can see that the interface actually extends it's superinterface.

6.5.3.2. Stereotypes (To be written)

To be written...

6.6. Sequence and Collaboration Diagrams (To be written)

[Note]Note

Sequence diagrams does not work in ArgoUML version 0.14.

To be written...

6.6.1. More on the Sequence Diagram (To be written)

To be written...

6.6.2. The Collaboration Diagram (To be written)

To be written...

6.6.2.1. Messages (To be written)

To be written...

6.6.2.2. Actions (To be written)

To be written...

6.6.3. Advanced Collaboration Diagrams (To be written)

To be written...

6.7. Creating Collaboration Diagrams in ArgoUML (To be written)

6.7.1. Collaboration Diagrams (To be written)

To be written...

6.7.2. Messages (To be written)

To be written...

6.7.2.1. Actions (To be written)

To be written...

6.7.3. Advanced Collaboration Diagrams (To be written)

To be written...

6.8. Statechart Diagrams (To be written)

To be written...

6.8.1. The Statechart Diagram (To be written)

More on this. To be written...

6.8.2. Advanced Statechart Diagrams (To be written)

To be written...

6.8.2.1. Actions (To be written)

To be written...

6.8.2.2. Transitions (To be written)

To be written...

6.8.2.2.1. Triggers (To be written)

To be written...

6.8.2.2.2. Guards (To be written)

To be written...

6.8.2.2.3. Effectss (To be written)

To be written...

6.8.2.3. Pseudo States (To be written)

To be written...

6.8.2.3.1. Junction and Choice (To be written)

To be written...

6.8.2.3.2. Fork and Join (To be written)

To be written...

6.8.2.4. Hierarchical State Machines (To be written)

To be written...

6.8.2.5. Models for State History (To be written)

Shallow v Deep. To be written...

6.9. Creating Statechart Diagrams in ArgoUML (To be written)

6.9.1. Statechart Diagrams (To be written)

To be written...

6.9.2. States (To be written)

To be written...

6.9.3. Transitions (To be written)

To be written...

6.9.4. Actions (To be written)

To be written...

6.9.5. Advanced Statechart Diagrams (To be written)

To be written...

6.9.5.1. Transitions (To be written)

To be written...

6.9.5.1.1. Triggers (To be written)

To be written...

6.9.5.1.2. Guards (To be written)

To be written...

6.9.5.1.3. Effectss (To be written)

To be written...

6.9.5.2. Pseudo States (To be written)

To be written...

6.9.5.2.1. Junction and Choice (To be written)

To be written...

6.9.5.2.2. Fork and Join (To be written)

To be written...

6.9.5.3. Hierarchical State Machines (To be written)

To be written...

6.9.5.4. History (To be written)

Shallow v Deep. To be written...

6.10. Activity Diagrams (To be written)

To be written...

6.10.1. The Activity Diagram (To be written)

More on this. To be written...

6.10.1.1. Action States (To be written)

To be written...

6.11. Creating Activity Diagrams in ArgoUML (To be written)

6.11.1. Activity Diagrams (To be written)

To be written...

6.11.1.1. Creating an Activity Diagram

Select a use case or class, then you can create an activity diagram.

6.11.2. Action States (To be written)

To be written...

6.12. Deployment Diagrams (To be written)

To be written...

6.12.1. The Deployment Diagram (To be written)

To be written...

6.13. Creating Deployment Diagrams in ArgoUML (To be written)

6.13.1. Nodes (To be written)

To be written...

6.13.1.1. Node Instances (To be written)

To be written...

6.13.2. Components (To be written)

To be written...

6.13.2.1. Component Instances (To be written)

To be written...

6.13.3. Relationships between nodes and components (To be written)

To be written...

6.13.3.1. Dependency (To be written)

To be written...

6.13.3.2. Associations (To be written)

To be written...

6.13.3.3. Links (To be written)

To be written...

6.14. System Architecture (To be written)

To be written...

6.15. Case Study (To be written)

6.15.1. CRC Cards (To be written)

To be written...

6.15.2. Packages (To be written)

To be written...

6.15.2.1. Identifying Packages (To be written)

To be written...

6.15.2.2. Datatypes and Stereotypes (To be written)

To be written...

6.15.3. Class Diagrams (To be written)

To be written...

6.15.3.1. Identifying classes (To be written)

To be written...

6.15.3.2. Identifying associations (To be written)

To be written...

6.15.3.3. Specifying Attributes and Operations (To be written)

To be written...

6.15.4. Sequence Diagrams (To be written)

To be written...

6.15.4.1. Identifying actions (To be written)

To be written...

6.15.5. Collaboration Diagrams (To be written)

To be written...

6.15.5.1. Identifying Messages (To be written)

To be written...

6.15.6. Statechart Diagrams (To be written)

To be written...

6.15.7. Activity Diagrams (To be written)

To be written...

6.15.8. The Deployment Diagram (To be written)

To be written...

6.15.9. The System Architecture (To be written)

To be written...

Chapter 7. Code Generation, Reverse Engineering, and Round Trip Engineering

7.1. Introduction

We now have our design fully specified. With the right simulator we could actually execute the design and see if it works. (ArgoUML does not provide such functionality, but this functionality has been provided in alternative tools.)

ArgoUML does allow you to generate code from the design in several different programming languages. We, most likely, already in the design had a programming language in mind because some of the design considerations are to care for a specific language.

The output of this process is the set of files that constitute the program that solves the problem.

Once again the recursive, and iterative nature of our process means we will come back to the Build phase many times in the future.

There is also another side to this and that is the reverse engineering side. If we happen to have an old program that we would like to examine then we could take the files and reverse engineer them to create a design. This can be used when trying to understand some not so well documented program or as a quick start for the design work.

The process of going back and forth between doing changes in the design followed by a code generation and then doing changes in the code followed by a reverse engineering using for every change, the best possible perspective, is called Round-trip Engineering.

7.2. Code Generation

The output of the Code Generation is the completed program. Depending on the contents of the design, we could also generate Unit test cases.

To do the work we need the design model, containing both static and dynamic descriptions of the program.

7.2.1. Generating Code from the Static Structure

It is rather straightforward to do this generation, at least as long as we do it for an object-oriented language. This is some of the basic rules:

  • A class will become a class.

    In some target languages (like java, c++) they also become files and compilation units.

  • A generalization will become an inheritance.

    If the target language does not support inheritance and we didn't address this during the design, some special conversions are required to solve this.

  • An attribute will become a member variable.

  • A navigable association will become a member variable.

    Depending on the target language, target platform, and the association multiplicities this will be a pointer, a reference, a collection class, an entry in some table or map.

  • A non-abstract operation in a class will become a method.

  • An abstract operation in a class will become an abstract method.

  • An in parameter in an operation will become a parameter in the method.

    For simple types (int, boolean), this is the normal case. For C++, these will probably const classes. For Java, this cannot be enforced for classes.

  • An out or in/out parameter in an operation will become a referenced parameter in the method.

    For C++, these will be referenced non-const parameters. For Java classes, this is the default. Simple types (int, boolean) must, in java, be converted to an object of a corresponding class (Integer, Boolean).

  • The visibilities of the attributes, associations, and operations will become visibilities on the member variables or methods.

  • Packages will become directories, namespaces, or both.

7.2.2. Generating code from interactions and state machines

This conversion is not as straight-forward as the conversion of the static structure. It is much more depending on the target language and target platform.

In general it is only possible to say the following for interactions:

  • A message is converted into a function call.

    The class of the recipient will have to have a function with the correct name and signature.

    The sender function in the class of the sender will have a call to the function in the recipient.

  • An asynchronous message is converted to either posting a message to be handled by some other thread or a function call to a function that starts a new thread.

The following describes one possible way to generate state machines:

  • A State Machine is generated to a set of member variables that each method in this class refer to when deciding behavior.

  • A State is generated to a closed set of combination of values on these member variables.

  • An Event is generated as a call to a member method that can change the state.

    These methods would then typically have one big switch statement splitting on the current state.

  • A Guard is generated to an if statement in the event member method in the branch for the correct state.

  • A Transition is generated as an assignment of some state variable.

  • An Action is generated as a function call.

7.3. Code Generation in ArgoUML

7.3.1. Static Structure

Most of the generation can be done automatically by the provided language modules. Files are generated in a directory hierarchy that need to be filled in by the actual code.

7.3.2. Interactions and statechart diagrams

There is currently no support for this in ArgoUML, not for any language.

7.4. Reverse Engineering

Reverse Engineering is used for two main purposes:

  1. To get previously developed classed into the model to build upon.

  2. To get a UML view of previously developed classes to understand how they work.

Essentially this does the opposite of Code Generation.

7.5. Round-Trip Engineering

Round-Trip Engineering makes it possible to switch perspective while doing the design. Create some classes in a class diagram. Write some code for some of the operations or functions using your favorite editor. Move the operations from one class to another in the class diagram...

ArgoUML currently does not support this for any language.

Part 2. User Interface Reference

Chapter 8. Introduction

This chapter describes the overall behavior of the user interface. Description of the various component parts???the menu bar, panes and various diagrams??? is in separate chapters.

8.1. Overview of the Window

Figure 8.1, “Overview of the ArgoUML window” shows the main ArgoUML window.

The titlebar of the window shows the following 4 parts of information, separated from each other by a dash.

  • The current filename. If no filename for the project is set yet, then the titlebar shows "Unititled".

  • The name of the currently active diagram.

  • The name “ArgoUML”.

  • An asterisk (*). This item is only present if the current project file is “dirty”, i.e. it is altered, but not yet saved. In other words, if the asterisk is absent, then the current file has not been altered.

Figure 8.1. Overview of the ArgoUML window

Overview of the ArgoUML window


At the top of screen is a menu bar, which is described in Chapter 10, The Menu bar. Below that is the toolbar, as described in Chapter 9, The Toolbar.

The bulk of the window comprises four sub-windows or panes. Clockwise from top left these are the explorer (see Chapter 11, The Explorer), editing pane (see Chapter 12, The Editing Pane), details pane (see Chapter 13, The Details Pane) and to-do pane (see Chapter 14, The To-Do Pane). All 4 panes have a tool bar at the top (in the details pane it is located under the properties tab). An overview of the panes is given in Section 8.3, “General Information About Panes”. Finally at the bottom of the window is a status bar described in Section 8.4, “The status bar”.

8.2. General Mouse Behavior in ArgoUML

Mouse behavior that is specific to the various panes of ArgoUML (see Section 8.3, “General Information About Panes”) or the menu bar, is discussed in the chapters covering those panes and the menu bar. In this section we cover behavior that is general across all of ArgoUML.

In a number of places in ArgoUML text may be directly edited (for example the constraint editor???see Section 13.7.1, “The Constraint Editor”). The behavior of the mouse when handling text is discussed in the sections that follow.

8.2.1. Mouse Button Terminology

ArgoUML assumes a two button mouse. We will refer to the buttons as “button 1” and “button 2”. Button 1 is the leftmost button on a right-handed mouse, and sometimes referred to as the select button. Button 2 is the rightmost button on a right-handed mouse, and is sometimes referred to as the adjust button.

A single depress and release of a mouse button with the mouse is referred to as a click. Two clicks in quick succession is referred to as a double click. Moving the mouse while holding a button down is referred to as button motion with the starting point being at button down and the end point at button up.

8.2.2. Button 1 Click

Clicking on an user-interface object or on a diagram artifact may establish many different things. Most of the behaviour is experienced quite intuitive by the user, mainly because the high degree of standardisation, even spanning different computer platforms (Macintosh, PC, UNIX,...). ArgoUML follows the Java Look and Feel Design Guidelines by Sun. See http://java.sun.com/products/jlf/. Hence, behaviour of common user-interface components is generally not discussed in this document.

On the other hand, mouse actions in a diagram may not seem so intuitive to the user, since it is specific for ArgoUML. Hence they are explained here. In short, clicking selects or activates the object beneath the mouse-pointer, and moves the focus (i.e. navigation).

More in detail, the button 1 click may cause the following result:

8.2.2.1. Selection

Here button 1 is used to choose (select) an artifact (in a list or tree or on a diagram) on which subsequent operations will take place. Multiple artifacts may be selected by using Shift and/or Ctrl in combination with button 1, see Section 8.2.5, “Shift and Ctrl modifiers with Button 1”. Selection is always clearly indicated by a colored background.

On a diagram, the selected artifact is indicated with colored "blocks" at the corners/ends of the object. Artifacts can be selected or deselected in different ways:

  • Button 1 click. Deselects all artifacts, and selects the one clicked on.

  • Button 1 motion. Button motion (moving the mouse with the button down) in the diagram, not on any artifact, allows to draw a rectangle around artifacts which will be selected when the button 1 is released.

  • Menu functions and shortcuts. Many menu operations change selection as side-effect, e.g. creating a new diagram. Many keyboard shortcuts for menu operations change the selection, e.g. Ctrl-A, which stands for the Select All function.

8.2.2.2. Activation

Here button 1 is used to activate the user interface component, e.g. a button. The object is usually highlighted when the mouse button is pressed and then activated when the mouse button is released. Activating an user-interface object means that its function is executed.

8.2.2.3. Navigation

Here button 1 is used to move the focus from one user interface component or diagram artifact to another. It is better known under the term keyboard focus. This because keyboard commands usually work on the artifact that has the focus. The focus is indicated by a (hardly visible) box around the artifact, or for a text entry box, by a flashing cursor.

8.2.2.4. General Behavior When Editing Text

Here button 1 is used to select the point within the text at which operations (text entry and deletion) will take place.

8.2.3. Button 1 Double Click

The behavior of button 1 double click varies betweens panes and is discussed in their chapters.

8.2.3.1. General Behavior When Editing Text

Here button 1 double click is used to select a complete word, or other syntactic unit within the text. Subsequent operations (text entry and deletion) will replace the selected text.

8.2.4. Button 1 Motion

8.2.4.1. General Behavior When Editing Text

Here button 1 motion is used to select a range of text. Subsequent operations (text entry and deletion) will replace the selected text.

8.2.5. Shift and Ctrl modifiers with Button 1

8.2.5.1. Within Lists

This behavior applies where there is a list of things that may be selected. This includes various dialog boxes, and the to-do pane, where there is a list of to-do items to be selected.

Where selections are to be made, the SHIFT key is used to with button 1 to extend from the original button 1 selection to the current position.

Similarly the CTRL key with button 1 is used to add individual items to the current selection. Where Ctrl-button 1 is used on an item already selected, that item is removed from the selection.

[Caution]Caution

Users of Microsoft Windows might be familiar with the use of SHIFT-CTRL-Click (i.e. holding both the Shift and Ctrl key down when clicking), to add sub-lists to an existing selection. ArgoUML does not support this. SHIFT-CTRL-Click will behave as CTRL-Click.

8.2.5.2. General Behavior When Editing Text

In a number of places in ArgoUML text may be directly edited (for example when naming a model???element in the properties pane, or when typing a UML note / comment). Here SHIFT button 1 is used to select a range of text from the previously selected point. Subsequent operations (text entry and deletion) will replace the selected text.

8.2.6. Alt with Button 1: Panning

When holding down the Alt key during button 1 down on a diagram, movement of the mouse pans the drawing area. The function is indicated by the mousepointer which turns into a crosshair with arrows.

8.2.7. Ctrl with Button 1: Constrained Drag

When holding down the Ctrl key while dragging with mouse button 1 down on a diagram, the movement of the dragged element element will be constrained to one of eight cardinal directions : North, South, East, West, NE, SE, SW, NW.

8.2.8. Button 2 Actions

Button 2 actions are all dependent on the pane or menu bar, and discussed in their various chapters.

8.2.9. Button 2 Double Click

Button 2 actions are all dependent on the pane or menu bar, and discussed in their various chapters.

8.2.10. Button 2 Motion

Button 2 actions are all dependent on the pane or menu bar, and discussed in their various chapters.

8.3. General Information About Panes

The four sub-windows of the main ArgoUML window are called panes. Clockwise from top left these are the explorer (see Chapter 11, The Explorer), editing pane (see Chapter 12, The Editing Pane), details pane (see Chapter 13, The Details Pane) and to-do pane (see Chapter 14, The To-Do Pane). At the top the editing pane is a tool bar.

8.3.1. Re-sizing Panes

You can re-size panes by dragging on the divider bars between them. To indicate this possibility, the mouse cursor changes shape when hovering over the divider bars.

In addition you will see there are two small left pointing arrows within the vertical divider bars, one at the top of the vertical divider bar between explorer and editing pane and one at the top of the vertical divider bar between to-do pane and details pane. Button 1 click on the first of these will expand the editing pane to the full width of the window, button 1 click on the second will expand the details pane to the full width of the window.

There is also a small downward pointing arrow within the horizontal divider bar at its leftmost end. Clicking on this will expand the explorer and editing panes to the full depth of the window.

By using both the top arrow on the vertical divider and the arrow on the horizontal divider, it is possible to expand the editing pane to use the entire window.

The original configuration can be restored by clicking again on these arrows, which are now located at the edge of the window.

8.4. The status bar

The status bar is at the very bottom of the ArgoUML window and is used to display short advisory messages. In general such messages are self explanatory. It is e.g. used for displaying parsing error messages in case a text entered on the diagram can not be interpreted.

Chapter 9. The Toolbar

9.1. File operations

These buttons have identical functions as their counterparts in the File menu.

9.2. Edit operations

These buttons have identical functions as their counterparts in the Edit menu.

9.3. View operations

The Find... button has identical behaviour as its counterpart in the View menu. The Zoom button is a more luxurously version of the function in the View menu.

  • Find... See for a full description Section 10.5.2, “ Find...”.

  • Zoom This is a different version of the menu-item for zooming, as described in Section 10.5.3, “Zoom” . Clicking with button 1 on the zoom-icon opens a panel as in the figure below.

    Figure 9.1. The Zoom slider on the Toolbar

    The Zoom slider on the Toolbar


    Once the panel is open, the following actions are possible:

    • Clicking with button 1 on the "knob" followed by button 1 movement will adjust the zoomfactor.

    • Clicking with button 1 on the shown percentage allows editing the given zoomfactor (in percent) directly with the keyboard. Double clicking on the value shown selects the whole entry for easy overtyping.

    • Clicking with button 1 below or above the knob increases or decreass the zoom factor with 1%. Use this function to easily fine-adjust the percentage.

    • Clicking with button 1 or button 2 on the Zoom tool, or anywhere outside the slider panel closes the panel.

    • The keyboard can be used to operate the Zoom Slider as follows: When the Zoom icon in the toolbar has the focus (indicated by the thin blue box around it), then pressing the spacebar opens the zoon slider panel. Use the arrow keys to increase and decrease the percentage 1 by 1. Use Shift-Tab to set the focus to the percentage box, where you can edit the given value directly. Pressing Enter activates the changed value. When the "knob" has the focus, pressing PageUp/PageDown increases/decreases the percentage by 50. Pressing Home sets the percentage to 500%, and End sets it to 0%.

9.4. Create operations

These buttons have identical functions as their counterparts in the Create menu.

Chapter 10. The Menu bar

10.1. Introduction

An important principle behind ArgoUML is that actions should be able to be invoked in whatever way the user finds convenient. As a result many (but not all) actions that can be carried out on the menu can be carried out in other ways as well under ArgoUML.

A number of the common menu entries are also available through keyboard shortcuts.

It is also be possible to navigate the menu from the keyboard. Each level of each menu is identified by a letter (shown underlined in the menu or entry name from the moment the ALT key is pressed). This sequence of letters while holding down the ALT key selects the entry.

The following is an explanation of why the menuitems are grouped as they are.

  • The File menu contains operations that affect on the whole project/file. All the items in this menu can be explained as such.

  • The Edit menu is generally intended for editing the model or changing the content of a diagram. It also contains functions to enable editing, like e.g. selecting. This menu is not intended for diagram layout functions. Most functions here do something with the selected modelelement and diagram. The items "Configure Perspectives..." and "Settings..." are a bit different, since they adjust the way ArgoUML works - but they do not belong in the File menu, since their settings are not stored in the project.

  • The View menu is for functions that do never alter the model, nor the diagram layout, only the way you view the diagram. A good example is "zoom". Also navigational functions belong here, e.g. "Find" and "Goto Diagram...". All changes of settings in this menu apply to all diagrams (e.g. zoom).

  • The Create menu contains all possible diagrams that can be created. These functions are context dependend, since they work on the selected modelelement.

  • The Arrange menu allows layout changes in the current diagram, which is not the same as the items in the View menu. Functions here can not alter the UML model.

  • The Generation menu is for Code Generation. The functions here work either on the selected modelelements, or on the whole project.

  • The Critique menu is specific for settings related to critics, which apply for all projects.

  • The Tools menu is currently empty. If plugins are installed, then their functions appear here.

  • The Help menu contains the usual "information" and "about".

10.2. Mouse Behavior in the Menu Bar

Behavior of the mouse in general, and the naming of the buttons is covered in the chapter on the overall user interface (see Section 8.2, “General Mouse Behavior in ArgoUML”). There is no ArgoUML specific behaviour for the menu.

10.3. The File Menu

These are actions concerned with input and output and the overall management of projects and the ArgoUML system.

10.3.1.  New

Shortcut Ctrl-N.

This initializes a new project within ArgoUML. The project is created without a the name. It contains a (top-level) Model named untitledModel and two empty diagrams: a class diagram and a use case diagram.

[Caution]Caution

untitledModel is not a conventional model name (most processes suggest models should be build from lower case letters). ArgoUML permits you to use any case letters, but a critic will trigger to warn that this is not conventional. See Section 16.2, “The Model” for a discussion of this.

If the model has been altered (as indicated by the "*" in the titlebar of ArgoUML's window), then activating the "New" function is potentionally not the user's intention, since it will erase the changes. Hence a confirmation dialog appears to allow the user to save his work first, or cancel the operation completely.

Figure 10.1. The confirmation dialog for New.

The confirmation dialog for New.


10.3.2.  Open Project...

Shortcut Ctrl-O.

This opens an existing project from a file. Selecting this menu option will open a file selection dialog (see Figure 10.2, “The file selection dialog for Open Project....”).

Figure 10.2. The file selection dialog for Open Project....

The file selection dialog for Open Project....


The main body of the dialog is a text area with a listing of all directories and files in the currently selected directory which match the current filter (see below).

Navigating in the directory tree is possible by selecting a directory in the drop down selector at the top of this dialog. Navigating deeper in the tree may be done by double clicking button 1 on the directory shown in the main text area.

In the lower portion of the dialog is a text box labeled File name: for the name of the file to be opened. The file name may be typed directly in here, or selected from the directory listing above using button 1 click.

Beneath this is a drop down selector labeled Files of type: to specify a filter on the files to be shown in the directory listing. Only files that match the filter are listed. The available filters are listed below. The default filter is the first one, which combines all available formats.

  • ArgoUML file (*.zargo, *.uml, *.xmi, *.xml, *.zip)

  • ArgoUML compressed project file (*.zargo)

  • ArgoUML project file (*.uml)

  • XML Metadata Interchange (*.xmi)

  • XML Metadata Interchange (*.xml)

  • XMI compressed project file (*.zip)

10.3.3.  Save Project

Shortcut Ctrl-S.

This saves the project using its current file name. Use Save Project As... to save the project to a different file. If no filename is given yet (e.g. after New), then this function works exactly as Save Project As....

[Note]Note

In certain circumstances, there is nothing to save, and this menuitem is downlighted. E.g. when the user did not yet alter a loaded project. The presence of a “*” in the titlebar of ArgoUML's window indicates that the current project is “dirty” (has been altered), and can be saved.

10.3.4.  Save Project As...

This opens a dialog allowing you to save the project under a different file name (or to specify a file name for the first time if the project is a new project).

The dialog box is almost identical to that for Open Project (see Figure 10.2, “The file selection dialog for Open Project....”). The extension of the filename is automatically set.

10.3.5. Revert to Saved

This menu-item allows you to throw away all your recent changes, and reload the last saved version of the current project. It works a bit like an Undo feature, but only restores changes done since the last time the file was saved.

This menu-item is downlighted unless the currentproject has been saved or loaded before (i.e. it has a name), and it has been altered.

When this menu-item is activated, a small confirmation dialog box opens, as shown in the figure below. This warning that all recent changes will be discarded, is needed because the action can not be undone. Selecting No cancels the whole action as if you did not select the menu-item in the first place. Selecting Yes reloads the last saved file.

Figure 10.3. The warning dialog for Revert to Saved.

The warning dialog for Revert to Saved.


10.3.6. Import XMI...

This menu-item allows to load an UML 1.3 or 1.4 model which was exported by e.g. another tool, as a XMI file, according the XMI V1.0, V1.1 or V1.2 standard. The extension of such file should be .xmi.

If the model has been altered (as indicated by the "*" in the titlebar of ArgoUML's window), then activating the "Import XMI..." function is potentionally not the user's intention, since it will erase the changes. Hence a confirmation dialog appears to allow the user to save his work first, or cancel the operation completely.

Figure 10.4. The confirmation dialog for Import XMI....

The confirmation dialog for Import XMI....


When the menu is activated, the standard filechooser appears, see Figure 10.5, “The dialog for Import XMI....”. Beware the fact that this file will only contain the model, not any diagram layout. Hence, the new project will not contain any diagrams.

Figure 10.5. The dialog for Import XMI....

The dialog for Import XMI....


10.3.7. Export XMI...

This menu-item allows to save the complete structure of the UML 1.4 model as a XMI file, according the XMI V1.2 standard. Beware the fact that this file will only contain the model, not any diagram layout. Hence, if the XMI file is reloaded with the File - Open Project... menu, then the diagrams are lost.

When the menu is activated, the standard filechooser appears, see Figure 10.6, “The dialog for Export XMI....”.

Figure 10.6. The dialog for Export XMI....

The dialog for Export XMI....


10.3.8.  Import Sources...

A very powerful feature of ArgoUML is that it can “Reverse Engineer” Java code to yield a class diagram. This sub-menu entry specifies Java code to be imported for reverse engineering.

The dialog box is similar to that for Open Project (see Figure 10.2, “The file selection dialog for Open Project....”), but with two extra tabs placed alongside the directory listing, as shown in Figure 10.7, “The file selection dialog for Import Sources....”).

Figure 10.7. The file selection dialog for Import Sources....

The file selection dialog for Import Sources....


Those fields that are the same as Open Project behave in the same way (see Section 10.3.2, “ Open Project...”).

Next to the "All Files" file filter, there is the default filter "Java Source File (*.java)".

The first of the two tabs is labeled General and is selected by button 1 click on its tab. It provides a combo box for the language selection (in V0.18 of ArgoUML only Java can be chosen), and the following selections:

  • Descend directories recursively. If enabled (the default), reverse engineering will track through sub-directories for any further Java files. If not it will restrict to the selected directory.

  • Changed/new files only. If enabled (the default), only changed and new files are imported. If not all classes will be replaced.

  • Create diagrams from imported code. If you unselect this, then no diagrams are created, i.e. all data will only be visible in the explorer.

  • Minimise Class icons in diagrams. If enabled, then the attributes and operations compartiments will not be shown in the classes on the generated class diagrams. Note: This item is checked by default, and is overseen by many users, which are then surprised by the result.

  • Perform Automatic Diagram Layout. If selected, then ArgoUML will do its best to layout the generated diagrams automatically. If not, then all items will be placed at the top left corner of the diagram.

  • Level of import detail: Classifiers only / Classifiers plus feature specifications / Full import. The latter is the default.

  • Import source file encoding:. The value Cp1252 is often the default. This string represents the coded character set identifier (CCSID).

The second of the two tabs is labeled Java and is selected by button 1 click on its tab. It provides two pairs of radio boxes.

  • The first radio box allows selection between modeling attributes of Java classes as UML attributes (the default) or as UML associations to the class specified.

  • The second radio box allows selection between modeling arrays as new datatypes in their own right (the default) or as their base datatype with multiplicity.

10.3.9.  Page Setup...

This brings up the standard dialog box provided by the operating system to adjust printer paper size, orientation, and other options.

10.3.10.  Print...

Shortcut Ctrl-P.

This brings up the standard dialog box provided by the operating system allowing the current diagram to be printed out.

In some cases, when the printing is started, the dialog box of Figure 10.8, “The diagram exceeds page size dialog.” appears. Selecting the "Fit to page" button does print the whole diagram fitted on one page by scaling it down. Which might cause all text to be too small to read in case of big diagrams, but it is a quick and easy way to get an usable printout. Selecting the "Multiple pages" option does print unscaled, by dividing the diagram in pieces, on as many pages as needed. Pressing the close button of the dialog does the former option.

Figure 10.8. The diagram exceeds page size dialog.

The diagram exceeds page size dialog.


[Warning]Warning

If the current diagram contains no selected artifacts, then the whole diagram is printed. However, if one or more artifacts are selected, then only the area they cover is printed! If scaling is selected (by the "Fit to page" choice in the dialog box descibed above), then the scaling is done on basis of the selected artifacts only. If scaling is not chosen (or in case it is not needed), then all pages containing a selected artifact are printed.

10.3.11. Export Graphics...

This menu entry brings up a dialog box allowing the currently selected diagram (in the editing pane) to be saved in one of a number of graphic formats.

The dialog box is identical to that for Open Project (see Figure 10.2, “The file selection dialog for Open Project....”), except for the Files of type:. The chosen filetype specifies the graphics format used for saving. The filename is automatically extended with the corresponding ending (if not entered already). A default filename is generated based on the diagram name.

The available graphics types are:

  • GIF image (*.gif)

  • Encapsulated Postscript file (*.eps)

  • PNG image (*.png)

  • Postscript file (*.ps)

  • Scalable Vector Graphics file (*.svg)

The graphics format that is selected by default is set in the dialog under the menu entry Edit - Settings...

10.3.12. Export All Graphics...

This menu entry brings up a dialog box to select a directory. In this directory, for all diagrams in the current project, a graphics file is generated.

The names of the files are deducted from the diagram names. The graphics format that is produced is set in the dialog under the Edit menu (see Section 10.4.5, “ Settings...”).

10.3.13. Notation

This sub-menu presents a radio button selection for notation, i.e. the language in which all textual adornments are shown on the diagrams.

This feature defines the project's notation language.

There are 2 ways to set the notation language:

  • In the Edit menu, see Section 10.4.5.5, “Notation Tab” in the notation tab of the settings dialog, which defines the default notation language for new projects. This choice is stored in the argouml.properties file.

  • In the File menu, item Notation. This determines how all textual adornments of figures on all diagrams of the current project are shown. This choice is stored in the project file.

The following 2 notations are build in ArgoUML:

  • UML 1.4. Uses UML notation as the default notation for every modelelement on any diagram.

  • Java. Uses Java notation as the default notation for every modelelement on any diagram.

The following choices are only available if the corresponding plugin languages are installed.

  • Cpp.

  • CSharp.

  • PHP.

Besides UML, only Java is partly implemented in V0.22 of ArgoUML.

10.3.14.  Properties

This menu entry brings up a dialog box, which allows the user to set various options of the currently loaded project.

All settings in this dialog are stored in the project-file together with the model.

Figure 10.9. The dialog for Properties - Notation: The User tab.

The dialog for Properties - Notation: The User tab.


In the User tab, you are able to set the following fields:

  • The first field contains the name of the author or responsible for the current project. By default the name and email of the creator are filled in, so probably you will never need to edit this, but it is possible.

  • The Project Description field may contain any text that you need to describe the project. By default it is empty.

  • The "Last saved with ArgoUML" field indicates the version of ArgoUML that was used to save this project (the last time it was saved). This may be usefull if multiple designers have different versions of ArgoUML, which may not be backwards compatible all the time.

Figure 10.10. The dialog for Properties - Notation: The Notations tab.

The dialog for Properties - Notation: The Notations tab.


In the Notations tab, you are able to set the following fields:

  • The first field is a combobox that allows selection of the project's Notation language. By default, it lists UML and Java, but other languages may be added by plugins. See the chapter on Notation for more explanation: Section 12.10, “Notation”.

  • Use guillemots (?? ??) for stereotypes (clear by default). By default ArgoUML uses pairs of less than and greater than (<< >>) characters for stereotypes. If this box is checked stereotypes on diagrams are shown between true guillemots (?? ??).

    This feature is presumably added to ArgoUML because guillemots are poorly supported by various fonts, and if they are present, then they are quite small and poorly visible.

  • Show visibility (clear by default). If this is selected, then ArgoUML will show the visibility indicators in front of e.g. attributes in the diagram. In UML the notation is "+" for public, "-" for private, "#" for protected, and "~" for package. E.g. for an attribute, it may show: +newAttr : int.

  • Show multiplicity (clear by default). If this is selected, then ArgoUML will show the multiplicity of e.g. attributes in the diagram. In UML notation, the multiplicity is shown between [], such as: +newAttr [0..*] : int. This setting has no impact on showing multiplicity near associationends.

  • Show initial value (clear by default). If this is selected, then ArgoUML will show the initial value of e.g. attributes in the diagram. In UML notation, the initial value is shown e.g. like this: +newAttr : int = 1.

  • Show properties (clear by default). If this is selected, then ArgoUML will show various properties between braces {}. E.g. for an attribute, it may show: +newAttr : int { frozen }.

  • Show types and parameters (set by default). When this checkbox is unmarked, attributes in classes are shown without type indication, and operations are shown without parameters. This feature may be usefull during the analysis phase of your project. If all checkmarks in the Notation Tab are unchecked, then e.g. for an attribute, ArgoUML may show: newAttr. And for an operation: newOperation().

  • Show stereotypes in explorer (clear by default). If this is selected, then ArgoUML will show stereotypes next to the icons of the modelelements in the Explorer, i.e. the tree structure at the left hand side.

  • Default shadow width (set to 1 by default). ArgoUML is able to draw all elements on a diagram with a shadow, for esthetical reasons. Use this setting to adjust the size of the shadow, used when the modelelement is created. The details tab "Presentation" allows to set the shadow per modelelement, after they are created, but ArgoUML V0.22 does not retain this latter change after save and load.

10.3.15. Save Configuration

ArgoUML has various user specific configurations that can be set, through the Settings... entry on the Edit menu (see Section 10.4.5, “ Settings...”) or directly on the various panes. Also the main window size and location is such a setting. Activating this menu entry causes the information to be saved in the file argo.user.properties. The location of this file is in the "users home directory", which is defined as ${user.home}, and can be determined as described in Section 10.4.5.2, “Environment Tab”.

[Tip]Tip

This is a text file, which you can edit to configure ArgoUML.

10.3.16. Most Recent Used Files

ArgoUML remembers a few of the most recently saved files, and lists them here, to enable loading then in the most simple way.

The maximum number of files that is listed here, can be adjusted in the Edit -> Settings... menu. The list of files is stored in the argo.user.properties file in the user's home directory.

10.3.17. Exit

Shortcut Alt-F4.

This closes down ArgoUML. A warning message will pop-up if you have a project open with unsaved changes asking if you wish to save it. See Figure 10.11, “The save changes dialog.”. The options are:

  • Yes (save the project and exit ArgoUML);

  • No (do not save the project, but still exit ArgoUML); and

  • Cancel (do not save the project and do not exit ArgoUML).

  • The dialog box can also be closed by clicking in the close button in the window border. The effect is the same as selecting "Cancel".

Figure 10.11. The save changes dialog.

The save changes dialog.


10.4. The Edit Menu

This menu provides support for selecting artifacts on the editing pane; removal of artifacts from diagrams and the model; and control of user settings.

10.4.1. Select

This sub-menu provides for selection of items on the editing menu. It has the following entries.

  • Select All (shortcut Ctrl-A). Selects all artifacts on the current pane or in the current field. The exact behaviour depends on the current pane (i.e. the last one you clicked in): explorer pane, editing pane, to-do pane, details pane. One rule applies in all cases though: the selection on the diagram (editing pane) and in the explorer are always synchronised.

    If the editing pane is the current pane: First everything in the explorer and on the current diagram is deselected, and then everything that is on the current diagram is selected (and if the same items apear in the explorer, then they are also there indicated as selected, because they are always synchronised).

    If the explorer pane is the current pane: All visible items in the explorer pane are selected, and non-visible items are deselected.

    If the to-do pane is the current pane: All visible items in the to-do pane are selected, and non-visible items are deselected. In fact, this works the same as for the explorer pane, because both are tree structures.

    If the details pane is the current pane: The function only works when the cursor is in certain fields, where selecting is possible, e.g. a Name field. In such a case, the Select All function extends the current selection to the whole field contents.

  • Navigate Back. ArgoUML keeps a record of the artifacts that you have been selecting while navigating the model. This button moves you back to the previous one selected. If there are no more previous artifacts, the button is grayed out.

  • Navigate Forward. ArgoUML keeps a record of the artifacts that you have been selecting while navigating the model. This button moves you forward to the next one selected (after you have used the Navigate Back button to move back). If there are no more next artifacts, the button is grayed out.

  • Invert Selection. This inverts the current selection on the current pane. More exact: everything that was selected is de-selected and everything that was not selected within the current pane is selected.

10.4.2.  Remove From Diagram

Shortcut Delete.

This removes the currently selected item(s) from the diagram, but not from the model.

The modelelement can be re-added to the diagram by button 2 click on the modelelement in the explorer, or by dragging it onto the diagram.

10.4.3.  Delete From Model

Shortcut Ctrl-Delete.

This function deletes the selected item(s) from the model completely.

If the item to be deleted is also present on another diagram than the current one, the dialog box from figure x appears.

Figure 10.12. The dialog for confirmation of Remove from Model.

The dialog for confirmation of Remove from Model.


10.4.4.  Configure Perspectives...

This menu-item invokes the same dialog as the button at the top of the explorer. See Section 11.5, “Configuring Perspectives”. for a complete description.

10.4.5.  Settings...

This menu entry brings up a dialog box, which allows the user to set various options that control the behavior of ArgoUML (see Figure 10.13, “The dialog for Settings - Preferences.”).

Figure 10.13. The dialog for Settings - Preferences.

The dialog for Settings - Preferences.


The options that can be set up on the various tabs are described in the following sections. For each tab there are three buttons at the bottom of the dialog box.

  • OK. Activating this button (button 1 click) applies the chosen settings and exits the dialog.

  • Cancel. Selecting this button (button 1 click) exits the dialog without applying any settings changed since the last Apply (or since the dialog started if Apply has not been used).

  • Apply. Selecting this button (button 1 click) applies the chosen settings and remains in the dialog.

Closing the dialog (with the close button in the top corner in the border of the window) causes the same effect as Cancel.

These settings are saved persistently for use by subsequent ArgoUML sessions.

10.4.5.1. Preferences Tab

Selecting the Preferences tab (button 1 click on the tab) gives the following options as check boxes.

  • Show Splash Panel (set by default). If enabled ArgoUML will show a small panel with a picture while starting up.

    [Tip]Tip

    The splash panel can be seen by using the Help menu (see Section 10.11.2, “About ArgoUML” ).

  • Preload Common Classes (set by default). If enabled ArgoUML creates class objects of a number of classes internally during start up so that instantiation is quicker when they are needed.

  • Reload last saved project on startup (clear by default). Check this item if you always work on the same project, and wish to load it automatically when you start up ArgoUML.

  • Strip (non-standard) diagrams from XMI file during import (clear by default). Checking this item will tell ArgoUML to ignore the "Diagram" elements when importing XMI files.

    You only need to use this setting, if ArgoUML gives an error while importing your XMI file saying that it encountered unrecognized elements named "Diagram." Some versions of Poseidon are known to create this type of file by default although there's usually an export option to force them to create standard XMI files.

  • UML Profile file ( /org/argouml/model/mdr/mof/default-uml14.xmi by default).

    This is a read-only field which shows the current profile being used by ArgoUML. If you specified an alternate profile at startup time or a plugin-module installed a different profile, it will display here.

    In the future this will be a settable field that allows you to select different profiles to match different modeling environments (Java, C++, AndroMDA, etc).

10.4.5.2. Environment Tab

Selecting the Environment tab (button 1 click on the tab) lists several environmental items. Note that none of the paths can be altered ??? these are just a matter of record.

Figure 10.14. The dialog for Settings - Environment.

The dialog for Settings - Environment.


  • Default Graphics Format. Here you can select the same graphics formats as in the menu Section 10.3.11, “Export Graphics...”. The chosen format is selected by default in the Export Graphics and Export All Graphics menu-items.

  • Graphics Export Resolution. This allows you to artificially increase the resolution of produced graphics. The advised setting is "Standard". To be able to use "High" or "Extra High", you usually need to start the Java virtual machine with extra memory.

  • ${argo.root}. The full path to the ArgoUML program, i.e. the argouml.jar file.

  • ${argo.home}. The ArgoUML home directory which contains the "jar" files needed by ArgoUML.

  • ${argo.ext.dir}. The directory holding ArgoUML extensions???by default the ext sub-directory of the ArgoUML build directory.

  • ${java.home}. The home directory of the Java Runtime Environment (JRE).

  • ${user.home}. The user's home directory. Used for storing the argo.user.properties file.

  • ${user.dir}. The directory from which ArgoUML was started.

  • Startup Directory. The directory in which ArgoUML starts file searches etc.

10.4.5.3. User Tab

This tab allows the user to record additional information of use to the system. There are two text boxes provided.

Figure 10.15. The dialog for Settings - User.

The dialog for Settings - User.


  • Full Name. Allows the user to record her full name.

  • Email Address. Allows the user to record his Email address.

This information is used when requesting to-do help by Email.

10.4.5.4. Appearance Tab

This tab allows the user to specify the LAF (Look And Feel) and theme, i.e. what the complete ArgoUML UI looks like. It comprises the following settings.

Figure 10.16. The dialog for Settings - Appearance.

The dialog for Settings - Appearance.


  • Look and Feel. The choice made here influences the complete User Interface. It only becomes effective when ArgoUML is exited and restarted.

  • Metal Theme. This item is downlighted if the Metal LAF is not chosen. The choice made here influences the complete User Interface. It only becomes effective when ArgoUML is exited and restarted.

  • Smooth edges of diagram lines and text. This feature is known as “anti-aliasing” on certain platforms. It causes diagonal lines to look much less jagged, by making use of several shades of gray. This feature only works if the operating system supports it.

10.4.5.5. Notation Tab

This tab allows the user to specify certain notation settings, i.e. how things are shown on diagrams. It comprises the following check boxes.

All settings here, only define the defaults used for new projects. If you want to change the way the diagrams in your current project look, then see the File - Properties menu.

Figure 10.17. The dialog for Settings - Notations.

The dialog for Settings - Notations.


  • Notation Language ( UML 1.4 by default). This feature allows changing the default notation (i.e. language: UML, Java,...) used on the diagrams for new projects. Suppose that a designer indicates that the default notation of a project is Java. When he saves the project, the choice for Java is stored inside the project file. If someone else is viewing the diagram, he will see the Java notation, too. This person can select the UML notation in the File - Notation menu, and see all diagrams in UML language. See Section 10.3.13, “Notation”).

  • Use guillemots (?? ??) for stereotypes (clear by default). By default ArgoUML uses pairs of less than and greater than (<< >>) characters for stereotypes. If this box is checked stereotypes on diagrams are shown between true guillemots (?? ??).

    This feature is presumably added to ArgoUML because guillemots are poorly supported by various fonts, and if they are present, then they are quite small and poorly visible.

    Independent of the way they are shown, when entering stereotypes, you can always type real guillemots (if your keyboard supports it) or their << >> equivalents.

  • Show visibility (clear by default). If this is selected, then ArgoUML will show the visibility indicators in front of e.g. attributes in the diagram. In UML the notation is "+" for public, "-" for private, "#" for protected, and "~" for package. E.g. for an attribute, it may show: +newAttr : int.

  • Show multiplicity (clear by default). If this is selected, then ArgoUML will show the multiplicity of e.g. attributes in the diagram. In UML notation, the multiplicity is shown between [], such as: +newAttr [0..*] : int. This setting has no impact on showing multiplicity near associationends.

  • Show initial value (clear by default). If this is selected, then ArgoUML will show the initial value of e.g. attributes in the diagram. In UML notation, the initial value is shown e.g. like this: +newAttr : int = 1.

  • Show properties (clear by default). If this is selected, then ArgoUML will show various properties between braces {}. E.g. for an attribute, it may show: +newAttr : int { frozen }.

  • Show types and parameters (set by default). When this checkbox is unmarked, attributes in classes are shown without type indication, and operations are shown without parameters. This feature may be usefull during the analysis phase of your project. If all checkmarks in the Notation Tab are unchecked, then e.g. for an attribute, ArgoUML may show: newAttr. And for an operation: newOperation().

  • Show stereotypes in explorer (clear by default). If this is selected, then ArgoUML will show stereotypes next to the icons of the modelelements in the Explorer, i.e. the tree structure at the left hand side.

  • Default shadow width (set to 1 by default). ArgoUML is able to draw all elements on a diagram with a shadow. Use this setting to adjust the size of the shadow, used when the modelelement is created. The details tab "Presentation" allows to set the shadow per modelelement, after they are created.

10.4.5.6. Modules Tab

This tab shows a list of modules that are installed, which may be enabled or disabled. Since this is a new concept for ArgoUML, it currently contains a list of modules that can not be removed, and a button to test the concept. Pressing this button adds a useless menu-item on the Tools menu, nothing else.

Notice also that this is a "new" modules concept so the old Pluggable modules do not work this way, and are not listed.

10.4.5.7. Extra Tabs added by Plugins

A plug-in module has the possibility to add extra tabs. One example is C++; it adds the following tab.

Figure 10.18. The dialog for Settings - C++.

The dialog for Settings - C++.


10.5. The View Menu

This menu is used for actions that affect how the various panes are viewed.

10.5.1. Goto Diagram...

This menu entry brings up a dialog box, describing all the diagrams in the current project under ArgoUML.

Figure 10.19. The dialog for Goto Diagram....

The dialog for Goto Diagram....


The dialog box contains a table with three columns and one row for each diagram in the current project. A scroll bar gives access if the table is too long for the box. Double button 1 click on any row will select that diagram in the editing pane. The three columns are as follows.

  • Type. Lists the type of diagram.

  • Name. Lists the name given to the diagram.

  • Description. Shows how many nodes and edges there are on the diagrams. A node is a “2-D” artifact and an edge is a connector artifact.

This dialog box is not modal, which allows it to remain open while editing the model for easy navigation.

[Warning]Warning

The V0.22 implementation of ArgoUML does not inmediately update the dialog box with changes made to diagrams: change of name, addition of diagrams, deletion of diagrams.

10.5.2.  Find...

This menu entry brings up a non-modal dialog box for the ArgoUML search engine.

Figure 10.20. The dialog for Find....

The dialog for Find....


At the top, the dialog box has four tabs labeled Name and Location, Last Modified, Tagged Values and Constraints. Of these all but the first are grayed out in the V0.22 version of ArgoUML (because they are not imlemented yet), so the first tab is always selected.

The Name and Location specifies the search to be made. It contains the following:

  • A text box labeled Element Name: specifies the name of the element (or artifact) to search for. Wild cards (*, ?) may be used here. A drop down gives access to find expressions previously used.

  • A text box labeled In Diagram: specifies which diagrams are to be searched. Again wild cards may be used. Both these two text boxes have a default entry of *, i.e. match anything.

  • To the right of these two text boxes, a selector labeled Element Type: allows you to specify the UML metaclass for which you are searching.

  • A selector labeled Find in: allows the search to be made over the entire project (the default) or as a sub-search over the results of a previous search. When opened, a list of all the search result tabs appears.

  • Beneath these boxes is the button Clear Tabs. This clears the display of tabs with the results from previous searches (see below). This button is downlighted if there are no tabs but the Help tab.

  • And finally, there is the button Find. This causes the search specified in the text boxes and selectors above to be executed. The results are displayed in a tab taking up the lower two thirds of the page.

The lower two thirds of the dialog comprises an initial tab (labeled Help) giving summary help, and further tabs displaying the results of searches. These search tabs are labeled with a summary of the search element  in diagram and are divided horizontally in two halves.

Button 1 double clicking on these tabs removes the tab, and spawns a new window that contains the tab contents, i.e. the search results. This window can be moved and sized at will. This does not work for the help tab.

The top half is labeled Search Results: followed by a count of the number of items found. It comprises a table with one row for each element (artifact) and four columns. The width of the columns can be adjusted.

  • Type. Lists the type of element (artifact).

  • Name. Lists the name given to the element (artifact).

  • In Diagram. Where the artifact is visible on a diagram, this lists the name of the diagram, otherwise it shows N/A.

  • Description. Contains a description of the element (artifact). In ArgoUML V0.18 this seems to be restricted to the single entry docs.

Button 1 click on any row will give more information on that artifact by showing related artifacts in the bottom half (see below). Double click on any row describing an artifact on a diagram and that item and diagram will be selected.

The bottom half of the tab is a table labeled Related Elements: and is a table with the same columns as the top half. When an element (artifact) has been selected in the top half, this table shows the details of any related elements.

[Tip]Tip

Enlarging the dialog vertically shows that the "Related Items" part changes in size, but not the Search results part. However, between them is a divider line and when hovering over this line, the mouse pointer changes into a sizing icon, and the border between these 2 areas can be moved up or down to redistribute the space in the window.

[Warning]Warning

This dialog box is not modal, which allows it to remain open while editing the model for easy navigation. But the V0.22 implementation of ArgoUML does not inmediately update the dialog box with changes made to the found artifacts: change of artifact name, change of diagram name. Deletion of a diagram does not stop the possibility to navigate to it.

10.5.3. Zoom

This entry brings up a sub-entry, which allows scaling the view of all diagrams to a factor of its normal size. This setting is not saved persistently.

The sub-menu items that can be selected are:

  • Zoom Out. Shortcut (Ctrl-Minus). Gives more overview over the drawing.

  • Zoom Reset. Returns to the default zoom ratio (i.e. 100%).

  • Zoom In. Shortcut (Ctrl-Equals). Makes the items on the drawings bigger.

10.5.4. Adjust Grid

This cycles the grid representation on the screen through the following sequence:

  • dots at 16 pixel spacing (the default);

  • dots at 32 pixel spacing;

  • no grid of any form;

  • full grid at 16 pixel spacing; and

  • full grid at 8 pixel spacing.

10.5.5. Adjust Grid Snap

This cycles the spacing of grid snapping through the following sequence:

  • snap at 8 pixel spacing (the default);

  • snap at 16 pixel spacing;

  • snap at 32 pixel spacing; and

  • snap at 4 pixel spacing.

[Note]Note

There is no option to turn off snap to grid altogether

[Caution]Caution

In the V0.22 version of ArgoUML this is not actually a true snap to grid. It just defines the increments by which artifacts are moved around. Thus if an item has an X coordinate of 4 and Grid Snap is set to 8, moving will take it to X coordinates of 12, 20, 28 etc, not 8, 16, 24 etc

If you wish to align on true grid snap boundaries, you can use the Arrange > Align To Grid menu (see Section 10.7.1, “Align”).

10.5.6. Page Breaks

This toggles whether page breaks are shown on the diagram (as white dotted lines).

[Warning]Warning

This menu item does not work in ArgoUML V0.22.

10.6. The Create Menu

This menu provides for creating the various types of UML diagrams supported by ArgoUML.

10.6.1.  New Use Case Diagram

This menu entry creates a blank use case diagram, and selects that diagram in the editing pane. If a package is currently selected, then the use case diagram will be created within that package. This means that it will be shown within the package on the explorer hierarchy (under Package-centric view) and artifacts created on the diagram will be created within the namespace of the package. This does not only apply to a package, but also to a class, interface, use case, etc.

[Tip]Tip

This does not prevent artifacts from other namespaces/packages appearing on the diagram. They can be added from the explorer using Add to Diagram from the button 2 pop-up menu.

10.6.2.  New Class Diagram

This menu entry creates a blank class diagram, and selects that diagram in the editing pane. If a package is currently selected, the class diagram will be created within that package. This means that it will be shown within the package on the explorer hierarchy (under Package-centric view) and artifacts created on the diagram will be created within the namespace of the package. This does not only apply to a package, but also to a class, interface, use case, etc.

[Tip]Tip

This does not prevent artifacts from other namespaces/packages appearing on the diagram. They can be added from the explorer using Add to Diagram from the button 2 pop-up menu.

10.6.3.  New Sequence Diagram

This menu entry creates a blank sequence diagram, and selects that diagram in the editing pane. It also creates a Collaboration UML element, which is a container for the elements shown on the new diagram. If a class is currently selected, a sequence diagram and a collaboration will be created that represent the behaviour of that class. This means that the created elements will be shown within the class in the explorer hierarchy (under Package-centric view) and artifacts created on the diagram will be created within the namespace of the collaboration. A sequence diagram may not only represent the behavior of a class, but also of any other classifier, such as interface, use case, etc. It is also possible to make sequence diagrams for an operation.

10.6.4.  New Collaboration Diagram

This menu entry creates a blank collaboration diagram, and selects that diagram. It also creates a Collaboration UML element, which is a container for the elements shown on the new diagram. If a package is selected when this menu item is activated, the collaboration diagram will be created within a collaboration within that package. This means that it will be shown within the collaboration within the package on the explorer hierarchy (under Package-centric view) and artifacts created on the diagram will be created within the namespace of the collaboration within the package.

[Tip]Tip

This does not prevent artifacts from other namespaces/packages appearing on the diagram. They can added from the explorer by dragging or by using Add to Diagram from the button 2 pop-up menu.

10.6.5.  New Statechart Diagram

This menu entry creates a blank statechart diagram associated with the currently selected class, and selects that diagram in the editing pane. It also creates a Statemachine UML element, which is a container for the elements shown on the new diagram.

Statechart diagrams are associated with a model element capable of dynamic behavior, such as a classifier or a behavioral feature, which provides the context for the state machine it represents. Suitable model elements are e.g. a class, an operation, and a use case. If such element is not selected at the time the New Statechart Diagram menu is activated, then an unattached statemachine is created. To obtain a well-formed UML model, you have to set the context of the statemachine on its details pane.

10.6.6.  New Activity Diagram

This menu entry creates a blank activity diagram associated with the currently selected class, and selects that diagram in the editing pane. It also creates a ActivityGraph UML element, which is a container for the elements shown on the new diagram.

Activity diagrams are associated with a model element capable of dynamic behavior, such as packages, classifiers (including use cases) and behavioral features. Suitable model elements are e.g. a class, a use case, an operation, and a package. If such element is not selected at the time the New Activity Diagram menu is activated, then an unattached ActivityGraph is created. To obtain a well-formed UML model, you have to set the context of the ActivityGraph on its details pane.

10.6.7.  New Deployment Diagram

This menu entry creates a blank deployment diagram, and selects that diagram in the editing pane.

[Tip]Tip

Artifacts from other namespaces/packages can be added from the explorer by dragging or by using Add to Diagram from the button 2 pop-up menu.

10.7. The Arrange Menu

This menu provides a range of functions to help in the alignment of artifacts on diagrams within the editing pane. In general the menu function invoked is applied to any artifact or artifacts currently selected in the editing pane.

10.7.1. Align

This sub-menu aligns the selected items. There are seven alignment options provided.

  • Align Tops. Aligns the selected artifacts by their top edges.

  • Align Bottoms. Aligns the selected artifacts by their bottom edges.

  • Align Rights (Shortcut Ctrl-R). Aligns the selected artifacts by their right edges.

  • Align Lefts (Shortcut Ctrl-L). Aligns the selected artifacts by their left edges.

  • Align Horizontal Centers. Aligns the selected artifacts so their horizontal centers are in a vertical line.

  • Align Vertical Centers. Aligns the selected artifacts so their vertical centers are in a horizontal line.

  • Align To Grid. Aligns the selected artifacts so their top and right edges are on the grid snap boundary (see Section 10.5.5, “Adjust Grid Snap” ) edge.

    [Tip]Tip

    The alignment is to the current grid snap setting, which may be smaller, larger or the same as the displayed grid. Since items are aligned to the grid snap boundary any way when you place them, this menu entry has no effect unless you have either changed the grid snap to a larger value or used one of the other Arrange menu entries to push items off their initial positions.

10.7.2. Distribute

This sub-menu distributes the selected items. There are four distribution options provided.

  • Distribute Horizontal Spacing. The leftmost and rightmost selected artifacts are not moved. The others are adjusted horizontally until the horizontal space (i.e. from the right edge of the left artifact to the left edge of the right artifact) is the same for all of the selected items

  • Distribute Horizontal Centers. The leftmost and rightmost selected artifacts are not moved. The others are adjusted horizontally until the distance between the horizontal centers of all the selected items is the same.

  • Distribute Vertical Spacing. The top and bottom selected artifacts are not moved. The others are adjusted vertically until the vertical space (i.e. from the bottom edge of the top artifact to the top edge of the bottom artifact) is the same for all of the selected items

  • Distribute Vertical Centers. The top and bottom selected artifacts are not moved. The others are adjusted vertically until the distance between the vertical centers of all the selected items is the same.

10.7.3. Reorder

This sub-menu adjusts the ordering of overlapping items. There are four reorder options provided.

  • Forward. The selected artifacts are moved one step forward in the ordering hierarchy with respect to other artifacts they overlap.

  • Backward. The selected artifacts are moved one step back in the ordering hierarchy with respect to other artifacts they overlap.

  • To Front. The selected artifacts are moved to the front of any other artifacts they overlap.

  • To Back. The selected artifacts are moved to the back of any other artifacts they overlap.

10.7.4. Nudge

This sub-menu provides fine adjustment to the positioning of selected artifacts. There are four nudge options provided.

  • Nudge Left. The selected artifacts are moved one pixel to the left.

  • Nudge Right. The selected artifacts are moved one pixel to the right.

  • Nudge Up. The selected artifacts are moved up one pixel.

  • Nudge Down. The selected artifacts are moved up one pixel.

10.7.5. Set Preferred Size

This menu-item acts on all selected items on the current diagram. It resets all sizes of all artifacts to its “preferred” size, i.e. the minimum size for which all text fits inside.

10.7.6. Toggle Auto Resizing

This menu-item is a checkbox that currently does not do anything.

10.7.7. Layout

This menu-item provides an automatic diagram layout function, i.e. when activating this menu-item, all items on the current class diagram are rearranged according a certain layout algorithm.

This function currently only works for classdiagrams. For all other types of diagrams, the menu-item is downlighted.

10.8. The Generation Menu

This menu provides support for code generation from UML diagrams. The functionality is built around the structural information of class diagrams.

[Note]Note

Without any plugin modules installed, ArgoUML supports only code generation of Java. ArgoUML V0.20 supports the following languages by plugin: C#, C++, php4, php5.

[Warning]Warning

Code generation is still very much a work in progress. The current version of ArgoUML will generate a structural template for your code, but is not able to handle behavioral specifications to generate code for the dynamic behavior of the model.

10.8.1. Generate Selected Classes ...

This menu entry brings up a dialog box for the ArgoUML code generator (see Figure 10.21, “The dialog for Generate Selected Classes....” ).

Figure 10.21. The dialog for Generate Selected Classes....

The dialog for Generate Selected Classes....


Below a label Available Classes the dialog box lists each of the selected classes by name with a check box to the left, for each language installed. All the checkboxes are initially unchecked. Checking any of these boxes will cause code generation for that class. Checking multiple languages for a class causes it to be generated in all these languages.

The buttons Select All and Select None may help when a lot of items have to be selected or deselected.

In the lower portion of the dialog box is an editable combo box labeled Output Directory to specify the directory in which code is generated. Within this directory, a top level directory will be created with the name of the model. Further sub-directories will be created to reflect the package/namespace hierarchy of the model. A drop down selector gives access to previously selected output directories.

Finally, at the bottom of the dialog box are two buttons, labeled Generate and Cancel. Button 1 click on the former will cause the code to be generated, button 1 click on the latter will cancel code generation.

10.8.2. Generate All Classes...

Shortcut F7.

This function behaves as Generate Selected Classes... (see Section 10.8.1, “Generate Selected Classes ...”) would with all classes in the current diagram selected.

10.8.3. Generate Code for Project... (To be Written)

10.8.4. Settings for Generate for Project... (To be Written)

10.9. The Critique Menu

This menu controls one of ArgoUML's unique features???the use of critics to guide the designer. The theory behind this is well described in Jason Robbins' PhD dissertation http://argouml.tigris.org/docs/robbins_dissertation/.

[Note]Note

A word about terminology: The critics are background processes, which evaluate the current model according to various “good” design criteria. There is one critic for every design criterion.

The output of a critic is a critique???a statement about some aspect of the model that does not appear to follow good design practice.

Finally a critique will generally suggest how the bad design issue it has identified can be rectified, by raising a to-do item.

[Note]Note

The critics run as asynchronous processes in parallel with the main ArgoUML tool. Changes typically take a second or two to propagate as the critics wake up.

10.9.1. Toggle Auto-Critique

This is a check box, controlling whether the critics are running. By default it is checked. If unchecked, then all critics are disabled, and any to-do items generated by critics (the only others being those the designer has added by hand) are hidden in the to-do pane.

10.9.2. Design Issues...

This menu entry brings up a dialog box controlling how critics associated with a particular design area are to be handled (see Figure 10.22, “The dialog for Design Issues....” ).

Figure 10.22. The dialog for Design Issues....

The dialog for Design Issues....


ArgoUML categorizes critics according the the design issue they address. There are 16 such categories. The critics in each category are discussed in detail in the chapter on critics (Chapter 15, The Critics).

The sliders may be set for each category to control the critics that trigger for that category. Setting a slider to Off will disable all critics in that category, and remove all associated to-do items from the to-do pane.

Setting a slider to a higher priority value will enable all critics at or above that priority level within the design issue category (Off being the lowest priority).

[Note]Note

The sliders are set by default to High for all design categories.

10.9.3. Design Goals...

This menu entry brings up a dialog box controlling how design goals are to be handled (see Figure 10.23, “The dialog for Design Goals....”).

Figure 10.23. The dialog for Design Goals....

The dialog for Design Goals....


ArgoUML has the concept that the designer will have a number of design goals to be achieved (for example good structural representation, detailed behavioral representation etc). Critics are associated with one or more goals.

This dialog allows the user to specify the priority of each design goal.

The sliders may be set for each design goal to control the critics that trigger for that goal. Setting a slider to zero will disable all critics in that goal, and remove all associated to-do items from the to-do pane.

Setting a slider to a higher value will enable all critics at or above that priority level within the design issue category (1 being the highest priority and 5 the lowest).

[Tip]Tip

It may be useful to think of this function as very similar to Design Issues... (see Section 10.9.2, “Design Issues...”), but with grouping of critics according to the outcomes of OOA&D rather than grouping according to the structure of UML.

[Warning]Warning

The V0.20 version of ArgoUML provides a single design goal, Unspecified, with its slider set by default to priority 1. However it contains no critics and so has no effect.

10.9.4. Browse Critics...

This menu entry brings up a dialog box controlling the individual critics (see Figure 10.24, “The dialog for Browse Critics....”).

Figure 10.24. The dialog for Browse Critics....

The dialog for Browse Critics....


This dialog controls the behavior of individual critics. To the left is a list of all the critics, to enable them to be switched on or off individually. For each critic there are three columns, labeled Active, Headline and Snoozed. The first of these is a check box, which may be toggled with button 1 click. The second is the headline name of the critic, the third indicates if the critic has been snoozed from the to-do pane (see Chapter 14, The To-Do Pane. A critic is only really active if the box in the first column is checked and the critic has not been snoozed.

Any critic for which the box in the first column is unchecked is inactive and will not trigger. In addition any to-do items associated with that critic will be removed from the to-do pane.

The V0.20 version of ArgoUML has a total of 90 critics, a few of which are incompletely implemented. They are described in detail by design issue category in the chapter on critics (see Chapter 15, The Critics).

To the right of the list are a series of fields, titled Critic Details, giving detailed control over individual critics. Selecting a critic in the list on the left will populate the fields for that critic.

The first field on the right is titled Critic Class: and then the full name of the class in ArgoUML that implements the critic. This name can be used as unique identifier of the critique, e.g. in conversations about the critic.

The first field below this title is a text box labeled Headline: giving the complete headline of the critic (which may be truncated in the list on the left).

[Note]Note

In the headline you may see the text <ocl>self</ocl>, which will be replaced by the name of the artifact in question when the critic is triggered.

The next field is a drop-down selector, labeled Priority:. The three options available are High, Medium and Low and specify the priority category of any to-do item generated by this critic. This does not alter the priority of the already existing todo items, only the newly generated ones. Changing the priority of a critic is not saved persistently.

The next field is labeled MoreInfo: and contains a URL pointing to further information with a button to the right labeled Go to navigate to that URL.

[Warning]Warning

In the V0.20 release of ArgoUML there is no further information available, and the Go button is always grayed out and disabled.

The next field is labeled Description: and is a text area with a detailed explanation of what this critic means. If the text is too large for the area a scroll bar is provided to the right.

[Note]Note

In this text area you may see the text <ocl>self</ocl>, which will be replaced by the name of the artifact in question when the critic is triggered.

The last field is a drop-down selector labeled Use Clarifier, with three options, Always, If Only One and Never.

Clarifiers are the icons and wavy red underlines drawn on the actual diagrams to indicate the artefact to which the critic refers. The original intention was to make the mapping from critics to clarifiers somewhat customizable.

For example one user might make a Missing Name critic show a red underline, another user might turn off the clarifier, or have it draw a wavy green underline or a blue questionmark. Critics with their clarifier's disabled would still produce feedback that is listed in the to-do pane.

[Caution]Caution

In the V0.20 release of ArgoUML this selector has no function whatsoever. It is for future development.

Underneath the fields are three buttons in a horizontal row.

  • Wake. It is possible to snooze a critic from the to-do pane (see Chapter 14, The To-Do Pane), which makes the critic inactive for a period. If the critic has been snoozed, this button is enabled and will wake the critic back up again. Otherwise it is grayed out.

    [Tip]Tip

    You can tell a snoozed critic, because in the list on the left it will be indicated in the third column.

  • Configure. This button is for configuring the critic.

    [Caution]Caution

    In the V0.20 version of ArgoUML this function is not implemented, and this button is always grayed out. It is for future development.

  • Edit Network. Right now critics are implemented in java code. That means end-users cannot add new critics.

    The idea of a critic network is that they would be a state machine like diagram with several steps. Each step would express a condition which, collectively with the other steps associated with that critic, articulates the “rule” that the critic is providing. If the rule fires, then remaining steps would define the steps of the wizard to help the user fix the problem.

    The ideas behind this are discussed in Chapter 4 of Jason Robbins PhD disseration ( http://argouml.tigris.org/docs/robbins_dissertation/diss4.html. In particular look at Figure 1-6 in this chapter and the related discussion.

    A suggested implementation is that the conditions could be written in OCL against the UML meta-model. A library of predefined conditions and steps would allow end-users to build new critics by combining those in novel ways.

    [Caution]Caution

    In the V0.20 version of ArgoUML this function is not implemented, and this button is always grayed out. It is for future development.

Finally the bottom right of the dialog contains a button labeled OK. Button 1 click here dismisses the dialog.

10.10. The Tools Menu

This menu provides a generic menu attachment point for any plug-ins provided with ArgoUML. The standard system has no plug-in, and this menu entry is empty by default.

10.11. The Help Menu

This menu provides help on the use of ArgoUML. It has two entries.

10.11.1. System Information

This menu entry brings up the system information dialog, see Figure 10.25, “The dialog for System Information.”

Figure 10.25. The dialog for System Information.

The dialog for System Information.


Use this menu to describe the system that runs ArgoUML to the system manager or developer. Pressing the button Run Garbage Collector not only runs the Java gargage collector, but also refreshes the information shown. To facilitate copy and paste into (e.g.) an email, the button Copy Information to System Clipboard is foreseen. The Cancel button dismisses the dialog box.

10.11.2. About ArgoUML

This menu entry brings up the help window for ArgoUML (see Figure 10.26, “The help window for ArgoUML”).

Figure 10.26. The help window for ArgoUML

The help window for ArgoUML


The window has six tabs, which are selected by button 1 click. By default the first tab (Splash) is shown.

  • Splash. This displays the picture shown when ArgoUML starts up, and the current version number.

  • Version. This provides version information on the various packages that make up ArgoUML, and some operating system and environment information.

  • Credits. This details all those who have created ArgoUML, including contact details for the various module owners.

  • Contact Info. This gives the major contact points for the ArgoUML project???the web site, and the developers mailing list.

  • Report bugs. This gives information about how to deal with bugs in ArgoUML. It is important that all bugs are reported, and all cooperation is appreciated.

  • Legal. A statement of the FreeBSD license which covers all the ArgoUML software.

    [Caution]Caution

    The various documentation of the project are not all covered by FreeBSD (which is really meant for software). In particular this manual is covered by the OpenPub license (see Appendix F, Open Publication License ).

Chapter 11. The Explorer

The Explorer was previously called Navigation Pane/Tree or sometimes Navigator Pane/Tree.

11.1. Introduction

Figure 11.1, “Overview of the explorer” shows the ArgoUML window, with the explorer highlighted.

Figure 11.1. Overview of the explorer

Overview of the explorer


The explorer allows the user to view the structure of the model from a number of predefined perspectives. It also allows the user to define their own perspetives for custom exploring of the model.

An important feature, related to the cognitive psychology ideas behind ArgoUML is that not all artifacts are necessarily shown in all perspectives. Rather, the perspectives are used to implement hiding of uninteresting parts of the model.

11.2. Mouse Behavior in the Explorer

Behavior of the mouse in general, and the naming of the buttons is covered in the chapter on the overall user interface (see Chapter 8, Introduction).

11.2.1. Button 1 Click

Within the hierarchical display, elements which have sub-hierarchies are indicated by when the hierarchy is hidden and when the hierarchy is open.

Button 1 click over the name of any diagram artifact will cause the diagram to be selected and displayed in the editing pane. Its details will also be displayed in the details pane.

Button 1 click over the name of any artifact other than a diagram in the main area of the explorer will cause it to be selected, and its details shown in the details pane. If the artifact is part of a diagram currently displayed in the editing pane, it will be highlighted there.

[Note]Note

If the artifact is part of a diagram other than that currently displayed in the Editing Pane, there will be no change of diagram in the Editing Pane.

Where button 2 click has been used to bring up a context sensitive pop-up menu (see below), button 1 click is used to select the menu entry required. button 1 click outside the menu area will remove it.

11.2.2. Button 1 Double Click

This has the effect of a button 1 single click, and if the tree item was not a leaf, it will toggle the hierarchy open or close.

11.2.3. Button 1 Motion

Button 1 motion means that you pick up one or more modelelements, and drag them to a new location. Dropping the modelelement somewhere causes ArgoUML to execute some function that depends on where you drop the modelelements.

11.2.3.1. From Explorer to Explorer

Releasing the mouse button above a namespace, makes the modelelement owned by the namespace. In the Package-centric explorer perspective, this means a straigh-forward drag-and-drop function.

Use this drap and drop feature to easily move e.g. classes from one package into another.

11.2.3.2. From Explorer to Diagram

Dropping a modelelement on the diagram is the equivalent of the "Add to Diagram" function. Hence, if the diagram did not yet show this modelelement, it is added.

Use this drap and drop feature e.g. to easily create a diagram from imported XMI files. This because XMI files contain all the modelelements, but not any diagram information.

11.2.4. Button 2 Actions

When used in the the explorer, this will display a selection dependent pop-up menu. Menu entries are highlighted (but not selected) and sub-menus exposed by subsequent mouse motion (without any buttons). Menu entry selection is with button 1 or button 2.

11.2.5. Button 2 Double Click

This has no effect other than that of button 2 single click.

11.3. Keyboard Behavior in the Explorer

All keys active in a tree widget have their normal behaviour.

When a diagram is selected, pressing Ctrl-C will copy the diagram in GIF format to the system clipboard.

11.4. Perspective Selection

The artifacts in the ArgoUML model may be configured for displaying in the tree by a number of perspectives. To this end, a drop-down at the top allows selection of the explorer perspective.

Below that, there is a drop-down to select the ordering of the atifacts within the hierarchy. The two possibilities are "Order by Type, Name" and "Order by Name". The former groups all items per type, and sorts them per group alphabetically on the name. The lattter simply sorts on name only.

The following explorer perspectives may be selected in the drop-down at the top:

  • Package-centric (the default). The exploring hierarchy is organized by package hierarchy. The top level shows the model. Under this are all the top level packages in the model and all the artifacts that are directly in the namespace of the model.

    Beneath each package are all the artifacts that sit within the namespace of that package, including any further sub-packages (which in turn have their own sub-hierarchies).

  • Class-centric. Shows classes in their package hierarchy as well as datatypes and use case diagram elements. Similar to the Package-centric view but it doesn???t show connecting or associating elements.

  • Diagram-centric. In this view the top level comprises all the diagrams in the model. Beneath each diagram is a flat listing of all the artifacts on the diagram. Artifacts that have sub-artifacts that do not appear on the diagram have their own hierarchy (for example attributes and operations of classes).

  • Inheritance-centric. In this view the top level shows the model. Beneath this are all artifacts that have no generalization in the model. Those artifacts that have specializations have a sub-hierarchy showing the specializations.

  • Class Associations. In this view the top level shows the model. Beneath this are all diagrams and all classes. All classes that have associations have a hierarchy tracking through the associated classes.

  • Residence-centric. In this view the model is shown at the top-level, with below it only Nodes, and below these only components that reside on the nodes, and below these components all elements that reside on the components.

  • State-centric. In this view the top level shows all the state machines and all activity graphics associated with classes.

    Beneath each state machine is a hierarchy showing the statechart diagram and all of the states. Beneath each state is a list of the transitions in and out of the state.

    Beneath each activity graph is a hierarchy showing the activity diagram and all of the action states. Beneath each action state is a list of the transitions in and out of the action state.

  • Transitions-centric. This is very similar to State-centric view, but under each state machine is listed the diagrams and all transitions on the diagram, with states being shown as sub-hierarchies under their connected transitions.

    Similarly under each activity graph is listed the diagrams and all transitions on the diagram, with action states being shown as sub-hierarchies under their connected transitions.

  • Composition-centric. In this view, all modelelements are shown according their composition in the UML metamodel.

    This perspective shows far more modelelements then all others - it does not hide anything. Hence, this view is not so user-friendly, but very suited for the UML specialist.

11.5. Configuring Perspectives

The explorer is designed to be user configurable, to allow the designer to view in his or her preferred way.

11.5.1. The Configure Perspectives dialog

button 1 click on the "Configure Perspectives" icon ( ) at the top left of the explorer brings up the explorer perspectives dialog (see Figure 11.2, “The Configure Perspectives dialog box”).

Figure 11.2. The Configure Perspectives dialog box

The Configure Perspectives dialog box


The top half of the dialog contains a list of all the currently defined perspectives and to the right a series of buttons stacked vertically. Button 1 click can be used to select a perspective. You can select only one perspective at a time.

Selecting a perspective reveals a text field above the list, where the name of the perspective can be edited.

The lower half of the dialog contains two list areas. The one on the left, labeled Rules Library, contains the list of available rules that may be used to create the perspective. The one on the right, labeled Selected Rules contains the actual rules chosen for the perspective that has been selected in the list of perspectives at the top. In both lists, you can select only one rule at a time.

Separating the two areas in the lower half of the dialog are buttons labeled >> and <<. The first of these transfers the rule selected in the library on the left to the list of rules on the right???i.e. it adds a rule to the perspective. The second one transfers the rule selected on the right to the library list on the left???i.e. it removes a rule from the perspective.

If you hover the mouse over the horizontal line that separates the two halves of the dialog, then you see it change shape, to indicate that you can grab this line and drag it up or down.

All three titles of the lists show the number of items in the list. ArgoUML V0.20 has 8 default perspectives, and 68 rules in the library to build perspectives from.

The buttons at the top right are explained as follows:

  • New. This creates a new perspective from scratch with no rules selected, with an automatically generated name.

  • Remove. This removes the selected perspective.

  • Duplicate. This creates a copy the selected perspective so it can be used as the basis of a new perspective. The new one is named "Copy of" followed by the original name.

  • Move Up. This moves the selected perspective one place up in the list. This button is downlighted for the topmost perspective.

  • Move Down. This moves the selected perspective one place down in the list. This button is downlighted for the last perspective.

  • Restore Defaults. This restores all perspectives and their selected rules to the build-in defaults of ArgoUML.

At the very bottom right is a button labeled OK to be used when all changes are complete. button 1 click on this button will close the dialog window. The changes are saved when you exit ArgoUML (or inmediately by activating the menuitem File->Save Configuration) in the argo.user.properties file.

Then there is the Cancel button, which cancels all changes made in the dialog. Pressing the dialog close icon (usually at the top right corner) has the same effect as pressing the cancel button.

11.6. Context Sensitive Menu

Button 2 Click over any selected artifact in the main area of the explorer will cause a pop-up menu to appear.

11.6.1. Add to Diagram

This entry on the pop-up menu appears for any artifact that could be added to the diagram in the editing pane.

The item can be placed in a diagram by moving the cursor to the editing pane or a spawned editing pane window (where it will appear as a cross) and clicking button 1.

[Caution]Caution

This menu entry only appears as not grayed out, if the diagram in the editor pane allows to contain the artifact, and the artifact is not present yet in the diagram. ArgoUML will not let you place more than one copy of any particular artifact on a diagram.

11.6.2.  Delete From Model

This entry on the pop-up menu appears for any artifact that could be deleted from the model.

[Warning]Warning

This deletes the artifact from the model completely, not just from the diagram. To remove the artifact just from the diagram, use the edit menu (see Section 10.4.2, “ Remove From Diagram”).

[Caution]Caution

You can delete a diagram from the model. Depending on the type of diagram, that might delete all artifacts shown on the diagram. To illustrate the differences, consider the following examples:

  • Deleting a class diagram does not delete any artifact drawn on it. All artifacts that were shown on the diagram remain present in the model. This because a class diagram does not "map" on any artifact according the UML standard V1.4.

  • Deleting a statechart diagram also deletes the statemachine it represents, and hence also all the artifacts owned by the statemachine. This because a statechart diagram does "map" into a StateMachine according the UML standard V1.4.

11.6.3. Set Source Path... (To be written)

This entry on the pop-up menu ...

11.6.4. Add Package

This entry on the pop-up menu is available whenever an artifact is selected that may contain a package, e.g. a package. After activating this menu the artifact will own a new package.

11.6.5. Add All Classes in Namespace

This entry on the pop-up menu is available for Class Diagrams only. Activating this menu-item will add all classes in the current namespace to the diagram. They will be located at the top left corner???obviously a perfect occasion to use the “Arrange->Layout” function in the menu.

Chapter 12. The Editing Pane

12.1. Introduction

Figure 12.1, “Overview of the editing pane” shows the ArgoUML window with the editing pane highlighted.

Figure 12.1. Overview of the editing pane

Overview of the editing pane


This is where all the diagrams are drawn. In earlier versions of ArgoUML this pane went under a variety of names. You may encounter “drawing pane”, “diagram pane” or “multi-editor pane” in other documentation that is still being updated.

The pane has a tool bar at the top, and a single tab labeled As Diagram at the bottom, which has no function in the 0.20 version of ArgoUML. The main area shows the currently selected diagram, of which the name is shown in the window title bar.

12.2. Mouse Behavior in the Editing Pane

Behavior of the mouse in general, and the naming of the buttons is covered in the chapter on the overall user interface (see Chapter 8, Introduction).

12.2.1. Button 1 Click

In the tool bar of the editing pane, button 1 click is used to select a tool for creating a new artifact and adding it to the diagram (see double clicking for creating multiple artifacts). For most tools, adding a new artifact to the diagram is achieved by moving the mouse into the editing area and clicking again.

In the main editing area button 1 click is used to select an individual artifact.

Many artifacts (e.g. actor, class) show special handles when selected and the mouse hovers over them. These are called “Selection Action Buttons”, see Section 12.5, “Selection Action Buttons”. They appear at the sides, top and bottom, and indicate a relationship type. Clicking on a Selection Action Button creates a new related artifact, with the relation of the type that was indicated. If the shift key is pressed when hovering the mouse over a selected artifact, sometimes different handles are shown, which stand for different relation types.

Where button 2 click has been used to bring up a context sensitive pop-up menu (see below), button 1 click is used to select the menu entry required. The pop-up menu will be removed by any button 1 click outside of the menu area.

There are various more detailed effects, which are discussed under the descriptions of the various tools (see Section 12.3, “The tool bar”).

12.2.2. Button 1 Double Click

When used on the tool bar with a tool to add an artifact, the selected artifact will be added multiple times to the drawing area, once for each further button click, until the tool is again selected or another tool chosen.

When used within the drawing area on an artifact that has sub-components, double click will select the sub-component for editing (creating it if necessary).

For example double clicking over an operation compartment of a class will select the operation. Or create one if there is none yet.

A special use is with package artifacts on the class diagram. A double click on a package will navigate to the class diagram associated with a package (the first created if there is more than one), or will offer to create one for you if there is none. See Figure 12.2, “The dialog for adding a new class diagram”

Figure 12.2. The dialog for adding a new class diagram

The dialog for adding a new class diagram


12.2.3. Button 1 Motion

Where the artifact being added is some form of connector its termination point is shown with button 1 up over the terminating artifact. button 1 click may be used in the space between artifacts to create articulation points in the connector. This is particularly useful where connectors must loopback on themselves.

Over graphical artifacts button 1 motion will move the artifact to a new position.

Graphical artifacts that are selected show handles at the corners or ends, and these can be used for re-sizing.

Some artifacts (e.g. actor, class) show special handles (called “Selection Action Buttons”, see Section 12.5, “Selection Action Buttons”) at the sides, top and bottom, which can be dragged to form types of relationship with other artifacts.

Where the artifact is some form of connector between other items, button 1 motion other than at a handle will cause a new handle to be created, allowing the connector to be articulated at that point. This only works when the connecting line is not straight angled. Such new handles can be removed by moving them to the end of the connector.

There are various more detailed effects, which are discussed under the descriptions of the various tools (see Section 12.3, “The tool bar”).

12.2.4. Shift and Ctrl modifiers with Button 1

Where multiple selections are to be made, the CTRL key is used with button 1 to add unselected artifacts to the current selection. Where an artifact is already selected, it is removed from the current selection.

Clicking Button 1 while the SHIFT key is pressed, invokes the broom tool, which causes the selected artifacts (and any others swept up with them) to be moved with the broom tool (see Section 12.3.1, “Layout Tools”).

12.2.5. Alt with Button 1 motion

Button 1 down anywhere in the diagram while the ALT key is pressed, allows to scroll the canvas in all directions with button 1 motion.

12.2.6. Button 2 Actions

When used over artifacts in the the editing pane, this will display a context dependent pop-up menu. Menu entries are highlighted (but not selected) and sub-menus exposed by subsequent mouse motion (without any buttons). Menu entry selection is with button 1 or button 2. See Section 12.9, “Pop-Up Menus” for details of the specific pop-up menus.

In case multiple elements are selected, the pop-up menu only appears if all the items are of the same kind. In this case, the functions apply to all selected elements.

12.2.7. Button 2 Double Click

This has no effect other than that of button 2 single click.

12.2.8. Button 2 Motion

This is used to select items in a context sensitive menu popped up by use of button 2 click.

12.3. The tool bar

The toolbar at the top of the editing pane provides the main functions of the pane. The default tool is the Select tool (). In general button 1 click on any tool selects a tool for one use, before reverting to the default tool, and button 1 double click selects a tool for repeated use.

The tools fall into four categories.

  • Layout tools. Provide assistance in laying out artifacts on the diagram.

  • Annotation tools. Used to annotate artifacts on the diagram.

  • Drawing tools. Used to add general graphic artifacts to diagrams.

  • Diagram specific tools. Used to add UML artifacts specific to a particular diagram type to the diagram.

Some of the tools that are generally not all used so often, are combined in a dropdown, to take less space on the toolbar. See e.g. Figure 12.3, “The drawing tools selector.”. Press the symbol at the right of the tool to pop it open. These drop-down tools remember their last used tool persistently. This means that when ArgoUML starts, they show the last tool that was activated the previous time ArgoUML was run.

12.3.1. Layout Tools

The following two tools are provided in all diagrams in this category.

  • Select. This tool provides for general selection of artifacts on the diagram. Button 1 click will select an artifact. CTRL with button 1 can be used to select (or deselect) multiple artifacts. Button 1 motion will move selected 2D items or add and move a new control point on a link. Button 1 motion on a selected component's control point will stretch that component's shape.

  • Broom. Button 1 motion with this tool provide a “broom” which will sweep all artifacts along. This is a very shortcut way of lining things up.

    The Broom can also be invoked by using SHIFT with button 1 motion when the Select tool is in use.

    The Broom is discussed at length in its own chapter, see Section 12.4, “The Broom”

[Tip]Tip

Additional control of artifact layout is provided through the Arrange menu (see Section 10.7, “The Arrange Menu”).

12.3.2. Annotation Tools

The annotation tool Comment ( ) is used to add a comment to a selected UML artifact.

[Caution]Caution

Unlike most other tools you use the Select tool to select an artifact, and then button 1 click on Comment to create the comment. If no element is selected when the comment tool is clicked, then the comment is created and put at the left top corner.

The comment is created alongside the selected artifact, empty by default. The text can be selected with button 1 double-click and edited from the keyboard.

The UML standard allows comments to be attached to any artifact.

You can link any comment to aditional elements using the CommentLink ( ) tool.

12.3.3. Drawing Tools

These are a series of tools for providing graphical additions to diagrams. Although they are not UML artifacts, the UML standard provides for such decoration to improve the readability of diagrams.

[Tip]Tip

These drawing tools provide a useful way to partially support some of the UML features (such as general purpose notes) that are missing from the current release of ArgoUML.

Eight tools are provided, all grouped into one drop-down widget. See Figure 12.3, “The drawing tools selector.”. Button 1 click on the diagram will place an instance of the graphical item of the same size as the last one placed. The size can be controlled by button 1 motion during placement. One side or end of the element will be at button 1 down, the other side or end at button 1 up. In general after they are placed on the diagram, graphical elements can be dragged with the Select tool and button 1 and re-sized by button 1 motion on the handles after they have been selected.

Figure 12.3. The drawing tools selector.

The drawing tools selector.


  • Rectangle. Provides a rectangle.

  • Rounded Rectangle. Provides a rectangle with rounded corners. There is no control over the degree of rounding.

  • Circle. Provides a circle.

  • Line. Provides a line.

  • Text. Provides a text box. The text is entered by selecting the box and typing. Text is centered horizontally and after typing, the box will shrink to the size of the text. However it can be re-sized by dragging on the corners.

  • Polygon. Provides a polygon. The points of the polygon are selected by button 1 click and the polygon closed with button 1 double click (which will link the final point to the first point).

  • Spline. Provide an open spline. The control points of the spline are selected with button 1 and the last point selected with button 1 double click.

  • Ink. Provide a polyline. The points are provided by button 1 motion.

12.3.4. Use Case Diagram Specific Tools

Several tools are provided specific to UML artifacts on use case diagrams. The detailed properties of these artifacts are described in the section on use case diagram artifacts (see Chapter 17, Use Case Diagram Artifact Reference).

  • Actor. Add an actor to the diagram. For convenience, when the mouse is over a selected actor it displays two handles to left and right which may be dragged to form association relationships.

  • Use Case. Add a use case to the diagram. For convenience, when the mouse is over a selected use case it displays two handles to left and right which may be dragged to form association relationships and two handles top and bottom which may be dragged to form generalization and specialization relationships respectively.

  • Association. Add an association between two artifacts selected using button 1 motion (from the first artifact to the second). There are 6 types of association offered here, see Figure 12.4, “The association tool selector.”: association, aggregation and composition, and all these three can be bidirectional or unidirectional.

    Figure 12.4. The association tool selector.

    The association tool selector.


  • Dependency. Add a dependency between two artifacts selected using button 1 motion (from the dependent artifact).

  • Generalization. Add a generalization between two artifacts selected using button 1 motion (from the child to the parent).

  • Extend. Add an extend relationship between two artifacts selected using button 1 motion (from the extended to the extending use case).

  • Include. Add an include relationship between two artifacts selected using button 1 motion (from the including to the included use case).

  • Add Extension Point. Add an extension point to a selected use case. The extension point is given the default name newEP and location loc. Where the extension point compartment is displayed, the extension point may be edited by button 1 double click and using the keyboard, or by selecting with button 1 click (after the use case has been selected) and using the property tab. Otherwise it may be edited through its property tab, selected through the property tab of the owning use case.

    [Note]Note

    This tool is grayed out except when a use case is selected.

12.3.5. Class Diagram Specific Tools

Several tools are provided specific to UML artifacts on class diagrams. The detailed properties of these artifacts are described in the section on class diagram artifacts (see Chapter 18, Class Diagram Artifact Reference).

  • Package. Add a package to the diagram.

  • Class. Add a class to the diagram. For convenience, when the mouse is over a selected class it displays two handles to left and right which may be clicked or dragged to form association relationships (or composition in case SHIFT has been pressed) and two handles top and bottom which may be dragged or clicked to form generalization and specialization relationships respectively.

  • Association. Add an association between two artifacts selected using button 1 motion (from the first artifact to the second). There are 2 types of association offered here, bidirectional or unidirectional.

  • Composition. Add an composition between two artifacts selected using button 1 motion (from the first artifact to the second). There are 2 types of composition offered here, bidirectional or unidirectional.

  • Aggregation. Add an aggregation between two artifacts selected using button 1 motion (from the first artifact to the second). There are 2 types of aggregation offered here, bidirectional or unidirectional.

  • Generalization. Add a generalization between two artifacts selected using button 1 (from the child to the parent).

  • Interface. Add an interface to the diagram. For convenience, when the mouse is over a selected interface it displays a handle at the bottom which may be dragged to form a realization relationship (the target being the realizing class).

  • Realization. Add a realization between a class and an interface selected using button 1 motion (from the realizing class to the realized interface).

  • Dependency. Add a dependency between two artifacts selected using button 1 motion (from the dependent artifact). There are also 2 special types of dependency offered here, Permission ( ) and Usage ( ). A Permission is created by default with stereotype Import, and is used to import elements from one package into another.

  • Attribute. Add a new attribute to the currently selected class. The attribute is given the default name newAttr of type int and may be edited by button 1 double click and using the keyboard, or by selecting with button 1 click (after the class has been selected) and using the property tab.

    [Note]Note

    This tool is grayed out except when a class is selected.

  • Operation. Add a new operation to the currently selected class or interface. The operation is given the default name newOperation with no arguments and return type void and may be edited by button 1 double click and using the keyboard, or by selecting with button 1 click (after the class has been selected) and using the property tab.

    [Note]Note

    This tool is grayed out except when a class or interface is selected.

  • Association Class. Add a new association class between two artifacts selected using button 1 motion (from the first artifact to the second).

  • Datatype. Add a datatype to the diagram. For convenience, when the mouse is over a selected datatype it displays handles at the top and at the bottom which may be clicked or dragged to form a generalization relationship (the target being another datatype). There are 2 other elements available here, Enumeration and Stereotype. These two have similar handles, except the one at the top of a stereotype: when clicked, it creates a metaclass, connected by a dependency marked with ??stereotype??. This eases the creation of "stereotype declaration" diagrams - see the literature on the subject.

12.3.6. Sequence Diagram Specific Tools

Seven tools are provided specific to UML artifacts on sequence diagrams. The detailed properties of these artifacts are described in the section on sequence diagram artifacts (see Chapter 19, Sequence Diagram Artifact Reference).

  • ClassifierRole. Add a classifierrole to the diagram.

  • Message with Call Action. Add a call message between two classifierroles selected using button 1 motion (from the originating classifierrole to the receiving classifierrole).

  • Message with Return Action. Add a return message between two classifierroles selected using button 1 motion (from the originating classifierrole to the receiving classifierrole).

  • Message with Create Action. Add a create message between two classifierroles selected using button 1 motion (from the originating classifierrole to the receiving classifierrole).

  • Message with Destroy Action. Add a destroy message between two classifierroles selected using button 1 motion (from the originating classifierrole to the receiving classifierrole).

  • Add Vertical Space to Diagram. Add vertical space to a diagram by moving all messages below this down. Click the mouse at the point where you want the space to be added and drag down the screen vertically the distance which matches the height of the space you'd like to have added.

  • Remove Vertical Space in Diagram. Remove vertical space from diagram and move all elements below up vertically. Click and drag the mouse vertically over the space that you want deleted.

12.3.7. Collaboration Diagram Specific Tools

Three tools are provided specific to UML artifacts on collaboration diagrams. The detailed properties of these artifacts are described in the section on collaboration diagram artifacts (see Chapter 21, Collaboration Diagram Artifact Reference ).

  • Classifier Role. Add a classifier role to the diagram.

  • Association Role. Add an association role between two classifier roles selected using button 1 motion (from the originating classifier role to the receiving classifier role). There are 6 types of association roles offered here, see Figure 12.4, “The association tool selector.”: association, aggregation and composition, and all these three can be bidirectional or unidirectional.

  • Generalization. Add a generalization between two artifacts selected using button 1 (from the child to the parent).

  • Dependency. Add a dependency between two artifacts selected using button 1 motion (from the dependent artifact).

  • Add Message. Add a message to the selected association role.

    [Note]Note

    This tool is grayed out except when an association role is selected.

12.3.8. Statechart Diagram Specific Tools

Eleven tools are provided specific to UML artifacts on statechart diagrams. The detailed properties of these artifacts are described in the section on statechart diagram artifacts (see Chapter 20, Statechart Diagram Artifact Reference).

  • Simple State. Add a simple state to the diagram.

  • Composite State. Add a composite state to the diagram. All artifacts that are subsequently placed on the diagram on top of the composite state will form part of that composite state.

  • Transition. Add a transition between two states selected using button 1 motion (from the originating state to the receiving state).

  • Synch State. Add a synchstate to the diagram.

  • Submachine State. Add a submachinestate to the diagram.

  • Stub State. Add a stubstate to the diagram.

  • Initial. Add an initial pseudostate to the diagram.

    [Caution]Caution

    There is nothing to stop you adding more than one initial state to a diagram or composite state. However to do so is meaningless, and one of the critics will complain.

  • Final State. Add a final state to the diagram.

  • Junction. Add a junction pseudostate to the diagram.

    [Caution]Caution

    A well formed junction should have at least one incoming transition and exactly one outgoing. ArgoUML does not enforce this, but an ArgoUML critic will complain about any junction that does not follow this rule.

  • Choice. Add a choice pseudostate to the diagram.

    [Caution]Caution

    A well formed choice should have at least one incoming transition and exactly one outgoing. ArgoUML does not enforce this, but an ArgoUML critic will complain about any choice that does not follow this rule.

  • Fork. Add a fork pseudostate to the diagram.

    [Caution]Caution

    A well formed fork should have one incoming transition and two or more outgoing. ArgoUML does not enforce this, but an ArgoUML critic will complain about any fork that does not follow this rule.

  • Join. Add a join pseudostate to the diagram.

    [Caution]Caution

    A well formed join should have one outgoing transition and two or more incoming. ArgoUML does not enforce this, but an ArgoUML critic will complain about any join that does not follow this rule.

  • Shallow History. Add a shallow history pseudostate to the diagram.

  • Deep History. Add a deep history pseudostate to the diagram.

12.3.9. Activity Diagram Specific Tools

Seven tools are provided specific to UML artifacts on activity diagrams. The detailed properties of these artifacts are described in the section on activity diagram artifacts (see Chapter 22, Activity Diagram Artifact Reference).

  • Action State. Add an action state to the diagram.

  • Transition. Add a transition between two action states selected using button 1 motion (from the originating action state to the receiving action state).

  • Initial. Add an initial pseudostate to the diagram.

    [Caution]Caution

    There is nothing to stop you adding more than one initial state to a diagram. However to do so is meaningless, and one of the critics will complain.

  • Final State. Add a final state to the diagram.

  • Junction. Add a junction (decision) pseudostate to the diagram.

    [Caution]Caution

    A well formed junction should have one incoming transition and two or more outgoing. ArgoUML does not enforce this, but an ArgoUML critic will complain about any junction that does not follow this rule.

  • Fork. Add a fork pseudostate to the diagram.

    [Caution]Caution

    A well formed fork should have one incoming transition and two or more outgoing. ArgoUML does not enforce this, but an ArgoUML critic will complain about any fork that does not follow this rule.

  • Join. Add a join pseudostate to the diagram.

    [Caution]Caution

    A well formed join should have one outgoing transition and two or more incoming. ArgoUML does not enforce this, but an ArgoUML critic will complain about any join that does not follow this rule.

  • CallState. Add a callstate to the diagram. A call state is an action state that calls a single operation. Hence, the name of the operation being called is put in the symbol, along with the name of the classifier that hosts the operation in parentheses under it.

  • ObjectFlowState. Add a objectflowstate to the diagram. An objectflowstate is an object that is input to or output from an action.

12.3.10. Deployment Diagram Specific Tools

Ten tools are provided specific to UML artifacts on deployment diagrams. The detailed properties of these artifacts are described in the section on deployment diagram artifacts (see Chapter 23, Deployment Diagram Artifact Reference).

[Note]Note

Remember that ArgoUML's deployment diagrams are also used for component diagrams.

  • Node. Add a node to the diagram. For convenience, when the mouse is over a selected node it displays four handles to left, right, top and bottom which may be dragged to form association relationships.

  • Node Instance. Add a node instance to the diagram. For convenience, when the mouse is over a selected node instance it displays four handles to left, right, top and bottom which may be dragged to form link relationships.

  • Component. Add a component to the diagram. For convenience, when the mouse is over a selected component it displays four handles to left, right, top and bottom which may be dragged to form dependency relationships.

  • Component Instance. Add a component instance to the diagram. For convenience, when the mouse is over a selected component instance it displays four handles to left, right, top and bottom which may be dragged to form dependency relationships.

  • Generalization. Add a generalization between two artifacts selected using button 1 (from the child to the parent).

  • Realization. Add a realization between a class and an interface selected using button 1 motion (from the realizing class to the realized interface).

  • Dependency. Add a dependency between two artifacts selected using button 1 motion (from the dependent artifact).

  • Association. Add an association between two artifacts (node, component, class or interface) selected using button 1 motion (from the first artifact to the second artifact). There are 6 types of association offered here, see Figure 12.4, “The association tool selector.”: association, aggregation and composition, and all these three can be bidirectional or unidirectional.

    [Caution]Caution

    The constraint that associations between classes and interfaces must not be navigable from the interface still applies on deployment diagrams.

  • Object. Add an object to the diagram. For convenience, when the mouse is over a selected object it displays four handles to left, right, top and bottom, which may be dragged to form link relationships.

  • Link. Add a link between two artifacts (node instance, component instance or object) selected using button 1 motion.

12.4. The Broom

ArgoUML's broom alignment tool is specialized to support the needs of designers in achieving the kind of alignment used in UML diagrams. It is common for designers to roughly align objects as they are created or by using simple movement commands. The broom is an easy way to precisely align objects that are already roughly aligned. Furthermore, the broom's distribution options are suited to the needs of UML designers: making related objects appear evenly spaced, packing objects to save diagram space, and spreading objects out to make room for new objects. The broom also makes it easy to change from horizontal to vertical alignment or from left-alignment to right-alignment.

The T-shaped icon in ArgoUML's diagram toolbar invokes the broom alignment tool. When the mouse button 1 is pressed while in broom-mode, the designer's initial mouse movement orients the broom to face in one of four directions: north, south, east, or west. After that, mouse drag events cause the broom to advance in the chosen direction, withdraw, or grow in a lateral direction. Like a real-world push broom, the broom tool pushes diagram elements that come in contact with it. This has the effect of aligning objects along the face of the broom and provides immediate visual feedback (see the figure below). Unlike a real-world broom, moving backwards allows diagram elements to return to their original position. Growing the broom makes it possible to align objects that are not near each other. When the mouse button is released, the broom disappears and the moved objects are selected to make it easy to manipulate them further.

Figure 12.5. The Broom.

The Broom.
The Broom.
The Broom.
The Broom.


If the designer presses the space bar while using the broom, objects on the face of the broom are distributed (i.e., spaced evenly). ArgoUML's broom supports three distribution modes: objects can be spaced evenly across the space that they use, objects can be packed together with only a small gap between them, or objects can be distributed evenly over the entire length of the broom's face. Repeatedly pressing the space bar cycles among these three distribution modes and displays a brief message indicating the operation just performed: Space evenly, Pack tightly, Spread out and Original.

12.5. Selection Action Buttons

When the user selects an artifact in a UML diagram, several handles are drawn on it to indicate that it is selected and to provide user interface affordances to resize the node. ArgoUML also displays some “selection-action buttons” around the selected artifact. See the figure below for some examples of the handles and “selection-action buttons”. The two figures for a class differ because for creating the second one, the shift key has been depressed.

Figure 12.6. Some examples of “Selection Action Buttons”.

Some examples of Selection Action Buttons.
Some examples of Selection Action Buttons.
Some examples of Selection Action Buttons.
Some examples of Selection Action Buttons.
Some examples of Selection Action Buttons.
Some examples of Selection Action Buttons.


Selection-action buttons offer common operations on the selected object. For example, a class node has a button at 12-o'clock for adding a superclass, one at 6-o'clock for adding a subclass, and buttons at 3-o'clock and 9-o'clock for adding associations. These buttons support a "click or drag" interaction: a single click creates a new related class at a default position relative to the original class and creates a generalization or association; a drag from the button to an existing class creates only the generalization or association; and, a drag to an empty space in the diagram creates a new class at the mouse position and the generalization or association. ArgoUML provides some automated layout support so that clicking the subclass button will position the new classes so that they do not overlap.

Selection-action buttons are transparent. They have a visibly recognizable rectangular shape and size and they contain an icon that is the same as the icon used for the corresponding type of design element on the standard toolbar. However, these icons are unfilled line drawings with many transparent pixels. This allows selection-action buttons to be overlaid onto the drawing area without overly obscuring the diagram itself. Also, the buttons are only drawn when the mouse is over the selected artifact; if any part of the diagram is obscured, the mouse can simply be moved away to get a clearer view of the diagram.

12.6. Clarifiers

A key feature of ArgoUML are the critics, which run in parallel with the main ArgoUML tool. When they find a problem, they typically raise a to-do item, and also highlight the problem on the editing pane. The graphical techniques used for highlighting are called Clarifiers

  • Note icon (). Displayed at the top left of an artifact indicates a critic of that artifact. Moving the mouse over the icon will pop up the critic headline.

  • Colored wavy line ( ). Used for critics specific to sub-components of graphical artifacts. For example to underline attributes with a problem within a class.

  • Solid colored line ( ). Not seen in ordinary editing, but used when a to-do item is highlighted from the to-do pane (see Chapter 14, The To-Do Pane) by button 1 double click. The solid line is used to show all the artifacts affected by the critic, for example all stimuli that are out of order.

12.7. The Drawing Grid

The editing pane is provided with a background grid which can be set in various styles or turned off altogether through the menu (see Section 10.5.4, “Adjust Grid”).

Whatever grid is actually displayed, placement of items on the diagram is always controlled by the setting for grid snap, which ranges from 4 to 32 pixels (see Section 10.5.5, “Adjust Grid Snap”).

12.8. The Diagram Tab

At the bottom of the editing pane is a small tab labeled as As Diagram. The concept is that a UML diagram can be displayed in a number of ways, for example as a graphical diagram or as a table. Each representation would have its own tab and be selected by button 1 click on the tab.

Earlier versions of ArgoUML did implement a tabular representation, but the current release only supports a diagram representation, so this tab does not have any function.

12.9. Pop-Up Menus

Within the editing pane, button 2 click over an artifact will bring up a pop-up menu with a variable number of main entries, many with a sub-menu.

12.9.1. Critiques

This sub-menu gives list of all the critics that have triggered for this artifact. Selection of a menu entry causes that entry to be highlighted in the to-do pane and its detailed explanation to be placed in the ToDoItem tab of the details pane. A solid colored line indicates the offending element.

12.9.2. Ordering

This menu controls the ordering of overlapping artifacts on the diagram. It is equivalent to the Reorder sub-menu of the Arrange menu (see Section 10.7.3, “Reorder”). There are four entries.

  • Forward. The selected artifacts are moved one step forward in the ordering hierarchy with respect to other artifacts they overlap.

  • Backward. The selected artifacts are moved one step back in the ordering hierarchy with respect to other artifacts they overlap.

  • To Front. The selected artifacts are moved to the front of any other artifacts they overlap.

  • To Back. The selected artifacts are moved to the back of any other artifacts they overlap.

12.9.3. Add

This sub-menu only appears for artifacts that can have notes attached (class, interface, object, state, pseudostate) or have operations or attributes added (class, interface). There are at most three entries.

  • New Attribute. Only appears where the selected artifact is a class. Creates a new attribute on the artifact

  • New Operation. Only appears where the selected artifact is a class or interface. Creates a new operation on the artifact

  • New Comment. Attaches a new comment to the selected artifact.

  • Add All Relations. Only appears where the selected artifact is a class or interface. Makes all relations visible that exist in the model and that are connected to the selected artifact.

  • Remove all Relations. Only appears where the selected artifact is a class or interface. Removes all connected relations from the diagram (without removing them from the model).

12.9.4. Show

This sub-menu only appears with certain artifacts. It is completely context dependent. There are many possible entries, depending on the selected artifact and its state.

  • Hide Extension Point Compartment. Only appears when the extension point compartment of a use case is displayed. Hides the compartment.

  • Show Extension Point Compartment. Only appears when the extension point compartment of a use case is hidden. Displays the compartment.

  • Hide All Compartments. Only appears when both attribute and operation compartments are displayed on a class or object. Hides both compartments.

  • Show All Compartments. Only appears when both attribute and operation compartments are hidden on a class or object. Displays both compartments.

  • Hide Attribute Compartment. Only appears when the attribute compartment of a class or object is displayed. Hides the compartment.

  • Show Attribute Compartment. Only appears when the attribute compartment of a class or object is hidden. Displays the compartment.

  • Hide Operation Compartment. Only appears when the operation compartment of a class or object is displayed. Hides the compartment.

  • Show Operation Compartment. Only appears when the operation compartment of a class or object is hidden. Displays the compartment.

  • Hide Enumeration Literal Compartment. Only appears when the enumeration literal compartment of an enumeration is displayed. Hides the compartment.

  • Show Enumeration Literal Compartment. Only appears when the enumeration literal compartment of an enumeration is hidden. Displays the compartment.

  • Show All Edges. Only appears on a class. Displays all associations (to shown artifacts) that are not shown yet. This is the same function as the "add to Diagram" on the asociation in the explorer context menu. currently.

  • Hide All Edges. Only appears on a class. Hides all associations. This is the same function as “Remove from Diagram” on all the associations of this class.

  • Hide Stereotype. Only appears when the Stereotype of a package is displayed. Hides the stereotype.

  • Show Stereotype. Only appears when the Stereotype of a package is hidden. Displays the stereotype.

  • Hide Visibility. Only appears when the visibility of a package is displayed. Hides the visibility.

  • Show Visibility. Only appears when the visibility of a package is hidden. Displays the visibility.

12.9.5. Modifiers

This sub-menu only appears with class, interface, package and use case artifacts. It is used to set or clear the values of the various modifiers available.

  • Abstract. Set for an abstract artifact.

  • Leaf. Set for a final artifact, i.e. one with no subartifacts.

  • Root. Set for a root artifact, i.e. one with no superartifacts.

  • Active. Set for a artifact with dynamic behavior.

    [Note]Note

    This really ought to be set automatically for artifacts with state machines or activity diagrams.

12.9.6. Multiplicity

This sub-menu only appears with association artifacts, when clicking at one end of the association. It is used to control the multiplicity at the end of the association nearest the mouse click point. There are only four entries, a sub-set of the range of multiplicities that are available through the property sheet of a association end (see Section 17.6, “Association End”).

  • 1

  • 0..1

  • 1..*

  • 0..*

12.9.7. Aggregation

This sub-menu only appears with association artifacts, when clicking at one end of the association. It is used to control the aggregation at the end of the association nearest the mouse click point. There are three entries.

  • none. Remove any aggregation.

  • aggregate. Make this end a shared aggregation (loosely known as an “aggregation”).

  • composite. Make this end a composite aggregation (loosely known as a “composition”).

[Caution]Caution

UML requires that an end with a composition relationship must have a multiplicity of 1 (the default).

12.9.8. Navigability

This sub-menu only appears with association artifacts, when clicking at one end of the association. It is used to control the navigability of the association. There are three entries.

  • bidirectional. Make the association navigable in both directions.

  • <class1> to <class2>. Make the association navigable only from <class1> to <class2>. In other words <class1> can reference <class2> but not the other way round.

  • <class2> to <class1>. Make the association navigable only from <class2> to <class1>. In other words <class2> can reference <class1> but not the other way round.

[Note]Note

UML does permit an association to be non-navigable in both directions. ArgoUML will allow this, but you will have to set each of the association ends navigation property, reached from the property tab of the association - and the diagram does not show any arrows in this case.

This is considered bad design practice (it will trigger a critic in ArgoUML), so is only of theoretical interest.

[Note]Note

UML does not permit navigability from an interface to a class. ArgoUML does not prevent this.

12.10. Notation

Notation is the textual representation on the diagram of a modelelement or its properties.

12.10.1. Notation Languages

ArgoUML supports showing notation in different languages. By default, all text is shown in UML notation, but the menus contain an item to select between Java and UML. With plugin modules, it is even possible to select other languages, such as C++ and PHP, but the current (0.22) version of ArgoUML does not show any difference.

Figure 12.7, “A class in UML notation” shows a class in UML notation, while Figure 12.8, “A class in Java notation” shows the same class in Java notation.

Figure 12.7. A class in UML notation

A class in UML notation


Figure 12.8. A class in Java notation

A class in Java notation


12.10.2. Notation Editing on the diagram

Most text shown on a diagram may be edited by double-clicking button 1 on the text. This causes a edit box to be shown, with the previous text selected, ready for amending.

Also, the status bar of ArgoUML (i.e. the small area at the bottom of the ArgoUML window), shows an help text that indicates the syntax of the text to be entered. Text entry can be concluded by pressing F2, or for single-line fields, by pressing the enter key. Additionally, editing can be concluded by clicking somewhere in the diagram outside the edit area.

Editing notation on the diagram is a very powerful way to enter a lot of model-information in a very compact way. It is e.g. possible to create an operation, its stereotype, all parameters and their types, and operation properties (visibility, concurrency), all at once by typing:

+Order(customerID : int,items : List) : void {sequential}

An association (e.g. between two classes) is showing many texts close to its middle and ends, so its deserves some extra explanation. Figure 12.9, “A couple of associations with adornments” shows two associations to clarify the following:

Figure 12.9. A couple of associations with adornments

A couple of associations with adornments


The association on the right shows that invisible fields where text can be entered become visible once the modelelement is selected. The fields are indicated by blue rectangles - double-click on them with mouse button 1 to start editing.

The visibility (the +, -, # or ~) is shown together with the association-end name, but it is not shown for an unnamed association end.

Likewise, the multiplicity is not shown if it is 1.

The example figure does not demonstrate this, but stereotypes of an association are shown on the diagram, but are not editable. And stereotypes of association-ends are shown together with the association-end name.

12.10.3. Notation Parsing

(to be written)

Chapter 13. The Details Pane

13.1. Introduction

Figure 13.1, “Overview of the details pane” shows the ArgoUML window, with the details pane highlighted.

Figure 13.1. Overview of the details pane

Overview of the details pane


For any artifact within the system, this pane is where all its associated data is viewed and entered.

The Pane has a series of tabs at the top, which are selected by button 1 click The body of a tab is a menu of items to be checked, selected or entered specific to the particular tab selected.

Of these, the Properties Tab is by far the most complex, with a different presentation for each artifact within the system. The detailed descriptions of the properties tab for each artifact are the subject of separate chapters covering the artifacts that may appear on the various diagrams (see Chapter 16, Top Level Artifact Reference through Chapter 23, Deployment Diagram Artifact Reference).

13.2. To Do Item Tab

This tab provides control over the various to-do items created by the user, or raised automatically by the ArgoUML critics (discussed in more detail in the section on the Critique menu???see Section 10.9, “The Critique Menu”). Figure 13.2, “Example of the To Do Item tab on the properties pane” shows a typical pane. The to-do item is selected with button 1 in the to-do pane (see Chapter 14, The To-Do Pane) or by using the Critiques context sensitive pop-up menu on the editing pane.

Figure 13.2. Example of the To Do Item tab on the properties pane

Example of the To Do Item tab on the properties pane


Customization of the critics behaviour is possible through the Browse critics... menu (see Section 10.9.4, “Browse Critics...”).

The body of the tab describes the problem found by the critic and outlines how it can be fixed. To the left are four buttons.

  • New To Do Item... This launches a dialog box (see Figure 13.3, “Dialog box for New To Do Item”), which allows you to create your own to-do item, with its own headline (which appears in the to-do pane), priority for the to-do pane, reference URL and detailed description for further information.

    Figure 13.3. Dialog box for New To Do Item

    Dialog box for New To Do Item


  • Resolve Item... This pops up a dialog allowing the user to resolve the selected to-do item (see Figure 13.4, “Dialog box for Resolve Item”). This is an important dialog, because it allows you to deal with to-do items in ways other than the recommendation of the to-do item (which is the whole point of their being advisory).

    This dialog box is intended to be used for the following reasons: deleting todo items that were manually created, preventing a single critic to trigger on a single object, and dismissing categories of todo items by lowering design concerns or design goals.

    Figure 13.4. Dialog box for Resolve Item

    Dialog box for Resolve Item


    At the top are three radio-buttons, of which by default the last is selected, labeled 1) It is not relevant to my goals, 2) It is not of concern at the moment, and 3) Reason given below. If you choose the third of these you should enter a reason in the main text box.

    [Tip]Tip

    If you wish to resolve a to-do item (that is generated by a critic) by following its recommendations, just make the recommended changes and the to-do item will disappear of its own accord. There is no need to use this dialog.

    [Warning]Warning

    The V0.20 version of ArgoUML implementation is incomplete: The reason given is not stored when the project is saved. And there is no way to retrieve todo items that were resolved. So, it is not usefull to give a reason at all.

    When a todo item generated by a critic is resolved, then there is no way to undo this (unless by re-creating the object that triggered the critic).

  • Send Email To Expert... Activating this tool allows the user to send an Email to an expert asking for advice. This works like clicking a "mailto:users@argouml.tigris.org?subject=[critic header]" link in your webbrowser.

  • Snooze Critic This suspends the activity of the critic that generated the current to-do item. The to-do item (and all others generated by the critic) will disappear from the to-do pane.

    The critic will wake up after a period of time. Initially this period is 10 minutes, but it doubles on each successive application of the Snooze button. The critic can be awakened explicitly through the Critique > Browse Critics... menu (see Section 10.9.4, “Browse Critics...”).

    [Tip]Tip

    Some common critics can fire the whole time as you build a big diagram. Some users find it useful to snooze these critics until the diagram has been completed.

13.2.1. Wizards

Some of the more common critics have a “wizard” available to help in fixing the problem. The wizard comprises a series of pages (one or more) in the ToDo Item tab that step you through the changes. Start the wizard by clicking the Next> button.

Figure 13.5. Example of a Wizard

Example of a Wizard


The wizard is driven through the first three buttons at the bottom of the ToDo Item tab.

  • <Back. This will take you back to the previous step in the wizard. Grayed out if this is the first step.

  • Next>. This will take you back to the next step in the wizard. Grayed out if this is the last step.

  • Finish. This will commit the changes you have made through the wizard in previous steps, and/or use the defaults for all next steps.

[Note]Note

Not all to-do items have wizards. If there is no wizard all three buttons will remain grayed out.

The ArgoUML wizards are non-modal, i.e. once started, you may select other todo items, or do some other actions, and all the while the wizard will remeber where it was, so if you return to the todo item, the wizard will indicate the same step it was on when you left it.

13.2.2. The Help Button

There is one remaining button at the bottom of the To Do Item tab, labeled Help. This will fire up a browser to a URL with further help.

[Warning]Warning

In the V0.20 release of ArgoUML the URLs are generally invalid. The few that are valid have no information.

13.3. Properties Tab

Through this tab, the properties of artifacts selected in the explorer or editing pane may be set. The properties of an artifact may be displayed in one of the following ways:

  1. Selection of the artifact in the explorer or editing panes, followed by selection of the properties tab in the details pane; or

  2. Navigation buttons cause different artifacts to be selected. I.e. the Go Up button on the properties tab, the Navigate Back and Navigate Forward buttons in the main tool bar, and the various menu-items under Edit - Select.

Figure 13.6, “A typical Properties tab on the details pane” shows a typical properties tab for an artifact in ArgoUML (in this case a class).

Figure 13.6. A typical Properties tab on the details pane

A typical Properties tab on the details pane


At the top left is the icon and name of the type of artifact (i.e. the UML metaclass, not the actual name of this particular artifact). In this example the property tab is for a class.

To the right of this is a toolbar of icons relevant to this property tab. The first one is always navigation Go up. The last is always Delete to delete the selected artifact from the model. The ones in between depend on the artifact.

The remainder of the tab comprises fields, laid out in two or three columns. Each field has a label to its left. The fields may be text boxes, text areas, drop down selectors, radio boxes and check boxes. In most (but not all cases) the values can be changed. In the case of text boxes this is sometimes by just typing the required value.

However for many text boxes and text areas, data entry is via a context sensitive pop-up menu (using button 2 click), which offers options to add a new entry, delete an entry or move entries up and down (in text areas with multiple entries).

The first field is almost always a text field Name, where the name of the specific artifact can be entered. The remaining fields vary depending on the artifact selected.

The detailed property sheets for all ArgoUML artifacts are discussed in separate chapters for each of the diagram types (use case diagram (Chapter 17, Use Case Diagram Artifact Reference, class diagram (Chapter 18, Class Diagram Artifact Reference, sequence diagram (Chapter 19, Sequence Diagram Artifact Reference, statechart diagram ( Chapter 20, Statechart Diagram Artifact Reference, collaboration diagram ( Chapter 21, Collaboration Diagram Artifact Reference, activity diagram ( Chapter 22, Activity Diagram Artifact Reference, deployment diagram ( Chapter 23, Deployment Diagram Artifact Reference). Property sheets for artifacts that are common to all diagram types have their own chapter (Chapter 16, Top Level Artifact Reference).

[Caution]Caution

ArgoUML will always try to squeeze all fields on to the property sheet. If the size of the property tab is too small, it may become unusable. The solution is to either enlarge the property tab by enlarging the main window, or by moving the dividers to left and top.

13.4. Documentation Tab

Within the UML 1.4 standard, all artifacts are children of the Element metaclass. The Element metaclass defines a tagged value documentation for comment, description or explanation of the element to which it is attached. Since this tagged value applies to every artifact, it is given its own tab in the details pane, rather than being part of the Tagged Values tab.

Figure 13.7, “A typical Documentation tab on the details pane” shows a typical documentation tab for an artifact in ArgoUML.

Figure 13.7. A typical Documentation tab on the details pane

A typical Documentation tab on the details pane


As you can see, many more fields have been added to the Documentation field alone. The other fields similarly store their information under tagged values: author, version, since, deprecated, see.

The fields on this tab are the same for all artifacts.

Since UML comments are a kind of documentation, they are also shown on this tab, with name and body.

  • Author: A text box for the author of the documentation.

  • Version: A text box for the version of the documentation.

  • Since: A text box to show how long the documentation has been valid.

  • Deprecated: A check box to indicate whether this artifact is deprecated (i.e. planned for removal in future versions of the design model).

  • See: Pointers to documentation outside the system.

  • Documentation: Literal text of any documentation.

  • Comment Name: The names of all comments attached to the modelelement.

  • Body: The bodies of all comments attached to this modelelement.

[Tip]Tip

ArgoUML is not primarily a documentation system. For artifacts that require heavy documentation, notably use cases, the use of the See: field to point to external documents is more practical.

13.5. Presentation Tab

This tab provides some limited control over the graphical representation of artifacts in the diagram in the editing pane.

Artifacts that do not have any specific direct graphical representation on the screen (beyond their textual description) do not have style tabs of their own. For example the style sheet of an operation on a class will be downlighted.

Style sheets vary a little from artifact to artifact, but Figure 13.8, “A typical Presentation tab on the details pane” shows a typical style tab for an artifact in ArgoUML (in this case a class).

Figure 13.8. A typical Presentation tab on the details pane

A typical Presentation tab on the details pane


There may be further fields in some cases, e.g. for a package, but most fields are common to many artifacts.

  • Path This checkbox allow to display or hide the path in front of the name of the modelelement. It is shown in UML notation with :: seperators. E.g. the ArgoUML Main class would be shown as: org::argouml::application::Main.

  • Attributes This checkbox allows to hide or show the attributes compartment of a class.

  • Operation This checkbox allows to hide or show the operations compartment of a class or interface.

  • Stereotype This checkbox allows to reveal or hide the stereotypes of a package, shown above the name.

  • Visibility This checkbox allows to hide the visibility of a package. The visibility is shown in UML notation as +, -, # or ~.

  • Extension Points This checkbox allows to reveal or hide the extensions points compartment of a usecase.

  • Bounds: This defines the corners of the bounding box for a 2D artifact. It comprises four numbers separated by commas. These four numbers are respectively: i) the X coordinate of the upper left corner of the box; ii) the Y coordinate of the upper left corner of the box; iii) the width of the box; and iv) the height of the box. All units are pixels on the editing pane.

    This field has no effect on 1D artifacts that link other artifacts (associations, generalizations etc), since their position is constrained by their connectedness. In this case the field is downlighted.

  • Fill: This drop-down selector specifies the fill color for 2D artifacts. It is not present for line artifacts. Selecting No Fill makes the artifact transparant. Selecting Custom allows to create other colors then the ones listed. It causes the color selector dialog box to appear, see Figure 13.9, “The Custom Fill/Line Color dialog box”.

  • Line: This drop-down selector specifies the line color for artifacts. Selecting No Fill makes the artifact transparant. Selecting Custom allows to create other colors then the ones listed. It causes the color selector dialog box to appear, see Figure 13.9, “The Custom Fill/Line Color dialog box”.

  • Shadow: This drop-down selector specifies the width of the shadow (if any) for 2D artifacts. It is not present for line artifacts.

Figure 13.9. The Custom Fill/Line Color dialog box

The Custom Fill/Line Color dialog box


Figure 13.10. The Custom Fill/Line Color dialog box

The Custom Fill/Line Color dialog box


Figure 13.11. The Custom Fill/Line Color dialog box

The Custom Fill/Line Color dialog box


13.6. Source Tab

This tab shows the source code that will be generated for this artifact, in the selected language. ArgoUML generates the code e.g. for classes and interfaces. The code shown here, may be saved in the indicated files with the aid of the functions in the Generation menu.

Figure 13.12. The Source Tab of a class.

The Source Tab of a class.


Any code you add will be lost - that is not the intention of ArgoUML - use an IDE instead.

The dropdown at the right allows selection of the output file. This function is not very useful for languages that generate all code for a class within one file, but serves its purpose for e.g. C++, where a .h and .cpp file are generated. See the figure below.

Figure 13.13. A C++ example.

A C++ example.


13.7. Constraints Tab

Constraints are one of the extension mechanisms provided for UML. ArgoUML is equipped with a powerful constraint editor based on the Object Constraint Language (OCL) defined in the UML 1.4 standard.

[Caution]Caution

The OCL editor implementation for ArgoUML V0.20 doesn't support OCL constraints for elements other than Classes and Features.

This is something of a general restriction of OCL. Although the UML specification claims that there may be a constraint for every model element, the OCL specification only defines classes/interfaces and operations as allowable contexts.

It is not before OCL 2.0 that a more general definition of allowable contexts is introduced. The key issue is that for each context definition you need to define what is the contextualClassifier, i.e., the classifier that will be associated with the self keyword. The creators of the OCL specification claim that this is not an issue for the OCL specification, but rather for UML or some integration task force. Conversely, it seems that the UML specification people seem to expect this to be defined in the OCL specification (which is why we did a first step in that direction in OCL 2.0).

So, to cut a long story short, it appeared that the simplest solution for ArgoUML at the moment would be to enable the OCL property panel only for those model elements for which there actually exists a definition of the contextualClassifier in OCL 1.4. These are (s. above) Class/Interface and Feature.

The standard pre-defines a small number of constraints (for example the xor constraint over a set of associations indicating that only one may be manifest for any particular instance).

The standard also envisages a number of circumstances where general purpose constraints may be useful:

  • To specify invariants on classes and types in the class model;

  • To specify type invariants for stereotypes;

  • To describe pre-conditions and post-conditions on operations and methods;

  • To describe guards;

  • As a navigation language; and

  • To specify constraints on operations.

Figure 13.14, “A typical Constraints tab on the details pane” shows a typical constraint tab for a artifact in ArgoUML (in this case a class).

Figure 13.14. A typical Constraints tab on the details pane

A typical Constraints tab on the details pane


Along the top of the tab are a series of icons.

  • New Constraint. This creates a new constraint and launches the constraint editor in the Constraints tab for that new constraint (see Section 13.7.1, “The Constraint Editor”). The new constraint is created with a context declaration for the currently selected artifact.

    [Warning]Warning

    It seems logical, that when a new constraint is created, it needs to be edited. But ArgoUML V0.20 fails to start the OCL editor upon creation; you have to do this by primo selecting the new constraint first, secundo rename it, and tertio press the Edit Constraint button. It is essental for successfully creating a constraint to follow these 4 steps accurately: create, select, rename, edit. The step to rename is necessary, because the validity check will refuse the constraint if its name differs from the name mentioned in the constraint text. For the same reason, renaming a constraint afterwards is impossible.

  • Delete Constraint. The constraint currently selected in the Constraint Name box (see below) is deleted.

    [Caution]Caution

    In V0.20 of ArgoUML this button is not downlighted when it is not functional, i.e. when no constraint is selected.

  • Edit Constraint. This launches the constraint editor in the Constraints tab (see Section 13.7.1, “The Constraint Editor”). The editor is invoked on the constraint currently selected in the Constraint Name box.

    [Caution]Caution

    In V0.18 of ArgoUML this button is not downlighted when it is not functional, i.e. when no constraint is selected.

  • Configure Constraint Editor. This a dialog to configure options in the constraint editor (see Figure 13.15, “Dialog box for configuring constraints” ).

    Figure 13.15. Dialog box for configuring constraints

    Dialog box for configuring constraints


    The dialog box has a check box for the following option.

    • Check type conformance of OCL constraints. OCL is strictly typed. At the early stages of design it may be helpful to disable type checking, rather than follow through all the detailed specification needed to get type consistency.

    At the bottom are two buttons, labeled OK (to accept the option changes) and Cancel (to discard the changes).

The main body of the constraints tab comprises two boxes, a smaller to the left and a larger one to the right. The two are separated by two small arrow buttons which control the size of the boxes.

  • Shrink Left. Button 1 click on this icon shrinks the box on the left. Its effect may be reversed by use of the Shrink Right button (see below).

  • Shrink Right. Button 1 click on this icon shrinks the box on the right. Its effect may be reversed by use of the Shrink Left button (see above).

Finer control can be achieved by using button 1 motion to drag the dividing bar to left and right.

The box on the left is titled Constraint Name and lists all the constraints (if any) so far defined for the selected artifact. A constraint may be selected by button 1 click.

The box on the right is labeled Preview and contains the text of the constraint. This box only shows some contents if a constraint is selected. Where a constraint is too large for the box, a scroll bar is provided to the right.

13.7.1. The Constraint Editor

This is invoked through the use of the Edit Constraint button on the main Constraints tab. The constraint editor takes up the whole tab (see Figure 13.16, “Dialog box for configuring constraints”).

Figure 13.16. Dialog box for configuring constraints

Dialog box for configuring constraints


Along the top of the tab are a series of icons.

  • Cancel Edit Constraint. This exits the constraint editor without saving any changes and returns to the main Constraints tab.

  • Check OCL Syntax. This button invokes a full syntax check of the OCL written in the editor. If the syntax is valid, the constraint is saved, and control returns to the main Constraints tab. If the syntax is not valid, a dialog box explains the problem.

    [Warning]Warning

    Whether type checking is included should be configurable with the Configure Constraint Editor button (see below). But ArgoUML V0.20 does always check, and refuses to accept any constraint with the slightest error.

  • Configure Constraint Editor. This a dialog to configure options in the constraint editor. It is also available in the main Constraints tab and is discussed in detail there (see Section 13.7, “Constraints Tab” ).

To the right of the toolbar is a check box labeled Syntax Assistant (unchecked by default), which will enable the syntax assistant in the constraint editor.

If the syntax assistant is enabled, six drop down menus are provided in a row immediately below the toolbar. These provide standard templates for OCL that, when selected, will be inserted into the constraint being edited.

The syntax assistant can be made floating in a separate window by button 1 motion on the small divider area to the left of the row of drop-down menus.

  • General. General OCL constructors. Entries: inv (inserts an invariant); pre (inserts a pre-condition); post (inserts a post-condition); self (inserts a self-reference); @pre (inserts a reference to a value at the start of an operation); and result (inserts a reference to a previous result).

  • Basic Operators. Relational operators and parentheses. Entries: =; <>; <; >; <=; >=; and ().

  • Numbers. Arithmetic operators and functions. Entries: +; -; *; /; mod; div; abs; max; min; round; and floor.

  • Strings. String functions. Entries: concat; size; toLower; toUpper; and substring.

  • Booleans. Logical functions. Entries: or; and; xor; not; implies; and if then else.

  • Collections. Operators and functions on collections???bags, sets and sequences. The large number of functions are organized into sub-groups.

    • General. Functions that apply to all types of collection. Entries: Collection {} (insert a new collection); Set {} (insert a a new set); Bag {} (insert a new bag); Sequence {} (insert a new sequence); size; count; isEmpty; notEmpty; includes; includesAll; iterate; exists; forAll; collect; select; reject; union; intersection; including; excluding; and sum.

    • Sets. Operators and functions that apply only to sets. Entries: - (set difference); and symmetricDifference.

    • Sequences. Functions that apply to sequences. Entries: first; last; at; append; prepend; and subSequence.

The remainder of the tab comprises a writable text area containing the text to be edited. The mouse buttons have their standard behavior within an editable text area (see Section 8.2, “General Mouse Behavior in ArgoUML”).

In addition, cut, copy and paste operations may be invoked through the keyboard shortcuts Ctrl-X, Ctrl-C and Ctrl-V respectively.

13.8. Stereotype Tab

This tab shows the available and applied stereotypes for the currently selected modelelement. It consists of 2 panels and 2 buttons. The buttons allow to move the stereotypes from one list to the other.

Figure 13.17. An example of a stereotype tab for a class.

An example of a stereotype tab for a class.


In the lists, between [] the baseclass of the stereotypes is shown. E.g. in the figure above, the thread [Classifier] stereotype may be applied to all types of classifiers, such as Class, UseCase,...

13.9. Tagged Values Tab

Tagged values are another extension mechanism provided by UML. The user can define name-value pairs to be associated with artifacts which define properties of that artifact. The names are known as tags. UML pre-defines a number of tags that are useful for many of its artifacts.

[Note]Note

The tag documentation is defined for the top UML metaclass, Element and is so available to all artifacts. In ArgoUML documentation values are provided through the Documentation tab, rather than by using the Tagged Values tab.

The Tagged Values tab in ArgoUML comprises a two column table, with a combo-box on the left to select the tagdefinition and an editable box on the right for the associated value. There is always at least one empty row available for any new tag.

The button at the top of this tab allows creation of a new tagdefinition. After clicking this button, go to the properties tab first to set the name of the new tagdefinition.

The mouse buttons have their standard behavior within the editable value area (see Section 8.2, “General Mouse Behavior in ArgoUML”). In addition, when in the value field, cut, copy and paste operations may be invoked through the keyboard shortcuts Ctrl-X, Ctrl-C and Ctrl-V respectively.

13.10. Checklist Tab

Conducting design reviews and inspections is one of the most effective ways of detecting errors during software development. A design review typically consists of a small number of designers, implementers, or other project stakeholders holding a meeting to review a software development artifact. Many development organizations have developed checklists of common design problems for use in design review meetings. Recent research indicated that reviewers inspecting code without meeting, makeing use of these checklists, are just as effective as design review meetings.

Hence, a checklist feature has been added to ArgoUML, that is much in the spirit of design review checklists. However, ArgoUML's checklists are integrated into the design tool user interface and the design task.

A software designer using ArgoUML can see a review checklist for any design element. The “Checklist” tab presents a list of check-off items that is appropriate to the currently selected design element. For example, when a class is selected in a design diagram, the checklist tab shows items that prompt critical thinking about classes. See the figure below. Designers may check off items as they consider them. Checked items are kept in the list to show what has already been considered, while unchecked items prompt the designer to consider new design issues. ArgoUML supplies many different checklists with many possible items.

Figure 13.18. An example of a checklist for a class.

An example of a checklist for a class.


[Caution]Caution

In the V0.20 release of ArgoUML, this tab is not completely implemented. E.g. the checks are not saved.

Chapter 14. The To-Do Pane

14.1. Introduction

Figure 14.1, “Overview of the to-do pane” shows the ArgoUML window with the to-do pane highlighted.

Figure 14.1. Overview of the to-do pane

Overview of the to-do pane


This pane provides access to the advice that comes from the critics processes running within ArgoUML.

A selector box at the top allows a choice of how the data is presented, a button allows the display of the hierarchy to be changed, and there is an indicator of the number of to-do items identified.

More information on critics can be found in the discussion of the Critique menu (see Section 10.9, “The Critique Menu”).

14.2. Mouse Behavior in the To-Do Pane

Behavior of the mouse in general, and the naming of the buttons is covered in the chapter on the overall user interface (see Chapter 8, Introduction).

14.2.1. Button 1 Click

This action is generally used to select an item for subsequent operations.

Within the hierarchical display, elements which have sub-hierarchies may be indicated by when the hierarchy is hidden and when the hierarchy is open.

When these icons are displayed, the display of the hierarchy is toggled by button 1 click on these icons.

Button 1 click over the headline of any to-do item will cause its details to be shown in the To Do Item tab of the details pane. That tab is automatically selected if it is not currently visible.

14.2.2. Button 1 Double Click

When applied to the folder icon alongside a hierarchy category, this will cause the display of that hierarchy to be toggled.

When applied to a headline, button 1 double click will show the diagram for the artifact to which the to-do item applies in the editing pane and select the artifact on the diagram using an appropriate clarifier (the artifact may be highlighted, underlined with a wavy line or surrounded by a colored box as appropriate).

14.2.3. Button 2 Actions

There are no button 2 functions in the to-do pane.

14.2.4. Button 2 Double Click

There are no button 2 functions in the to-do pane.

14.3. Presentation Selection

At the top of the pane is a drop-down selector controlling how the to-do items are presented. The to-do items may be presented in six different ways. This setting is not stored persistently, i.e. it is on its default vallue when ArgoUML is started.

  • By Priority. This is the default setting. The to-do items are organized into three hierarchies by priority: High, Medium and Low. The priority associated with the to-do items generated by a particular critic may be altered through the Critique > Browse Critics... menu (see Section 10.9.4, “Browse Critics...”).

  • By Decision. The to-do items are organized into 17 hierarchies by design issue: Uncategorized, Class Selection, Behavior, Naming, Storage, Inheritance, Containment, Planned Extensions, State Machines, Design Patterns, Relationships, Instantiation, Modularity, Expected Usage, Methods, Code Generation and Stereotypes. The details of the critics in each category are discussed in Section 10.9.2, “Design Issues...”.

  • By Goal. ArgoUML has a concept that critics may be grouped according to the user goals they affect. This presentation groups the to-do items into hierarchies by goal.

    [Caution]Caution

    In the current release of ArgoUML there is only one goal, Unspecified and all to-do items will appear under this heading.

  • By Offender. The to-do items are organized into a hierarchy according to the artifact that caused the problem. Todo items that were manually created with the "New ToDo item" button (i.e. not by a critic), are not listed here.

  • By Poster. The to-do items are organized into a hierarchy according to which critic generated the to-do item. The class name of the critic is listed instead of just its headline name since the former is guaranteed to be a unique name.

  • By Knowledge Type. ArgoUML has the concept that a critic reflects a deficiency in a category of knowledge. This presentation option groups the critics according to their knowledge category: Designer's, Correctness, Completeness, Consistency, Syntax, Semantics, Optimization, Presentational, Organizational, Experiencial and Tool. The former category (Designer's) contains the manually entered todo items.

14.4. Item Count

To the right of the flat/hierarchical button is a count of the number of to-do items currently found. It will be highlighted in yellow when the number of to-do items grows above 50 todo items, and red when above 100.

Chapter 15. The Critics

15.1. Introduction

The key feature that distinguishes ArgoUML from other UML CASE tools is its use of concepts from cognitive psychology. The theory behind this is well described in Jason Robbins' PhD dissertation http://argouml.tigris.org/docs/robbins_dissertation/.

Critics are one of the main ways in which these ideas are implemented. Running in the background they offer advice to the designer which may be accepted or ignored. A key point is that they do not impose a decision on the designer.

[Note]Note

The critics are asynchronous processes that run in parallel with the main ArgoUML tool. Changes typically take a second or two to propagate as the critics wake up.

15.1.1. Terminology

The critics are background processes, which evaluate the current model according to various “good” design criteria. There is one critic for every design criterion.

The output of a critic is a critique???a statement about some aspect of the model that does not appear to follow good design practice.

Finally a critique will generally suggest how the bad design issue it has identified can be rectified, by raising a to-do item.

15.1.2. Design Issues

ArgoUML categorizes critics according the the design issue they address (some critics may be in more than one category). At present there are 16 such categories.

Within this manual the descriptions of critics are grouped in sections by design issue.

15.2. Uncategorized

These are critics that do not fit into any other category.

ArgoUML has no critics in this category. Maybe some will be added in later versions.

15.3. Class Selection

These are critics concerning how classes are chosen and used.

ArgoUML has the following critics in this category.

15.3.1. Wrap DataType

DataTypes are not full classes within UML 1.4. They can only have enumeration literals as values, and only support query operations (that is operations that do not change the DataType's state).

DataTypes cannot be associated with classes, unless the DataType is part of a composite (black diamond) aggregation. Such an association relects the tight binding of a collection of DataType instances to a class instance. In effect such a DataType is an attribute of the class with multiplicity.

Good OOA&D depends on careful choices about which entities to represent as full objects and which to represent as attributes of objects.

There are two options to fix this problem.

  • Replace the DataType with a full class.

  • or change the association aggregation to composite relationship at the DataType end.

15.3.2. Reduce Classes in diagram <diagram>

Suggestion to improve readability by having fewer classes on a diagram. If one class diagram has too many classes it may become very difficult for humans to understand. Defining an understandable set of class diagrams is an important part of your design.

The Wizard of this critic allows setting of the treshold, i.e. the maximum number of classes allowed before this critic fires.

[Caution]Caution

This number is not stored persistently, and there is no way to reduce it after it has been set higher, except by creating more classes until the critic fires again. Restarting ArgoUML resets this number to its default: 20.

15.3.3. Clean Up Diagram

Suggestion that the diagram could be improved by moving artifacts that are overlapping.

15.4. Naming

These are critics concerning the naming of artifacts. The current version of ArgoUML has 18 critics in this category.

15.4.1. Resolve Association Name Conflict

Suggestion that two association names in the same namespace have the same name. This is not permitted in UML.

15.4.2. Revise Attribute Names to Avoid Conflict

Suggestion that two attribute names of a class have the same name. This is not permitted in UML.

[Note]Note

The problem may be caused by inheritance of an attribute through a generalization relationship.

15.4.3. Change Names or Signatures in an Artifact

Two operations in <artifact> have the same signature. This means their name is the same, and the list of parameters has the same type.

Where there are conflicting signatures, correct code cannot be generated for mainstream OO languages. It also leads to very unclear semantics of the design.

In comparing signatures, this critic considers:

  1. the name;

  2. the list of in, out and in-out parameter types in order; and

Only if these all match in both type and order, will the signatures be considered as the same.

This follows the line of Java/C++ in ignoring the return parameters for the signature. This may be unsatisfactory for some functional OO languages.

[Note]Note

Some purists would argue that the comparison should really differentiate between in, out and in-out parameters. However no practical programming language can do this when resolving an overloaded method invocation, so this critics lumps them all together.

15.4.4. Duplicate End (Role) Names for an Association

The specified association has two (or more) ends (roles) with the same name. One of the well-formedness rules in UML 1.4 for associations, is that all end (role) names must be unique.

This ensures that there can be unambiguous reference to the ends of the association.

To fix this, manually select the association and change the names of one or more of the offending ends (roles) using the button 2 pop-up menu or the property sheet.

15.4.5. Role name conflicts with member

A suggestions that good design avoids role names for associations that clash with attributes or operations of the source class. Roles may be realized in the code as attributes or operations, causing code generation problems.

15.4.6. Choose a Name (Classes and Interfaces)

The class or interface concerned has been given no name (it will appear in the model as anon). Suggestion that good design requires that all interfaces and classes are named.

15.4.7. Choose a Unique Name for an Artifact (Classes and Interfaces)

Suggestion that the class or interface specified has the same name as another (in the namespace), which is bad design and will prevent valid code generation.

15.4.8. Choose a Name (Attributes)

The attribute concerned has been given no name (it will appear in the model as (anon Attribute)). Suggestion that good design requires that all attributes are named.

15.4.9. Choose a Name (Operations)

The operation concerned has been given no name (it will appear in the model as (anon Operation)). Suggestion that good design requires that all operations are named.

15.4.10. Choose a Name (States)

The state concerned has been given no name (it will appear in the model as (anon State)). Suggestion that good design requires that all states are named.

15.4.11. Choose a Unique Name for a (State related) Artifact

Suggestion that the state specified has the same name as another (in the current statechart diagram), which is bad design and will prevent valid code generation.

15.4.12. Revise Name to Avoid Confusion

Two names in the same namespace have very similar names (differing only by one character). Suggestion this could potentially lead to confusion.

[Caution]Caution

This critic can be particularly annoying, since at times it is useful and good design to have a series of artifacts var1, var2 etc.

It is important to remember that critics offer guidance, and are not always correct. ArgoUML lets you dismiss the resulting to-do items through the to-do pane (see Chapter 14, The To-Do Pane).

15.4.13. Choose a Legal Name

All artifact names in ArgoUML must use only letters, digits and underscore characters. This critic suggests an entity has not met this requirement.

15.4.14. Change an Artifact to a Non-Reserved Word

Suggestion that this artifact's name is the same as a reserved word in UML (or within one character of one), which is not permitted.

15.4.15. Choose a Better Operation Name

Suggestion that an operation has not followed the naming convention that operation names begin with lower case letters.

[Caution]Caution

Following the Java and C++ convention most designers give their constructors the same name as the class, which begins with an upper case character. In ArgoUML, this will trigger this critic, unless the constructor is stereotyped ??create??.

It is important to remember that critics offer guidance, and are not always correct. ArgoUML lets you dismiss the resulting to-do items through the to-do pane (see Chapter 14, The To-Do Pane).

15.4.16. Choose a Better Attribute Name

Suggestion that an attribute has not followed the naming convention that attribute names begin with lower case letters.

15.4.17. Capitalize Class Name

Suggestion that a class has not followed the naming convention that classes begin with upper case letters.

[Note]Note

Although not triggering this critic, the same convention should apply to interfaces.

15.4.18. Revise Package Name

Suggestion that a package has not followed the naming convention of using lower case letters with periods used to indicated sub-packages.

15.5. Storage

Critics concerning attributes of classes.

The current version of ArgoUML has the following critics in this category.

15.5.1. Revise Attribute Names to Avoid Conflict

This critic is discussed under an earlier design issues category (see Section 15.4.2, “Revise Attribute Names to Avoid Conflict” ).

15.5.2. Add Instance Variables to a Class

Suggestion that no instance variables have been specified for the given class. Such classes may be created to specify static attributes and methods, but by convention should then be given the stereotype ??utility??.

15.5.3. Add a Constructor to a Class

You have not yet defined a constructor for class class. Constructors initialize new instances such that their attributes have valid values. This class probably needs a constructor because not all of its attributes have initial values.

Defining good constructors is key to establishing class invariants, and class invariants are a powerful aid in writing solid code.

To fix this, add a constructor manually by clicking on class in the explorer and adding an operation using the context sensitive pop-up menu in the property tab, or select class where it appears on a class diagram and use the Add Operation tool.

In the UML 1.4 standard, a constructor is an operation with the stereotype ??create??. Although not strictly standard, ArgoUML will also accept ??Create?? as a stereotype for constructors.

By convention in Java and C++ a constructor has the same name as the class, is not static, and returns no value. ArgoUML will also accept any operation that follows these conventions as a constructor even if it is not stereotyped ??create??.

[Caution]Caution

Operators are created in ArgoUML with a default return parameter (named return). You will need to remove this parameter to meet the Java/C++ convention.

15.5.4. Reduce Attributes on a Class

Suggestion that the class has too many attributes for a good design, and is at risk of becoming a design bottleneck.

The Wizard of this critic allows setting of the treshold, i.e. the maximum number of attributes allowed before this critic fires.

[Caution]Caution

This number is not stored persistently, and there is no way to reduce it after it has been set higher, except by creating more attributes until the critic fires again. Restarting ArgoUML resets this number to its default: 7.

15.6. Planned Extensions

Critics concerning interfaces and subclasses.

[Note]Note

It is not clear why this category has the name “Planned Extensions”.

The current version of ArgoUML has three critics in this category.

15.6.1. Operations in Interfaces must be public

Suggestion that there is no point in having non-public operations in Interfaces, since they must be visible to be realized by a class.

15.6.2. Interfaces may only have operations

Suggestion that an interfaces has attributes defined. The UML standard defines interfaces to have operations.

[Caution]Caution

ArgoUML does not allow you to add attributes to interfaces, so this should never occur in the ArgoUML model. It might trigger if a project has been loaded with XMI created by another tool.

15.6.3. Remove Reference to Specific Subclass

Suggestion that in a good design, a class should not reference its subclasses directly through attributes, operations or associations.

15.7. State Machines

Critics concerning state machines.

ArgoUML has the following critics in this category.

15.7.1. Reduce Transitions on <state>

Suggestion given state is involved in so many transitions it may be a maintenance bottleneck.

The Wizard of this critic allows setting of the treshold, i.e. the maximum number of transitions allowed before this critic fires.

[Caution]Caution

This number is not stored persistently, and there is no way to reduce it after it has been set higher, except by creating more transition until the critic fires again. Restarting ArgoUML resets this number to its default: 10.

15.7.2. Reduce States in machine <machine>

Suggestion that the given state machine has so many states as to be confusing and should be simplified (perhaps by breaking into several machines, or using a hierarchy).

The Wizard of this critic allows setting of the treshold, i.e. the maximum number of states allowed before this critic fires.

[Caution]Caution

This number is not stored persistently, and there is no way to reduce it after it has been set higher, except by creating more states until the critic fires again. Restarting ArgoUML resets this number to its default: 20.

15.7.3. Add Transitions to <state>

Suggestion that the given state requires both incoming and outgoing transitions.

15.7.4. Add Incoming Transitions to <artifact>

Suggestion that the given state requires incoming transitions.

15.7.5. Add Outgoing Transitions from <artifact>

Suggestion that the given state requires outgoing transitions.

15.7.6. Remove Extra Initial States

Suggestion that there is more than one initial state in the state machine or composite state, which is not permitted in UML.

15.7.7. Place an Initial State

Suggestion that there is no initial state in the state machine or composite state.

15.7.8. Add Trigger or Guard to Transition

Suggestion that a transition is missing either a trigger or guard, one at least of which is required for it to be taken.

15.7.9. Change Join Transitions

Suggestion that the join pseudostate has an invalid number of transitions. Normally there should be one outgoing and two or more incoming.

15.7.10. Change Fork Transitions

Suggestion that the fork pseudostate has an invalid number of transitions. Normally there should be one incoming and two or more outgoing.

15.7.11. Add Choice/Junction Transitions

Suggestion that the branch (choice or junction) pseudostate has an invalid number of transitions. Normally there should be at least one incoming transition and at least one outgoing transition.

15.7.12. Add Guard to Transition

Suggestion that the transition requires a guard.

[Caution]Caution

It is not clear that this is a valid critic. It is perfectly acceptable to have a transition without a guard???the transition is always taken when the trigger is invoked.

15.7.13. Clean Up Diagram

This critic is discussed under an earlier design issues category (see Section 15.3.3, “Clean Up Diagram” ).

15.7.14. Make Edge More Visible

Suggestion that an edge artifact such as an association or abstraction is so short it may be missed. Move the connected artifacts apart to make the edge more visible.

15.7.15. Composite Association End with Multiplicity > 1

An instance may not belong by composition to more than one composite instance. You must change the multiplicity at the composite end of the association to either 0..1 or 1..1 (1) for your model to make sense.

Remember that composition is the stronger aggregation kind and aggregation is the weaker. The problem can be compared to a model where a finger can be an integral part of several hands at the same time.

This is the second well-formedness rule on AssociationEnd in UML 1.4.

15.8. Design Patterns

Critics concerning design pattern usage in ArgoUML.

These relate to the use of patterns as described by the so called “Gang of Four”. ArgoUML also uses this category for critics associated with deployment and sequence diagrams. The current version of ArgoUML has the following critics in this category.

15.8.1. Consider using Singleton Pattern for <class>

The class has no non-static attributes nor any associations that are navigable away from instances of this class. This means that every instance of this class will be identical to every other instance, since there will be nothing about the instances that can differentiate them.

Under these circumstances you should consider making explicit that you have exactly one instance of this class, by using the singleton Pattern. Using the singleton pattern can save time and memory space. Within ArgoUML this can be done by using the ??singleton?? stereotype on this class.

If it is not your intent to have a single instance, you should define instance variables (i.e. non-static attributes) and/or outgoing associations that will represent differences bewteen instances.

Having specified class as a singleton, you need to define the class so there can only be a single instance. This will complete the information representation part of your design. To achieve this you need to do the following.

  1. You must define a static attribute (a class variable) holding the instance. This must therefore have class as its type.

  2. You must have only private constructors so that new instances cannot be made by other code. The creation of the single instance could be through a suitable helper operation, which invokes this private constructor just once.

  3. You must have at least one constructor to override the default constructor, so that the default constructor is not used to create multiple instances.

For the definition of a constructor under the UML 1.4 standard, and extensions to that definition accepted by ArgoUML see Section 15.5.3, “Add a Constructor to a Class” .

15.8.2. Singleton Stereotype Violated in <class>

This class is marked with the ??singleton?? stereotype, but it does not satisfy the constraints imposed on singletons (ArgoUML will also accept ??Singleton?? stereotype as defining a singleton). A singleton class can have at most one instance. This means that the class must meet the design criteria for a singleton (see Section 15.8.1, “Consider using Singleton Pattern for <class>”).

Whenever you mark a class with a stereotype, the class should satisfy all constraints of the stereotype. This is an important part of making a self-consistent and understangle design. Using the singleton pattern can save time and memory space.

If you no longer want this class to be a singleton, remove the ??singleton?? stereotype by clicking on the class and selecting the blank selection on the stereotype drop-down within the properties tab.

To apply the singleton pattern you should follow the directions in Section 15.8.1, “Consider using Singleton Pattern for <class>” .

15.8.3. Nodes normally have no enclosers

A suggestion that nodes should not be drawn inside other artifacts on the deployment diagram, since they represent an autonomous physical object.

15.8.4. NodeInstances normally have no enclosers

A suggestion that node instances should not be drawn inside other artifacts on the deployment diagram, since they represent an autonomous physical object.

15.8.5. Components normally are inside nodes

A suggestion that components represent the logical entities within physical nodes, and so should be drawn within a node, where nodes are shown on the deployment diagram.

15.8.6. ComponentInstances normally are inside nodes

A suggestion that component instances represent the logical entities within physical nodes, and so should be drawn within a node instance, where node instances are shown on the deployment diagram.

15.8.7. Classes normally are inside components

A suggestion that classes, as artifacts making up components, should be drawn within components on the deployment diagram.

15.8.8. Interfaces normally are inside components

A suggestion that interfaces, as artifacts making up components, should be drawn within components on the deployment diagram.

15.8.9. Objects normally are inside components

A suggestion that objects, as instances of artifacts making up components, should be drawn within components or component instances on the deployment diagram.

15.8.10. LinkEnds have not the same locations

A suggestion that a link (e.g. association) connecting objects on a deployment diagram has one end in a component and the other in a component instance (since objects can be in either). This makes no sense.

15.8.11. Set classifier (Deployment Diagram)

Suggestion that there is an instance (object) without an associated classifier (class, datatype) on a deployment diagram.

15.8.12. Missing return-actions

Suggestion that a sequence diagram has a send or call action without a corresponding return action.

15.8.13. Missing call(send)-action

Suggestion that a sequence diagram has a return action, but no preceding call or send action.

15.8.14. No Stimuli on these links

Suggestion that a sequence diagram has a link connecting objects without an associated stimulus (without which the link is meaningless).

[Warning]Warning

Triggering this critic indicates a serious problem, since ArgoUML provides no mechanism for creating a link without a stimulus. It probably indicates that the diagram was created by loading a corrupt project, with an XMI file describing a link without a stimulus, possibly created by a tool other than ArgoUML.

15.8.15. Set Classifier (Sequence Diagram)

Suggestion that there is an object without an associated classifier (class, datatype) on a sequence diagram.

15.8.16. Wrong position of these stimuli

Suggestion that the initiation of send/call-return message exchanges in a sequence diagram does not properly initiate from left to right.

15.9. Relationships

Critics concerning associations in ArgoUML.

The current version of ArgoUML has the following critics in this category.

15.9.1. Circular Association

Suggestion that an association class has a role that refers back directly to itself, which is not permitted.

[Warning]Warning

This critic is meaningless in the V0.14 version of ArgoUML which does not support association classes.

15.9.2. Make <association> Navigable

Suggestion that the association referred to is not navigable in either direction. This is permitted in the UML standard, but has no obvious meaning in any practical design.

15.9.3. Remove Navigation from Interface via <association>

Associations involving an interface can be not be navigable in the direction from the interface. This is because interfaces contain only operation declarations and cannot hold pointers to other objects.

This part of the design should be changed before you can generate code from this design. If you do generate code before fixing this problem, the code will not match the design.

To fix this, select the association and use the Properties tab to select in turn each association end that is not connected to the interface. Uncheck Navigable for each of these ends.

The association should then appear with a stick arrowhead pointed towards the interface

When an association between a class and interface is created in ArgoUML, it is by default navigable only from the class to the interface. However, ArgoUML does not prevent to change the navigability afterwards into a wrong situation. Which will cause this critic to be triggered.

15.9.4. Add Associations to <artifact>

Suggestion that the specified artifact (actor, use case or class) has no associations connecting it to other artifacts. This is required for the artifact to be useful in a design.

15.9.5. Remove Reference to Specific Subclass

This critic is discussed under an earlier design issues category (see Section 15.6.3, “Remove Reference to Specific Subclass” ).

15.9.6. Reduce Associations on <artifact>

Suggestion that the given artifact (actor, use case, class or interface) has so many associations it may be a maintenance bottleneck.

The Wizard of this critic allows setting of the treshold, i.e. the maximum number of associations allowed before this critic fires.

[Caution]Caution

This number is not stored persistently, and there is no way to reduce it after it has been set higher, except by creating more associations until the critic fires again. Restarting ArgoUML resets this number to its default: 7.

15.9.7. Make Edge More Visible

This critic is discussed under an earlier design issues category (see Section 15.7.14, “Make Edge More Visible” ).

15.10. Instantiation

Critics concerning instantiation of classifiers in ArgoUML.

The current version of ArgoUML has no critics in this category.

15.11. Modularity

Critics concerning modular development in ArgoUML.

The current version of ArgoUML has the following critics in this category.

15.11.1. Classifier not in Namespace of its Association

One of the well-formedness rules in UML 1.4 for associations, is that all the classifiers attached to the ends of the association should belong to the same namespace as the association.

If this were not the case, there would be no naming, by which each end could refer to all the others.

This critic is triggered when an association does not meet this criterion. The solution is to delete the association, and recreate it on a diagram, whose namespace includes those of all the attached classifiers.

[Caution]Caution

In the current implementation of ArgoUML this critic does not handle hierarchical namespaces. As a consequence it will trigger for associations where the immediate namespaces of the attached classifiers is different, even though they are part of the same namespace hierarchy.

15.11.2. Add Elements to Package <package>

Suggestion that the specified package has no content. Good design suggests packages are created to put things in.

[Note]Note

This will always trigger when you first create a package, since you cannot create one that is not empty!

15.12. Expected Usage

Critics concerning generally accepted good practice in ArgoUML.

The current version of ArgoUML has one critic in this category.

15.12.1. Clean Up Diagram

This critic is discussed under an earlier design issues category (see Section 15.3.3, “Clean Up Diagram” ).

15.13. Methods

Critics concerning operations in ArgoUML.

The current version of ArgoUML has the following critics in this category.

15.13.1. Change Names or Signatures in <artifact>

This critic is discussed under an earlier design issues category (see Section 15.4.3, “Change Names or Signatures in an Artifact” ).

15.13.2. Class Must be Abstract

Suggestion that a class that inherits or defines abstract operations must be marked abstract.

15.13.3. Add Operations to <class>

Suggestion that the specified class has no operations defined. This is required for the class to be useful in a design.

15.13.4. Reduce Operations on <artifact>

Suggestion that the artifact (class or interface) has too many operations for a good design, and is at risk of becoming a design bottleneck.

The Wizard of this critic allows setting of the treshold, i.e. the maximum number of operations allowed before this critic fires.

[Caution]Caution

This number is not stored persistently, and there is no way to reduce it after it has been set higher, except by creating more operations until the critic fires again. Restarting ArgoUML resets this number to its default: 20.

15.14. Code Generation

Critics concerning code generation in ArgoUML.

The current version of ArgoUML has one critic in this category.

15.14.1. Change Multiple Inheritance to interfaces

Suggestion that a class has multiple generalizations, which is permitted by UML, but cannot be generated into Java code, because Java does not support multiple inheritance.

15.15. Stereotypes

Critics concerning stereotypes in ArgoUML.

The current version of ArgoUML has no critics in this category.

15.16. Inheritance

Critics concerning generalization and specialization in ArgoUML.

The current version of ArgoUML has the following critics in this category.

15.16.1. Revise Attribute Names to Avoid Conflict

This critic is discussed under an earlier design issues category (see Section 15.4.2, “Revise Attribute Names to Avoid Conflict” ).

15.16.2. Remove <class>'s Circular Inheritance

Suggestion that a class inherits from itself, through a chain of generalizations, which is not permitted.

[Caution]Caution

This critic is marked inactive by default in the current release of ArgoUML (the only one so marked). It will not trigger unless made active.

15.16.3. Class Must be Abstract

This critic is discussed under an earlier design issues category (see Section 15.13.2, “Class Must be Abstract” ).

15.16.4. Remove final keyword or remove subclasses

Suggestion that a class that is final has specializations, which is not permitted in UML.

15.16.5. Illegal Generalization

Suggestion that there is a generalization between artifacts of different UML metaclasses, which is not permitted.

[Caution]Caution

It is not clear that such a generalization can be created within ArgoUML. It probably indicates that the diagram was created by loading a corrupt project, with an XMI file describing such a generalization, possibly created by a tool other than ArgoUML.

15.16.6. Remove Unneeded Realizes from <class>

Suggestion that the specified class has a realization relationship both directly and indirectly to the same interface (by realization from two interfaces, one of which is a generalization of the other for example). Good design deprecates such duplication.

15.16.7. Define Concrete (Sub)Class

Suggestion that a class is abstract with no concrete subclasses, and so can never be realized.

15.16.8. Define Class to Implement <interface>

Suggestion that the interface referred to has no influence on the running system, since it is never implemented by a class.

15.16.9. Change Multiple Inheritance to interfaces

This critic is discussed under an earlier design issues category (see Section 15.14.1, “Change Multiple Inheritance to interfaces” ).

15.16.10. Make Edge More Visible

This critic is discussed under an earlier design issues category (see Section 15.7.14, “Make Edge More Visible” ).

15.17. Containment

Critics concerning containment in ArgoUML, that is where one artifact forms a component part of another.

The current version of ArgoUML has the following critics in this category.

15.17.1. Remove Circular Composition

Suggestion that there is a series of composition relationships (associations with black diamonds) that form a cycle, which is not permitted.

15.17.2. Duplicate Parameter Name

Suggestion that a parameter list to an operation or event has two or more parameters with the same name, which is not permitted.

15.17.3. Two Aggregate Ends (Roles) in Binary Association

Only one end (role) of a binary association can be aggregate or composite. This a well-formedness rule of the UML 1.4 standard.

Aggregation and composition are used to indicate whole-part relationships, and by definition, the “part” end cannot be aggregate.

To fix this, identify the “part” end of the association, and use the critic wizard (the Next> button, or manually set its aggregation to none using the button 2 pop-up menu or the property sheet.

Composition (more correctly called composite aggregation) is used where there is a whole-part relationship that is one-to-one or one-to-many, and the lifetime of the part is inextricably tied to the lifetime of the whole. Instances of the whole will have responsibility for creating and destroying instances of the associated part. This also means that a class can only be a part in one composite aggregation.

An example of a composite aggregation might be a database of cars and their wheels. This is a one-to-four relationship, and the database entry for a wheel is associated with its car. When the car ceases to exist in the database, so do its wheels.

Aggregation (more correctly called shared aggregation) is used where there is a whole-part relationship, that does not meet the criteria for a composite aggregation. An example might be a database of university courses and the students that attend them. There is a whole-part relationship between courses and students. However there is no lifetime relationship between students and course (a student continues to exist even after a course is finished) and the relationship is many-to-many.

15.17.4. Aggregate End (Role) in 3-way (or More) Association

Three-way (or more) associations can not have aggregate ends (roles). This a well-formedness rule of the UML 1.4 standard.

Aggregation and composition are used to indicate whole-part relationships, and by definition can only apply to binary associations between artifacts.

To fix this, manually select the association, and set the aggregation of each of its ends (roles) to none using the button 2 pop-up menu or the property sheet.

15.17.5. Wrap DataType

This critic is discussed under an earlier design issues category (see Section 15.3.1, “Wrap DataType” ).

Part 3. Model Reference

Chapter 16. Top Level Artifact Reference

16.1. Introduction

This chapter describes each artifact that can be created within ArgoUML. The chapter covers top-level “general” artifacts. The following chapters (see Chapter 17, Use Case Diagram Artifact Reference through Chapter 23, Deployment Diagram Artifact Reference) cover each of the ArgoUML diagrams.

There is a close relationship between this material and the properties tab of the details pane (see Section 13.3, “Properties Tab”). That section covers properties in general, in this chapter they are linked to specific artifacts.

16.2. The Model

The model is the top level artifact within ArgoUML. In the UML meta-model it is a sub-class of package. In many respects within ArgoUML it behaves similarly to a package (see Section 18.2, “Package”).

[Note]Note

ArgoUML is restricted to one model within the tool.

Standard data types, classes and packages are loaded (the default, see Chapter 24, Built In DataTypes, Classes, Interfaces and Stereotypes) as sub-packages of the model. These sub-packages are not initially present in the model but are added to the model when used.

16.2.1. Model Details Tabs

The details tabs that are active for the model are as follows.

ToDoItem

Standard tab.

Properties

See Section 16.2.2, “Model Property Toolbar” and Section 16.2.3, “Property Fields For The Model” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Stereotype

Standard tab. This contains a a list of the stereotypes applied to this model, and a list of available stereotypes that may be applied to the model.

Tagged Values

Standard tab. In the UML meta-model, Model has the following standard tagged values defined.

  • derived (from the superclass, ModelElement).

    Values true, meaning the class is redundant ??? it can be formally derived from other elements, or false meaning it cannot.

    Derived models have their value in analysis to introduce useful names or concepts, and in design to avoid re-computation.

16.2.2. Model Property Toolbar

Go up

Navigate up through the composition structure of the model.

Since the model is the top package nothing can happen, and this button is allways downlighted.

New Package

This creates a new Package (see Section 18.2, “Package”) within the model (which appears on no diagram), navigating immediately to the properties tab for that package.

[Tip]Tip

While it can make sense to create Packages of the model this way, it is usually a lot clearer to create them within diagrams where you want them.

New DataType

This creates a new DataType (see Section 16.3, “Datatype”) within the model (which appears on no diagram), navigating immediately to the properties tab for that DataType.

New Enumeration

This creates a new Enumeration (see Section 16.4, “Enumeration”) within the model (which appears on no diagram), navigating immediately to the properties tab for that Enumeration.

New Stereotype

This creates a new Stereotype (see Section 16.5, “Stereotype”) within the model, navigating immediately to the properties tab for that stereotype.

Delete

This tool is always downlighted, since it is meaningless to delete the model!

16.2.3. Property Fields For The Model

Name

Text box. The name of the model. The name of a model, like all packages, is by convention all lower case.

[Note]Note

The default name supplied to a new model by ArgoUML, untitledModel, is thus erroneous and guarantees that ArgoUML always starts up with at least one problem being reported by the design critics.

Stereotype

Drop down selector. Model is provided by default with the UML standard stereotypes for model ( systemModel and metamodel) and package ( facade, framework, stub).

Stereotyping models is a useful thing, although it is of limited value in ArgoUML where you have only a single model.

Navigate Stereotype

icon. If a stereotype has been selected, this will navigate to the stereotype property panel (see Section 16.5, “Stereotype”).

Namespace

Text box. Records the namespace for the model. This is the package hierarchy. However since the model is at the top of the hierarchy in ArgoUML, this box is always empty.

Visibility

Radio box, with entries public, private, protected, and package.

Records the visibility for the model. Since ArgoUML only permits one model, this has no meaningful use.

Modifiers

Check box, with entries Abstract, Leaf and Root.

  • abstract is used to declare that this model cannot be instantiated, but must always be specialized.

    The meaning of abstract applied to a model is not that clear. It might mean that the model contains interfaces or abstract classes without realizations. Since ArgoUML only permits one model, this is not a meaningful box to check.

  • Leaf indicates that this model can have no further subpackages, while root indicates it is the top level model.

    Within ArgoUML root only meaningfully applies to the Model, since all packages sit within the model. In the absence of the topLevel stereotype, this could be used to emphasize that the Model is at the top level.

Generalizations

Text area. Lists any model that generalizes this model.

[Note]Note

Since there is only one model in ArgoUML there is no sensible specialization or generalization that could be created.

Specializations

Text box. Lists any specialized model (i.e. for which this model is a generalization.

[Note]Note

Since there is only one model in ArgoUML there is no sensible specialization or generalization that could be created.

Owned Elements

Text area. A listing of the top level packages, classes, interfaces, datatypes, actors, use cases, associations, generalizations, and stereotypes within the model.

Button 1 double click on any of the artifacts yields navigating to that artifact.

16.3. Datatype

Datatypes can be thought of as simple classes. They have no attributes, and any operations on them must have no side-effects. A useful analogy is primitive datatypes in a language like Java. The integer “3” stands on its own???it has no inner structure. There are operations (for example addition) on the integers, but when I perform 3 + 4 the result is a new number, “3” and “4” are unchanged by the exercise.

Within UML 1.3, DataType is a sub-class of the Classifier metaclass. It embraces the predefined primitive types ( byte, char, double, float, int, long and short), the predefined enumeration, boolean and user defined enumeration types.

[Note]Note

Also void is implemented as a datatype within ArgoUML

Within ArgoUML new datatypes may be created using the New datatype button on the property tabs of the model and packages (in which case the new datatype is restricted in scope to the package), as well as the properties tab for datatype.

[Note]Note

UML 1.3 allows user defined datatypes to be placed on class diagrams. This is not permitted in ArgoUML.

16.3.1. Datatype Details Tabs

The details tabs that are active for datatypes are as follows.

ToDoItem

Standard tab.

Properties

See Section 16.3.2, “Datatype Property Toolbar” and Section 16.3.3, “Property Fields For Datatype” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Source

Standard tab. Unused. One would expect a class declaration for the new datatype to support code generation.

Tagged Values

Standard tab. In the UML metamodel, Datatype has the following standard tagged values defined.

  • persistence (from the superclass, Classifier). Values transitory, indicating state is destroyed when an instance is destroyed or persistent, marking state is preserved when an instance is destroyed.

    [Tip]Tip

    Since user defined datatypes are enumerations, they have no state to preserve, and the value of this tagged value is irrelevant.

  • semantics (from the superclass, Classifier). The value is a specification of the semantics of the datatype.

  • derived (from the superclass, ModelElement). Values true, meaning the class is redundant???it can be formally derived from other elements, or false meaning it cannot.

    [Tip]Tip

    While formally available, a derived datatype does not have an obvious value, and so datatypes should always be marked with derived=false.

16.3.2. Datatype Property Toolbar

Go up

Navigate up through the package structure.

New datatype

This creates a new datatype (see Section 18.5, “Class”) within the same package as the current datatype.

[Tip]Tip

While it can make sense to create datatypes this way, it can be clearer to create them within the package or model where you want them.

New enumeration literal

This creates a new enumeration literal within the datatype, navigating immediately to the properties tab for that literal.

[Caution]Caution

ArgoUML does not actually have a separate concept of a literal. The navigation will navigate to the property sheet for an attribute of a class (see Section 18.6, “Attribute”). When defining a literal, all that matters is its name. Other parts of the attribute property sheet should be ignored. Also the name of the literal must obey the rules for an Attribute or a critic will fire.

New Operation

This creates a new operation within the datatype, navigating immediately to the properties tab for that operation.

New Stereotype

This creates a new Stereotype (see Section 16.5, “Stereotype”) within the same package as the datatype, navigating immediately to the properties tab for that stereotype.

Delete

This deletes the datatype from the model.

16.3.3. Property Fields For Datatype

Name

Text box. The name of the datatype. The primitive datatypes all have lower case names, but there is no formal convention.

[Note]Note

The default name supplied for a newly created datatype is the empty string “”. Datatypes with empty string names will appear with the name (anon Datatype) in the explorer.

Stereotype

Drop down selector. Stereotype is provided by default with the UML standard stereotypes for classifier (metaclass, powertype, process, thread and utility).

[Tip]Tip

The stereotype enumeration should always be used for any created enumeration datatypes.

[Caution]Caution

In ArgoUML version 0.18 the stereotype enumeration must be created before it can be used. However, by creating an Enumeration Literal, the stereotype enumeration is created automatically.

Navigate Stereotype

icon. If a stereotype has been selected, this will navigate to the stereotype property panel (see Section 16.5, “Stereotype”).

Namespace

Drop down selector. Allows changeing the namespace for the datatype. This is the package hierarchy.

Modifiers

Check box, with entries Abstract, Leaf and Root.

  • Abstract is used to declare that this datatype cannot be instantiated, but must always be specialized.

    [Note]Note

    ArgoUML provides no mechanism for specializing datatypes, so this check box is of little use.

  • Leaf indicates that this datatype can have no further sub-types, while Root indicates it is a top level datatype.

    [Tip]Tip

    In the absence of specialization of datatypes within ArgoUML these have little value. In effect all datatypes are both Root and Final

Visibility

Radio box, with entries public, private, protected, and package.

Records the visibility for the Datatype.

Client Dependencies

Text area. Lists any elements that depend on this datatype.

[Caution]Caution

It is not clear that dependencies between datatypes makes much sense.

Supplier Dependencies

Text area. Lists any elements that this datatype depends on.

[Caution]Caution

It is not clear that dependencies between datatypes makes much sense.

Generalizations

Text area. Lists any datatype that generalizes this datatype.

[Caution]Caution

It is not clear that generalizing datatypes makes much sense.

Specializations

Text box. Lists any specialized datatype (i.e. for which this datatype is a generalization.

[Caution]Caution

It is not clear that specializing datatypes makes much sense.

Operations

Text area. Lists all the operations defined on this datatype. Button 1 double click navigates to the selected operation. button 2 click brings up a pop up menu with two entries.

  • Move Up. Only available where there are two or more operations, and the operation selected is not at the top. It is moved up one.

  • Move Down. Only available where there are two or more operations listed, and the operation selected is not at the bottom. It is moved down one.

See Section 18.7, “Operation” for details of operations.

[Caution]Caution

ArgoUML treats all operations as equivalent. Any operations created here will use the same mechanism as operations for classes. Remember that operations on datatypes must have no side effects (they are read-only). This means the query modifier must be checked for all operations.

Literals

Text area. Lists all the enumeration literals defined for this datatype. Button 1 double click navigates to the selected literal, button 2 click brings up a pop up menu with two entries.

  • Move Up. Only available where there are two or more literals, and the literal selected is not at the top. It is moved up one.

  • Move Down. Only available where there are two or more literals listed, and the literal selected is not at the bottom. It is moved down one.

[Caution]Caution

ArgoUML does not actually have a separate concept of a literal. The navigations listed above will all navigate to a property sheet equal to an attribute of a class (see Section 18.6, “Attribute”). When defining a literal, all that matters is its name. Other parts of the attribute property sheet should be ignored.

16.4. Enumeration

Enumeration can be thought of as simple classes. They have no attributes, and any operations on them must have no side-effects. A useful analogy is primitive datatypes in a language like Java. The boolean “true” stands on its own???it has no inner structure. There are operations (for example logical xor) on the booleans, but when I perform true xor true the result is a new boolean, and the original 2 booleans “true” are unchanged by the exercise.

Within UML 1.4, Enumeration is a sub-class of the DataType metaclass.

The big difference with other DataTypes, is that an Enumeration has EnumerationLiterals. E.g. the Enumeration “boolean” is defined as having 2 EnumerationLiterals, “true” and “false”.

Within ArgoUML new enumerations may be created using the New Enumeration button on the property tabs of the model and packages (in which case the new enumeration is restricted in scope to the package), as well as the properties tab for datatype and enumeration.

[Note]Note

UML 1.4 allows user defined datatypes to be placed on class diagrams. This is not yet possible in ArgoUML.

16.4.1. Enumeration Details Tabs

The details tabs that are active for enumerations are as follows.

ToDoItem

Standard tab.

Properties

See Section 16.4.2, “Enumeration Property Toolbar” and Section 16.4.3, “Property Fields For Enumeration” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Source

Standard tab.

Stereotype

Standard tab. The UML metamodel has the following stereotypes defined by default for a Classifier, which also apply to an Enumeration:

  • metaclass (from the superclass, Classifier).

  • powertype (from the superclass, Classifier).

  • process (from the superclass, Classifier).

  • thread (from the superclass, Classifier).

  • utility (from the superclass, Classifier).

Tagged Values

Standard tab. In the UML metamodel, Enumeration has no standard tagged values defined.

16.4.2. Enumeration Property Toolbar

Go up

Navigate up through the composition structure.

New datatype

This creates a new datatype (see Section 18.5, “Class”) within the same package as the current enumeration.

New enumeration literal

This creates a new enumeration literal within the enumeration, navigating immediately to the properties tab for that literal.

New Operation

This creates a new operation within the enumeration, navigating immediately to the properties tab for that operation.

New Stereotype

This creates a new Stereotype (see Section 16.5, “Stereotype”) within the same package as the enumeration, navigating immediately to the properties tab for that stereotype.

Delete from Model

This deletes the datatype from the model.

16.4.3. Property Fields For Enumeration

Name

Text box. The name of the enumeration. The primitive enumerations all have lower case names, but there is no formal convention.

[Note]Note

The default name supplied for a newly created datatype is the empty string “”. Enumerations with empty string names will appear with the name (anon Enumeration) in the explorer.

Namespace

Drop down selector. Allows changeing the namespace for the enumeration. This is the composition hierarchy.

Modifiers

Check box, with entries Abstract, Leaf and Root.

  • Abstract is used to declare that this enumeration cannot be instantiated, but must always be specialized.

    [Note]Note

    ArgoUML provides no mechanism for specializing enumerations, so this check box is of little use.

  • Leaf indicates that this enumeration can have no further sub-types, while Root indicates it is a top level enumeration.

    [Tip]Tip

    In the absence of specialization of enumerations within ArgoUML these have little value. In effect all enumerations are both Root and Final

Visibility

Radio box, with entries public, private, protected, and package.

Records the visibility for the Enumeration.

Client Dependencies

Text area. Lists any elements that depend on this enumeration.

[Caution]Caution

It is not clear that defining dependencies between enumerations makes much sense.

Supplier Dependencies

Text area. Lists any elements that this enumeration depends on.

[Caution]Caution

It is not clear that defining dependencies between enumeration makes much sense.

Generalizations

Text area. Lists any enumeration that generalizes this enumeration.

Specializations

Text box. Lists any specialized enumerations (i.e. for which this enumeration is a generalization.

Operations

Text area. Lists all the operations defined on this enumeration. Button 1 double click navigates to the selected operation. button 2 click brings up a pop up menu with two entries.

  • Move Up. Only available where there are two or more operations, and the operation selected is not at the top. It is moved up one.

  • Move Down. Only available where there are two or more operations listed, and the operation selected is not at the bottom. It is moved down one.

See Section 18.7, “Operation” for details of operations.

[Caution]Caution

ArgoUML treats all operations as equivalent. Any operations created here will use the same mechanism as operations for classes. Remember that operations on enumerations must have no side effects (they are read-only). This means the query modifier must be checked for all operations.

Literals

Text area. Lists all the enumeration literals defined for this enumeration. Button 1 double click navigates to the selected literal, button 2 click brings up a pop up menu with two entries.

  • Move Up. Only available where there are two or more literals, and the literal selected is not at the top. It is moved up one.

  • Move Down. Only available where there are two or more literals listed, and the literal selected is not at the bottom. It is moved down one.

16.5. Stereotype

Stereotypes are the main extension mechanism of UML, providing a way to derive specializations of the standard metaclasses. Stereotype is a sub-class of GeneralizableElement in the UML metamodel. Stereotypes are supplemented by constraints and tagged values.

New stereotypes are added from the property tab of almost any artifact. Properties of existing stereotypes can be reached by selecting the property tab for any artifact with that stereotype and using the navstereo button ( ) within the property tab.

16.5.1. Stereotype Details Tabs

The details tabs that are active for stereotypes are as follows.

ToDoItem

Standard tab.

Properties

See Section 16.5.2, “Stereotype Property Toolbar” and Section 16.5.3, “Property Fields For Stereotype” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Source

Standard tab. This contains the representation of the stereotype on diagrams (its name between ?? and ??).

[Warning]Warning

You can edit this entry, but it has no effect and when you return to the entry it will be restored to its original value.

Tagged Values

Standard tab. In the UML metamodel, Stereotype has the following standard tagged values defined.

  • derived (from the superclass, ModelElement). Values true, meaning the class is redundant???it can be formally derived from other elements, or false meaning it cannot.

    [Note]Note

    This indicates any element with this stereotype has the derived tag set accordingly.

[Caution]Caution

Tagged values for a stereotype are rather different to those for elements in the UML core architecture, in that they apply to all artifacts to which the stereotype is applied, not just the stereotype itself.

16.5.2. Stereotype Property Toolbar

Go up

Navigate up through the package structure of the model.

Add stereotype

This creates a new stereotype (see Section 16.5, “Stereotype”) within the model (which appears on no diagram), navigating immediately to the properties tab for that stereotype.

Delete

This deletes the stereotype from the model.

16.5.3. Property Fields For Stereotype

Name

Text box. The name of the stereotype. There is no convention for naming stereotypes, beyond starting them with a lower case letter. Even the standard UML stereotypes vary between all lower case (e.g. metamodel), bumpy caps (e.g. systemModel) and space separated (e.g. object model).

[Note]Note

ArgoUML does not enforce any naming convention for stereotypes

Base Class

Drop down selector. Any stereotype must be derived from one of the metaclasses in the UML metamodel Abstraction, Actor, Association, AssociationEnd, Attribute, BehavioralFeature, CallEvent, Class, Classifier, Collaboration, Comment, Component, Constraint, DataType, Exception, Flow, Generalization, Interface, Link, Model, ModelElement, Node, NodeInstance, ObjectFlowState, Operation, Package, Permission, Signal, Subsystem and Usage) or the artifact classes that derive from them. The stereotype will then be available to artifacts that derive from that same metaclass or that artifact.

Namespace

Drop down selector. Records the namespace for the stereotype. This is the package hierarchy.

Modifiers

Check box, with entries Abstract, Leaf and Root.

  • Abstract is used to declare that artifacts that use this stereotype cannot be instantiated, but must always be specialized.

  • Leaf indicates that artifacts that use this stereotype can have no further sub-types, while Root indicates it is a top level artifact.

[Caution]Caution

Remember that these modifiers apply to the artifacts using the stereotype, not just the stereotype.

[Warning]Warning

ArgoUML neither imposes, nor checks that artifacts using a stereotype adopt the stereotype's modifiers.

Generalizations

Text area. Lists any stereotype that generalizes this stereotype.

[Caution]Caution

It is not clear that generalizing stereotypes makes much sense.

Specializations

Text box. Lists any specialized stereotype (i.e. for which this stereotype is a generalization.

[Caution]Caution

It is not clear that specializing stereotypes makes much sense.

16.6. Diagram

The UML standard specifies eight principal diagrams, all of which are supported by ArgoUML.

  • Use case diagram. Used to capture and analyse the requirements for any OOA&D project. See Chapter 17, Use Case Diagram Artifact Reference for details of the ArgoUML use case diagram and the artifacts it supports.

  • Class diagram. This diagram captures the static structure of the system being designed, showing the classes, interfaces and datatypes and how they are related. Variants of this diagram are used to show package structures within a system (the package diagram) and the relationships between particular instances (the object diagram).

    The ArgoUML class diagram provides support for class and package diagrams. See Chapter 18, Class Diagram Artifact Reference for details of the artifacts it supports. The object diagram is suported on the Deployment diagram.

  • Behavior diagrams. There are four such diagrams (or strictly speaking, five, since the use case diagram is a type of behavior diagram), which show the dynamic behavior of the system at all levels.

    • Statechart diagram. Used to show the dynamic behavior of a single object (class instance). This diagram is of particular use in systems using complex communication protocols, such as in telecommunications. See Chapter 20, Statechart Diagram Artifact Reference for details of the ArgoUML statechart diagram and the artifacts it supports.

    • Activity diagram. Used to show the dynamic behavior of groups of objects (class instance). This diagram is an alternative to the statechart diagram, and is better suited to systems with a great deal of user interaction. See Chapter 22, Activity Diagram Artifact Reference for details of the ArgoUML activity diagram and the artifacts it supports.

    • Interaction diagrams. There are two diagrams in this category, used to show the dynamic interaction between objects (class instances) in the system.

      • Sequence diagram. Shows the interactions (typically messages or procedure calls) between instances of classes (objects) and actors against a timeline. Particularly useful where the timing relationships between interactions are important. See Chapter 19, Sequence Diagram Artifact Reference for details of the ArgoUML sequence diagram and the artifacts it supports.

      • Collaboration diagram. Shows the interactions (typically messages or procedure calls) between instances of classes (objects) and actors against the structural relationships between those instances. Particularly suitable where it is useful to relate interactions to the static structure of the system. See Chapter 21, Collaboration Diagram Artifact Reference for details of the ArgoUML collaboration diagram and the artifacts it supports.

  • Implementation diagrams. UML defines two implementation diagrams to show the relationship between the software components that make up a system (the component diagram) and the relationship between the software and the hardware on which it is deployed at run-time (the deployment diagram.

    The ArgoUML deployment diagram provides support for both component and deployment diagrams, and additionally for object diagrams. See Chapter 23, Deployment Diagram Artifact Reference for details of the diagram and the artifacts it supports.

Diagrams are created using the Create drop down menu (see Section 10.6, “The Create Menu” ), or with the tools on the toolbar (see Section 9.4, “Create operations”).

[Note]Note

ArgoUML uses its deployment diagram to create the UML 1.4 component, deployment and object diagrams.

[Caution]Caution

Statechart and activity diagrams are associated with a particular class or operation (or the latter also with a package), and can only be created when this modelelement has been selected.

[Warning]Warning

In ArgoUML version 0.20, the UML 1.4 object diagram as a variant of the class diagram is not directly supported. However, it is possible to create simple object diagrams within the ArgoUML deployment diagram.

16.6.1. Diagram Details Tabs

The details tabs that are active for diagrams are as follows.

ToDoItem

Standard tab.

Properties

See Section 16.6.3, “Property Fields For Diagram” below.

16.6.2. Diagram Property Toolbar

Go up

Navigate up through the package structure of the model.

Delete

This deletes the diagram from the model. As a consequence, in case of a statechart diagram or an activity diagram, all contained elements are deleted, too.

16.6.3. Property Fields For Diagram

Name

The name of the diagram. There are no conventions for naming diagrams. By default, ArgoUML uses the (space separated) diagram name and a sequence number, thus Use Case Diagram 1.

[Tip]Tip

This name is used to generate a filename when activating the “Save Graphics...” menu-item.

Chapter 17. Use Case Diagram Artifact Reference

17.1. Introduction

This chapter describes each artifact that can be created within a use case diagram. Note that some sub-artifacts of artifacts on the diagram may not actually themselves appear on the diagram.

There is a close relationship between this material and the properties tab of the details pane (see Section 13.3, “Properties Tab”). That section covers properties in general, in this chapter they are linked to specific artifacts.

Figure 17.1, “Possible artifacts on a use case diagram.” shows a use case diagram with all possible artifacts displayed.

Figure 17.1. Possible artifacts on a use case diagram.

Possible artifacts on a use case diagram.


17.1.1. ArgoUML Limitations Concerning Use Case Diagrams

Use case diagrams are now well supported within ArgoUML. There still are some minor limitations though. One is that extension points may be shown in a separate compartment on the use case, but this is not retained after saving and reloading.

[Note]Note

Earlier versions of ArgoUML (0.9 and earlier) implemented extend and include relationships by using a stereotyped dependency relationship. Although such diagrams will show correctly on the diagram, they will not link correctly to the use cases, and should be replaced by proper extend and include relationships using the current system.

17.2. Actor

An actor represents any external entity (human or machine) that interacts with the system, providing input, receiving output, or both.

Within the UML metamodel, actor is a sub-class of classifier.

The actor is represented by a “stick man” figure on the diagram (see Figure 17.1, “Possible artifacts on a use case diagram.”).

17.2.1. Actor Details Tabs

The details tabs that are active for actors are as follows.

ToDoItem

Standard tab.

Properties

See Section 17.2.2, “Actor Property Toolbar” and Section 17.2.3, “Property Fields For Actor” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Presentation

Standard tab. The fill color is used for the stick man's head.

Source

Standard tab. Usually, no code is provided for an actor, since it is external to the system.

[Note]Note

The source tab content can be changed, but the changes are not retained.

Constraints

Standard tab. ArgoUML only supports constraints on Classes and Features (Attributes, Operations, Receptions, and Methods), so this tab is grayed out.

Tagged Values

Standard tab. In the UML metamodel, Actor has the following standard tagged values defined.

  • persistence (from the superclass, Classifier). Values transitory, indicating state is destroyed when an instance is destroyed or persistent, marking state is preserved when an instance is destroyed.

    [Tip]Tip

    Actors sit outside the system, and so their internal behavior is of little concern, and this tagged value is best ignored.

  • semantics (from the superclass, Classifier). The value is a specification of the semantics of the actor.

  • derived (from the superclass, ModelElement). Values true, meaning the actor is redundant???it can be formally derived from other elements, or false meaning it cannot.

    [Note]Note

    Derived actors have limited value, since they sit outside the system being designed. They may have their value in analysis to introduce useful names or concepts.

Checklist

Standard tab for a Classifier.

17.2.2. Actor Property Toolbar

Go up

Navigate up through the package structure of the model.

Add Actor

This creates a new actor within the model, (but not within the diagram), navigating immediately to the properties tab for that actor.

[Tip]Tip

This method of creating a new actor may be confusing. It is much better to create an actor on the diagram.

Delete

This deletes the selected actor from the model.

[Warning]Warning

This is a deletion from the model not just the diagram. To delete an actor from the diagram, but keep it within the model, use the main menu Remove From Diagram (or press the Delete key).

17.2.3. Property Fields For Actor

Name

Text box. The name of the actor. The diagram shows this name below the stick man figure. Since an actor is a classifier, it would be conventional to Capitalize the first letter (and initial letters of any component words), e.g. RemoteSensor.

[Note]Note

ArgoUML does not enforce any naming convention for actors

Stereotype

Drop down selector. Actor is provided by default with the UML standard stereotypes ( metaclass, powertype, process, thread, utility) for classifiers. Stereotypes are of limited value with actors. The stereotypes machine, organization, person and singleton are probably of most use. However, they are not provided by default with ArgoUML.

Navigate Stereotype

icon. If a stereotype has been selected, this will navigate to the stereotype property panel (see Section 16.5, “Stereotype”).

Namespace

Text box. Records the namespace for the actor. This is the package hierarchy.

Modifiers

Check box, with entries Abstract, Leaf and Root.

  • Abstract is used to declare that this actor cannot be instantiated, but must always be specialized.

    [Caution]Caution

    While actors can be specialized and generalized, it is not clear that an abstract actor has any meaning. Perhaps it might be used to indicate an actor that does not itself interact with a use case, but whose children do.

  • leaf indicates that this actor can have no further children, while Root indicates it is a top level actor with no parent.

Generalizations

Text area. Lists any actor that generalizes this actor.

Button 1 double click navigates to the generalization and opens its property tab.

Specializations

Text box. Lists any specialized actor (i.e. for which this actor is a generalization. The specialized actors can communicate with the same use case instances as this actor.

Button 1 double click navigates to the generalization and opens its property tab.

Association Ends

Text area. Lists any association ends of associations connected to this actor.

Button 1 double click navigates to the selected entry.

17.3. Use Case

A use case represents a complete meaningful “chunk” of activity by the system in relation to its external users (actors), human or machine. It represents the primary route through which requirements are captured for the system under construction

Within the UML metamodel, use case is a sub-class of classifier.

The use case icon is an oval (see Figure 17.1, “Possible artifacts on a use case diagram.”). It may be split in two, with the lower compartment showing extension points

[Caution]Caution

By default ArgoUML does not show the extension point compartment. It may be revealed by the context sensitive Show menu (using button 2 click), or from the Presentation tab.

17.3.1. Use Case Details Tabs

The details tabs that are active for use cases are as follows.

ToDoItem

Standard tab.

Properties

See Section 17.3.2, “Use Case Property Toolbar” and Section 17.3.3, “Property Fields For Use Case” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Presentation

Standard tab. The Fill color is used for the use case oval.

The Display: Extension Points check box is used to control whether an extension point compartment is displayed.

Source

Standard tab. It would not be usual to provide any code for a use case, since it is primarily a vehicle for capturing requirements about the system under construction, not creating the solution.

Tagged Values

Standard tab. In the UML metamodel, UseCase has the following standard tagged values defined.

  • persistence (from the superclass, Classifier). Values transitory, indicating state is destroyed when an instance is destroyed or persistent, marking state is preserved when an instance is destroyed.

    [Tip]Tip

    In general the instantiation of use cases is not a major aspect of any design method (they are mostly concerned with requirements capture. For most OOA&D methodologies, this tag can safely be ignored.

  • semantics (from the superclass, Classifier). The value is a specification of the semantics of the use case.

  • derived (from the superclass, ModelElement). Values true, meaning the use case is redundant???it can be formally derived from other elements, or false meaning it cannot.

    [Note]Note

    Derived use cases still have their value in analysis to introduce useful names or concepts.

Checklist

Standard tab for a Classifier.

17.3.2. Use Case Property Toolbar

Go up

Navigate up through the package structure of the model.

New use case

This creates a new use case within the model, (but not within the diagram), and shows immediately the properties tab for that use case.

[Tip]Tip

This method of creating a new use case can be confusing. It is much better to create a new use case on the diagram of your choice.

New extension point

This creates a new use extension point within the namespace of the current use case, with the current use case as its associated use case, navigating immediately to the properties tab for that extension point.

Delete

This deletes the selected use case from the model.

[Warning]Warning

This is a deletion from the model not just the diagram. To delete a use case from the diagram, but keep it within the model, use the main menu Remove From Diagram (or press the Delete key).

17.3.3. Property Fields For Use Case

Name

Text box. The name of the use case. Since a use case is a classifier, it would be conventional to Capitalize the first letter (and initial letters of any component words), e.g. RemoteSensor. The name is shown inside the oval representation of the use case on the diagram.

[Note]Note

ArgoUML does not enforce any naming convention for use cases

Stereotype

Drop down selector. Use case is provided by default with the UML standard stereotypes ( metaclass, powertype, process, thread, utility) for classifiers. Stereotyping can be useful when creating use cases in the problem domain (requirements capture) and solution domain (analysis), but none of the predefined stereotypes are well suited to this.

Navigate Stereotype

icon. If a stereotype has been selected, this will navigate to the stereotype property panel (see Section 16.5, “Stereotype”).

Namespace

Text box. Records the namespace for the use case. This is the package hierarchy.

Modifiers

Check box, with entries Abstract Leaf and Root.

  • Abstract is used to declare that this actor cannot be instantiated, but must always be specialized. .

  • Leaf indicates that this use case can have no further children, while Root indicates it is a top level use case with no parent.

Extension Points

Text box. If this use case is, or can be extended, this field lists the extension points for the use case.

[Note]Note

Extension points are listed by their location point rather than their name.

Where an extension point has been created (see below), button 1 Double Click will navigate to that relationship. Button 2 gives a pop up menu with one entry.

  • New. Add a new extension point and navigate to it, making this use case the owning use case of the extension point.

Generalizations

Text area. Lists use cases which are generalizations of this one. Will be set whenever a generalization is created on the from this Use Case. Button 1 Double Click on a generalization will navigate to that generalization.

Specializations

Text box. Lists any specialized use case (i.e. for which this use case is a generalization.

Button 1 double click navigates to the generalization and opens its property tab.

Extends

Text box. Lists any class that is extended by this use case.

Where an extends relationship has been created, button 1 double click will navigate to that relationship.

Includes

Text box. Lists any use case that this use case includes.

Where an include relationship has been created, button 1 Double Click will navigate to that relationship.

Association Ends

Text box. Lists any association ends (see Section 18.11, “Association”) of associations connected to this use case.

Button 1 double click navigates to the selected entry.

17.4. Extension Point

An extension point describes a point in a use case where an extending use case may provide additional behavior.

Examples for a travel agent sales system might be the use case for paying for a ticket, which has an extension point in the specification of the payment. Extending use cases may then extend at this point to pay by cash, credit card etc.

Within the UML metamodel, Extension Point is a sub-class of ModelElement. A use case may display an extension point compartment (see Section 17.3, “Use Case” for details), in which extension points are shown with the following syntax.

name :location.

17.4.1. Extension Point Details Tabs

The details tabs that are active for extension points are as follows.

ToDoItem

Standard tab.

Properties

See Section 17.4.2, “Extension Point Property Toolbar” and Section 17.4.3, “Property Fields For Extension Point” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Source

Standard tab. It would not be usual to provide any code for an extension point, since it is external to the system.

[Note]Note

The source tab content can be changed, but this has no effect.

Tagged Values

Standard tab. In the UML metamodel, ExtensionPoint has the following standard tagged values defined.

  • derived (from the superclass, ModelElement). Values true, meaning the extension point is redundant???it can be formally derived from other elements, or false meaning it cannot.

    [Note]Note

    It is not clear how derived extension points could have any value in analysis.

17.4.2. Extension Point Property Toolbar

Go up

Navigate up to the use case which owns this extension point.

New Extension Point

This creates a new Extension Point below the selected extension point, navigating immediately to the properties tab of the newly created extension point.

New Stereotype

This creates a new Stereotype (see Section 16.5, “Stereotype”) for the selected extension point, navigating immediately to the properties tab for that stereotype.

Delete

This deletes the selected extension point from the model.

17.4.3. Property Fields For Extension Point

Name

Text box. The name of the extension point.

[Tip]Tip

It is quite common to leave extension points unnamed in use case analysis, since they are always listed (within use cases and extend relationships) by their location.

[Note]Note

ArgoUML does not enforce any naming convention for extension points.

Stereotype

Drop down selector. ArgoUML does not provide any stereotypes for extension points.

[Tip]Tip

Stereotyping does not have great value on an extension point.

Navigate Stereotype

icon. If a stereotype has been selected, this will navigate to the stereotype property panel (see Section 16.5, “Stereotype”).

Location

Text box. A description of the location of this extension point within the owning use case.

[Tip]Tip

Extension points are always listed (within use cases and extend relationships) by their location. Typically this will be the number/name of the paragraph in the specification.

Base Use Case

Text box. Shows the base use case within which this extension point is defined. Button 1 Double Click will navigate to the use case.

Extend

Text box. Lists all use cases which extend the base use case through this extension point.

Where an extending use case exists, button 1 double click will navigate to that relationship.

17.5. Association

An association on a use case diagram represents a relationship between an actor and a use case showing that actor's involvement in the use case. The invocation of the use case will involve some (significant) change perceived by the actor.

Associations are described fully under class diagrams (see Section 18.11, “Association”).

17.6. Association End

Association ends are described under class diagrams (see Section 18.12, “Association End”).

17.7. Dependency

Dependencies are described under class diagrams (see Section 18.13, “Dependency”).

[Caution]Caution

Dependency has little use in use case diagrams. It is provided, because earlier versions of ArgoUML used it (incorrectly) to implement include and extends relationships.

17.8. Generalization

Generalization is a relationship between two use cases or two actors. Where A is a generalization of B, it means A describes more general behavior and B a more specific version of that behavior.

Examples for a travel agent sales system might be the use case for making a booking as a generalization of the use case for making a flight booking and a salesman actor being a generalization of a supervisor actor (since supervisors can also act as salesmen, but not vice versa).

Generalization is analogous to class inheritance within OO programming.

[Note]Note

It is easy to confuse extends relationships between use cases with generalization. However extends is about augmenting a use case's behavior at a specific point. Generalization is about specializing the behavior throughout the use case.

Within the UML metamodel, Generalization is a sub-class of Relationship.

Generalization is represented as an arrow with white filled head from the specialized use case or actor to the generalized use case or actor (see Figure 17.1, “Possible artifacts on a use case diagram.”).

17.8.1. Generalization Details Tabs

The details tabs that are active for associations are as follows.

ToDoItem

Standard tab.

Properties

See Section 17.8.2, “Generalization Property Toolbar” and Section 17.8.3, “Property Fields For Generalization” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Presentation

Standard tab

[Note]Note

The values for the bounds of the generalization are downlighted, since they have no meaning, given that the generalization is tied to a particular actor and use case.

Source

Standard tab. You would not expect to generate any code for a generalization end so this is empty.

Tagged Values

Standard tab. In the UML metamodel, Generalization has the following standard tagged values defined.

  • derived (from the superclass, ModelElement). Values true, meaning the generalization is redundant???it can be formally derived from other elements, or false meaning it cannot.

    [Note]Note

    Derived generalizations still have their value in analysis to introduce useful names or concepts, and in design to avoid re-computation.

17.8.2. Generalization Property Toolbar

Go up

Navigate up through the package structure of the model. For a generalization this will be the package containing the generalization.

New Stereotype

This creates a new Stereotype (see Section 16.5, “Stereotype”) for the selected generalization, navigating immediately to the properties tab for that generalization.

Delete

This deletes the selected generalization from the model.

[Warning]Warning

This is a deletion from the model not just the diagram. To delete a generalization from the diagram, but keep it within the model, use the main menu Remove From Diagram (or press the Delete key).

17.8.3. Property Fields For Generalization

Name

Text box. The name of the generalization.

[Tip]Tip

It is quite common to leave generalizations unnamed in use case analysis.

[Note]Note

ArgoUML does not enforce any naming convention for associations.

[Note]Note

There is no representation of the name of a generalization on the diagram.

Stereotype

Drop down selector. Generalization is provided by default with the UML standard stereotype implementation. The stereotype is shown between ?? and ?? above or across the generalization.

[Tip]Tip

Stereotyping generalization does not have great value on a use case diagram. The standard stereotype is about implementation, and suited to the use of generalization on class diagrams.

Navigate Stereotype

icon. If a stereotype has been selected, this will navigate to the stereotype property panel (see Section 16.5, “Stereotype”).

Discriminator

Text box. The name of a discriminator for the specialization. UML 1.3 allows grouping of specializations into a number of sets, on the basis of this value.

[Tip]Tip

The empty string “” is a valid entry (and the default) for this field. The discriminator is only of practical use in cases of multiple inheritance. A (class diagram) example is shown in Figure 17.2, “Example use of a discriminator with generalization”. Here each type of user should inherit from two sorts of user. One distinguishing between local or remote user (which can be identified by one discriminator) and one indicating their function as a user (identified by a different discriminator).

There is little point in using this within a use case diagram.

Namespace

Text box. Records the namespace for the generalization. This is the package hierarchy.

Parent

Text box. Shows the use case or actor that is the parent in this relationship, i.e. the more general end of the relationship. Button 1 Double Click on this entry will navigate to that use case or actor. Button 2 click will give a pop up menu, with a single entry, Open which will also navigate to that use case or actor.

Child

Text box. Shows the use case or actor that is the child in this relationship, i.e. the more specific end of the relationship. Button 1 Double Click on this entry will navigate to that use case or actor. Button 2 click will give a pop up menu, with a single entry, Open which will also navigate to that use case or actor.

Powertype

Drop down selector providing access to all standard UML types provided by ArgoUML and all new classes created within the current model.

This is the type of the child entity of the generalization.

[Tip]Tip

This can be ignored for use case analysis. The only sensible value to put in would be the child use case type (as a classifier, this appears in the drop down list.

Figure 17.2. Example use of a discriminator with generalization

Example use of a discriminator with generalization


17.9. Extend

Extend is a relationship between two use cases. Where A extends B, it means A describes more specific behavior and B the general version of that behavior.

In many respects extend is like generalization. However the key difference is that the extended use case defines extension points (see Section 17.4, “Extension Point”), which are the only places where its behavior may be extended. The extending use case must define at which of these extension points it adds behavior.

This makes the use of extend more tightly controlled than general extension, and it is thus preferred wherever possible.

Examples for a travel agent sales system might be the use case for paying for a ticket, which has an extension point in the specification of the payment. Extending use cases may then extend at this point to pay by cash, credit card etc.

Within the UML metamodel, Extend is a sub-class of Relationship.

An extend relationship is represented as a dotted link with an open arrow head and a label ??extend??. If a condition is defined, it is shown under the ??extend?? label (see Figure 17.1, “Possible artifacts on a use case diagram.”).

17.9.1. Extend Details Tabs

The details tabs that are active for extend relationships are as follows.

[Note]Note

There is no source tab, since there is no source code that could be generated for an extend relationship.

ToDoItem

Standard tab.

Properties

See Section 17.9.2, “Extend Property Toolbar” and Section 17.9.3, “Property Fields For Extend” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Presentation

Standard tab

[Note]Note

The values for the bounds are downlighted, since the extend is tied to a particular pair of use cases.

Source

Standard tab. You would not expect to generate any code for an extend relationship so this is empty.

Tagged Values

Standard tab. In the UML metamodel, Extend has the following standard tagged values defined.

  • derived (from the superclass, ModelElement). Values true, meaning the extend relationship is redundant???it can be formally derived from other elements, or false meaning it cannot.

    [Note]Note

    Derived extend relationships could have their value in analysis to introduce useful names or concepts.

17.9.2. Extend Property Toolbar

Go up

Navigate up through the package structure of the model. For a extend this will be the package containing the extend.

New extension point

This creates a new use case extension point within the namespace of the current extend relationship, with the current extend relationship as its first extending relationship.

[Tip]Tip

While it is perfectly valid to create extension points from an extend relationship, the created extension point will have no associated use case (it can subsequently be set up).

It would be more usual to instead create the extension point within a use case and subsequently link to it from an extend relationship (see Section 17.9.3, “Property Fields For Extend” below).

New Stereotype

This creates a new Stereotype (see Section 16.5, “Stereotype”) for the selected extent relationship, navigating immediately to the properties tab for that stereotype.

Delete

This deletes the selected extend relationship from the model.

[Warning]Warning

This is a deletion from the model not just the diagram. To delete a extend from the diagram, but keep it within the model, use the main menu Remove From Diagram (or press the Delete key).

17.9.3. Property Fields For Extend

Name

Text box. The name of the extend relationship.

[Tip]Tip

It is quite common to leave extends unnamed in use case analysis.

[Note]Note

ArgoUML does not enforce any naming convention for extend relationships.

Stereotype

Drop down selector. ArgoUML does not provide any stereotypes by default.

[Tip]Tip

Stereotyping does not have great value on an extend relationship.

[Note]Note

There is no representation of the stereotype of an extend relationship on the diagram.

Navigate Stereotype

icon. If a stereotype has been selected, this will navigate to the stereotype property panel (see Section 16.5, “Stereotype”).

Namespace

Text box. Records the namespace for the extend relationship. This is the package hierarchy.

Button 1 Double Click on the entry will navigate to the package defining this namespace (or the model for the top level namespace).

Base Use Case

Drop down selector. Shows the use case that is being extended by this extend relationship. Button 1 click on this entry will give a drop down menu of all available use cases (and an empty entry) which may be selected by button 1 click.

Extension

Drop down selector. Show the use case that is doing the extending through this extend relationship. Button 1 click on this entry will give a drop down menu of all available use cases (and an empty entry) which may be selected by button 1 click.

Extension Points

Text box. If this use case is, or can be extended, this field lists the extension points for the use case.

[Note]Note

Extension points are listed by their location point rather than their name.

Where an extension point has been created, button 1 double click will navigate to that relationship. Button 2 gives a pop up menu with two entries.

  • Add. The “Ad/Remove ExtensionPoints” window opens. In this window it is possible to build a list of extension points.

  • New. Add a new extension point in the list and navigate to it. The current extend relationship is added as the first in list of extending relationships of the new extension point.

Condition

Text area. Multi-line textual description of any condition attached to the extend relationship.

17.10. Include

Include is a relationship between two use cases. Where A includes B, it means B described behavior that is to be included in the description of the behavior of A at some point (defined internally by A).

Examples for a travel agent sales system might be the use case for booking travel, which includes use cases for booking flights and taking payment.

Within the UML metamodel, Include is a sub-class of Relationship.

An include relationship is represented as a dotted link with an open arrow head and a label ??include?? (see Figure 17.1, “Possible artifacts on a use case diagram.”).

17.10.1. Include Details Tabs

The details tabs that are active for include relationships are as follows.

[Note]Note

There is no source tab, since there is no source code that could be generated for an include relationship.

ToDoItem

Standard tab.

Properties

See Section 17.10.2, “Include Property Toolbar” and Section 17.10.3, “Property Fields For Include” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Presentation

Standard tab

[Note]Note

The values for the bounds of the include relationships are downlighted, since the include relationship is represented by a line between a particular pair of use cases.

Tagged Values

Standard tab. In the UML metamodel, Include has the following standard tagged values defined.

  • derived (from the superclass, ModelElement). Values true, meaning the include relationship is redundant???it can be formally derived from other elements, or false meaning it cannot.

    [Note]Note

    Derived include relationships could have their value in analysis to introduce useful names or concepts.

17.10.2. Include Property Toolbar

Go up

Navigate up through the package structure of the model. For a include this will be the package containing the include.

New Stereotype

This creates a new Stereotype (see Section 16.5, “Stereotype”) for the selected include relationship, navigating immediately to the properties tab for that stereotype.

Delete

This deletes the selected include relationship from the model.

[Warning]Warning

This is a deletion from the model not just the diagram. To delete a include from the diagram, but keep it within the model, use the main menu Remove From Diagram (or press the Delete key).

17.10.3. Property Fields For Include

Name

Text box. The name of the include relationship.

[Tip]Tip

It is quite common to leave include relationships unnamed in use case analysis.

[Note]Note

ArgoUML does not enforce any naming convention for include relationships.

Stereotype

Drop down selector. ArgoUML does not provide any stereotypes for include relationships.

[Tip]Tip

Stereotyping does not have great value on an include relationship.

[Note]Note

There is no representation of the stereotype of an include relationship on the diagram.

Navigate Stereotype

icon. If a stereotype has been selected, this will navigate to the stereotype property panel (see Section 16.5, “Stereotype”).

Namespace

Text box. Records the namespace for the include. This is the package hierarchy.

Button 1 click on the entry will navigate to the package defining this namespace (or the model for the top level namespace).

Base Use Case

Drop down selector. Records the use case that is doing the including in this include relationship. Button 1 click on this entry will give a drop down menu of all available use cases which may be selected by button 1 click.

Included Use Case

Drop down selector. Records the use case that is being included by this include relationship. Button 1 click on this entry will give a drop down menu of all available use cases (and an empty entry) which may be selected by button 1 click.

Chapter 18. Class Diagram Artifact Reference

18.1. Introduction

This chapter describes each artifact that can be created within a class diagram. Note that some sub-artifacts of artifacts on the diagram may not actually themselves appear on the diagram.

Class diagrams are used for only one of the UML static structure diagrams, the class diagram itself. Object diagrams are represented on the ArgoUML deployment diagram.

In addition, ArgoUML uses the class diagram to show model structure through the use of packages.

There is a close relationship between this material and the Properties Tab of the Details Pane (see Section 13.3, “Properties Tab”). That section covers Properties in general, in this chapter they are linked to specific artifacts.

Figure 18.1, “Possible artifacts on a class diagram.” shows a class diagram with all possible artifacts displayed.

Figure 18.1. Possible artifacts on a class diagram.

Possible artifacts on a class diagram.


Figure 18.2, “Possible artifacts on a package diagram.” shows a package diagram with all possible artifacts displayed.

Figure 18.2. Possible artifacts on a package diagram.

Possible artifacts on a package diagram.


18.1.1. Limitations Concerning Class Diagrams in ArgoUML

The current implementation does not allow datatypes to be shown on class diagrams.

A variant of the class diagram within the UML standard is the object diagram. There is currently no support for objects or links within ArgoUML Class diagrams;. Instead the ArgoUML deployment diagram does have both objects and links, and can be used to draw object diagrams.

18.2. Package

The package is the main organizational artifact within ArgoUML. In the UML metamodel it is a sub-class of both Namespace and GeneralizableElement.

[Note]Note

ArgoUML also implements the UML Model artifact as a sub-class of package, but not the Subsystem artifact.

ArgoUML also implements some less common aspects of UML model management. In particular the relationship UML 1.4 defines as Generalization and the sub-class dependency Permission for use between packages.

18.2.1. Package Details Tabs

The details tabs that are active for packages are as follows.

ToDoItem

Standard tab.

Properties

See Section 18.2.2, “Package Property Toolbar” and Section 18.2.3, “Property Fields For Package” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Presentation

Standard tab. The Bounds: field defines the bounding box for the package on the diagram.

Source

Standard tab. This contains a template package declaration appropriate to the entire package. In the future this would be part of the code generation activity.

Tagged Values

Standard tab. In the UML metamodel, Package has the following standard tagged values defined.

  • derived (from the superclass, ModelElement). Values true, meaning the package is redundant???it can be formally derived from other elements, or false meaning it cannot.

    [Note]Note

    Derived packages still have their value in analysis to introduce useful names or concepts, and in design to avoid re-computation.

18.2.2. Package Property Toolbar

Go up

Navigate up through the package structure.

New Package

This creates a new package within the package (which appears on no diagram), navigating immediately to the properties tab for that package.

New Datatype

This creates a new Datatype (see Section 16.3, “Datatype”) for the selected package, navigating immediately to the properties tab for that datatype.

New Stereotype

This creates a new Stereotype (see Section 16.5, “Stereotype”) for the selected package, navigating immediately to the properties tab for that stereotype.

Delete Package

Deletes the package from the model.

[Warning]Warning

This is a deletion from the model not just the diagram. To delete a package from the diagram, but keep it within the model, use the main menu Remove From Diagram (or press the Delete key).

18.2.3. Property Fields For Package

Name

Text box. The name of the package. The name of a package, like all packages, is by convention all lower case, not containing any periods.

[Note]Note

By default a new package has no name defined. The package will appear with the name (anon Package) in the explorer.

Stereotype

Drop down selector. Package is provided by default with the UML standard stereotypes for package ( facade, framework, metamodel, stub, topLevel, systemModel).

Navigate Stereotype

icon. If a stereotype has been selected, this will navigate to the stereotype property panel (see Section 18.4, “Stereotype”).

Namespace

Drop down selector. Records the namespace for the package. This is the package hierarchy.

Visibility

Radio box, with four entries public, private, protected, and package. Indicates whether the package is visible outside the package.

Modifiers

Check box, with entries abstract, leaf and root.

  • Abstract is used to declare that this package cannot be instantiated, but must always be specialized.

    [Tip]Tip

    The meaning of abstract applied to a package if not that clear. It might mean that the package contains interfaces or abstract classes without realizations. This is probably better handled through stereotyping of the package (for example ??facade??).

  • Leaf indicates that this package can have no further subpackages.

  • Root indicates that it is the top level package.

    [Tip]Tip

    Within ArgoUML Root only meaningfully applies to the Model, since all packages sit within the model. This could be used to emphasize that the Model is at the top level.

Generalizations

Text area. Lists any package that generalizes this package.

Button 1 double click navigates to the generalization and opens its property tab.

Specializations

Text box. Lists any specialized package (i.e. for which this package is a generalization.

button 1 double click navigates to the generalization and opens its property tab.

Owned Elements

Text area. A listing of all the packages, classes, interfaces, datatypes, actors, use cases, associations, generalizations and stereotypes within the package.

Button 1 double click on any item listed here navigates to that artifact.

18.3. Datatype

Datatypes are not specific to packages or class diagrams, and are discussed within the chapter on top level artifacts (see Section 16.3, “Datatype”).

18.4. Stereotype

Stereotypes are not specific to packages or class diagrams, and are discussed within the chapter on top level artifacts (see Section 16.5, “Stereotype”).

18.5. Class

The class is the dominant artifact on a class diagram. In the UML metamodel it is a sub-class of Classifier and GeneralizableElement.

A class is represented on a class diagram as a rectangle with three horizontal compartments. The top compartment displays the class name (and stereotype), the second compartment any attributes and the third any operations. The last two compartments may optionally be hidden.

18.5.1. Class Details Tabs

The details tabs that are active for classes are as follows.

ToDoItem

Standard tab.

Properties

See Section 18.5.2, “Class Property Toolbar” and Section 18.5.3, “Property Fields For Class” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Presentation

Standard tab. The tick boxes, Attributes and Operations allow the attributes and operations compartments to be shown (the default) or hidden. This is a setting valid for only the current diagram that shows the class. The Bounds: field defines the bounding box for the package on the diagram.

Source

Standard tab. This contains a template for the class declaration and declarations of associated classes.

Constraints

Standard tab. There are no standard constraints defined for Class within the UML metamodel.

Tagged Values

Standard tab. In the UML metamodel, Class has the following standard tagged values defined.

  • persistence (from the superclass, Classifier). Values transitory, indicating state is destroyed when an instance is destroyed or persistent, marking state is preserved when an instance is destroyed.

  • semantics (from the superclass, Classifier). The value is a specification of the semantics of the class.

  • derived (from the superclass, ModelElement). Values true, meaning the class is redundant???it can be formally derived from other elements, or false meaning it cannot.

    [Note]Note

    Derived classes still have their value in analysis to introduce useful names or concepts, and in design to avoid re-computation.

[Note]Note

The UML Element metaclass from which all other artifacts are derived includes the tagged element documentation which is handled by the documentation tab under ArgoUML

Checklist

Standard tab for a Classifier.

18.5.2. Class Property Toolbar

Go up

Navigate up through the package structure.

New attribute

This creates a new attribute (see Section 18.6, “Attribute”) within the class, navigating immediately to the properties tab for that attribute.

New operation

This creates a new operation (see Section 18.7, “Operation”) within the class, navigating immediately to the properties tab for that operation.

New reception

This creates a new reception, navigating immediately to the properties tab for that reception.

New inner class

This creates a new inner class (which appears on no diagram) within the class. This belongs to the class and is restricted to the namespace of the class. It exactly models the Java concept of inner class. As an inner class it needs no attributes or operations, since it shares those of its owner.

[Note]Note

Inner class is not a separate concept in UML. This is a convenient shorthand for creating a class that is restricted to the namespace of its owning class.

New class

This creates a new class (which appears on no diagram) within the same namespace as the current class.

New Stereotype

This creates a new Stereotype (see Section 16.5, “Stereotype”) for the selected class, navigating immediately to the properties tab for that stereotype.

Delete

This deletes the class from the model

[Warning]Warning

This is a deletion from the model not just the diagram. To delete a class from the diagram, but keep it within the model, use the main menu Remove From Diagram (or press the Delete key).

18.5.3. Property Fields For Class

Name

Text box. The name of the class. The name of a class has a leading capital letter, with words separated by “bumpy caps”.

[Note]Note

The ArgoUML critics will complain about class names that do not have an initial capital.

Stereotype

Drop down selector. Class is provided by default with the UML standard stereotypes for Class (implementationClass and type) and for Classifier (metaclass, powertype, process, thread and utility).

[Tip]Tip

One stereotype that is not part of the UML standard, but is widely used is Singleton, used to distinguish classes which have a single static instance, and no public constructor. Although not part of ArgoUML by default, this stereotype is understood by the critics. You may find it useful to create this stereotype for yourself (see Section 16.5, “Stereotype”).

Navigate Stereotype

icon. If a stereotype has been selected, this will navigate to the stereotype property panel (see Section 18.4, “Stereotype”).

Namespace

Drop down selector. Records and allows setting of the namespace for the class. This is the package hierarchy.

Button 1 click on the entry will move the class to the selected namespace.

Modifiers

Check box, with entries Abstract, Leaf, Root, and Active.

  • Abstract is used to declare that this class cannot be instantiated, but must always be subclassed. The name of an abstract class is displayed in italics on the diagram.

    [Caution]Caution

    If a class has any abstract operations, then it should be declared abstract. ArgoUML will not enforce this.

  • Leaf indicates that this class cannot be further subclassed, while Root indicates it can have no superclass. It is possible for a class to be both Abstract and Leaf, since its static operations may still be referenced.

  • Active indicates that this class exhibits dynamic behavior (and is thus associated with a state or activity diagram).

Visibility

Radio box, with four entries public, private, protected, and package. Indicates whether the class is visible outside the namespace.

Client Dependencies

Text area. Lists the “depending” ends of the relationship, i.e. the end that makes use of the other end.

Button 1 double click navigates to the dependency and opens its property tab.

Supplier Dependencies

Text area. Lists the “supplying” ends of the relationship, i.e. the end supplying what is needed by the other end.

Button 1 double click navigates to the dependency and opens its property tab.

Generalizations

Text area. Lists any class that generalizes this class.

Button 1 double click navigates to the generalization and opens its property tab.

Specializations

Text box. Lists any specialized class (i.e. for which this class is a generalization).

Button 1 double click navigates to the generalization and opens its property tab.

Attributes

Text area. Lists all the attributes (see Section 18.6, “Attribute”) defined for this class. Button 1 double click navigates to the selected attribute. Button 2 gives a pop up menu with two entries, which allow reordering the attributes.

  • Move Up. Only available where there are two or more attributes listed, and the attribute selected is not at the top. It moves the attribute up one position.

  • Move Down. Only available where there are two or more attributes listed, and the attribute selected is not at the bottom. It moves the attribute down one position.

Association Ends

Text box. Lists any association ends (see Section 18.11, “Association”) of associations connected to this class.

Button 1 double click navigates to the selected entry.

Operations

Text area. Lists all the operations (see Section 18.7, “Operation”) defined on this class. Button 1 click navigates to the selected operation. Button 2 gives a pop up menu with two entries, which allow reordering the operations.

  • Move Up. Only available where there are two or more operations listed, and the operation selected is not at the top. It moves the operation up one position.

  • Move Down. Only available where there are two or more operations listed, and the operation selected is not at the bottom. It moves the operation down one position.

Owned Elements

Text area. A listing of artifacts contained within the classes' namespace. This is where any inner class (see Section 18.5.2, “Class Property Toolbar”) will appear

Button 1 double click on any of the artifacts navigates to that artifact.

[Tip]Tip

Most namespace hierarchies should be managed through the package mechanism. Namespace hierarchies through classes are best restricted to inner classes. Conceivable datatypes, signals and interfaces could also appear here, but actors and use cases would seem of no value.

18.6. Attribute

Attribute is a named slot within a class (or other Classifier) describing a range of values that may be held by instances of the class. In the UML metamodel it is a sub-class of StructuralFeature which is itself a sub-class of Feature.

An attribute is represented in the diagram on a single line within the attribute compartment of the class. Its syntax is as follows:

visibility attributeName : type [= initialValue]

visibility is +, #, - or ~ corresponding to public, protected, private, or package visibility respectively.

attributeName is the actual name of the attribute being declared.

type is the type (UML datatype, class or interface) declared for the attribute.

initialValue is any initial value to be given to the attribute when an instance of the class is created. This may be overridden by any constructor operation.

In addition any attribute declared static will have its whole entry underlined on the diagram.

18.6.1. Attribute Details Tabs

The details tabs that are active for attributes are as follows.

ToDoItem

Standard tab.

Properties

See Section 18.6.2, “Attribute Property Toolbar” and Section 18.6.3, “Property Fields For Attribute” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Source

Standard tab. This contains a declaration for the attribute.

Constraints

Standard tab. There are no standard constraints defined for Attribute within the UML metamodel.

Tagged Values

Standard tab. In the UML metamodel, Attribute has the following standard tagged values defined.

  • transient.

  • volatile. This is an ArgoUML extension to the UML 1.4 standard to indicate that this attribute is realized in some volatile form (for example it will be a memory mapped control register).

[Note]Note

The UML Element metaclass from which all other artifacts are derived includes the tagged element documentation which is handled by the documentation tab under ArgoUML

Checklist

Standard tab for a Attribute.

18.6.2. Attribute Property Toolbar

Go up

Navigate up through the package structure.

New attribute

This creates a new attribute within the owning class of the current attribute, navigating immediately to the properties tab for that attribute.

[Tip]Tip

This is a very convenient way to add a number of attributes, one after the other, to a class.

New Datatype

This creates a new Datatype (see Section 16.3, “Datatype”) for the selected attribute, navigating immediately to the properties tab for that datatype.

New Stereotype

This creates a new Stereotype (see Section 16.5, “Stereotype”) for the selected attribute, navigating immediately to the properties tab for that stereotype.

Delete

This deletes the attribute from the model

[Warning]Warning

This is a deletion from the model not just the diagram. If desired the whole attribute compartment can be hidden on the diagram using the style tab (see Section 18.6.2, “Attribute Property Toolbar”) or the button 2 pop up menu for the class on the diagram.

18.6.3. Property Fields For Attribute

Name

Text box. The name of the attribute. The name of a attribute has a leading lower case letter, with words separated by “bumpy caps”.

[Note]Note

The ArgoUML critics will complain about attribute names that do not have an initial lower case letter.

Stereotype

Drop down selector. There are no UML standard stereotypes for Attribute.

Navigate Stereotype

icon. If a stereotype has been selected, this will navigate to the stereotype property panel (see Section 16.5, “Stereotype”).

Owner

Text box. Records the class which contains this attribute.

Button 1 double click on the entry will navigate to the class.

Multiplicity

Editable drop down selector. The default value (1) is that there is one instance of this attribute for each instance of the class, i.e. it is a scalar. The drop down provides a number of commonly used specifications for non-scalar attributes.

[Note]Note

ArgoUML presents a number of predefined ranges for multiplicity for easy access. The user may also enter any user defined range that follows the UML syntax, such as “1..3,7,10”.

The value 1..1 is equivalent to the default (exactly one scalar instance). The selection 0..1 indicates an optional scalar attribute.

Type

Drop down selector. The type of this attribute. This can be any UML Classifier, although in practice only Class, DataType, or Interface make any sense.

[Note]Note

A type must be declared (it can be void). By default ArgoUML supplies int as the type.

Navigate Type

icon. This will navigate to the property panel for the currently selected type. (see Section 18.5, “Class”, Section 18.3, “Datatype” and Section 18.15, “Interface”).

Initial Value

Text box with drop down. This allows you to set an initial value for the attribute if desired (this is optional). The drop down menu provides access to the common values 0, 1, 2, and null.

[Caution]Caution

Any constructor operation may ignore this initial value.

Visibility

Radio box, with entries public, private, protected and package.

  • public. The attribute is available to any artifact that can see the owning class.

  • private. The attribute is available only to the owning class (and any inner classes).

  • protected. The attribute is available only to the owning class, or artifacts that are subclasses of the owning class.

  • package. The attribute is available only to artifacts contained in the same package.

Changeability

Radio box, with entries addOnly, changeable, and frozen.

  • addOnly. Meaningful only if the multiplicity is not fixed to a single value. Additional values may be added to the set of values, but once created a value may not be removed or altered.

  • changeable. There are no restrictions of modification.

  • frozen. Also named “immutable”. The value of the attribute may not change during the lifetime of the owner class. The value must be set at object creation, and may never change after that. This implies that there is usually an argument for this value in a constructor and that there is no operation that updates this value.

Static

Check box for static. If unchecked (the defaults) then the attribute has “instance scope”. If checked, then the attribute is static, i.e. it has “class scope”. Static attributes are indicated on the diagram by underlining.

18.7. Operation

An operation is a service that can be requested from an object to effect behavior. In the UML metamodel it is a sub-class of BehavioralFeature which is itself a sub-class of Feature.

In the diagram, an operation is represented on a single line within the operation compartment of the class. Its syntax is as follows:

visibility name (parameter list) : return-type-expression {property-string}

You can edit this line directly in the diagram, by double-clicking on it. All elements are optional and, if left unspecified, the old values will be preserved.

A stereotype can be given between any two elements in the line in the format: <<stereotype>>.

The following properties are recognized to have special meaning: abstract, concurrency, concurrent, guarded, leaf, query, root and sequential.

The visibility is +, #, - or ~ corresponding to public, protected, private visibility, or package visibility respectively.

static and final optionally appear if the operation has those modifiers. Any operation declared static will have its whole entry underlined on the diagram.

There may be zero or more entries in the parameter list separated by commas. Every entry is a pair of the form:

name : type

The return-type-expression is the type (UML datatype, class or interface) of the result returned.

Finally the whole entry is shown in italics if the operation is declared abstract.

18.7.1. Operation Details Tabs

The details tabs that are active for operations are as follows.

ToDoItem

Standard tab.

Properties

See Section 18.7.2, “Operation Property Toolbar” and Section 18.7.3, “Property Fields For Operation” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Presentation

Standard tab. The Bounds: field does allow editing, but the changes have no effect.

Source

Standard tab. This contains a declaration for the operation.

Constraints

Standard tab. There are no standard constraints defined for Operation within the UML metamodel.

Tagged Values

Standard tab. In the UML metamodel, Operation has the following standard tagged values defined.

  • semantics. The value is a specification of the semantics of the operation.

  • derived (from the superclass, ModelElement). Values true, meaning the operation is redundant???it can be formally derived from other elements, or false meaning it cannot.

    [Note]Note

    Derived operations still have their value in analysis to introduce useful names or concepts, and in design to avoid re-computation.

[Note]Note

The UML Element metaclass from which all other artifacts are derived includes the tagged element documentation which is handled by the documentation tab under ArgoUML

Checklist

Standard tab for an Operation.

18.7.2. Operation Property Toolbar

Go up

Navigate up through the package structure.

New operation

This creates a new operation within the owning class of the current operation, navigating immediately to the properties tab for that operation.

[Tip]Tip

This is a very convenient way to add a number of operations, one after the other, to a class.

New parameter

This creates a new parameter for the operation, navigating immediately to the properties tab for that parameter.

New raised signal

This creates a new raised signal for the operation, navigating immediately to the properties tab for that raised signal.

New Datatype

This creates a new Datatype (see Section 16.3, “Datatype”) in the namespace of the owner of the operation, navigating immediately to the properties tab for that datatype.

New Stereotype

This creates a new Stereotype (see Section 16.5, “Stereotype”) for the selected operation, navigating immediately to the properties tab for that stereotype.

Delete

This deletes the operation from the model

[Warning]Warning

This is a deletion from the model not just the diagram. If desired the whole operation compartment can be hidden on the diagram using the presentation tab (see Section 18.7.2, “Operation Property Toolbar”) or the button 2 pop up menu for the class on the diagram.

18.7.3. Property Fields For Operation

Name

Text box. The name of the operation. The name of an operation has a leading lower case letter, with words separated by “bumpy caps”.

[Note]Note

The ArgoUML critics will complain about operation names that do not have an initial lower case letter.

[Tip]Tip

If you wish to follow the Java convention of constructors having the same name as the class, you will violate this rule. Silence the critic by setting the stereotype create for the constructor operation.

Stereotype

Drop down selector. There are two UML standard stereotypes for Operation (from the parent metaclass, BehavioralFeature), create and destroy.

[Tip]Tip

You should use create as the stereotype for constructors, and destroy for destructors (which are called “finalize” methods under Java).

Navigate Stereotype

icon. If a stereotype has been selected, clicking button 1 will navigate to the stereotype property panel (see Section 18.4, “Stereotype”).

Owner

Text box. Records the class which contains this operation.

Button 1 double click on the entry will navigate to the class.

Visibility

Radio box, with entries public, private, protected and package.

  • public. The operation is available to any artifact that can see the owning class.

  • private. The operation is available only to the owning class (and any inner classes).

  • protected. The operation is available only to the owning class, or artifacts that are subclasses of the owning class.

  • package. The operation is available only artifacts contained in the same package.

Modifiers

Check box, with entries abstract, leaf, root, query, and static.

  • abstract. This operation has no implementation with this class. The implementation must be provided by a subclass.

    [Important]Important

    Any class with an abstract operation must itself be declared abstract.

  • leaf. The implementation of this operation must not be overridden by any subclass.

  • root. The declaration of this operation must not override a declaration of the operation from a superclass.

  • query. This indicates that the operation must have no side effects (i.e. it must not change the state of the system). It can only return a value.

    [Caution]Caution

    Operations for user defined datatypes must always check this modifier.

  • static. There is only one instance of this operation associated with the class (as opposed to one for each instance of the class). This is the OwnerScope attribute of a Feature metaclass within UML. Any operation declared static is shown underlined on the class diagram.

Concurrency

Radio box, with entries guarded, sequential, and concurrent.

  • guarded. Multiple calls from concurrent threads may occur simultaneously to one instance (on any guarded operation), but only one is allowed to commence. The others are blocked until the performance of the first operation is complete.

    [Caution]Caution

    It is up to the system designer to ensure that deadlock cannot occur. It is the responsibility of the operation to implement the blocking behavior (as opposed to the system).

  • sequential. Only one call to an instance (of the class with the operation) may be outstanding at any one time. There is no protection, and no guarantee of behavior if the system violates this rule.

  • concurrent. Multiple calls to one instance may execute at the same time. The operation is responsible for ensuring correct behavior. This must be managed even if there are other sequential or synchronized (guarded) operations executing at the time.

Parameter

Text area, with entries for all the parameters of the operation (see Section 18.8, “Parameter”). A new operation is always created with one new parameter, return to define the return type of the operation.

Button 1 double click on any of the parameters navigates to that parameter. Button 2 click brings up a pop up menu with two entries.

  • Move Up. Only available where there are two or more parameters, and the parameter selected is not at the top. It is moved up one position.

  • Move Down. Only available where there are two or more parameters listed, and the parameter selected is not at the bottom. It is moved down one position.

Raised Signals

Text area, with entries for all the signals (see Section 18.9, “Signal”) that can be raised by the operation.

[Caution]Caution

ArgoUML at present (V0.18) has limited support for signals. In particular they are not linked to signal events that could drive state machines.

Button 1 double click on any of the signals navigates to that parameter.

18.8. Parameter

A parameter is a variable that can be passed. In the UML metamodel it is a sub-class of ModelElement.

A parameter is represented within the operation declaration in the operation compartment of a class as follows.

name : type

name is the name of the parameter.

type is the type (UML datatype, class or interface) of the parameter.

The exception is any parameter representing a return value, whose type only is shown at the end of the operation declaration.

18.8.1. Parameter Details Tabs

The details tabs that are active for parameters are as follows.

ToDoItem

Standard tab.

Properties

See Section 18.8.2, “Parameter Property Toolbar” and Section 18.8.3, “Property Fields For Parameter” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Source

Standard tab. This contains a declaration for the parameter.

Tagged Values

Standard tab. In the UML metamodel, Parameter has the following standard tagged values defined.

  • derived (from the superclass, ModelElement). Values true, meaning the parameter is redundant???it can be formally derived from other elements, or false meaning it cannot.

    [Caution]Caution

    A derived parameter is a meaningless concept.

[Note]Note

The UML Element metaclass from which all other artifacts are derived includes the tagged element documentation which is handled by the documentation tab under ArgoUML

18.8.2. Parameter Property Toolbar

Go up

Navigate up through the package structure.

New parameter

This creates a new parameter for the for the same operation as the current parameter, navigating immediately to the properties tab for that parameter.

[Tip]Tip

This is a convenient way to add a series of parameters for the same operation.

New Datatype

This creates a new Datatype (see Section 16.3, “Datatype”) in the namespace of the owner of the operation of the parameter, navigating immediately to the properties tab for that datatype.

New Stereotype

This creates a new Stereotype (see Section 16.5, “Stereotype”) for the selected parameter, navigating immediately to the properties tab for that stereotype.

Delete

This deletes the parameter from the model

[Warning]Warning

This is a deletion from the model not just the diagram. If desired the whole operation compartment can be hidden on the diagram using the presentation tab or the button 2 pop up menu for the class on the diagram.

18.8.3. Property Fields For Parameter

Name

Text box. The name of the parameter. By convention, the name of a parameter has a leading lower case letter, with words separated by “bumpy caps”.

[Note]Note

The ArgoUML critics do not complain about parameter names that do not have an initial lower case letter.

Stereotype

Drop down selector. There are no UML standard stereotypes for Parameter.

Navigate Stereotype

icon. If a stereotype has been selected, this will navigate to the stereotype property panel (see Section 16.5, “Stereotype”).

Owner

Text box. Records the operation which contains this parameter.

Button 1 double click on the entry will navigate to the operation.

Type

Drop down selector. The type of this parameter. This can be any UML Classifier, although in practice only Class, DataType, or Interface make any sense.

[Note]Note

A type must be declared (it can be void, but this only makes sense for a return parameter). By default ArgoUML supplies int as the type the first time a parameter is created, and thereafter the type of the most recently created parameter.

Default Value

Text box with drop down. This allows you to set an initial value for the parameter if desired (this is optional). The drop down menu provides access to the common values 0, 1, 2, and null.

[Caution]Caution

This only makes sense for out or return parameters.

Kind

Radio box, with entries out, in/out, return, and in.

  • out. The parameter is used only to pass values back from the operation.

  • in/out. The parameter is used both to pass values in and to pass results back out of the operation.

    [Note]Note

    This is the default for any new parameter.

  • return. The parameter is a return result from the call.

    [Note]Note

    There is nothing to stop you declaring more than one return parameter (some programming languages support this concept).

    [Tip]Tip

    The name of the return parameter does not appear on the diagram, but it is convenient to give it an appropriate name (such as the default return to identify it in the list of parameters on the operation property tab.

  • in. The parameter is used only to pass values in to the operation.

18.9. Signal

A signal is a specification of an asynchronous stimulus communicated between instances. In the UML metamodel it is a sub-class of Classifier.

Within ArgoUML signals are not fully handled. Their value is when they are received as signal events driving the asynchronous behavior of state machines and when associated with send actions in state machines and messages for collaboration diagrams.

[Tip]Tip

In general there is limited value at present in defining signals within ArgoUML. It may prove more useful to define signals as classes, with a (user defined) stereotype of ??signal?? as suggested in the UML 1.4 standard. This allows any dependency relationships between signals to be shown.

18.9.1. Signal Details Tabs

The details tabs that are active for signals are as follows.

ToDoItem

Standard tab.

Properties

See Section 18.9.2, “Signal Property Toolbar” and Section 18.9.3, “Property Fields For Signal” below.

Documentation

Standard tab. See Section 13.4, “Documentation Tab”.

Source

Standard tab. There is nothing generated for a signal.

Tagged Values

Standard tab. In the UML metamodel, Signal has the following standard tagged values defined.

  • persistence (from the superclass, Classifier). Values transitory, indicating state is destroyed when an instance is destroyed or persistent, marking state is preserved when an instance is destroyed.

  • semantics (from the superclass, Classifier). The value is a specification of the semantics of the signal.

  • derived (from the superclass, ModelElement). Values true, meaning the signal is redundant???it can be formally derived from other elements, or false meaning it cannot.

    [Note]Note

    Derived signals still have their value in analysis to introduce useful names or concepts, and in design to avoid re-computation.

[Note]Note

The UML Element metaclass from which all other artifacts are derived includes the tagged element documentation which is handled by the documentation tab under ArgoUML

18.9.2. Signal Property Toolbar

Go up

Navigate up through the package structure.

New signal

This creates a new signal, navigating immediately to the properties tab for that signal.

[Caution]Caution

The signal is not associated with the same operation as the original signal, so this will have to be done afterwards.

New Stereotype

This creates a new Stereotype (see Section 16.5, “Stereotype”) for the selected signal, navigating immediately to the properties tab for that stereotype.

Delete

This deletes the signal from the model

[Warning]Warning

This is a deletion from the model.

18.9.3. Property Fields For Signal

Name

Text box. The name of the signal. From their similarity to classes, by convention, the name of a signal has a leading upper case letter, with words separated by “bumpy caps”.

[Note]Note

The ArgoUML critics do not complain about signal names that do not have an initial upper case letter.

Stereotype

Drop down selector. Signal is provided by default with the UML standard stereotypes for its parent in the UML meta-model, Classifier ( metaclass, powerType, process, thread, and utility).

Navigate Stereotype

icon. If a stereotype has been selected, this will navigate to the stereotype property panel (see Section 16.5, “Stereotype”).

Namespace

Drop down selector. Records and allows changing the namespace for the signal. This is the package hierarchy of the signal.

Contexts

Text area. Lists all the contexts defined for this signal. Button 1 double click navigates to the selected context, button 2 click brings up a pop up menu with one entry.

  • Add. Add a new context. This opens the Add/Remove Contexts dialog box (see figure below), which allows choosing between all possible operations, and adding them to the selected list.

    Figure 18.3. The “add/remove context” dialog box

    The add/remove context dialog box


18.10. Reception (to be written)

A reception is ...

18.11. Association

An association on a class diagram represents a relationship between classes, or between a class and an interface. On a usecase diagram, an association binds an actor to a usecase.

Within the UML metamodel,