1. ECLIPSE and UML Onur Demir odemir@cse.yeditepe.edu.tr

2. An extremely useful tool for application development
ECLIPSE

3. Eclipse Provide open platform for application development tools
Run on a wide range of operating systems
GUI and non-GUI
Language-neutral
Permit unrestricted content types
HTML, Java, C, JSP, EJB, XML, GIF, …
Facilitate seamless tool integration
At UI and deeper
Add new tools to existing installed products
Attract community of tool developers
Including independent software vendors (ISVs)
Capitalize on popularity of Java for writing tools

4. Eclipse Platform Platform Runtime Eclipse Project Another Tool
Java
Development
Tools
(JDT)
Workbench
Help
JFace
SWT
Team
Your
Tool
Plug-in
Development
Environment
(PDE)
Workspace
Debug
Platform Runtime
Their
Tool
Eclipse Project

5. What is Eclipse?
Eclipse is a universal platform for integrating development tools
Open, extensible architecture based on plug-ins
PDE
Plug-in development environment
Java development tools
JDT
Platform
Eclipse Platform
Java VM
Standard Java2 Virtual Machine

6. Eclipse Plug-ins Plug-in - smallest unit of Eclipse function
Big example: HTML editor
Small example: Action to create zip files
Extension point - named entity for collecting “contributions”
Example: extension point for workbench preference UI
Extension - a contribution
Example: specific HTML editor preferences

7. Eclipse Plug-ins Each plug-in
Contributes to 1 or more extension points
Optionally declares new extension points
Depends on a set of other plug-ins
Contains Java code libraries and other files
May export Java-based APIs
Lives in its own plug-in subdirectory
Details spelled out in the plug-in manifest
Manifest declares contributions
Code implements contributions and provides API
plugin.xml file in root of plug-in subdirectory

8. Plug-in Manifest plugin.xml Plug-in identification
<plugin id = “com.example.tool"
name = “Example Plug-in Tool"
class = "com.example.tool.ToolPlugin">
<requires>
<import plugin = "org.eclipse.core.resources"/>
<import plugin = "org.eclipse.ui"/>
</requires>
<runtime>
<library name = “tool.jar"/>
</runtime>
<extension point = "org.eclipse.ui.preferencepages">
<page id = "com.example.tool.preferences"
icon = "icons/knob.gif"
title = “Tool Knobs"
class = "com.example.tool.ToolPreferenceWizard“/>
</extension> <extension-point name = “Frob Providers“ id = "com.example.tool.frobProvider"/>
</plugin>
Plug-in identification
Other plug-ins needed
Location of plug-in’s code
Declare contribution this plug-in makes
Declare new extension point open to contributions from other plug-ins

9. Eclipse Plug-in Architecture
Typical arrangement
plug-in A
plug-in B
extension point P
contributes
extension
implements
interface I
class C
Plug-in A
Declares extension point P
Declares interface I to go with P
Plug-in B
Implements interface I with its own class C
Contributes class C to extension point P
Plug-in A instantiates C and calls its I methods
creates, calls

10. Eclipse Runtime Eclipse Platform Runtime is micro-kernel
All functionality supplied by plug-ins
Eclipse Platform Runtime handles start up
Discovers plug-ins installed on disk
Matches up extensions with extension points
Builds global plug-in registry
Caches registry on disk for next time

11. Plug-in Activation Each plug-in gets its own Java class loader
Delegates to required plug-ins
Restricts class visibility to exported APIs
Contributions processed without plug-in activation
Example: Menu constructed from manifest info for contributed items
Plug-ins are activated only as needed
Example: Plug-in activated only when user selects its menu item
Scalable for large base of installed plug-ins
Helps avoid long start up times

12. Plug-in Fragments Plug-in fragments holds some of plug-in’s files
Separately installable
Each fragment has separate subdirectory
Separate manifest file
Logical plug-in = Base plug-in + fragments
Plug-in fragments used for
Isolation of OS dependencies
Internalization – fragments hold translations

13. Plug-in Install Features group plug-ins into installable chunks
Feature manifest file
Plug-ins and features bear version identifiers
major . minor . service
Multiple versions may co-exist on disk
Features downloadable from web site
Using Eclipse Platform update manager
Obtain and install new plug-ins
Obtain and install updates to existing plug-ins

