uml classes online material

8/14/2019 Uml Classes Online Material

1/59

In the previous article, we gained an overview of what the Unified ModelingLanguage stands for and what are the nine diagrams that make up UML. BecauseUML is essentially a set of diagrams, you can simply draw them by hand on a pieceof paper. But, drawing UML diagrams on a piece of paper is certainly not a bestpractice to design systems. Software applications simplify the task of drawingdiagrams of software designs. In addition, because the design is in an electronic

format, archiving the design for future use, collaborating on the design becomesmuch easier. Also, routine tasks can be automated by using a UML tool. Hence, usinga UML tool is by far the most preferred way for designing software applications.

Features in UML Tools

This takes us to an important questionwhat exactly should we look for in a UMLtool?

Because the primary use of a UML tool is to enable you to draw diagrams, first andforemost, we need to see what types of UML diagrams the tool supports. But, isdrawing UML diagrams all that you would expect from a UML tool? For example,

wouldn't it be great if the class diagrams that you draw in the tool can somehow beused to generate the source code for actual Java classes or C++ classes?

Let us take a look at another scenario. Suppose you were given a large set of sourcecode files with lots and lots of classes. Wouldn't it be a nightmare wading throughthe code trying to figure out how all the classes are interconnected? This is whereUML tools step in to make things a lot easier by providing support for such features.Now, let's define these features in technical terms:

UML diagram support: The UML tool should support all the nine diagrams

that make up UML. You should look for a tool that supports drawing usecases, designing the static view diagrams such as class diagrams and object

diagrams, defining the dynamic view diagrams such as sequence, activity,state, and collaboration diagrams and the component and deploymentdiagrams that form the implementation view of the system.

Forward engineering: A UML tool should not have its use limited to just a

pictorial depiction of diagrams. Because the structure of the system definedby the diagram is translated by a developer into actual source code (classes),the UML tool should bridge this step by generating the source code of theclasses with the methods stubbed out. Developers can take up this stub codeand fill in with the actual code. This characteristic of automating thegeneration of source code is called forward engineering. Forward engineeringsupport by a UML tool is normally for a specific language or a set oflanguages. If you are a Java developer, verify that the UML tool that you wantto use has forward engineering support for Java. Similarly, if you are a C++developer, the UML tool should provide you forward engineering support forC++.

Reverse engineering: Reverse engineering is exactly the opposite of

forward engineering. In reverse engineering, the UML tool loads all the files ofthe application/system, identifies dependencies between the various classes,and essentially reconstructs the entire application structure along with all therelationships between the classes. Reverse engineering is a feature normallyprovided by sophisticated and high-end UML tools.
http://www.developer.com/design/article.php/1553851http://www.developer.com/design/article.php/1553851


2/59

Round-trip engineering: Another useful feature apart from forward and

reverse engineering is round-trip engineering. Forward and reverseengineering are essentially one-off activities that take input and generate therequired output. Round-trip engineering extends these features.

An important rule in software design is that no design remains unchanged.

This is as true for small systems as it is for large systems. Duringdevelopment, the design structure defined in the UML model does undergochanges to incorporate physical differences in implementation that may nothave been envisaged during design. It becomes very difficult to keep thedesign of the system updated with the changes in the source code. Theround-trip engineering feature enables the UML tool to synchronize the modelwith the changes in the application code.

Documentation: Documentation is an integral aspect of a UML tool.

Software designing, by nature, is an abstract process. Apart from a fewsyntax and semantic ground rules, there are no other rules. The thoughtprocess of a software architect who designs applications using UML can belost if the reasons behind certain design decisions are not captured and welldocumented. This becomes painfully clear when large systems are maintainedand no one has a clue to why a subsystem was designed in a certain way.Hence, a UML tool must necessarily provide some way for the designer todocument design decisions in the diagrams by using simple things such asannotations or comments. In addition to this, the UML tool should support thegeneration of reports/listings of the different design elements of the diagram.

Apart from the above features, you should also identify a few features thatwould definitely be useful to have in the UML tool.

Version control: A very important feature that we want to have in the UML

tool is either an integrated version control mechanism or connectivity to astandard version control system. Configuration management is an integral

part in the building of software systems. Considering that the design of asystem is a very important artefact of the software lifecycle, maintainingversions and baselines of the system design is a desirable feature to have inUML tools. In the absence of direct support for version control, it is theresponsibility of the designer to maintain versions of the design.

Collaborative modeling environment: Enterprise systems are huge and

their designs are quite complex. While designing complex systems, there maybe different teams involved and may carry out design work on differentsubsystems in parallel. This collaborative design effort needs to be properlysynchronized by the UML tool. The UML tool should provide support for acollaborative modeling environment with capability to compare differentversions designs for differences or even merge different versions of a design.

Collaborative modeling is always a nice feature to have in UML tools. Integration with popular Integrated Development Environments

(IDE): With the increasing use of iterative methodologies for buildingsoftware systems, it becomes very difficult to keep the design of the systemin sync with the developed code. Hence, it would be useful if the UML toolprovides integration with popular IDEs. This feature would enable the UMLtool to be updated with the changes in the source code made in the IDE.

Test script generation: The system or subsystem designed in a UML tool

may represent a set of functional aspects as well. Hence, it would be really


3/59

useful if, in addition to generating stub code, the tool also generates testscripts that can be used for testing how the generated class functions.

Model View Controller (MVC) modeling: Enterprise application

architectures have increasingly begun to standardize and are based on theModel View Controller architecture. Hence, if you design n-tier, Web-enabledenterprise applications, you should look for a UML tool that supports

designing applications based on the MVC architecture. Support for MVCmodeling makes it easier to organize and clearly distinguish the designelements along the lines of the MVC layers. This will help in the long run inimproving the readability of the model.

Template-driven modeling

Re-usability is the key to improving productivity. An application design may consist ofseveral classes with relationships defined. Quite a few times, while designingapplications, you encounter the same design problems or scenarios and end updefining the same design again and again. By using a modeling tool, you can definecertain components or even subsystems that might potentially be reusable in thefuture. For example, design elements of an application used to define access to thedatabase using, say, a ConnectionPool class are potentially reusable. You might needto define a similar database connection pool in another application as well. Hence, itwould benefit us in the long run if we design the ConnectionPool class separately. Wethen can include the ConnectionPool design in any future subsystems and avoid theneed of reinventing the wheel.

Such reusable designs or models are termed as templates and the entire modelingprocess involving the identification and use of templates is called template-drivenmodeling. The benefits of template-driven modeling are apparent in the savings indesign time. You can consider model templates to be very similar to reusable codelibraries used in application development.

Popular UML Tools

We will list here a few of the "movers and shakers" of vendors of UML tools. Pleasenote that this list is by no means exhaustive and is not meant to provide any rankingfor any UML tool.

Rational Rose: No discussion of UML tools is complete without the mention

of the Rational Rose modeling tool from Rational Software Corporation.Rational Rose (the Rose stands for "Rational Object-oriented SoftwareEngineering") is a visual modeling tool for UML. It comes in different versionssuited to different requirements. Rational Rose provides support for all the

standard features that we discussed in the previous section such as UMLdiagram support, forward and reverse engineering support, anddocumentation and round-trip engineering support. Apart from this, RationalRose also provides support for version control, IDE integration, design patternmodeling, test script generation, and collaborative modeling environment. Inaddition, Rational Rose also supports the designing of data models within thesame environment. An interesting feature of Rational Rose is the ability topublish the UML diagrams as a set of Web pages and images. This enables


4/59

you to share and distribute your application design where the Rational Rosetool is not installed.

Together Control Center: Together Control Center (formerly from

Togethersoft) from Borland is an entire suite of visual modeling tools for UML.Together Control Center supports UML diagrams, MVC modeling, forward andreverse engineering, and round-trip engineering, as well as integration with

IDEs such as IBM WebSphere Studio.

It supports comprehensive documentation and a powerful collaborativemodeling environment.

