Title Object-Orientated Design and Programming Introduction

DescriptionKeywords UML, Object-oriented design and programming, Java

NetBeans, Use caseObjectivesAuthor Jin SaOrganisationVersion Version 1Date 6 June 2008Copyright

Object-Orientated Design and Programming IntroductionPlease ensure that you enter a name in the yellow box above that will be used as a banner title across the top of your web pages.The following Item is used by the Resource Converter, Please do not delete it.

The first page of your online resource should begin below this line

Module Overview

IntroductionFirstly, welcome to the course! In this section we provide an overview of the module. This covers the aims of the module, the learning outcomes, the approach to learning, assumed pre-requisite knowledge and finally concludes with some suggested reading.

Module GoalsThe purpose of this module is to give you a solid grounding in object-oriented concepts. Upon completion of this module if you were given a requirements document, you will be able to analyse the document and produce an object orientated design that could then be implemented in an object-oriented programming language. Object-Orientation like other design approaches is by no means perfect. During this course we will introduce you to some of its limitations and to methods to handle these shortcomings. In addition, you will be aware of the benefits of using both a UML modelling tool and an Integrated Development Environment (IDE) to develop and implement your design.

In summary, the module aims to help you to:

Gain an understanding of object-oriented concepts, to be able to analyse, design and implement systems in an object-oriented programming language.

Develop a critical awareness of the possibilities and limitations of the OO paradigm, its methods and tools.

Develop an understanding of the benefits and problems associated with software reuse.

Fully use a modelling tool to analyse and design an object-oriented system.

Fully use the facilities of a typical object-oriented programming language (e.g. Java) to implement and test an object-oriented design

Content

You can’t do object-oriented design without knowledge of the OO programming language, but... you can’t do object-oriented programming without knowledge of OO design, so... we must interleave the two! Therefore this course has been structured with these interdependencies in mind. The table below outlines the plan for course (each unit represents a week).

Unit Unit TitleUnit 1 Object-oriented design: introduction and use casesUnit 2 Object-oriented programming: getting started with Java Unit 3 Object-oriented design: objects and classes Unit 4 Object-oriented design: class relationshipUnit 5 Assignment element 1Unit 6 Object-oriented programming: objects and classesUnit 7 Object-oriented design: interaction modellingUnit 8 Object-oriented design and programming: inheritance and polymorphismUnit 9 Object-oriented design and programming: abstract classes and interfacesUnit 10 Assignment element 2 Unit 11 Object-oriented programming: graphic user interface (GUI)Unit 12 Object-oriented programming: event-driven programming

Review and some Java Certification style questionsSelf-directed study and examination

Prerequisite Knowledge

The assumed prerequisite knowledge of this course is relatively little. We assume some basic understanding of the software development lifecycle and the factors motivating the need for software design. From a programming perspective, we assume you have no experience with Java but do assume some experience with another programming language. Whether this language is objected-orientated or procedural in nature is not important.

Useful Reading

Throughout this course it is assumed that you will carry out your own independent research and reading. In this section we suggest some useful reading to accompany this process.

There are numerous books covering the subject of object orientated software design, programming and the Unified Modeling Language. For the design aspect of the course we recommend you purchase: “UML Distilled: A Brief Guide to the Standard Object Modeling Language (Object Technology S.)”. This book is written by Martin Fowler and Kendall Scott, the ISBN number is: 0321193687. We recommend that you purchase the edition that covers version 2.0 (or above) of the UML specification. If you own an alternative book covering UML and software design we recommend you check with your tutor regarding the suitability of the book before purchasing “UML Distilled”.

For Java, most of the materials will be based on “Introduction to Java Programming – Comprehensive version, 6/e” by Daniel Liang. At the time of

writing (May 2008), edition 7/e is due out soon. The book has a very comprehensive accompanying website which contains a lot of useful information, including a large database of multiple choices questions. There are two versions by Liang on introduction to Java programming: the “comprehensive version” and the “fundamental first version”. The “fundamental version” includes all the topics we cover in this module. However there is very little difference in terms of the costs between the two versions. If you are purchasing a copy, it is worth getting the comprehensive version which may become useful in the future. There are also many other Java books available. “Java Software Solution” by Lewis and Loftus is a popular Java book. The authors explain the concepts very clearly and easy to understand, but I do not like the way that the GUI part is presented in the Lewis and Loftus book. If you have got a copy of an alternative book on Java, you may not need to buy the recommended book.

In addition to text books there are some excellent resources available online.

Unit Aims

