(7/14/05)Incorporate direct reference to VP-UML online tutorial?
{
Remove references to C++ after Sp'05 Sp'06.}
warning_.gif: 2/11/06; 3/29/06warning_.gif

COSC 390 LAB 1
INTRODUCTIONS TO JAVA DEVELOPMENT USING AN IDE

        This lab is intended to introduce students to a Java integrated development environment (IDE), specifically JBuilder Foundation Edition from Borland,  gain introductory experience developing Java applications.  (Your are familiar with applications; they are conceptually identical to C++ applications.  Since applications are essentially equivalent to their counterpart in C++, they will be largely ignored in this course; instead, we will focus on applets (which are introduced in Lab 2).  Therefore, the applications you develop in this lab will the only ones you do in COSC 390. )

OBJECTIVES:

  1. To acquire and become familiar with an IDE  for Java, JBuilder from Borland (the standard Java IDE to be used in our department).
  2. To learn what Java applications are and compare them to C++ applications.
  3. To begin learning how to document Java code using UML class diagrams to show the software architecture.  Specifically, in this "introduction" to the UML as a documentation tool, you will focus on
    1. how to illustrate the encapsulation and visibility of class members and
    2. how to illustrate the four fundamental relationships between classes (association, dependency, and inheritance) and interfaces (realization).  (In this lab you create only one class so only "built-in" classes will be related to it; however, in subsequent labs you will create multiple classes and then you will have to define the relationships between user-developed classes and interfaces as well.).
  4. To distinguish between applications and applets and the differences in their development processes {Moved to Lab 2.}
  5. To distinguish what a component is.
  6. To gain introductory experience developing a JavaBean.