An added feature of Together Control Center is the pattern repository. Thepattern repository (similar to the template-driven modeling concept discussedabove) makes frequently used diagrams and design patterns readily availablefor reuse in modeling. Together Control Center supports the Rational UnifiedProcess as well as the eXtreme Programming methodologies.

Poseidon: Poseidon from Gentleware has its roots in the ArgoUML open

source project. The ArgoUML modeling tool evolved as an open source effortand is a useful, full-featured UML tool freely available under the OpenPublication License. Gentleware has taken ArgoUML a step further and turnedit into a good modeling tool. Poseidon comes in different flavors suited todifferent requirements. Poseidon supports forward and reverse engineeringand documentation generation by using special-purpose plug-ins.

Gentleware has not forgotten its open source moorings and offers thePoseidon for UML Community Edition 1.5 free for individual softwaredevelopers.

Integration of UML Tools with Integrated Development

Environments (IDEs)

One interesting feature in UML tools that we discussed in the previous section wasround-trip engineering. For round-trip engineering to be useful, we need to have theUML tool to be used in conjunction with an IDE. This integration of a UML tool withthe IDE will help you to really benefit from round-trip engineering. Any changes inthe application code that you make in the IDE are immediately reflected in the modelin the UML tool and vice versa. For our discussion, we will be considering IDEs for theJava language.

Quite a few of the UML tools on the market can be integrated with the popular IDEssuch as IBM's WebSphere Studio, Borland's JBuilder, WebGain's Visual Caf, or Sun's

Forte. For instance, Rational Rose (Java edition) provides integration with all of thesepopular IDEs. Together Control Center has a special version that integrates withIBM's WebSphere Studio.

The downside of UML tool integration is that the integration solution is proprietary tothe UML tool vendor. Hence, you might not always find a UML tool providingintegration with popular IDEs in the market. But all this is changing. (See box fordetails on the Eclipse project.)


5/59


6/59

2) point

Over the previous two articles, we took a brief look at the nine UML diagrams andwhat kind of tools you can use to model UML diagrams. Now that we have our basicsclear, we will start our study of these nine UML diagrams. Today we will cover theUse case diagram. We will learn the basics of use case diagrams and try our hand

at drawing a use case diagram. In addition, we will see what a use case specificationis. Finally, we will attempt to apply what we have learned of use cases and model theuse case diagrams for our case study applicationthe Courseware ManagementSystem.

Basics

Before we start off today's article, let us revisit the definition of use a case diagram,as described in the first article.

The Use case diagram is used to identify the primary elements and processes that

form the system. The primary elements are termed as "actors" and the processes

are called "use cases." The Use case diagram shows which actors interact with eachuse case.

The above statement pretty much sums up what a use case diagram is primarilymade up ofactors and use cases.

A use case diagram captures the functional aspects of a system. More specifically, itcaptures the business processes carried out in the system. As you discuss thefunctionality and processes of the system, you discover significant characteristics ofthe system that you model in the use case diagram. Due to the simplicity of use casediagrams, and more importantly, because they are shorn of all technical jargon, usecase diagrams are a great storyboard tool for user meetings. Use case diagrams

have another important use. Use case diagrams define the requirements of thesystem being modeled and hence are used to write test scripts for the modeledsystem.

So who should normally be involved in the creation of use cases? Normally, domainexperts and business analysts should be involved in writing use cases for a givensystem. Use cases are created when the requirements of a system need to becaptured. Because, at this point no design or development activities are involved,technical experts should not be a part of the team responsible for creating use cases.Their expertise comes in use later in the software lifecycle.

Elements of a Use Case Diagram

A use case diagram is quite simple in nature and depicts two types of elements: onerepresenting the business roles and the other representing the business processes.Let us take a closer look at use at what elements constitute a use case diagram.

Actors: An actor portrays any entity (or entities) that performs certain roles

in a given system. The different roles the actor represents are the actualbusiness roles of users in a given system. An actor in a use case diagraminteracts with a use case. For example, for modeling a banking application, a


7/59

customer entity represents an actor in the application. Similarly, the personwho provides service at the counter is also an actor. But it is up to you toconsider what actors make an impact on the functionality that you want tomodel. If an entity does not affect a certain piece of functionality that you aremodeling, it makes no sense to represent it as an actor. An actor is shown asa stick figure in a use case diagram depicted "outside" the system boundary,

as shown in Figure 3.1.

Figure 3.1: an actor in a use case diagram

To identify an actor, search in the problem statement for business terms thatportray roles in the system. For example, in the statement "patients visit the

doctor in the clinic for medical tests," "doctor" and "patients" are the businessroles and can be easily identified as actors in the system.

Use case: A use case in a use case diagram is a visual representation of a

distinct business functionality in a system. The key term here is "distinctbusiness functionality." To choose a business process as a likely candidate formodeling as a use case, you need to ensure that the business process isdiscrete in nature. As the first step in identifying use cases, you should list thediscrete business functions in your problem statement. Each of these businessfunctions can be classified as a potential use case. Remember that identifyinguse cases is a discovery rather than a creation. As business functionalitybecomes clearer, the underlying use cases become more easily evident. A usecase is shown as an ellipse in a use case diagram (see Figure 3.2).

Figure 3.2: use cases in a use case diagram

Figure 3.2 shows two uses cases: "Make appointment" and "Perform medicaltests" in the use case diagram of a clinic system. As another example,consider that a business process such as "manage patient records" can in turnhave sub-processes like "manage patient's personal information" and

"manage patient's medical information." Discovering such implicit use cases ispossible only with a thorough understanding of all the business processes ofthe system through discussions with potential users of the system andrelevant domain knowledge.

System boundary: A system boundary defines the scope of what a system

will be. A system cannot have infinite functionality. So, it follows that usecases also need to have definitive limits defined. A system boundary of a use


8/59

case diagram defines the limits of the system. The system boundary is shownas a rectangle spanning all the use cases in the system.

Figure 3.3: a use case diagram depicting the system boundary of a clinic

application

Figure 3.3 shows the system boundary of the clinic application. The use casesof this system are enclosed in a rectangle. Note that the actors in the systemare outside the system boundary.

The system boundary is potentially the entire system as defined in theproblem statement. But this is not always the case. For large and complexsystems, each of the modules may be the system boundary. For example, foran ERP system for an organization, each of the modules such as personnel,payroll, accounting, and so forth, can form the system boundary for use casesspecific to each of these business functions. The entire system can span all ofthese modules depicting the overall system boundary.

Relationships in Use Cases

Use cases share different kinds of relationships. A relationship between two usecases is basically a dependency between the two use cases. Defining a relationshipbetween two use cases is the decision of the modeler of the use case diagram. Thisreuse of an existing use case using different types of relationships reduces theoverall effort required in defining use cases in a system. A similar reuse establishedusing relationships, will be apparent in the other UML diagrams as well. Use caserelationships can be one of the following:

Include: When a use case is depicted as using the functionality of another

use case in a diagram, this relationship between the use cases is named as aninclude relationship. Literally speaking, in an include relationship, a use caseincludes the functionality described in the another use case as a part of itsbusiness process flow. An include relationship is depicted with a directedarrow having a dotted shaft. The tip of the arrowhead points to the parent usecase and the child use case is connected at the base of the arrow. The


9/59

stereotype "" identifies the relationship as an includerelationship.

Figure 3.4: an example of an include relationship

For example, in Figure 3.4, you can see that the functionality defined by the"Validate patient records" use case is contained within the "Makeappointment" use case. Hence, whenever the "Make appointment" use caseexecutes, the business steps defined in the "Validate patient records" usecase are also executed.

Extend: In an extendrelationship between two use cases, the child use caseadds to the existing functionality and characteristics of the parent use case.An extend relationship is depicted with a directed arrow having a dotted shaft,similar to the include relationship. The tip of the arrowhead points to theparent use case and the child use case is connected at the base of the arrow.The stereotype "" identifies the relationship as an extendrelationship, as shown in Figure 3.5.

Figure 3.5: an example of an extend relationship