In this unit we will introduce the concept of object orientated software design. We will also introduce a set of standards or notation, known as the Unified Modelling Language (UML). Finally, we will provide an approach for developing use case diagrams from textual requirements descriptions.

Object-orientation

Introduction

What is object-orientated design? In this section we aim to answer this question. First we will discuss some important aspects of software design – applicable to all design approaches. Then we will move on to define the concept of an object and demonstrate how objects can work together to achieve an overall goal. We provide a brief overview of the roles of object-orientated models before discussing the object-orientated lifecycle.

Design is art!

Before we start discussing software design it is important to note the following four points:

There are many ways to achieve the same end result. Design is opinionated. Design is subject to fashion! Don’t take everything you read as gospel.

In reality there are often multiple approaches that can be taken to satisfy customer requirements. This is not to say that all approaches are correct; some will clearly be better than others. In short, do not work under the illusion that there is only ever a single solution for one set of requirements. As such, it is important that you consider alternative approaches and methods and are able to justify your design decisions to your colleagues and peers. Even if your design meets all the requirements if you are not able to justify why your approach is better than an alternative then your colleagues and employers will lose faith and will not be convinced your design is the best approach. This brings us to the next point, design is opinionated. Although software designers typically agree on most core design decisions there are aspects of design that designers will never agree on! For example, it may be the level of detail to include in a diagram or the type

of relationships among a group of related classes. This point also relates to the next; design is subject to fashion. Although there are many well established tried-and-tested design patterns, new ones are proposed and developed all the time. The quality and benefits of the new design patterns will vary. Established designers may champion a particular pattern or approach to only later drop it favouring another technique. Finally there is much literature discussing object-orientation and the quality and accuracy of this literature will vary. Whilst researching you will need to critique literature and consider the merits of the points it raises. In short, don’t take everything you read as gospel!

What is an Object?

In simple terms an object knows something – its data, and it knows how to do something – its functions. For example, a Bank account object may know the balance of the account and provide functions to add or withdraw funds. We refer to the functions that an object can perform as its “behaviour”. In object-orientated programming languages object behaviour is implemented in the form of methods. In the OO world we have a habit of using multiple terms to describe essentially the same things. Therefore when introducing terms we will also mention some alternatives you may hear. Multiple terms are often used interchangeably when describing methods, these are: procedures and functions. C programmers will tend to use the term functions whilst Pascal programmers will use the term procedures.

In object-orientated programming, the knowledge an object has is referred to as an objects attributes.

Key Point: An object comprises of two parts, its behaviour and its attributes.

Objects make up Systems

The functionality of an Object-Oriented system is delivered by objects collaborating to get the job done. Collaboration takes the form of objects sending messages to each other to request services. Collaboration between objects requires a distinct, time-ordered sequence of messages passed between objects.

The example below shows a stereotypical internet shopping scenario. The virtual shopping basket is the holder for items that the buyer intends to purchase. The buyer adds items to the shopping basket as they browse the web site. When the buyer decides they wish to proceed to purchase the goods, they first require the total price of the purchase. The shopping system sends a message to the Shopping Basket object, requesting the total price of goods in the basket. In order to satisfy this request, the Shopping Basket object requests, object by object in turn, each object in the Basket for its cost. The Shopping Basket object totals each cost, and returns the total value of to the shopping system.

Object Orientated Lifecycle - SimplifiedIn the diagram below we provide a simplified view of the object-orientated lifecycle. For a more detailed explanation please see the course text, UML Distilled.

Use cases capture the system functionality. They are derived from the specifications and business models produced by business analysts and other parties with a detailed knowledge of how the business operates. Use cases bridge the gap between the required system functionality (requirements documentation) and the logical design that will satisfy these requirements. The logical design will comprise of class models, interaction models and state/activity models. All of these will be discussed in more detail as the course progresses. But for the time being, think of these models as blueprints for the structure of a system.

Using these “logical” models we can create a physical implementation using a platform and language of our choice. The logical design should not reflect the properties of a specific language such as Java or particular properties of a system such as UNIX; instead it should provide a generic design that can be implemented using any object-orientated language on any platform.

The key point in this section is the separation between logical designs and physical implementations.

Student activity 1.1 Section SummaryLearning Objective: This exercise will ensure that you’re familiar with the basic building block of object-orientation – the object.

Before moving on consider the following self-test questions.

Q1. Define the term object.Q2. Why do objects need to work together?

Unified Modelling Language (UML)

Introduction