14. Plug-in Architecture - Summary
All functionality provided by plug-ins
Includes all aspects of Eclipse Platform itself
Communication via extension points
Contributing does not require plug-in activation
Packaged into separately installable features
Downloadable

15. Eclipse Platform Eclipse Platform is the common base
Consists of several key components
Platform Runtime
Eclipse Platform
“Core”
“UI”
Workbench
Team
Help
Debug
JFace
SWT
Workspace
Ant

16. Workspace Component Tools operate on files in user’s workspace
Workspace holds 1 or more top-level projects
Projects map to directories in file system
Tree of folders and files
{Files, Folders, Projects} termed resources
Tools read, create, modify, and delete resources in workspace
Plug-ins access via workspace and resource APIs

17. Workspace and Resource API
Allows fast navigation of workspace resource tree
Resource change listener for monitoring activity
Resource deltas describe batches of changes
Maintains limited history of changed/deleted files
Several kinds of extensible resource metadata
Persistent resource properties
Session resource properties
Markers
Project natures
Workspace session lifecycle
Workspace save, exit, restore
Incremental project builders

18. Workbench Terminology
Menu bar
Message
area
Editor
Status
Text
editor
Tool bar
Perspective
and
Fast View
bar
Properties
view
Tasks
Outline
Bookmarks
Resource
Navigator
view
Stacked
views

19. Editors Editors appear in workbench editor area
Contribute actions to workbench menu and tool bars
Open, edit, save, close lifecycle
Open editors are stacked
Extension point for contributing new types of editors
Example: JDT provides Java source file editor
Eclipse Platform includes simple text file editor
Windows only: embed any OLE document as editor
Extensive text editor API and framework

20. Views Views provide information on some object Views augment editors
Example: Outline view summarizes content
Views augment other views
Example: Properties view describes selection
Extension point for new types of views
Eclipse Platform includes many standard views
Resource Navigator, Outline, Properties, Tasks, Bookmarks, Search, …
View API and framework
Views can be implemented with JFace viewers

21. Perspectives Perspectives are arrangements of views and editors
Different perspectives suited for different user tasks
Users can quickly switch between perspectives
Task orientation limits visible views, actions
Scales to large numbers of installed tools
Perspectives control
View visibility
View and editor layout
Action visibility
Extension point for new perspectives
Eclipse Platform includes standard perspectives
Resource, Debug, …
Perspective API

22. Workbench Responsibilities
Eclipse Platform manages windows and perspectives
Eclipse Platform creates menu and tool bars
Labels and icons listed in plug-in manifest
Contributing plug-ins not activated
Eclipse Platform creates views and editors
Instantiated only as needed
Scalable to large numbers of installed tools

23. Team Component Version and configuration management (VCM)
Share resources with team via a repository
Repository associated at project level
Extension point for new types of repositories
Repository provider API and framework
Eclipse Platform includes CVS repository provider
Available repository providers*
ChangeMan (Serena) - AllFusion Harvest (CA)
ClearCase (Rational) - Perforce
CM Synergy (Telelogic) - Source Integrity (MKS)
PVCS (Merant) - TeamCode (Interwoven)
Microsoft Visual Source Safe

24. Debug Component Launch configurations Generic debug model
How to run a program (debug mode option)
Generic debug model
Standard debug events: suspended, exit, …
Standard debug actions: resume, terminate, step, …
Breakpoints
Expressions
Source code locator
Generic debug UI
Debug perspective
Debug views: stack frames, breakpoints, …
Example: JDT supplies Java launcher and debugger
Java debugger based on JPDA
Debug mechanisms available to other plug-ins

25. Ant Component Eclipse incorporates Apache Ant
Ant is Java-based build tool
“Kind of like Make…without Make's wrinkles”
XML-based build files instead of makefiles
Available from workbench External Tools menu
Run Ant targets in build files inside or outside workspace
PDE uses Ant for building deployed form of plug-in

26. Help Component Help books are HTML webs
Extension points for contributing
entire books
sections to existing books
F1-help pop ups
Eclipse Platform contributes
“Workbench User Guide”
“Platform Plug-in Developer Guide” (APIs)
F1-help for views, editors, dialogs, …
JDT and PDE contribute their own help
Help mechanisms available to all plug-ins