ASSIGNMENT:
  1. If you do not have it, download and install the latest version of Borland's JBuilder Foundation Edition  It is available in specified FSU labs. and Tony has a CD which can be copied; however it is recommended that you order your own copy of the "JBuilder Foundation", a limited "demo" version, of JBuilder for $9.95.  (This is does not have any "limitations" as far as learning is is concerned; it is a super, fully-featured IDE with complete Help facilities.)  If you are on campus, the download does not take long; however, I would not attempt this using a modem because it is well over 100MB!
  2. Learn to use the Java IDE, JBuilder, by working through JBuilder's built-in Help facilities and tutorials. Record the times it takes you to do the tour and the application tutorial.  {We will be using Swing components; that's the reason for using a browser, such as Netscape 7, which supports them; we'll have to verify this!} You will use Swing in the Application tutorial of this lab.  (Note that "j" is the prefix used to distinguish such components, e.g. jbutton is a Swing component.
    1. Look through the "JBuilder Features" that pops up when you open JBuilder.
    2. Gain an overview of JBuilder by reading the "Tour" that appears in the right frame of welcome.html by clicking the  button.  There are several points worth noting:
      1. There are several links to more information.  You should check these out briefly, but do not get diverted from your objective of getting an overall view of JBuilder.  One sidetrack worth checking out more thorougly is the editor options; remember that you can customize this after you become familiar with it.
      2. Note that there are several facilities that we will (probably) not use in COSC 390.  You should be aware of them (so that you can pursue them on your own, after the course, if you want to continue your Java development skills) but don't clutter your mind with these advanced features.  They are:
        1. Enterprise JavaBeans (EJB) which are designed for large scale "enterprise" projects of team design.
        2. Servlets and Java Server Pages (JSP).  We will focus on client-side applets in this course.
        3. Team development facilites, and
        4. Database development facilities like JDataStore.
        5. Database Web applications,
        6. Developing applications using XML,
        7. Developing Services, and
        8. Developing mobile applications.
    3. Glance through the other documents ("Release Notes", "What's New", "Quick Tips", "Tutorials", and "Samples") whose links appear on welcome_first.html below the tour button.
    4. Familiarize yourself with the Help features accessed via the Help menu of JBuilder.  These should look familiar to most Windows users but browse through the links and, if necessary, read How to Use Help (under the Help menu on the JBuilder Help Viewer page).
    5. Read through the items of Getting Started "book" of the JBuilder Help; the link to this is under the content tab of the page accessed via Help | Help Topicswarning_.gifAgain, do not get diverted from this introduction by spending too much time on the links within these pages.  (Comments on the last two parts of this book, "Tutorial: Building an application" and "Tutorial: Building an applet", are presented in the following two items.)
    6. Work through  Jbuilder's Tutorial: Building an application of the Getting Started "book" of the JBuilder Help.
      1. You may want to print the tutorial, but it is rather long and I didn't find it necessary to have hardcopy.
      2. Note that most of this tutorial is similar to the applet tutorial you do next  (i.e. similar steps and identical dialog boxes in which subtle differences are entered) .
      3. It might help to refer to the equivalent exercise in the Java Tutorial; this version uses only the JDK and simple text editor instead of our IDE, JBuilder.
      4. Use the CodeInsight feature of JBuilder whenever this is suggested.  It gives you a good idea of all the members that can be used at the particular point in the code.  One of the problems in learning Java is "getting a handle on the incredible range of methods that are available in the Java development environment.
      5. Note that, in the source code, many of the attribute types begin with a capitol "J", e.g. JPanel, JMenuBar, JButton, etc.  This is because the tutorial uses a feature of Java called Swing or the Java Foundation Classes (JFC). ; older versions of Java use AWT (abstract window toolkit), whose classes do not have the preceeding "J".
      6. Manually modify your code to conform to the standards of this course:
        1. Edit the internal documentation, that JBuilder generates at the beginning of each class, so that it conforms to the MINIMUM SPECIFICATIONS FOR DOCUMENTATION for COSC390, given in Appendix A of this lab.
        2. Add //end <name> to all classes, interfaces, and methods (after the last "}").  (<name> should be replaced by the actual name of the class, interface, or method.) You should do this on all the sourse code produced in this class; I recommend that you do it on all sourse code you develop, in any language!  Not only does it help you, quickly, find the limits of code blocks, it makes it easier to resequence pages of hardcopy code that gets shuffled.
      7. Manually modify your code to conform to include the following items.
        1. Add comments to clearly indicate the following:
          1. the attributes of each class
          2. the methods of each class
  3. Draw the UML class diagram architecture for this application.  Include all the attributes and methods of HelloWorldClass, but only the methods of HelloWorldFrame and HelloWorldFrame_AboutBox.)   Note: the few classes utilized in this lab form a rare "minimal" architecture (Typical Java applications contains numerous classes/interfaces with complex architectures.), so you should try to construct a "complete" UML CD for this software architecture, i.e. one which has a UML class (not necessarily all its members) for ALL the "nearest neighbor classes", i.e. every class appearing in the code as well as the UML relationships linking these UML classes.  However, since JBuilder creates the IDE it uses many built-in Java classes, so even this simple application will be complex; therefore, you need not submit a complete UMLCD.  (For me to check your understanding you should include, in your UMLCD submission, the most significant relationships as well as AT LEAST ONE example of every relationship, i.e. association, dependency, inheritance, and realization; you need not worry about aggregation and composition (special cases of association) at this stage. The best way to start is to follow the guideline given in Appendix B of these lab instructions.  (Note that, in subsequent labs, you will need to be selective in what you include in your UMLCD, i.e. you will have decide what is most important in your UML documentation; that is the primary guideline for selecting which classes to include.)
    1. Ultimately you should publish, on your Web site, your UML class diagram as documentation of this lab, but if that is inconvenient, you can turn in a hand-drawn diagram to me (in a floder, please!) in order to recieve a grade and move on to subsequent labs.  This will allow me to assess your understanding of UML class diagrams as documentation tools (as opposed to a software development tool).  You should still publish an online UML graphic, but you can do that at your convenience.
    2. There are many ways of producing a Web accessable UML diagram, but they all result in a graphic file (GIF or JPEG; the newer PNG format apparently needs a plug-in for Netscape, so try to avoid them.).  You should use the VP-UML, specified in the syllabus, which will be the standard UMLCD tool for this course.  
      1. Note that you only use the class diagrams of VP-UML.
      2. You should work through the online tutorial for class diagrams of VP-UML.
        1. To access the online tutorials click Learning Center under the Tools menu.
        2. You will benefit by glancing through the Textual Analysis tutorial to see how VP-UML helps you identify candidate classes for a prototype architecutre from a text problem statement.  (However, this is irrelevant to the central theme of this part of the lab, learning how to represent class diagrams using the UML.)
        3. Work through the Class Diagram tutorial under the Tutorial section.  (Like most instructions/tutorials, this rather "long winded" because it takes a lot of words and pictures to explain rather simple techniques; therefore, you might want to skim this and learn how to create class diagram using a trial and error approach, referring only to the tutorial when you get stuck. On the other hand, the tutorial systematically "leads" you through all the things that can be done with VP-UML, so "skimming" through you can stop and read things that are not intuitive or interesting.  If you learn as you go, the "ad hoc" approach may cause you to miss useful facilities. )
        4. Follow the GUIDELINES FOR USING UMLCD TO DOCUMENT JAVA CODE in Appendix B to create your UML CD in this and all subsequent labs.  In particular, for this lab:
          1. Include every class generated by JBuilder, except the several "...ActionAdapter..." classes (they only crowd the illustration!); also give the relationships between them.
          2. Include all the "nearest neighbors" related by generalization and realization.
          3. Include at least one class related by association; note that there are numerous built-in classes that are associates of the classes generated by JBuilder.  There is no need to include them all (This only crowds the illustrative documentation!), simply indicate that you know how to draw all relationships in a UML CD.
  4. Analyze your application:
    1. Look at the contents of the directory where you created your HelloWorld project and note all the files that JBuilder automatically generates.
    2. Find the main() method and try to mentally follow the sequence of execution that occurs when this project is run.
    warning_.gifBe prepared to discuss these in class!
  5. Assignment:
    1. Copy the entire HelloWorld directory to a floppy disk.  (Check that it runs properly by running this copy.)
    2. Print out the source code of HelloWorldClass.java (your application), HelloWorldFrame.java (the user interface), and HelloWorldFrame_AboutBox.java (the documentation) and carefully analyze the Java by comparing it to C++.
    3. Submit the floppy, source code hardcopies, and a JPEG image of your VP-UML class diagram ( the "UML representation of your 'architecture'")  in a folder as specified in class.
    4. Add comments/suggestions that will improve this lab's learning experience, especially things that need to be changed with respect to the newest versin of JBuilder.  (If there is an urgent correction, place it on the class forum.)
SAQ: (a) What is the difference between "internal" and "external" documentation?  (b) What should constitute minimal external documentation for software?
APPENDIX A: MINIMUM SPECIFICATIONS FOR DOCUMENTATION
NOTE: Remember that an "acceptable" program must:
  1. include documentation (both internal and external); in order of priority, BE CLEAR, PRECISE, and CONCISE!
    1. Minimal external documentation is hardcopy (or a Web page for HTML/Applets) that includes (1) LAB NAME (e.g. "Lab 390-1", for this assignment), (2) FILENAME, (3) STUDENT NAME:, (4) LANGUAGE/VERSION: (e.g. LANGUAGE/VERSION: Java 2 with JBuilder 9.0), (5) DATE COMPLETED:, (6) DATE LAST MODIFIED:, (7) DESCRIPTION: (8) HOW TO EXECUTE: plus a printout of the code.
    2. Minimal internal documentation should include:
      1. "prolog documentation" (general documentation at the beginning of your source code).  JBuilder (and most IDEs) generate this for you, but if this does not include the eight items indicated for the minimal external documentation (in part A, above), add the missing items.  Prolog documentation should be a concise version of your external documentation that is permanently attached to your source code.  (External documentation can get seperated because it and the source code are in separate files; prolog documentation is part of your source code file.)
      2. Until further notice, document...
        1. the beginning of the attribute declarations,
        2. the beginning of the method declarations,
        3. the ends of all classes, and
        4. the ends of all "large" control structures, i.e. those not easily distinguished.
      3. comments on code that is not self explanatory. However, do not be excessive; be concise!
    3. For your own sake, 10 years from now, you should also specify the course and instructor for whom it was written, reasons for the assignment, concepts illustrated, ideas for improvement, modification, extensions, etc., and whatever else that will help you benefit from relooking at the program.
  2. be modular and self documenting (readable with meaningful module names),
  3. pass parameters (where reasonable) and use private and protected attributes (where appropriate) rather than global variables, and
  4. have error traps (Java Exceptions) where appropriate. You do not have to go through the tedium of making your source code "bullet proof", but you must demonstrate that you are aware of user misuse/abuse and have taken steps to prevent it!
  5. be explicit.  Do not use any defaults (only for the lazy!) in this course.
Programs that do not follow these guidelines will be returned as "UNACCEPTABLE"; they must then be resubmitted and will be consequently "late", and receive grade reductions and worst of all, probably miss the curve at the end of the course!

APPENDIX B: GUIDELINES FOR USING UMLCD TO DOCUMENT JAVA CODE

Note that this use of a UMLCD (UML class diagram) is for "documentation", only one of the four basic ways to use UMLCD*, albeit the most straightforward.  When documenting code using the UML, one starts with code and illustrates the semantics of that code by drawing an equivalent UMLCD.  (This is often called "reverse engineering".)  This is an important exercise to help you become familiar with UMLCD before we start using them to prototype software architectures in subsequent labs.  Drawing the UMLCD for documentation is very straightforward.  Hear are some guidelines:

  1. Identify all the different classes of your architecture.  This simply requires that you go through your code and circle every class name you find.  This really involves finding (and highlighting) every identifier declaration (class, interface, attribute, and method); superclasses and interfaces will be found in the first line of the class declaration; all other declarations will involve types of attributes or types of method elements (return type, argument types, and local variable types).
  2. Associate each class, found in your code, with a specific relationship; this is easily done by recognizing where, in the code, the class name appears.  If the class name appears (See hints and answers, below.)...
    1. in the class declaration line, the relationship is either _____________ or ____________(1).
    2. as an attribute type, the relationship is ____________, ______________, or _________(2).
    3. in a method definition (return type, argument type, or local variable type), the relationship is _____________(3).  (Note that the creation of new instances, within main or init operations, are examples of local variables.)
    Be sure to include (1) the visibility of ALL class members and (2) the navigability, multiplicity, and (if possible) distinguish the kinds of association.
  3. Normally you need only draw user defined classes and interfaces, i.e. ones you create or ones, created by others (but NOT including those in built-in class libraries).  However, often it is important to include critical built-in classes (e.g. those used from the Core Java Class Library).   In such cases you need only draw the "nearest neighbors", i.e. the built-in classes directly related to (appear in the code of) your application or applet; however, it is useful to also include all the classes in your inheritance hierarchy because they contain members which, because they are inherited, can be freely used in your local methods.
    1. To find the classes in your class's inheritance hierarchy, refer to our primary Java Reference, JavaTM 2 Platform, Standard Edition, v 1.3.1 API Specification. and look up the class from which you derive each of your classes.
  4. Sketch tentative draft software architectures by shuffling simple class/interface rectangles (rectangles with only class/interface names or abbreviations) until they form a "logical" arrangement and then drawing the proper UML relationship between each class and interface.  While learning the UML, it is wise to enclose all classes/interfaces in their package.
    1. Enclosing classes/interfaces in their package helps you organize your architecture efficiently, i.e. collecting associated classess/interfaces together and deciding where on the page they belong.
    2. Later, after you are competent with drawing UMLCD, you might want to include only packages (ignoring their constituent classes/interfaces) to simplify your architecture; this is especially useful if you are breaking up your complex architecture into several UML class architectures.
  5. Finally, once you decide on an optimum architectural diagram,  draw a final version, with complete class names, the most relevant members, as well as the essential relationships, and incorporate notes into your software architecture.  At this point you should use VP-UML, a public comain UML drawing tool to create you UMLCD.  (Note, however, that using a computer UML drawing tool, earlier, helps you think as well as create a correct, efficient UMLCD, i.e. selecting components and filling in properties in dialog boxes guide your thinking and creativity.)
*Actually, in this exercise, you are using the UML for more than "documentation"; you are also using it to "analyze" code, the fourth of the four basic ways to use UMLCD.  Actually you are "reverse engineering" (a fancy software development term) the Java code into a UMLCD.  If you had written all the code, then drawing the UMLCD would be only documentation, but when drawing UML classes for code you did not write and identifying semantic relationships between them you are, in fact, analyzing the code, and drawing the UML representing the software architecture helps you do this.

HINTS FOR FIB:
  1. See item 1 of Appendix B.
    1. Superclasses are identified by declaring ____________ on the first line of the class definition.  In Java this is accomplished by using the keyword ____________.
    2. Interfaces are identified by declaring ____________ on the first line of the class definition.    In Java this is accomplished by using the keyword ____________.
  2. See item 1 of Appendix B.  Declaring an attribute to have a type defined by a class is ____________ which has two special cases:
    1. _____________ which is has-a by reference.
    2. _____________ which is has-a by value.
  3. See item 1 of Appendix B.
    1. Anything declared to have a class as its type implements the UML relationship ___________.
ANSWERS FOR HINTS:
  1. ....
    1. inheritance; extends (Java can only inherit from one class; C++ has multiple inheritance.)
    2. interfaces; implements
  2. association
    1. aggregation
    2. composition
  3. dependency

ANSWERS FOR ORIGINAL FIB:
  1. inheritance or realization
  2. association, aggregation, or composition
  3. dependency