“The Unified Modelling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artefacts of a software-intensive system.” [UML Specification 2.0]

In short, UML gives us a standard approach to modelling elements and concepts such as: use case, class, object, state etc. and provides us with a consistent visual notation to render the model elements into graphical diagrams.

The advantage of a consistent notation is that one software designer can pass a system design to another in the knowledge that they will fully understand the design because it is written in a standardised notation understood by all in the field. By placing the emphasis on the visual aspects of design, graphical diagrams can quickly be produced enabling design ideas to be rapidly prototyped and understood by both analysts and programmers.

Following first issue of the UML at version 1.0 in January 1997, Object Management Group (OMG) has continued the evolution of the UML. A number of bug-fixes and omissions have been rectified, and further refinements added including a number of domain specific profiles, such as one for component-based development, resulting in the latest version, 2.0, being released in 2005. (A profile is a set of extensions to model elements adapting their use to a specific context).

In subsequent sections we will review various types of design diagrams that have been standardised as part of the UML specification.

Student Activity 1.2: UML SpecificationLearning Objective: This exercise will ensure that you know the location of the UML specifications.

Navigate to the UML homepage (http://www.uml.org) and find the current version of specification. This isn’t as simple as you might first think. Remember the name of the specification is “Unified Modeling Language”, look for the latest specification and find the “Superstructure” version. The resulting PDF will be approximately 5 to 6mb in size and will probably be called 07-011-02.pdf. The specification although at times hard to read, is a core, free resource!

UML DiagramIn UML there are many diagrams that support different aspects of design. In this section we review some of these diagrams.

Generally speaking, there are two types of diagram: “Structure” and “Behaviour”. We use the term “structure diagram” to describe diagrams that specify the “structure” of something. These diagrams represent the static view of a system. That is, they provide no description of the order of interaction between components such as objects. Examples of this type of diagram are Class diagram and Object diagram. Behaviour diagrams focus on the dynamic behaviour. An example of a behaviour diagram would be a use case diagram, where its purpose is to illustrate how users interact with the system. Behaviour diagrams can be subdivided into more specialised diagrams; one such type is called interaction diagram. An example of this type of diagram is a sequence diagram, where it focuses on the interactions between objects and the sequence of such interactions.

Arguably the most popular software design diagram is the class diagram. However the way that inexperienced designers typically construct this diagram and then in turn, convert it to program code perhaps makes it the most misused diagram in the UML. In the next section we will illustrate how the class model should be used as part of other models to ensure that a good, solid design that meets all system requirements is developed.

System ViewsIn the previous section we finished by making the point that models of various aspects of the design need to be coordinated in order to produce a good, solid design that meets all system requirements is developed. In this section we illustrate the relationships between design models and discuss the outside V’s inside view of the system using the following diagram.

The “Rich Picture” is a hierarchical composition of the system, the enterprise and the universe. The Use Cases define the system boundary by defining a “Black Box” system interface to the system actors. The “White Box” inner system details are represented within the system by three models. The dynamic semantics of the system are captured by Interaction Models; static semantics are captured by Class Models. State models capture aspects of dynamic semantics on internal system behaviour, but are confined to the dynamics of an instance of a class (typically), a use case or a system (less typically). Activity diagrams also capture dynamic semantics of internal system behaviour, but focus on activities rather than states. Activity diagrams are confined to the activities of a use case, or component, or operation.

We discuss actors in detail later in this unit but for the time being think of them as people or external systems that interact with the system being modelled.

DiagramsIn this section we take a look at some of the diagrams we have previously mentioned.

Example Use Case Diagram

Use case diagrams are similar in appearance to those used in OOSE by Ivar Jacobson.

Example Class Diagram

Class diagrams are a unification of OMT, Booch and class diagrams of most other OO methods.

Behavioural Diagrams

Sequence diagrams were found in a variety of OO methods under a variety of names - interaction, message trace and event trace.

Collaboration diagrams are similar to Sequence diagrams in that they show object interactions. In UML 2 collaboration diagrams are called communication diagrams.

State diagrams are based on the state charts of David Harel with minor changes.

Activity diagrams are based on a number of workflow-oriented approaches. The most immediate ancestor is Jim Odell’s event diagrams, described in “Object-Oriented Methods: A Foundation” by James Martin and James Odell.

Student Activity 1.3: Section Summary

Learning Objective: This exercise will ensure that you’re familiar with core concepts of UML.

In this section we have provided a brief introduction to the Unified Modelling Language (UML). Review some of these concepts using the following self-test questions.

Q1. What is the purpose of UML?Q2. Name 4 different UML diagrams.Q3. In terms of scope, where do actors reside, inside or outside the system?

You may find some of the Podcasts from the Gentleware’s website useful. At this stage, you should focus on these two topics: “What is Object-oriented modelling?” And “What is UML?”

Case StudyIn this section we introduce a case study that we will use throughout the course to illustrate various design and programming concepts. For the time being just have a quick read through. We will start to refer back to this case study in later sections.

Case Study – UweFlix Cinema Booking SystemBackground and required System Goal

The famous and fictitious UweFlix cinema on Frenchay Campus has a limited ticketing system in place currently. However, to enable customers to place advance bookings, UweFlix Inc. have decided to put in place a Cinema Booking System to replace the current system. The goal of the Cinema Booking system is to enable customers (students, staff and their families) to purchase cinema tickets in advance of the showing while still offering customers the traditional purchase of tickets on entry to the cinema requirement.

Initial analysis reveals that System Actors include:

CustomerBooking ClerkCinema Manager

Initial analysis also reveals the following use case scenarios -

Customer scenarios:

Purchase Advance Tickets

A customer uses the UweFlix desktop. The customer selects a date and is provided with a list of showings for that date, including the time of the showings. The customer selects a showing and is provided with details of the showing, including film title, age rating, duration, and a short trailer description. The customer then selects the quantity of tickets required, together with the ticket type. Ticket types may be one of student, child, or adult. The total cost of the booking is supplied to the customer. If the customer is happy, they then confirm their booking request.

If there are insufficient seats available at the showing, the booking request is cancelled and the customer is invited to make a further booking request. If there

are sufficient seats, the customer confirms the booking and enters their payment card details, which include card number and expiry date. Payment cards may be one of two types – credit card or payment card. The payment is transacted.Collect Tickets

On entry to the UweFlix cinema, the customer swipes their payment card through an attractive and easy to use swipe / printer device which determines the current booking details for the payment card. If a booking currently exists for the payment card, the swipe / printer device prints the appropriate tickets for the booking.

Booking Clerk scenarios:

Purchase Tickets

Having entered the UweFlix cinema, the customer requests to the booking clerk a number of tickets for a specific showing. The booking clerk selects the requested showing and sees how many tickets are available. If there are sufficient seats available, the booking clerk confirms the tickets by type (student, child, adult) and the total cost of the booking is shown. If the cost is unacceptable to the customer, the booking is cancelled. However, if the cost is acceptable, the booking clerk takes the customer’s payment card details, which include card number and expiry date. Payment cards may be one of two types – credit card or payment card. The payment is transacted, and the appropriate tickets are printed and handed to the happy customer.

Cinema Manager scenarios:

Add Film

The cinema manager adds details of a new film. Film details include Title, Age Rating, Duration, and short trailer description.

Delete Film

The cinema manager requests to delete details of an obsolete film. The film can only be deleted if there are no showings allocated to it.

Add Screen

The cinema manager adds details of a new screen in the cinema. Screen details include the capacity of the screen in terms of the numbers of seats.

Add Showing

The cinema manager adds details of a new showing of a film. Showing details include the date and time of the showing. (Showing details must also be able to record the number of tickets sold against the showing at any time).

Cancel Showing

The cinema manager requests to delete a showing. A showing can only be deleted if there are no tickets sold for the showing.

Use cases

Introduction

In this section we will introduce a concept known as “use cases”. The UML specification defines uses cases as:

“… a means for specifying required usages of a system” [UML spec. v2.0].

Briefly, the process is as follows. You, the software designer, will map groups of related scenarios – the system functionality, to a series of use cases. Each of these use cases will represent a substantial part of the system. The system requirements will be derived from reading the requirements documentation. You will then be in a position to establish who will interact with the use cases, the actors, and which use cases will work with each other to achieve the desired system functionality. We now discuss this in more detail.

Definition

“Use cases are a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system, that is, what a system is supposed to do. The key concepts associated with use cases are actors, use cases, and the subject. The subject is the system under consideration to which the use cases apply. The users and any other systems that may interact with the subject are represented as actors. Actors always model entities that are outside the system. The required behaviour of the subject is specified by one or more use cases, which are defined according to the needs of actors. Strictly speaking, the term “use case” refers to a use case type. An instance of a use case refers to an occurrence of the emergent behaviour that conforms to the corresponding use case type. Such instances are often described by interaction specifications. Use cases, actors, and systems are described using use case diagrams. “ [UML spec.]

The long quote above taken from the UML specification may be confusing at first. So we will now break it down and identify the key points.

A use case is a collection of related scenarios. The scenarios are taken from the requirements document or other similar textual description outlining the goals of the system. In effect, a use case defines what the system will do, not how it will do it. Think of the purpose of deriving use cases as converting the functional requirement of the system into a form that can be used to produce further, more detailed, designs that will define the structure of the system.

The content of a use case is a textual narrative that describes the functionality or requirements that the use case represents. For example, a use case that represented the process of buying an item from an online store would be given a name like “Purchase Item”. The contents of the use case would be the textual description describing the process of purchasing an item. This description normally describes a series of interactions between the system and the actor. This process normally yields a result that is of value to the actor. In the next section we discuss the role of an actor in more detail.

Example Notations:

Below are two forms of the notation for illustrating use cases. Both represent the same thing, however the ellipse notation is more common.

Actor

“An actor specifies a role played by a user or any other system that interacts with the subject.” [UML spec. v2.0]

We use the term “actor” to represent the role of someone or something that interacts with the system. Actors need not be human, they may be external systems such as credit card verification systems that reside outside of the scope of the system currently being modelled but their involvement is required in order to meet the goals of the system.

Actors exist outside of the scope of a use case and are responsible for initiating use cases. The interaction between an actor and a use case (system) is illustrated in the diagram below.

Example Notations:

The following three methods of notation for denoting actors are all equivalent.

Example Use Case DescriptionTo write the content of a use case, you begin by picking one of the scenarios as the main scenario. You start the body of the use case by writing the main success scenario as a sequence of numbered steps. You then take the other scenarios and write them as extensions. Extensions can be successes, as in 3a below or failure, as in 6b below. Each use case has a primary actor, which calls on the system to deliver a service. Each step in a use case is an element of the interaction between the user and the system. A complicated step in a use case can be another use case. In UML terms, we say that the first use case includes the second.

Buy a Product (Taken from UML Distilled p101)

Main Success Scenario:1. Customer browses catalogue and selects item to by.2. Customer goes to the check out.3. Customer fills in shipping information4. System presents full pricing information5. Customer fills in credit card information6. system authorizes purchase7. System confirms sale8. System sends confirming email to customer

Extensions3a: Customer is a regular customer

.1 System displays current shipping information

.2 Customer may accept or override6a: System fails to authorize credit purchases

.1 Customer may reenter credit card information or may cancel

Adapted from UML Distilled page 101

Identifying Use CasesBefore we can produce a use case diagram we must first identify the groups of related scenarios – the use cases. In addition we need to identify the initiators of the use cases – the actors. Recall from the previous sections, actors reside outside of the system and interact with it; use cases describe the functionality that helps actors achieve their goals. There are many approaches to identifying actors and use cases. In this section we present a method for doing this.

To identify use cases we will take the following steps:

Step 1: Identify candidate system actors.Step 2: Identify the goals of the actors.Step 3: Identify the candidate use cases. Step 4: Identify the start point for each use case.Step 5: Identify the end point for each use case.Step 6: Refine and scope units of interaction.

Now we discuss each of these steps in more detail.

Step 1: Identify candidate system actors.

Read through the requirements documentation and make a note of all the candidate system actors. Remember an actor is not just a person but may also be an external system such as a credit card verification service. Actors interact with the system and reside outside of it. If you find that multiple terms have been used to describe the same actor, group these terms together and use a generic term. Be aware, it is crucial that you are certain that these terms are describing the same actor.

Activity: Identify the Actors in the Case Study

Learning Objective: This exercise will give you some insight into the process of identifying the system actors that are responsible for initiating uses cases.

Read through the UWEFlix case study and identify the actors. Remember from the previous section, actors are external to the system and not part of it. They are not necessarily human and can be external systems such as credit card verification services. For example, Manager could be an actor. Any others?

Step 2: Identify the goals of the actors.

Use cases describe the functionality required of the system in order for actors to achieve their goals. Therefore you need to identify what the goals of your candidate actors are. At this stage you may find that you have multiple actors requiring the same or similar system functionality, at this stage do not worry about this. For example, the manager needs to decide what films to shown in which screens.

Step 3: Identify the candidate use cases.

Now that you have identified the candidate actors and the goals of these actors we can identify the candidate list of use cases. Remember a use case represents a substantial piece of system functionality, not just a single method in software. Use cases cover a group of related scenarios, for example, a use case called “purchase ticket” will include the scenario where payment is unsuccessful in addition to the typical payment success scenario. Using the actors goals try and identify the text in the requirements document that corresponds to these goals. Choose an initial name to describe the candidate use case and paste the textual commentary from the requirements document underneath the use case name. At this point do not worry about common functionality in multiple use cases.

Activity: Identify the Use Cases in the Case Study

Learning Objective: This exercise will give you some insight into the process of identifying the uses cases that represent the required system functionality.

Read through the case study and identify the use cases. Remember from the previous section that use cases are groups of related scenarios. For example, we may have a use case for deleting film.

Step 4: Identify the start point for each use case.

You may have already started to do this when producing your list of candidate use cases but you need to identify the start point for each use case. To do this, look for an actor and an initial event. You will find this is easier to do with some use cases rather than others. For example, with the “DeleteFilm” use case, the initial event may be to choose a film.

Step 5: Identify the end point for each use case.

In a manner similar to that of step 2, you need to identify the beneficial result of the use case, the end point. The purpose of this step is to allow you to refine the size of use cases, ensuring that a candidate use case is neither too small nor too big.

Step 6: Refine and scope units of interaction.

At this point all of the functionality described in the requirements document needs to be covered by at least one candidate use case. You now need to work through the list of candidate use cases refining size and scope. Remember after completing this step you are not after a fixed final list of actors and use cases, it is still possible to refine this later.

Note: You will find that as you gain more experience you will carry out steps 3-5 at the same time.

NotationThe use case diagram is used to graphically illustrate the use cases that make up the system. It represents the relationship between the actor and the use case. The actor is represented by a stickman, the use cases by ellipses. The system as a whole may be bounded by a box. Below is an example use case diagram.

It is at the discretion of the practitioner on when they use a separate diagram, or add use cases to the one diagram. The following are two possible approaches:

Each actor has their own use case diagram; Each business process has its own use case diagram.

In general the diagram is used to support a representation of some aspect of the system. It is therefore not incorrect to have the same use case present on numerous diagrams.

Student Activity 1.4

In this unit we have introduced a lot of new concepts that may seem a little daunting at first. In this section we present some self-test questions that will help to clarify key points.

Q1. Define the term object.Q2. What is the purpose of a use case?

Produce a use case diagram for the case study supplied in this unit.

Broadening your knowledge and critical thinking

Search on the Internet for resources about Use Cases. You may find that different sources have different opinions. Study and evaluate your findings. Post any useful links to the Module Forum to share your findings with other people. The ability to carry out research and to critically evaluate is an important aspect of your MSc training.

To access the module forum, you click on the button “Discussion Board” on the left of the module page.

Getting Familiar with NetBeans There are many tools supporting UML. In this module, we will be using the UML modeller module supported in NetBeans. NetBeans is free and it is a very popular tool for programming in Java. NetBeans 6.0 or above also supports UML modelling.

Download and install NetBeans

Go to http://www.netbeans.orgClick on “Download NetBeans IDE”Choose the pack which contains both Java SE and UML, i.e. the pack contains all.Once the download is completed, run the installation wizard.

Now you have a tool that can support you to model systems using UML and to program in Java.

Creating your first UML project in NetBeansIn this first project, you will learn how to create a UML project and a use case diagram. Note that in NetBeans, when you create a new UML project, it gives you three options: Platform-independent, Java-platform or reverse engineer. The notation in the platform independent model is similar to the UML standard notation, but you will not be able to generate code from the model. The notation in the Java-platform model is similar to Java syntax. You are able to generate Java code from the Java-platform model. You may want to experiment with both the platform-independent model and the Java-platform model. For the moment, you don’t need to worry about the reverse-engineer option. We can explore this towards the end of the module.

Follow this link for a tutorial on how to crate a UML project and a use case diagram: http://www.netbeans.org/kb/60/uml/use-case.html#UMLProject

Later on in the module, you will learn how to add other types of UML diagram to your project.

Student Activity 1.5 In Student Activity 1.4, you have produced a use case diagram for the UWEFlix case study. Create the use case diagram in NetBeans.

References

UML Distilled: A Brief Guide to the Standard Object Modeling Language (Object Technology S.) Addison Wesley. Martin Fowler.

Unified Modeling Language: http://www.uml.org (accessed May 2008)

NetBeans UML tutorial:http://www.netbeans.org/kb/trails/uml.html (accessed May 2008)

Gentleware tutorials: http://www.gentleware.com/fileadmin/media/synergy/Course/Overview/index.htm

NetbBeans: http://www.netbeans.org