27. Eclipse Platform - Summary
Eclipse Platform is the nucleus of IDE products
Plug-ins, extension points, extensions
Open, extensible architecture
Workspace, projects, files, folders
Common place to organize & store development artifacts
Workbench, editors, views, perspectives
Common user presentation and UI paradigm
Key building blocks and facilities
Help, team support, internationalization, …

28. Java Development Tools
JDT = Java development tools
State of the art Java development environment
Built atop Eclipse Platform
Implemented as Eclipse plug-ins
Using Eclipse Platform APIs and extension points
Included in Eclipse Project releases

29. JDT Goals
Goal: To be #1 Java IDE
Goal: To make Java programmers smile

30. Java Perspective Java-centric view of files in Java projects
Java elements meaningful for Java programmers
Java project
package
class
field
method
Java editor

31. Java Perspective Browse type hierarchies “Up” hierarchy to supertypes
“Down” hierarchy to subtypes
Type hierarchy
Selected type’s members

32. Java Perspective Search for Java elements Declarations or references
Including libraries and other projects
Hits flagged in margin of editor
All search results

33. Java Editor Hovering over identifier shows Javadoc spec
[Contains animated elements]

34. Java Editor Method completion in Java editor List of plausible methods
Doc for method
[Contains animated elements]

35. Java Editor On-the-fly spell check catches errors early Click to see
Quick fixes
Preview
Click
to see
fixes
[Contains animated elements]
Syntax and spell checking are done on-the-fly.
Calls Java compiler to parse source code and resolve names in context.
Developers refer to those wavy red lines as “the red sea” :-).
Problem markers are appear in the left margin of editor.
“Red X” instead of “light bulb” if no proposed corrections.
Problem

36. Java Editor Code templates help with drudgery Statement template
Preview
[Contains animated elements]

37. Java Editor Java editor creates stub methods
Method stub insertion for anonymous inner types
[Contains animated elements]
Method stub insertion for inherited methods

38. Java Editor Java editor helps programmers write good Java code
Variable name suggestion
JavaDoc code assist
[Contains animated elements]
Argument hints and proposed argument names

39. Java Editor Other features of Java editor include Local method history
Code formatter
Source code for binary libraries
Built-in refactoring

40. Refactoring
JDT has actions for refactoring Java code

41. Refactoring Refactoring actions rewrite source code
Within a single Java source file
Across multiple interrelated Java source files
Refactoring actions preserve program semantics
Does not alter what program does
Just affects the way it does it
Encourages exploratory programming
Encourages higher code quality
Makes it easier to rewrite poor code

42. Refactoring Full preview of all ensuing code changes
Programmer can veto individual changes
List of changes
Screen shot shows Extract Method applied to the print statement in HelloWorld.main method.
“before” vs. “after”

43. Refactoring Growing catalog of refactoring actions Organize imports
Rename {field, method, class, package}
Move {field, method, class}
Extract {method, local variable, interface}
Inline {method, local variable}
Reorder method parameters
Push members down

44. Eclipse Java Compiler Eclipse Java compiler
JCK-compliant Java compiler (selectable 1.3 and 1.4)
Helpful error messages
Generates runnable code even in presence of errors
Fully-automatic incremental recompilation
High performance
Scales to large projects
Multiple other uses besides the obvious
Syntax and spell checking
Analyze structure inside Java source file
Name resolution
Content assist
Refactoring
Searches
Scales to large projects, like Eclipse itself.

45. Eclipse Java Debugger Run or debug Java programs Local variables
Threads and stack frames
Editor with breakpoint marks
Console I/O

46. Eclipse Java Debugger Run Java programs Debug Java programs
In separate target JVM (user selectable)
Console provides stdout, stdin, stderr
Scrapbook pages for executing Java code snippets
Debug Java programs
Full source code debugging
Any JPDA-compliant JVM
Debugger features include
Method and exception breakpoints
Conditional breakpoints
Watchpoints
Step over, into, return; run to line
Inspect and modify fields and local variables
Evaluate snippets in context of method
Hot swap (if target JVM supports)