Figure 3.5 shows an example of an extend relationship between the "Performmedical tests" (parent) and "Perform Pathological Tests" (child) use cases.The "Perform Pathological Tests" use case enhances the functionality of the"Perform medical tests" use case. Essentially, the "Perform Pathological Tests"use case is a specialized version of the generic "Perform medical tests" use

case.

Generalizations: A generalization relationship is also a parent-child

relationship between use cases. The child use case in the generalizationrelationship has the underlying business process meaning, but is anenhancement of the parent use case. In a use case diagram, generalization isshown as a directed arrow with a triangle arrowhead (see Figure 3.6). Thechild use case is connected at the base of the arrow. The tip of the arrow isconnected to the parent use case.


10/59

Figure 3.6: an example of a generalization relationship

On the face of it, both generalizations and extends appear to be more or less similar.But there is a subtle difference between a generalization relationship and an extendrelationship. When you establish a generalization relationship between use cases,this implies that the parent use case can be replaced by the child use case withoutbreaking the business flow. On the other hand, an extend relationship between usecases implies that the child use case enhances the functionality of the parent use

case into a specialized functionality. The parent use case in an extend relationshipcannot be replaced by the child use case.

Let us see if we understand things better with an example. From the diagram of ageneralization relationship (refer to Figure 3.6), you can see that "Store patientrecords (paper file)" (parent) use case is depicted as a generalized version of the"Store patient records (computerized file)" (child) use case. Defining a generalizationrelationship between the two implies that you can replace any occurrence of the"Store patient records (paper file)" use case in the business flow of your system withthe "Store patient records (computerized file)" use case without impacting anybusiness flow. This would mean that in future you might choose to store patientrecords in a computerized file instead of as paper documents without impacting otherbusiness actions.

Now, if we had defined this as an extend relationship between the two use cases,this would imply that the "Store patient records (computerized file)" use case is aspecialized version of the "Store patient records (paper file)" use case. Hence, youwould not be able to seamlessly replace the occurrence of the "Store patient records(paper file)" use case with the "Store patient records (computerized file)" use case.

Creating the Use Case Diagram

For drawing use case diagrams, you need to use any tool that supports use casediagrams. We will be using the Poseidon Community Edition tool for drawing the use

case diagram, as shown in Figure 3.7. You can use any tool that you are comfortablewith. A use case modeling tool provides a palette of options to draw actors and usecases and to define relationships between the use cases.


11/59

Click here for a larger image.

Figure 3.7: a screen shot of the Poseidon tool

Take a look at the screen shot of the Poseidon tool. You can see the different optionsit provides to draw the use case diagram elements. In addition to drawing the usecase diagram elements such as actors and use cases, you also can definerelationships between use cases. Apart from this, the tool also provides capability todocument the different elements that we draw. This documentation can be viewed asa consolidated report for future reference.

An additional feature that you can check in your modeling tool is support forgenerating test scripts from the use case diagram. A comprehensive use case diagramprovides a good foundation for basing test cases for the system that you model.

Writing a Use Case Specification

A use case diagram, as we have seen, is a visual depiction of the different scenariosof interaction between an actor and a use case. The usefulness of use case diagramsis more as a tool of communication between the requirements capture team and theuser group. The next step after finalizing of use case diagrams is to document thebusiness functionality into clear-cut and detailed use case specifications. Because usecases are used as an input to the other project phases such as design, development,and testing, we need to ensure that the visual depiction of the business requirementsis translated into clear and well-defined requirements in the form of use casespecifications. Elaborate use case specifications are used as an input for design anddevelopment and for writing test cases (unit, system, and regression tests, as thecase may be).

A use case specification document should enable us to easily document the businessflow. Information that you document in a use case specification includes what actorsare involved, the steps that the use case performs, business rules, and so forth. Ause case specification document should cover the following areas:

Actors: List the actors that interact and participate in this use case.

Pre-conditions: Pre-conditions that need to be satisfied for the use case to

perform.
http://www.developer.com/img/articles/2003/03/14/UML/UseCaseDiagram07.gifhttp://www.developer.com/img/articles/2003/03/14/UML/UseCaseDiagram07.gifhttp://www.developer.com/img/articles/2003/03/14/UML/UseCaseDiagram07.gif


12/59

Post-conditions: Define the different states in which you expect the system

to be in, after the use case executes. Basic Flow: List the basic events that will occur when this use case is

executed. Include all the primary activities that the use case will perform. Befairly descriptive when defining the actions performed by the actor and theresponse of the use case to those actions. This description of actions and

responses are your functional requirements. These will form the basis forwriting the test case scenarios for the system.

Alternative flows: Any subsidiary events that can occur in the use case

should be listed separately. Each such event should be completed in itself tobe listed as an alternative flow. A use case can have as many alternative flowsas required. But remember, if there are too many alternative flows, you needto revisit your use case design to make it simpler and, if required, break theuse case into smaller discrete units.

Special Requirements: Business rules for the basic and alternative flows

should be listed as special requirements in the use case narration. Thesebusiness rules will also be used for writing test cases. Both success and failurescenarios should be described here.

Use case relationships: For complex systems, it is recommended that youdocument the relationships between use cases. If this use case extends fromother use cases or includes the functionality of other use cases, theserelationships should be listed here. Listing the relationships between usecases also provides a mechanism for traceability.

You can download a template for a use case specification document and customize it

for your use here.

Dos and Don'ts

Use cases should not be used to capture all the details of a system. The granularityto which you define use cases in a diagram should be enough to keep the use casediagram uncluttered and readable, yet, be complete without missing significantaspects of the required functionality. You will encounter such decision points of thelevel of granularity that you need to define when you build any of the UML diagrams.

An important rule that gets forgotten during use creation is the creeping in of designissues. Use cases are meant to capture "what" the system is, not "how" the systemwill be designed or built. Use cases should be free of any design characteristics. Ifyou end up defining design characteristics in a use case, you need to go back to thedrawing board and start again.

Case studyCourseware Management System

Use case modeling, as we have learnt today, involves analyzing the problemstatement to determine the business processes of the system. We will now designthe use case model for the Courseware Management System case study.
http://www.developer.com/img/articles/2003/03/14/UML/UseCaseDiagram.ziphttp://www.developer.com/img/articles/2003/03/14/UML/UseCaseDiagram.zip


13/59

Note: In case you need to revisit the problem statement of the CoursewareManagement System described in Article 2, clickhere.

Let us analyze the problem statement to identify the potential actors and use casesof the system. First, let us list the potential actors. A quick look at the problemstatement shows up the following terms and entities specific to the system:

Courses and Topics that make up a course

Tutors who teach courses

Course administrators who mange the assignment of the courses to tutors

Calendar or Course Schedule is generated as a result of the

Students who refer to the Course schedule or Calendar to decide which

courses they wish to take up for study

Identifying Actors of the Courseware ManagementSystem

Out of the preceding list, one thing is clear. There are certain terms and entities inthe list that identify that they perform certain roles or business processes. We willdiscuss what these business processes are after we complete our analysis foridentifying actors. For now, we focus on identifying the actors in the system. Fromthe preceding list, we can see that there are some entities that perform an actionand some that form the target for the action. The entities that perform action will bethe actors for the Courseware Management System. In the above list, the actors thatwe can identify are:

Tutors

Course administrators

Students

But, because students are not the potential active participants for this system, wewill drop them from the list of actors. Similarly, tutors are not active participantsfrom our system's perspective, and hence, we will exclude tutors from our list ifroles. Yet, we will still record them in our use case model since we do not wish tolose this business information. Our final list of primary actors has now come down toonly one:


Identifying Use Cases of the Courseware ManagementSystem

Next, let us identify the potential business processes in the Courseware ManagementSystem. The primary business flows in the system are:

Manage courses

Manage course assignments
http://www.developer.com/design/article.php/1593811http://www.developer.com/design/article.php/1593811


14/59

As we analyze the problem statement further, we can determine some discreteprocesses within these primary business flows. To manage courses, the actor needsto have the ability to view existing courses, manage the course information for acourse, such as duration and so forth, and also manage the addition or removal oftopics for a course. So, within the "Manage courses" use case, we can identify thefollowing sub processes:

View courses

Manage topics for a course

Manage course information

And similarly, the "Manage course assignment" use case can be refined into smallerdiscrete processes such as viewing the course calendar, viewing tutors, managing thetutor information of tutors working for the organization, and of course, assigningcourses to tutors. Now, the use cases that we have identified within the "Managecourse assignment" use case are:

View course calendar

View tutors Manage tutor information

Assign courses to tutors

Our final list of use cases for the courseware management system will now be:

View courses




View tutors

Manage tutor information


If you were analyzing a sentence in English, the subject in the sentence can beidentified as a potential actor and the verb part of the sentence can be a potential usecase. Remember, this may or may not apply to the problem at hand, but is a goodstarting point for use case modeling.

Use Case Diagram


15/59


Figure 3.8: the use case diagram for the Courseware Management System

We have completed identifying potential use cases and actors. Take a look at the usecase diagram for the Courseware Management System in Figure 3.7. The use casediagram of the Courseware Management System includes all the actors and use

cases that we identified during our analysis of the problem statement.

Summary

Use case diagrams were the starting point of our journey in exploring each of theUML diagrams. Business functionality can be quickly represented in a simple andlucid fashion by using use case diagrams. Once the groundwork for depicting usecases is completed, the next step, as we learnt today, is writing detailed use casescenarios that will be used as the base functional requirements for the system. Ourexercise in defining the use case diagram for the Courseware Management Systemcase study was useful and enabled us to get a hands-on experience in applying whatwe learnt today.
http://www.developer.com/img/articles/2003/03/14/UML/UseCaseDiagram08.gifhttp://www.developer.com/img/articles/2003/03/14/UML/UseCaseDiagram08.gifhttp://www.developer.com/img/articles/2003/03/14/UML/UseCaseDiagram08.gif


16/59

3# point

In the coming article, we will study the next UML diagramthe Class diagram.

In the last article, we saw what use cases were, and how to identify and create usecases. Taking the series ahead, in this article, we will see what class diagrams are,

what the elements of a class diagram are, what each of these elements signify, andhow to identify them. In our next article, a sequel to this one, we will see how tocreate class diagrams for our case studyCourseware Management System. By theend of the second article, you will be able to define classes for a system and readand create class diagrams.

Basics

So, what is a class diagram? Imagine you were given a task of drawing a family tree.The steps you would take would be:

Identify the main members of the family

Determine how they are related to each other

Identify the characteristics of each family member

Find relations among family members

Decide the inheritance of personal traits and characters

A class diagram is similar to a family tree. A class diagram consists of a group ofclasses and interfaces reflecting important entities of the business domain of thesystem being modeled, and the relationships between these classes and interfaces.The classes and interfaces in the diagram represent the members of a family treeand the relationships between the classes are analogous to relationships betweenmembers in a family tree. Interestingly, classes in a class diagram are interconnectedin a hierarchical fashion, like a set of parent classes (the grand patriarch or matriarchof the family, as the case may be) and related child classes under the parent classes.

Similarly, a software application is comprised of classes and a diagram depicting therelationship between each of these classes would be the class diagram.

By definition, a class diagram is a diagram showing a collection of classes andinterfaces, along with the collaborations and relationships among classes and

interfaces.

A class diagram is a pictorial representation of the detailed system design. Designexperts who understand the rules of modeling and designing systems design thesystem's class diagrams. A thing to remember is that a class diagram is a static view

of a system. The structure of a system is represented using class diagrams. Classdiagrams are referenced time and again by the developers while implementing thesystem.

Now you now know what a class diagram is. But, how does a class diagram relate tothe use case diagrams that you read about in the earlier article? When you designedthe use cases, you must have realized that the use cases talk about "what are therequirements" of a system. The aim of designing classes is to convert this "what" to


17/59

a "how" for each requirement. Each use case is further analyzed and broken up intoatomic components that form the basis for the classes that need to be designed.

However, besides use cases, the artifacts of a project, such as stakeholder requests,(signed off) requirement documents, functional specifications, and a glossary ofterms for the project serve as other important inputs to the discovery of classes.

We will now see what the components of a class diagram are, and how to create aclass diagram.

Elements of a Class Diagram

A class diagram is composed primarily of the following elements that represent thesystem's business entities:

Class: A class represents an entity of a given system that provides an

encapsulated implementation of certain functionality of a given entity. Theseare exposed by the class to other classes as methods. Apart from businessfunctionality, a class also has properties that reflect unique features of a class.The properties of a class are called attributes. Simply put, individual membersof a family of our family tree example are analogous to classes in a classdiagram.

As an example, let us take a class named Student. A Student class representsstudent entities in a system. The Student class encapsulates studentinformation such as student id #, student name, and so forth. Student id,student name, and so on are the attributes of the Student class. The Studentclass also exposes functionality to other classes by using methods such asgetStudentName(), getStudentId(), and the like. Let us take a look at how aclass is represented in a class diagram.

A class is represented by a rectangle. The following diagram shows a typicalclass in a class diagram:

Figure 4.1.1the structure of a class

If you are familiar with object-oriented concepts, you will be aware of theconcept of access modifiers. You can apply access modifiers such as publicaccess, protected access, and private access applied to methods andattributes of a classeven to a class as well, if required. These access


18/59

modifiers determine the scope of visibility of the class and its methods andattributes.

You also can add documentation information to a class. Notes and constraintscan be added to a list of attributes. Notes contain additional information forreference while developing the system, whereas constraints are the business

rules that the class must follow, and are text included in curly brace brackets.

During the early phase of the system design conception, classes calledAnalysis classes are created. Analysis classes are also called stereotypes. Inthe UML context, stereotypes are UML models that that represent an existingUML element, while showing additional characteristics that are commonacross the classes to be used for that application. Only one stereotype can becreated for any UML element in the same system.

Analysis classes are of the following types as per their behavior, as shown inthe following table:

Class Behavior

Boundary In an ideal multi tier system, the user interacts only with theboundary classes. For example, JSPs in a typical MVC architectureform the boundary classes.

Control These classes typically don't contain any business functionality.However, their main task is to transfer control to the appropriatebusiness logic class, depending on a few inputs received from theboundary classes.

Entity These classes are those that contain the business functionality. Anyinteractions with back-end systems are generally done through theseclasses.

Interface: An interface is a variation of a class. As we saw from the previous

point, a class provides an encapsulated implementation of certain businessfunctionality of a system. An interface on the other hand provides only adefinition of business functionality of a system. A separate class implementsthe actual business functionality.

So, why would a class not suffice? You can define an abstract class thatdeclares business functionality as abstract methods. A child class can providethe actual implementation of the business functionality. The problem withsuch an approach is that your design elements get tied together in ahierarchy of classes. So, even though you may not have intended to connectyour design elements representing drastically different business entities, thatis what might result. Hence, the use of the interface design construct in classdiagrams. Different classes belonging to different and discrete hierarchies canmaintain their distinct hierarchies and still realize the functionality defined inthe methods of the interface.


19/59


20/59

star sign near thestudent class (one tomany, many tomany, and so forthkind of relations).

1 b. Directed Association Association betweenclasses is bi-directional bydefault. You candefine the flow of theassociation by usinga directedassociation. Thearrowhead identifiesthe container-containedrelationship.

1 c. Reflexive Association No separate symbol. However,the relation will point back atthe same class.

An example of thiskind of relation iswhen a class has avariety ofresponsibilities. Forexample, anemployee of acollege can be aprofessor, ahousekeeper, or anadministrativeassistant.

2 Aggregation When a class isformed as acollection of otherclasses, it is calledan aggregationrelationship betweenthese classes. It isalso called a "has a"relationship.

2 a. Composition Composition is avariation of theaggregationrelationship.Compositionconnotes that astrong life cycle isassociated betweenthe classes.


21/59

3 Inheritance/Generalization Also called an "is a"relationship, becausethe child class is atype of the parentclass. Generalizationis the basic type of