47. JDT APIs JDT APIs export functionality to other plug-ins Java model
Java-centric analog of workspace
Tree of Java elements (down to individual methods)
Java element deltas
Type hierarchies
Model accurate independent of builds
Building blocks
Java scanner
Java class file reader
Java abstract syntax trees (down to expressions)
Many others…

48. Eclipse Java programmmers
Eclipse JDT - Summary
JDT is a state of the art Java IDE
Java views, editor, refactoring
Helps programmer write and maintain Java code
Java compiler
Takes care of translating Java sources to binaries
Java debugger
Allows programmer to get inside the running program
Eclipse Java programmmers

49. Plug-in Development Environment
PDE = Plug-in development environment
Specialized tools for developing Eclipse plug-ins
Built atop Eclipse Platform and JDT
Implemented as Eclipse plug-ins
Using Eclipse Platform and JDT APIs and extension points
Included in Eclipse Project releases
Separately installable feature
Part of Eclipse SDK drops

50. PDE Goals Goal: To make it easier to develop Eclipse plug-ins
Goal: Support self-hosted Eclipse development

51. PDE
PDE templates for creating simple plug-in projects

52. PDE
Specialized PDE editor for plug-in manifest files

53. PDE PDE runs and debugs another Eclipse workbench
1. Workbench running PDE (host)
2. Run-time workbench (target)

54. PDE is basis for self-hosted Eclipse development
PDE - Summary
PDE makes it easier to develop Eclipse plug-ins
PDE also generates Ant build scripts
Compile and create deployed form of plug-in
PDE is basis for self-hosted Eclipse development

55. Installing Eclipse What do you need ? A suitable platform
Windows, Linux, Solaris, QNX, AIX, HP-UX, and Mac OS X.
Sufficient disk space. 300 MB should be enough.
Sufficient RAM. 256 MB should be fine.
Java SDK
Eclipse SDK for your platform.
You may need the Eclipse example files (eclipse-examples-3.0) for your platform.

56. Eclipse – Running it for the First Time
Eclipse prompts you with the Workspace Launcher. Here you can select the location of the Eclipse workspace.

57. Welcome Screen Overview section : Tutorials section Samples section
you will find relevant chapters from the various user guides in the Eclipse help system.
Tutorials section
you can learn how to create a simple Java program, a simple SWT application, and an Eclipse plug-in.
you can learn how to create and deploy an Eclipse feature.
Samples section
contains ready-to-run example programs.
What’s New section
you will find a compilation of the new features contained in Eclipse 3 and also a migration guide for converting the Eclipse 2 application into Eclipse 3
You can return at any time to this screen by invoking the function Help > Welcome.

58. Eclipse Help Command-line options: Chosing Java Virtual Machine (JVM):
Help > Help Contents. Then select Workbench User Guide, expand the Tasks item, and choose Running Eclipse
Chosing Java Virtual Machine (JVM):
Can be done by using option –vm
-vmargs can be used to specify parameters
eclipse.exe -vm C:\java13\bin\javaw -vmargs -Xmx256M
Here Eclipse is started with a specific JVM and sets the JVM heap to 256 MB. With very large projects this can help to prevent instabilities of the workbench.

59. Perspectives
Consist of a combination of windows and tools best suited for specific tasks.
Perspectives are added to the Eclipse workbench by various Eclipse plug-ins.
To start developing Java programs, you therefore must first open the Java perspective using the Open Perspective icon.

60. Create your first Java program
Select from the menu
File -> New-> Java project.
Type a project name.
Select "Create separate source and output folders".

61. Create package
A good convention is to use the same name for the top package as the project.
Select the folder src, right mouse click on it and select New -> Package.

62. Create Java class
Right click on your package and select New -> Class

63. Create Java class
Create MyFirstClass, select the flag "public static void main (String[] args)"

64. Run
Now run your code. Right click on your Java class and select Run-as-> Java application

65. Output
You can see the output of your application in the console

66. Creating jar file
Select your project then select Export

67. Creating jar file Select JAR file, select next.
Select your project and maintain the export destination and a name for the jar file.

68. Run your program outside Eclipse
Open a command shell, switch to your output directory
To run this program you need to include the jar file into your classpath.

69. Content assist
Ctrl+space brings up Content Advisor