relationship used todefine reusableelements in the classdiagram. Literally,the child classes"inherit" the commonfunctionality definedin the parent class.

4 Realization In a realizationrelationship, oneentity (normally aninterface) defines a

set of functionalitiesas a contract and theother entity(normally a class)"realizes" thecontract byimplementing thefunctionality definedin the contract.

Go to page: 1 2 Next

A Few Terms

Here are a few terms that we will be using to annotate our class diagrams. Youshould be familiar with them:

1. Responsibility of a class: It is the statement defining what the class isexpected to provide.

2. Stereotypes: It is an extension of the existing UML elements; it allows you todefine new elements modeled on the existing UML elements. Only onestereotype per element in a system is allowed.

3. Vocabulary: The scope of a system is defined as its vocabulary.4. Analysis class: It is a kind of a stereotype.5. Boundary class: This is the first type of an analysis class. In a system

consisting of a boundary class, the users interact with the system through theboundary classes.

6. Control class: This is the second type of an analysis class. A control classtypically does not perform any business functions, but only redirects to theappropriate business function class depending on the function requested bythe boundary class or the user.

7. Entity class: This is the third type of an analysis class. An entity class consistsof all the business logic and interactions with databases.
http://www.developer.com/design/article.php/10925_2206791_2http://www.developer.com/design/article.php/10925_2206791_2http://www.developer.com/design/article.php/10925_2206791_2http://www.developer.com/design/article.php/10925_2206791_2


22/59

Creating a Class Diagram

Class diagrams can be modeled by using any UML tool that supports class diagrams.We will be using the Poseidon Community Edition tool to draw the class diagram. Youcan use any tool that you are comfortable with.


Figure 4.1.3a screen shot of the Poseidon tool

The screen shot of the Poseidon tool in Figure 4.1.3 shows the different options tomodel class diagrams and establish relationships among the packages, classes, andinterfaces.

Some additional features that you can check in your modeling tool are:

Support for forward and reverse engineering for class diagrams. A fewsophisticated modeling tools also integrate with standard IDEs with supportfor round-trip engineering.

Documentation and report generation features

Dos and Don'ts
http://www.developer.com/img/articles/2003/05/14/UML04a03.gifhttp://www.developer.com/img/articles/2003/05/14/UML04a03.gifhttp://www.developer.com/img/articles/2003/05/14/UML04a03.gif


23/59

Classes in a class diagram should be descriptive and must be named after businessentities. Using business entities as names ensures greater readability of classdiagrams.

Relationships between classes may not be apparent in the first iteration. Revise andrefine your class diagrams to determine possible relationships during each iteration.

Designing is an incremental process and class diagrams are updated as the systemgets built. Hence, do not try to capture and freeze the class diagrams of a system inthe first pass.

Summary

Class diagrams are the basic building block used to define the design of a system.Today, we learned about the elements of a class diagramclasses, interfaces, andpackagesand the different types of relationships among these elements such asassociation, aggregation, composition, generalization, and realization.

4### point

Introduction

In the last article of this series, we saw what class diagrams were, and how to createclass diagrams. In today's article, we will see a practical example building on ourCourseware Management system case study.

Case studyCourseware Management System

The class diagram of our Courseware Management System case study can be builtafter a careful analysis of the requirements. In the previous article, we identified theprimary actors and use cases in the use case model of the case study. Because wedid much of the groundwork of our analysis while building the use case model, wewill use those analysis steps as the basis for identifying the classes and interfaces ofthis system.

Let us recap our analysis that we had performed when we designed the use casemodel. The following terms and entities specific to the system were identified from

the problem statement:

Courses and Topics that make up a course

Tutors who teach courses

Course administrators who mange the assignment of the courses to tutors

Calendar or Course Schedule is generated as a result of the

Students who refer to the Course schedule or Calendar to decide which

courses for which they wish to sign up


24/59

The potential actors of the system were:

Tutors


Students

And the use cases of the system were:

View courses




View tutors

Manage tutor information


Identifying classes of the Courseware Management

System

As we did in use case modeling, we will identify the classes and interfaces using anincremental approach.

1. Identify the "active" entities in the system

The basic rule that we learned until now for identifying classes and interfacesis that classes and interfaces reflect important entities of the business domainof the system being modeled. We will apply this rule to determine classes andinterfaces of the case study system. At first glance, the actors identified in theuse case appear to be prime candidates for being listed as potential classes.Even though we had excluded Students and Tutors from our final list ofactors, we will still include them in our list as potential classes. So, our firstlist of classes in the system appears to be:

o Course administrators

o Tutors

o Students

2. Identify business domain ("passive") entities in the system

But these are the "active" entities of the system. We had also identified"passive" elements in the system as well in the analysis for our use casemodel. These entities reflect the business domain and hence are potential

classes for our system.

o Courses

o Topics that make up a course

o Course calendar generated


25/59

Entities that reflect the business terms are also called business domain classesor just "domain classes." Some of the business domain classes hold transientdata and some hold persistent data for the application. Normally, such businessdomain classes map to either one or many database tables.

For example, in our case study, the Course class can be modeled as a database

table cms_course. The data in this table for a particular course will berepresented by an instance of the Course class and made available to the restof the application.

Our two-step process has definitely yielded promising results! We havecovered all the relevant items in our analysis. So, let us list the list of classesand interfaces that we have identified in the Courseware ManagementSystem.

o CourseAdministratoro Tutoro Student

o Courseo Topic

o CourseCalendar

3. Categorize and map the use cases and any relevant business functionality toeither the passive or active entities. These will become the business methodsof the classes in the system.

Classes encapsulate functionality. The classes that we have identified for theCourseware Management System also provide business functionality related

to the application. The functionality encapsulated by these classes is distinctin nature and differs from each class. Recall from our use case model, that,along with actors, we had identified a set of use cases that the actorsinteracted with. Let us try to associate them with our classes. Because ourprimary actor is the course administrator and the use cases were related tothis actor, we can directly map the use cases to the CourseAdministrator

class as methods.

ClassName Methods

CourseAdministrator viewCourses()manageCourse()manageTopic()

viewCourseCalendar()viewTutors()manageTutorInformation()assignTutorToCourse()

Go to page: 1 2 3 Next
http://www.developer.com/design/article.php/10925_2210821_2http://www.developer.com/design/article.php/10925_2210821_3http://www.developer.com/design/article.php/10925_2210821_2http://www.developer.com/design/article.php/10925_2210821_2http://www.developer.com/design/article.php/10925_2210821_3http://www.developer.com/design/article.php/10925_2210821_2


26/59

In addition to this, we also can determine some implicit functionality of classes thatreflect business entities. For example, what functionality should the Course class

provide? Intuitively, we would define the Course class to provide functionality to view

all courses in the system, ability to create new courses or modify information ofexisting courses, view the details of a particular course, or even remove a coursefrom the system. We expect the Course class to provide such business functionality

because the Course class reflects a business entity in the system. Hence, thesebecome the methods exposed by the Course class. So, we can now refine the class

diagram and add methods to each of these classes.

To cut a long story short, each of the classes that reflect business entities will providesimilar implicit business functionality. Let us list all such "implicit" functionality foreach of these classes.

ClassName Methods

Course viewAllCourses()viewCourseInformation()

createCourse()modifyCourse()removeCourse()

Topic viewAllTopics()viewTopicInformation()createTopic()

modifyTopic()removeTopic()

Tutor viewTutorInformation()createTutor()

modifyTutor()removeTutor()

CourseCalendar viewCourseCalendar()Student viewAllStudents()

viewStudentInformation()

Refine and revise the list of classes and interfaces

Revisit the class diagram and revise it by identifying shared features and/or commonfunctionality between classes or interfaces. These will translate into reusable piecesof code for your system. To some extent, we can say that CourseAdministrator,

Tutor, and Student are essentially users of the system. Hence, we can define a

shared parent class named User and define basic functionality like for example,

authentication, in the User class that can be inherited by the CourseAdministrator,Tutor, and Student classes. It is left to the design expertise to identify reusable

classes/functionality.

This completes our analysis of the problem statement to define the classes for theCourseware Management System.


27/59

Identifying relationships between the classes of theCourseware Management System

The next step after defining the classes of the Courseware Management System is todefine the relationships and dependencies between these classes and interfaces. To

define the relationships between the classes, we need to analyze theinterconnections between the classeswhether implicit or explicit. Relationshipanalysis can be broken up into three steps:

1. Identify relationships between "active" entities

Active entities normally share generalization relationships ("is-a"). Essentially,the common attributes and functionality between classes are defined in acommon parent class. All the related child classes inherit functionality fromthe parent class. Apart from generalization, a few active entities can also beinterconnected by a realization relationship. Recall that elements in arealization relationship implement declared functionality as a "contract." For

example, a set of classes may implement functionality declared as methods inan interface, and this can be modeled as a realization relationship betweenthe interface and the classes implementing the interface.

In our case study, we do not find an example of inheritance relationshipbetween the active entities such as Student, Tutor, and

CourseAdministrator or any realization relationships.

2. Identify relationships between "passive" business entities

Passive business entities frequently share plain association or aggregationrelationships ("has-a"). This is especially true because these business entities

are non-transactional in nature and reflect data more than behavior. It is byfar quite intuitive to identify aggregation as well as its variationscompositionrelationships for passive business entities.

Some of the classes in our case study do exhibit aggregation relationships.Because a set of topics makes up a course, we can define an aggregationrelationship between the Course and Topic classes. Moreover, we can define

this as a directed aggregation, meaning that you can check for the topics of acourse but not vice versa. Similarly, we can define a plain associationrelationship between the Course and Tutor classes and Course and Student

classes.

Identify relationships between "active" and "passive" entities

Relationships between active and passive entities can easily be represented usingdirected association. The directed association, a variation of the "vanilla" associationrelationship, provides easy identification of which is the container class and which isthe contained class. The CourseAdministrator class can be modeled to have a

directed association with the Course class. This association can be named as

"manages" because the course administrator manages courses as a business activity.In addition to this, because the course administrator also manages the tutor


28/59

information and topic information, we can model a directed relationship named as"manages" between the CourseAdministrator and the Course and Topic classes,

respectively. We can enhance the readability of the association betweenCourseAdministrator and the Course, Tutor, and Topic classes by defining the

multiplicity for the associationone to many, one to one, many to many, and soforth.

Class diagram


Figure 4.2.1 shows the class diagram for the Courseware Management System

We have completed identifying the classes for the Courseware Management Systemand established the relationships among the classes. Take a look at the class diagramin Figure 4.2.1. The class diagram of the Courseware Management System includesall the classes and their relationships that we identified during our analysis of theproblem statement.

Model View Controller Design

The class diagram that we designed for the Courseware Management System definedthe basic classes necessary for representing the basic structure of the system. But thisis by no means a complete design if the architecture of your system is to be based onthe Model View Controller (MVC) architecture. Because an MVC model defines clearseparation of classes among the three layersbusiness, presentation, and flow controlyou need to define additional classes and revise your design to include them. In caseyour UML tool does not support explicit partitioning of classes, you can mark classes ineach of the layers using stereotypes such as , ,, and so forth.
http://www.developer.com/img/articles/2003/05/21/UML/UML04b1.gifhttp://www.developer.com/img/articles/2003/05/21/UML/UML04b1.gifhttp://www.developer.com/img/articles/2003/05/21/UML/UML04b1.gif


29/59

For example, in our case study application, we can revise the class diagram to define anew CMSController class that manages the flow of the application. The model layer

primarily consists of classes relevant to the business domain. Next, the classes that wehad defined can be categorized as transactional and persistent classes. The

CourseAdministrator class performs most of the activities in the system. Hence, this

class can be designated as a transaction class of the model layer. Similarly, theCourse, Topic, Tutor, CourseCalendar, and Student classes represent persistent

business data. Hence, these can be categorized as persistent classes of the modellayer. Finally, you can define a set of classes that represent the presentation layer; inother words, the user interface of the system.

Forward Engineering from Class Diagrams

Forward engineering is the process of generating source code (in a specific language)from a class diagram model. The extent to which a UML class diagram can be used togenerate source code depends upon the limitations of the source code language.

Because UML is pictorial, and can depict a lot of details, these details could be lost inthe code. Hence, before creating a complete class model, it is a good idea to beaware of the language that is going to be used, to limit the class model accordingly.Typically, the association relationships between classes are generated as membervariables between the related classes in the source code. Generalization relationshipsare generated as inheritance relationships in the source code.



30/59

Figure 4.2.2 shows forward engineering a class diagram

The above screenshot shows the source code file generated for theCourseAdministrator Java source code file as a result of forward engineering the

class diagram of the Courseware Management System case study. You need to checkhow forward engineering works in the tool that you use.

Reverse Engineering of Class Diagrams

Obtaining a class model from existing source code is called reverse engineering. Thisis generally done when it is required to understand the architecture of an existingsystem, either for re-engineering, or for maintenance. Reverse engineering is ofgreat use especially when trying to figure out the static structure and organization ofa complex system. Typically, classes defined as member variables in the source codeare modeled as association relationships between the classes. Inheritancerelationships in the source code are generated as generalization relationshipsbetween the classes.


Figure 4.2.3 shows reverse engineering a sample source code file

The above screenshot shows a class diagram generated as a result of reverseengineering a sample source code file. You need to check how reverse engineeringworks in the tool that you use.


31/59

Summary

In the last article, we saw how class diagrams are the basic building blocks thatdefine the design of a system. We learned about the elements of a class diagramclasses, interfaces, and packagesand the different types of relationships amongthese elements, such as association, aggregation, composition, generalization, andrealization.

Today, we defined a few steps to identify classes and interfaces of a system from aproblem statement for designing the class diagram for the Courseware ManagementSystem case study.

5### point

Introduction

In the last article, you saw how your application could be represented in a classdiagram. A class diagram is a static representation of your system. It shows thetypes of classes, and how these classes are linked to each other. In this edition of ourseries we introduce the object diagram.

Basics

Although we design and define classes, in a live application classes are not directlyused, but instances or objects of these classes are used for executing the businesslogic. A pictorial representation of the relationships between these instantiatedclasses at any point of time (called objects) is called an "Object diagram." It looksvery similar to a class diagram, and uses the similar notations to denoterelationships.

If an object diagram and a class diagram look so similar, what is an object diagramactually used for? Well, if you looked at a class diagram, you would not get thepicture of how these classes interact with each other at runtime, and in the actual

system, how the objects created at runtime are related to the classes. An objectdiagram shows this relation between the instantiated classes and the defined class,and the relation between these objects, in the logical view of the system. These arevery useful to explain smaller portions of your system, when your system classdiagram is very complex, and also sometimes recursive.

Let us now see what the components of an object diagram are. After this, we willbuild an object diagram for our case studyCourseware Management system.


32/59

Elements of an Object Diagram

Because an object diagram shows how specific instances of a class are linked to eachother at runtime, at any moment in time it consists of the same elements as a classdiagram; in other words, it contains classes and links showing the relationships.However, there is one minor difference. The class diagram shows a class withattributes and methods declared. However, in an object diagram, these attributesand method parameters are allocated values.

As an example, in the last article, a class diagram for a multiplicity relation betweencollege and students was shown, as you cam see in Figure 5.1:

Figure 5.1an example College-Student class diagram

This class diagram shows that many students can study in a single college. Now, ifwe were to add attributes to the classes "College" and "Student," we would have adiagram as shown in Figure 5.2:

Figure 5.2the class diagram with attributes

Now, when an application with the class diagram as shown above is run, instances ofCollege and Student class will be created, with values of the attributes initialized. Theobject diagram for such a scenario will be represented as shown in Figure 5.3:


33/59


Figure 5.3the object diagram for the College-Student class diagram