70. Eclipse Shortcuts - Navigation
DESCRIPTION
CTRL + SHIFT + R
Open / Search for resources, e.g. files
CTRL + SHIFT + T
Open / Search for Types
CTRL + T
Used on a method in an interface shows all implementing methods
STRG + O
In place outline view (displayed in editor), allows to search directly for elements in the selected file via type-ahead
ALT + LEFT ARROW KEY or ALT + RIGHT ARROW KEY
Go to prev/ next editor position in history
CTRL + Mouse-click on a variable
Go to declaration of this variable
CTRL + SHIFT + P
Go to matching bracket

71. Eclipse Shortcuts - Search
DESCRIPTION
Ctrl + .
Go to previous / next problem
F3 on a variable
Go to Declaration of this variable
F4 on a variable
Show type hierarchy
Ctrl+ J , Strg +k
Incremental search, find next
STRG + SHIFT + G
Search for reference in the workspace

72. Eclipse Shortcuts - Run
DESCRIPTION
Ctrl F11
Run last launched
Alt + Shift + X - J
Run as Java applicatio

73. Eclipse Shortcuts- Editing
DESCRIPTION
CTRL + 1
Quickfix, dependend on cursor position
F12
Focuses the editor (especially helpful if you working with Fast Views
Ctrl + M
Maximize Java editor
CTRL + Shift + F
Format source code
CTRL + Shift + O
Organize the imports / Will import the missing imports.
CTRL + Shift + S
Source generation related operations such as creating getter/setter
CTRL + Q
Last edited position

74. UML –Unified Modeling Language
Why we need UML?
We need models to discuss and describe object-oriented software, as well as the problems and business processes the software serves
What does it do?
Supports all aspects of the software development life cycle from requirements gathering to design to deployment
Very useful for documenting the object structure underlying an application, known as the domain model
UML models can represent
use cases
class structures
program interactions
process flows
physical deployments
packages, and more.

75. A Brief History Modeling Languages are around since 70s
There was no consensus over a vocabulary
Booch, Rumbaugh and Jacobson merged their own modeling languages in to one around mid-90s
In 1997 UML 1.0 was submitted to OMG(Object Management Group)
Modeling languages for object-oriented software have been around since the 1970s and began to proliferate in the late 1980s. The profusion of modeling options caused problems, and no single approach managed to reach critical mass. Thus, while many approaches were helpful in the design process itself, no common vocabulary emerged. The debates between the practitioners of different modeling systems are sometimes referred to as the "method wars," which brings to mind some fairly amusing images of the goings-on at academic conferences in the late 1980s and early 90s.
The UML specification developed out of the method wars. Grady Booch, James Rumbaugh, and Ivar Jacobson emerged as the leading lights in the modeling movement. Booch's approach was design-oriented, while Rumbaugh's Object Modeling Technique was geared toward data analysis. Jacobson created the Object Oriented Software Engineering (OOSE) method, which focused on developing "use cases" to feed system design. Jacobsen is known as the Father of Use Cases.
In 1994, Rumbaugh joined Booch at Rational Software, and introduced Version .8 of UML in October. A year later Jacobson arrived at Rational, and the three focused on merging their different, yet largely complementary approaches into a single model. Booch, Jacobson, and Rumbaugh became known as the Three Amigos. The Software Development Life Cycle (SDLC) they developed at Rational is known as the Rational Unified Process, but the modeling language associated with it can be applied in any number of frameworks.
In 1996, in response to a request for standards proposals from the Object Management Group, Rational formed the UML Partners Consortium to gather support for the standard. UML 1.0 was submitted to the OMG in January 1997 as a suggested specification.
The consortium followed up with the UML 1.1 proposal, and in November 1997, the UML specification was accepted as a standard. Subsequent iterations have brought the UML to Version 1.4, and a substantially improved version, 2.0, is currently in the advanced preparatory stages. The rest of this chapter focuses on key elements of UML 1.4.

76. UML and Software Development Lifecycles
UML provides several diagram types that fit into each section of the Software Development Lifecycle (SDLC)
We will focus on the following diagrams:
Use Case Diagrams
Class Diagrams
Interaction Diagrams
Activity Diagrams
Deployment Diagrams
The typical software development process consists of several phases: requirements-gathering, high-level design, low-level design, coding and unit testing, integration testing, and deployment. Different methodologies divide these areas into different categories and subdivisions.
UML provides several diagram types that fit into each section of the Software Development Lifecycle (SDLC). Here's an overview of the diagram types we address in this chapter, in roughly the order they enter the development process:
Use case diagrams Used through the high-level design phase to identify common sets of activities that users of the system indulge in. Use case diagrams also describe the participants in each use case. Use cases are helpful when developing test plans.
Class diagrams Used as early as the high-level design process to define the domain model for the application: specifically, the relationship of data objects within the system, the relationships between them, and the operations that they can perform or that can be performed on them.
Interaction diagrams Sometimes used during the requirements gathering process but particularly used in high- and low-level design to show the interactions between objects in the system. Interaction diagrams are also very helpful in the testing state when creating testing processes and procedures.
Activity diagrams Used during requirements gathering and high-level design to further identify process flows within the system. Unlike program flow charts, activity diagrams include users and activities beyond the code itself, and allow clear delineation of the roles played by various participants.
Deployment diagrams Used during the high-level design phase to indicate how a system will be distributed across physical resources, and during the deployment phase to document that configuration.
The rest of this chapter explores the diagram types in more detail.

77. Use Case Diagrams
A use case diagram is the highest level of abstraction available in UML.
Use cases are collections of related activities that work toward a particular goal.
They're part of the requirements gathering process rather than the design process itself, and can be as detailed or as generic as is necessary to communicate system requirements.
A use case diagram is the highest level of abstraction available in UML. Use cases are collections of related activities that work toward a particular goal. They're part of the requirements gathering process rather than the design process itself, and can be as detailed or as generic as is necessary to communicate system requirements.
The challenge here is often to make the requirements accessible and useful to both the design team and the domain experts involved in the project. Depending on need, the size of the team and the preferences of those leading the development a project might have two or three use cases, or dozens, or even more, although there is generally a point at which the sheer volume of use cases grows unmanageable.
A "Buy Groceries" use case, for example, could consist of selecting food, checking out, processing a credit card, and bagging groceries. The use case can also incorporate internal variations, such as a declined credit card.
Use cases incorporate multiple actors, which may be humans or systems. The actors in the Buy Groceries use case could be the shopper, the checkout person, the grocery bagger, the inventory system, and the credit processor.
Like any UML diagram, use cases exist to convey information. A use case diagram can be a valuable communication tool, and the process of creating the use cases themselves almost invariably leads to better software and greater accountability. In addition to ensuring user needs are met, use cases help determine where a system is likely to need extension in the immediate future—information that can play a valuable part in the design process.
The ultimate consumer of the use case diagram is a human being; as a result, the diagram's goal is clarity, rather than precision. Some developers don't like using use case diagrams at all, preferring text, and some mix-and-match according to the needs of the current project. Use case diagrams at a high level are often used to quickly communicate the scope of a more detailed and nuanced textual discussion. In fact, UML use case diagrams alone are almost, but not quite, useless without the full textual use case sitting behind them.
In a diagram, a single use case is represented in the UML with an oval Detail is added by breaking each use case into a set of smaller use cases and adding them to the diagram. Actors are represented by stick figures. UML use case diagrams are not generally designed to demonstrate sequence. Activity diagrams, discussed later in this chapter, provide a more formalized mechanism for showing process, allowing use case diagrams to focus on goals.

78. Use Case Diagrams
A single use case is represented in the UML with an oval
Detail is added by breaking each use case into a set of smaller use cases and adding them to the diagram
Actors are represented by stick figures
UML use case diagrams are not generally designed to demonstrate sequence.

79. Use Case Diagrams
A simple use case
Create Account

80. Use Case Diagrams
The project is a corporate web portal that will serve employees, customers, and partners. The task at hand is use registration for each type of user. Employees are assumed to be able to register themselves. Customers can, too. Partners can register themselves and get basic access, but need to be checked against a partner list before they can be granted full access. If the partner isn't on the list, a manager needs to authorize partner-level access for the user. We'll use this example (or variations) throughout this chapter.
To begin, we divide the problem into four basic use cases: Request Account, Define Partners, Approve Account, and Create Account. A simple UML diagram, as in Figure 2-2, shows the three actors that interact with the use cases.