As can be seen from Figure 5.3, the object diagram shows how objects areinstantiated in the running system represented by the College-Student classdiagram. The class diagram shows that a single college has many students, anddefines the variables. The object diagram for the same system shows instantiatedclasses of Student (Student #1 and Student #2) enrolled in College (GraduateSchool of Business).

The object diagram shows the name of the instantiated object, separated from theclass name by a ":", and underlined, to show an instantiation.Eg. Graduate School of Business: College

In the diagram, values are assigned to variables and represented using the notationvariable name=variable value.

This example was the representation of the relation of only two classes with eachother. However, in a real application system, there will be multiple classes. An objectdiagram then shows the relation between the instantiations of these classes. We shallsee this in our case study.

A class that defines the flow of the system is called as an active class. This classinstance in the object diagram is represented by thick border. In an MVC applicationarchitecture, the controller servlet is the action class, and is denoted by a thickerborder. Also, multiple instances of the same class, as in a factory pattern, if the

attributes of the individual objects are not important, or are not different, these canbe represented by a single symbol of overlapping rectangles (see Figure 5.4):

Figure 5.4the object diagram for a Factory class
http://www.developer.com/img/articles/2003/06/17/UML0503.jpghttp://www.developer.com/img/articles/2003/06/17/UML0503.jpghttp://www.developer.com/img/articles/2003/06/17/UML0503.jpg


34/59

A class that performs more than one role, and is self-linked, is represented by acurve starting and ending on itself, as illustrated in Figure 5.5:

Figure 5.5the object diagram for a self-linked class

Object Diagrams in UMLBy Mandar Chitnis, Pravin Tiwari, & Lakshmi Ananthamurthy

Go to page:Prev 1 2 3 Next

Creating an Object Diagram in Poseidon

In Poseidon, you will find the option to create object diagrams clubbed with theoption to create deployment and component diagrams. Presently, Poseidon does notsupport display of attributes and methods in the object diagram; in other words, youcan as of now only define an object of class, its type, and the linked objects. Hence,for our case study, we will use Microsoft Word to create an object diagram.

The steps for creating an object diagram in Poseidon are as follows:

1. Open your Poseidon project file (the .zargo file) in which you created yourclass diagram earlier.

2. Make sure you are viewing your class diagram in the "Package centric,""Diagram centric," or "Inheritance centric" modes to view the deployment

diagram. See Figure 5.6.
http://www.developer.com/feedback.php/http:/www.developer.com/design/article.php/2223551http://www.developer.com/design/article.php/10925_2223551_1http://www.developer.com/design/article.php/10925_2223551_1http://www.developer.com/design/article.php/10925_2223551_3http://www.developer.com/design/article.php/10925_2223551_3http://www.developer.com/feedback.php/http:/www.developer.com/design/article.php/2223551http://www.developer.com/design/article.php/10925_2223551_1http://www.developer.com/design/article.php/10925_2223551_1http://www.developer.com/design/article.php/10925_2223551_3http://www.developer.com/design/article.php/10925_2223551_3


35/59


Figure 5.6the creation of an object diagram in Poseidon

3. Click on Create diagram -> Deployment/Object/Component diagram (orCtrl+D) in the menu bar above.

4. Click on the object icon (shown in the black circle) in the icon menu bar onthe top, to create an object. See Figure 5.7.

5. Fill in the Name of the Object instantiated, in the properties bar below. Selectthe class of which this object is an instance, in the area titled "Type."

6. After creating all the objects, click on the icon for "link" (shown in the redcircle in Figure 5.7) to link the objects. Give the name of the link.

7. In case of our Case study, if we show an object diagram for theCourseAdministrator managing the Courses scenario, we get a diagram asshown in Figure 5.7.


36/59


Figure 5.7the object diagram in Poseidon for the case studyCourseware management system

Dos and Don'ts

Dos

1. Use the object diagram as a means of debugging the functionality of yoursystem.

2. Object diagrams can also be used to check whether the system has beendesigned as per the requirements, and behaves how the businessfunctionality needs the system to respond.

3. Show associations of any kind between objects as linkages (for example, asingle segment joining two objects, without arrows), and not as a dependencyor any other specific type of association. An object diagram only shows thelinkages, but not the type of association.

Don'ts

1. Avoid representing all the objects of your system in an object diagram.Because an object diagram represents the state of objects, it can becomequite complex if you try to represent all the objects. Hence, it is always betterto represent the state of objects in certain important/critical flows in yourapplication using an object diagram. This will keep your object diagram


37/59

readable, yet useful enough to capture the state of objects that areimportant.

2. Because object diagrams represent the state of objects, forward engineeringof object diagrams does not make sense.

Case Study: Courseware Management System

Now, we shall create an object diagram for the courseware system. To do this, wewill first build up on our class diagram, and include the possible attributes and definethe parameters of to the classes defined earlier.

We will follow the following convention for the variable names:Names starting with "s_" are of the String data typeNames starting with "i_" are of the int data typeNames starting with "v_" are of the Vector data type

The following table outlines the attributes, methods, and their return types for eachof the classes:

Class Name Attributes Methods

CourseAdministrator s_adminIdv_coursess_courseIdv_tutorsv_tutorInfos_tutorIdv_topicss_topicId

Vector viewCourses()Vector manageCourse(s_courseId)Vector manageTopic(s_topicId)Vector viewCourseCalendar(s_courseId)Vector viewTutors()Vector manageTutorInformation(s_tutorId)Boolean assignCourseToTutor(s_courseId,s_tutorId)

Student s_studentId

v_studentInfov_studentList

Vector viewAllStudents()

Vector viewStudentInformation(s_studentId)

Tutor s_tutorIdv_tutorInfov_tutorList

Vector viewTutorInformation(s_tutorId)String createTutor(v_tutorInfo)Boolean modifyTutor(v_newTutorInfo)Boolean removeTutor(s_tutorId)

Course s_courseIdv_courseListv_courseInfo

Vector viewAllCourses()Vector viewCourseInfo(s_courseId)Boolean createCourse(v_courseInfo)Boolean modifyCourse(v_newCourseInfo)Boolean removeCourse(s_courseId)

Topic s_topicIdv_topicListv_topicInfo

Vector viewAllTopics()Vector viewTopicInformation(s_topicId)Boolean createTopic(v_topicInfo)Boolean modifyTopic(v_newTopicInfo)Boolean removeTopic(s_topicId)

CourseCalender v_courseCalendar Vector viewCourseCalendar(s_courseId)


38/59

To follow a logical sequence now, let us consider that the course administrator,courses, tutors, and topics already exist. Let us now make an object diagram for thecase where the administrator with user id "admin" wishes to access the coursecalendar of a course with course id "Math_Course_001."

Hence, the following will be the attribute values, and method calls:

CourseAdministratorAttributes: s_adminId = admin

s_courseId = Math_Course_001Methods: viewCourseCalendar("Math_Course_001")

This method will call the method viewCourseInfo of class Course, which returns aVector object populated with all the details of the course "MathCourse_001" (seeFigure 5.8)

CourseMethods: viewCourseInfo("Math_Course_001")


Figure 5.8the object diagram for the courseware management system, fora simple scenario of the course administrator managing a math course.

In Figure 5.8, for the single case where the flow is from Course Administrator toCourse, when the CourseAdministrator is requesting the course information for aparticular course.

Summary

In the last article, we saw how to make class diagrams, and made a class diagramfor the case studythe Courseware Management system. In this article, we saw:

What an object diagram is

Notation used in an object diagram

What the significance and use of an object diagram is

How to make an object diagram in Poseidon

The object diagram for a simple scenario in our Courseware Management

system


39/59

6 #### point

State Diagram in UMLBy Mandar Chitnis, Pravin Tiwari, & Lakshmi Ananthamurthy


In the previous article, we saw what Object diagrams are, the notations to be used inObject diagrams, their significance, and how to make an Object diagram usingPoseidon. We then made an Object diagram for our Courseware ManagementSystem. By the end of this article, you will know what a State diagram is, what itselements are, and you will be able to create State diagrams for your system.

The Basics

Until now, we have seen Use Cases, Class diagrams, and Object diagrams. These

diagrams give an architectural and high-level view of a system. In a typical softwarelife cycle, the business or functional domain experts define Use Case diagrams. TheClass diagrams and Object diagrams are made by senior-level developers, with thehelp of system architects. Once this has been accomplished, and the system designand architecture is in place, these artifacts are passed on to the developer, whoactually codes the system. All the above diagrams arestaticdiagrams, which meansthat they help in visualizing what the elements of the complete system would be, butdo not say anything about the flows any object of the system can have when anevent occurs. Structural elements are used to depict static diagrams.

While coding, it is necessary to understand the details of the modes an Object of aClass can go through and its transitions at time intervals with the occurrence of anyevent or action.

State diagrams (also called State Chart diagrams) are used to help the developerbetter understand any complex/unusual functionalities or business flows ofspecialized areas of the system. In short, State diagrams depict the dynamicbehavior of the entire system, or a sub-system, or even a single object in a system.This is done with the help ofBehavioral elements.

It is important to note that having a State diagram for your system is not acompulsion, but must be defined only on a need basis.

Defining a State diagram

Just as we define classes for a Class diagram, it is necessary to define the elementsof a State diagram. Let us first see what the elements of a State diagram are.

Elements of a State diagram

A State diagram consists of the following behavioral elements:
http://www.developer.com/feedback.php/http:/www.developer.com/design/article.php/2238131http://www.developer.com/design/article.php/10925_2238131_2http://www.developer.com/design/article.php/10925_2238131_2http://www.developer.com/design/article.php/2223551http://www.developer.com/feedback.php/http:/www.developer.com/design/article.php/2238131http://www.developer.com/design/article.php/10925_2238131_2http://www.developer.com/design/article.php/10925_2238131_2http://www.developer.com/design/article.php/2223551


40/59

Element and its Description Symbol

Initial State: This shows the starting point or first activity ofthe flow. Denoted by a solid circle. This is also called as a"pseudo state," where the state has no variables describing itfurther and no activities.

State: Represents the state of object at an instant of time. In astate diagram, there will be multiple of such symbols, one foreach state of the Object we are discussing. Denoted by arectangle with rounded corners and compartments (such as aclass with rounded corners to denote an Object). We willdescribe this symbol in detail a little later.

Transition: An arrow indicating the Object to transition fromone state to the other. The actual trigger event and actioncausing the transition are written beside the arrow, separatedby a slash. Transitions that occur because the state completedan activity are called "triggerless" transitions. If an event hasto occur after the completion of some event or action, the event

or action is called the guard condition. The transition takesplace after the guard condition occurs. This guardcondition/event/action is depicted by square brackets aroundthe description of the event/action (in other words, in the formof a Boolean expression).

History States: A flow may require that the object go into atrance, or wait state, and on the occurrence of a certain event,go back to the state it was in when it went into a wait stateitslast active state. This is shown in a State diagram with the helpof a letter H enclosed within a circle.

Event and Action: A trigger that causes a transition to occur iscalled as an event or action. Every transition need not occurdue to the occurrence of an event or action directly related tothe state that transitioned from one state to another. Asdescribed above, an event/action is written above a transitionthat it causes.

Signal: When an event causes a message/trigger to be sent toa state, that causes the transition; then, that message sent bythe event is called a signal. Represented as a class with the icon above the action/event.

Final State: The end of the state diagram is shown by a bull's

eye symbol, also called a final state. A final state is anotherexample of a pseudo state because it does not have anyvariable or action described.

Note: Changes in the system that occur, such as a background thread while themain process is running, are called "sub states." Even though it affects the mainstate, a sub state is not shown as a part of the main state. Hence, it is depicted ascontained within the main state flow.


41/59

As you saw above, a state is represented by a rectangle with rounded edges. Withina state, its Name, variables, and Activities can be listed as shown in Figure 6.1.

Figure 6.1: the structure of the state element

Creating a State Diagram

Let us consider the scenario of traveling from station A to station B by the subway.Figure 6.2 would be a state diagram for such a scenario. It represents the normalflow. It does not show the sub states for this scenario.


Figure 6.2: an example flow in a state diagram

Things to Remember

Create state diagrams when the business logic for a particular flow is very complex,or needs greater understanding by the developer to be coded perfectly.

Arrange the states and transitions to ensure that the lines that cross each other areminimal. Criss-crossing lines are potential sources of confusion in conveying thediagram's meaning

Case StudyCourseware Management System

Because our Courseware Management System case study does not undergo anynoticeable state changes, we will drill down our attention to the Course object in thesystem. Recall that a state diagram can be defined not only for a system orsubsystem, but also for an object in the system.
http://www.developer.com/img/articles/2003/07/21/UML0602.gifhttp://www.developer.com/img/articles/2003/07/21/UML0602.gifhttp://www.developer.com/img/articles/2003/07/21/UML0602.gif


42/59

Identifying states and events of the Course object

The Course object does undergo state changes during its lifecycle, right from coursecreation to deleting a course. Let us depict the Course object's lifecycle by using astate diagram to understand it better. The events that occur in the lifecycle of theCourse object are listed below:

Create new courseadd information for the course or update an existing

course; update information for the course Add topicsadd topics to the course

Assign tutorsassign the available tutors for the course

Closefinished adding or updating the course

Consider the event of adding a new course to the Courseware Management Systemby the course administrator. The course administrator fills in the course information,thus initiating the creation of the Course object.

This event kicks off two events that change the state of the Course object, but arepart of the new course event. These two events contained within the new coursecreation event are adding topics to the Course object and assigning tutors for thecourse. This results in the Topic objects getting associated with the Course object.Next, the course administrator may wish to assign tutors to teach the course byidentifying the tutors that teach this course (based on their specialty/preferences)and checking the availability of the tutors for a given period of time.

This completes the lifecycle Course object until the time an update course eventoccurs.

Figure 6.3 shows the state diagram for the Course object. The state diagram depictsthe changes in the state of the Course object as it transitions through the variousevents in its lifecycle.

http://www.developer.com/img/articles/2003/07/21/UML0603.gifhttp://www.developer.com/img/articles/2003/07/21/UML0603.gifhttp://www.developer.com/img/articles/2003/07/21/UML0603.gif


43/59

Figure 6.3: the state diagram of the Course object

Summary

This article covered the first of the series of dynamic diagrams in UML. The statediagram is one of the simplest ways to represent the lifecycle of an entire system ora subsystem or even an object of a system. In the next article of this series, we willlearn about Activity diagrams.

7#### point

Activity Diagram in UMLBy Mandar Chitnis, Pravin Tiwari, & Lakshmi Ananthamurthy


In the previous article, we learned about State diagrams, the notations to be used inState diagrams, their significance, and how to build a State diagram for a specificscenario in our Courseware Management system.

In this article, we will cover the next dynamic diagramthe Activity diagram. By theend of this article, you will know what an Activity diagram is, what its elements are,and you will be able to create Activity diagrams for your system.

Basics

The easiest way to visualize an Activity diagram is to think of a flowchart of a code.The flowchart is used to depict the business logic flow and the events that cause

decisions and actions in the code to take place.

Activity diagrams represent the business and operational workflows of a system. AnActivity diagram is a dynamic diagram that shows the activity and the event thatcauses the object to be in the particular state.

So, what is the importance of an Activity diagram, as opposed to a State diagram? AState diagram shows the different states an object is in during the lifecycle of itsexistence in the system, and the transitions in the states of the objects. Thesetransitions depict the activities causing these transitions, shown by arrows.

An Activity diagram talks more about these transitions and activities causing the

changes in the object states.

Defining an Activity diagram

Let us take a look at the building blocks of an Activity diagram.
http://www.developer.com/feedback.php/http:/www.developer.com/design/article.php/2247041http://www.developer.com/design/article.php/10925_2247041_2http://www.developer.com/design/article.php/10925_2247041_2http://www.developer.com/feedback.php/http:/www.developer.com/design/article.php/2247041http://www.developer.com/design/article.php/10925_2247041_2http://www.developer.com/design/article.php/10925_2247041_2

uml classes online material

Documents