Deployment Diagram

A UML deployment diagram depicts a static view of the runtime configuration of hardware nodes and the software components that run on those nodes. UML deployment diagrams show the hardware for our system, the software that is being installed on that hardware, and the middleware used to connect the disparate machines to one another. We create a UML deployment model to

·         explore the issues involved in installing your system into production,

·         explore the dependencies that your system has with other systems that are currently in, or planned for, your production environment,

·         depict a major deployment configuration of a business application,

·         design the hardware and software configuration of an embedded system, or

·         depict the hardware/network infrastructure of an organization.

The are 2 main element in the deployment diagram, these are :

·         Node

·         Communication path

A node is something that can host some software. Nodes come in two forms. A device is hardware, it may be a Computer or a simpler piece of hardware connected to a system. An execution environment is software that itself hosts or contains other software, examples are an operating System or a Container process.

The nodes contain artifacts, which are the physical manifestations of software: usually, files. These files might be executables (such as .exe files, binary files, DLLs, JAR files, assemblies, or scripts), or data files, configuration files, HTML documents, and so on. Listing an artifact within a node shows that the artifact is deployed to that node in the running system.

You can show artifacts either as class boxes or by listing the name within a node. If you show them as class boxes, you can add a document icon or the «artifact» keyword. You can tag nodes or artifacts with tagged values to indicate various interesting information about the node, such as vendor, operating system, location, or anything else.

We may have multiple physical nodes carrying out the same logical task. We can either show this with multiple node boxes or state the number as a tagged value. We used the tag number deployed to indicate four physical Web Servers, but there is no standard tag for this.

Communication paths between nodes indicate how things communicate. We can label these paths with information about the communication protocols that are used.

There are two types of connectors used between nodes and artifacts in a deployment diagram. The association represents a communication path between nodes. The association shows the nodes that communicate, and a label on the association can be used to show the communications protocol between nodes. Additionally, an artifact can be drawn outside a node (some tools does not support nesting artifacts in nodes) and attached to a node with a dependency and a «deploy» stereotype. The deploy dependency between an artifact and a node means the same thing as a nested artifact or a listed text artifact—that that kind of artifact is deployed on that kind of node

Common Stereotypes for Communication paths

 

Stereotype	Implication
asynchronous	An asynchronous connection, perhaps via a message bus or message queue.
HTTP	Hypertext Transport Protocol, an Internet protocol.
JDBC	Java Database Connectivity, a Java API for database access.
ODBC	Open Database Connectivity, a Microsoft API for database access.
RMI	Remote Method Invocation, a Java communication protocol.
RPC	Communication via remote procedure calls.
Synchronous	A synchronous connects where the sender waits for a response from the receiver.
web services	Communication is via Web services protocols such as SOAP and UDDI.

 

Package Diagram

Classes represent the basic form of structuring an object-oriented System. Although they are wonderfully useful, we need something more to structure large Systems, which may have hundreds of classes.

A package is a grouping construct that allows you to take any construct in the UML and group its elements together into higher-level units. Its most common use is to group classes.

In a UML model, each class is a member of a single package. Packages can also be members of other packages, so we are left with a hierarchic structure in which top-level packages get broken down into sub packages with their own sub packages and so an until the hierarchy bottoms out in classes. A package can contain both sub packages and classes.

Each package represents a namespace, which means that every class must have a unique name within its own package.

Suppose, if we want to create a class called Date, and a Date class is already in the System package, we can have Date class as long as we put it in a separate package. To make it clear which is which, we can use a fully qualified name, that is, a name that Shows the owning package structure. We use double colons to Show package names in UML, so the dates might be System::Date and myPackage::Util::Date.

In diagrams, packages are shown with a tabbed folder. We can simply Show the package name or show the contents too. At any point, we can use fully qualified names or simply regular names. Showing the contents with class icons allows us to Show all the details of a class, even to the point of showing a class diagram within the package. Simply listing the names makes sense when all we want to do is indicate which classes are in which packages. UML allows classes in the package can be public or private.

 

The contents of a package can be drawn inside the package or outside the package attached by a line. If we draw the elements inside the package, write the name of the package in the folder tab.

Element Visibility

Elements in a package may have public or private visibility . Elements with public visibility are accessible outside the package. Elements with private visibility are available only to other elements inside the package. We can model public or private visibility in UML by writing a plus or minus symbol in front of the element's name

Package Dependency

Sometimes a class in one package needs to use a class in another package. This causes a dependency between packages : if an element in package A uses an element in package B, then package A depends on package B

Understanding the dependencies among packages is useful for analyzing the stability of software. In fact, the most common use of UML package diagrams is to give an overview of the core packages in our software and the dependencies among them. Packages can assist with organizing classes as deployment modules and in creating the build scripts.

Importing a package

When a package imports another package, elements in the importing package can use elements in the imported package without having to use their fully scoped names. This feature is similar to a Java import, in which a class can import a package and use its contents without having to provide their package names.

In an import relationship, the imported package is referred to as the target package. To show the import relation, draw a dependency arrow from the importing package to the target package with the stereotype import.

The package users imports security, so classes in users may use public classes in security without having to specify the package name

A package can also import a specific element in another package instead of the whole package. When importing a package, only public elements of the target package are available in the importing namespace.

 

The users package imports only the MyClassA element from the myPackage package

 

When to Use Package Diagrams

Package diagrams are extremely useful on larger-scale systems to get a picture of the dependencies between major elements of a system. These diagrams correspond well to common programming structures. Plotting diagrams of packages and dependencies helps to keep an application's dependencies under control.

 

 

 

Component Diagram

UML component diagrams show the dependencies among software components, including the classifiers that specify them, such as implementation classes; and the artifacts that implement them; such as source-code files, binary-code files, executable files, scripts, and tables. Create them to

·         model the low-level design configuration of your system,

·         model the technical infrastructure

·         model the business/domain architecture for your organization

Good candidates for components are items that perform a key functionality and will be used frequently throughout our system. Software, such as loggers, XML parsers, or online shopping carts, are components we may already be using. These happen to be examples of common third-party components, but the same principles apply to components we create our self.

In system, we might create a component that provides services or access to data. For example, in a CMS we could have a conversion management component that converts blogs to different formats, such as RSS feeds.

Since components are major players in software design, it is important that they are loosely coupled so that changes to a component do not affect the rest of the system. To promote loose coupling and encapsulation, components are access through interfaces.

Elements of Component diagram

A component is drawn as a rectangle with the <<component>> stereotype and an optional tabbed rectangle icon in the upper righthand corner.

 

We can show that a component is actually a subsystem of a very large system by replacing <<component>> with <<subsystem>>. A subsystem is a secondary or subordinate system that's part of a larger system.

Provided and Required Interfaces in Component

Components need to be loosely coupled so that they can be changed without forcing changes on other parts of the system this is where interfaces come in. Components interact with each other through provided and required interfaces to control dependencies between components and to make components swappable.

A provided interface of a component is an interface that the component realizes. Other components and classes interact with a component through its provided interfaces . A component's provided interface describes the services provided by the component.

A required interface of a component is an interface that the component needs to function. More precisely, the component needs another class or component that realizes that interface to function. But to stick with the goal of loose coupling, it accesses the class or component through the required interface. A required interface declares the services a component will need.

There are three standard ways to show provided and required interfaces in UML: ball and socket symbols, stereotype notation, and text listings.

We can show a provided interface of a component using the ball symbol. A required interface is shown using the counterpart of the ball, the socket symbol drawn as a semicircle extending from a line. Write the name of the interface near the symbols.

Stereotype notation can be used to show required and provider interfaces. This notation is helpful if you want to show the operations of interfaces. If not, it is best to use the ball and socket notation, since it shows the same information more compactly.

When to use Component Diagram

Use component diagrams when you are dividing your System into components and want to show their interrelationships through Interfaces or the breakdown of components into a lower-level structure.

 

Collaboration Diagram

A collaboration diagram— a.k.a as communication diagram in UML version 2.0— conveys the same information as a sequence diagram. Where time ordering is implicit in the linear layout of a sequence diagram, we explicitly indicate the time ordering by numbering the messages in geometrically organized collaboration diagrams.

Key symbols in collaboration diagrams are the rectangle, called a classifier role, and a line indicating the message, again called a connector. The classifier role represents the objects. Connectors represent connected objects, and a named arrow indicates the message as well as the sender and receiver.

As you can see, the collaboration has the same elements but fewer details. The compact nature and fewer elements make collaborations convenient when doodling designs.

To read the diagram, start with message 1 and follow the messages by number. Collaborations are not meant to use interaction frames and, as a result, don't convey as much information as the sequence diagram.

TIP: Consider using collaboration diagrams when working on a whiteboard or napkins or wherever you doodle your inspired designs. The compact nature and fewer adornments of collaboration diagrams make them more manageable when designing manually.

Comparing Sequence and Collaboration diagrams

Feature	Sequence Diagram	Collaboration Diagram	Remarks
Shows participants effectively	Participants are mostly arranged along the top of page. It is easy to gather the participant involved in a particular interaction	Participants as well as links are the focus, so they are shown clearly as rectangle	Collaboration diagram win. Although both type of diagram can show participants as effectively as each other, it can be argued that collaboration diagrams have edge since participants are one of their focuses.
Showing the links between  participants	Links are implied. If a message is passed from one participant to another, then it is implied that a link must  exist between those participants.	Explicitly shows the links between participants. In fact, this is the primary purpose of these types of diagram.	Collaboration diagrams win because they explicitly and clearly show the links between participants.
Showing message signature	Message signatures can be fully described.	Message signatures can be fully described.	Both are good
Support parallel messages	With the introduction of sequence fragments, sequence diagrams are much better.	Shown using the number-letter notation on the message sequences.	Both are good
Support asynchronous  message	Achieved using the asynchronous arrow.	Collaboration diagrams have no concept of the asynchronous messages, since its focus is not on the message ordering	Sequence diagrams are the clear winner because they explicitly support asynchronous messages
Easy to read message ordering	Sequence diagram clearly show message ordering	Shown using the number notation	Sequence diagrams are a clear winner here since they really show off message ordering clearly and effectively.
Easy to create and maintain the diagram	Creating a sequence diagram is simple. However maintaining sequence diagram can be a difficult unless a UML tool is being used	Collaboration diagrams are simple to create, however maintenance is difficult if we need to change the message numbering.	This is difficult to judge and large based on the personal choice.

Sequence Diagram

There are two comman interaction diagram

·         Sequence Diagram

·         Communication Diagram (a.k.a Collabaration diagram)

These two diagram tell excatly the same meaning in the anaylsis and design of system and any of these two diagram are need not both

Sequence diagram have have an explict time ordering and are linear where as in communication diagram have labelled time ordering and are geometric.

Interaction diagrams provide you with enough information to begin coding. The objects are instances of classes, so you need to define a class for each object. Messages generally equate to methods, and the method is placed in the class of the receiver (not the caller).

Sequence Diagram: Sequence are more comman, easy to create and are naturally organized and we don’t need to indicate the time ordering by annotating the meassages.

Elements of the Sequence Diagrams

Object lifeline: A lifeline is a rectangle with a verical line descending from the rectangle. The lifeline represens an instance of a class and the verticall descending line is a convenient place to attache incoming and outgoing messages. Adding multiple lifeline to a single diagram and attaching these to the time ordered message permits you to show all the classes and messages mecessary to complete a scenario described by use case. By eliminating ambiguous gaps or avoiding the repetition of classed and messages, you can get a whole solution, one scenario at a time.

Object lifelins can represent actors or objects. Both actors and object may or may not be actualized as code.

 

 

Activating lifeline : Objects have a lifetime. In the java implementation langauge, we create a object and we cann’t destroy the object. Destroying the objects is job of the garbage collector. But from the modeller (design) perspective we only care whe we begin using an object and when we are done using an object unless the object represents a finite resource. In both cases, the activation line represent the span of an object’s lifetime or scope for the practical purposes. It is also important to know than an object can be represented as being created and destroyed using a single lifeline.

The activation symbol is a vertical rectangle replacing the lifeline for the duration of that instance’s existence, keeping in mind that an object can be created and destroyed multiple times and that one lifeline is used to represent all instances of that class in a sequence

 

Sending Messages: Messages are directed lines connecting lifelines. The lines begins at one lifeline and the arrow points toward a lineline containing the message invoked. The message can begin and end on the same lifeline, this is a nested call. A filled-in triangle arrow head represents a synchronousmessage. A stick triangle arrow head represent an asynchronous message. A dashed line represents the return messages.

The other type of messages used in sequence diagram are:

Found Messages : A found message is a message with a known receiver but the sender is not known

Lost messages : A lost message is message with a know sender but there is not specified receiver.

Interaction Frame:

Interaction frames (or combined fragments) are new in UML version 2.0. Interaction frames are rectangular regions used to organize interaction diagrams (sequence and timing diagrams). Interaction frames can surround an entire interaction diagram or just part of a diagram. Each interaction frame is tagged with a specific word (or an abbreviated form of that word), and each kind of interaction frame conveys some specific information.

Alt	Alternatives fragments (i.e. conditional logic) only guard conditions evaluating to true will be execute
Loop	The guard indicates how many times this part will execute.
Neg	An invalid interaction
Opt	Equivalent to an alt with one condition (i.e. an if condition with no else statement
Par	Fragments run in parallel (multithreading)
Ref	Reference to an interaction defined on another diagram
Region	Critical region
Sd	Used to surround an entire sequence diagram, if desired.

 

  

Interaction frame diagram showing the loop frame

Complete sequence diagram example

 

Use Case Diagram

The Unified Modeling Language (UML) supports object-oriented analysis and design by providing you with a way to capture the results of analysis and design. In general, we start with understanding our problem, i.e., analysis. An excellent type of model for capturing analysis is the use case diagram.

The purpose of a use case is to describe how a system will be used—to describe its essential purposes. The purpose of use case diagrams is to capture the essential purposes visually.

A use case illustrates a unit of functionality provided by the system. The main purpose of the use-case diagram is to help stakeholder visualize the functional requirements of a system, including the relationship of "actors" (human beings who will interact with the system) to essential processes, as well as the relationships among different use cases. Use-case diagrams generally show groups of use cases — either all use cases for the complete system, or a breakout of a particular group of use cases with related functionality. To show a use case on a use-case diagram, you draw an oval in the middle of the diagram and put the name of the use case in the center of the oval. To draw an actor (indicating a system user) on a use-case diagram, you draw a stick person to the left or right of your diagram  Use simple lines to depict relationships between actors and use cases, as shown in image1.

Symbols used in Use Case diagrams:

Actor - The stick figure, referred to as an actor, represents participants in use cases. Actors can be people or any other system/subsystem/cron jobs/schedule jobs.

Actors are discovered as a result of analysis. As you are identifying the macro uses of the system, you will identify who the participants for those use cases are. Initially, record each actor as it is discovered by adding an actor symbol to your model and describing what the actor's role is.

Actor in Use case

Use Case - The use case symbol is used to represent capabilities. The use case is given a name and a text description.
Connectors - Because use case diagrams can have multiple actors, and because use cases can be associated with actors and other use cases, use case connectors are used to indicate how actors and use cases are associated. In addition, connector styles can change to convey more information about the relationship between actors and use cases. Finally, connectors can have additional adornments and annotations that provide even more information.
          There are 3 connector line styles

Association (Plain line connector) – is used to show which actors are related to which use cases.

Dependency (dashed line with directional arror) - is used to show which actors are related to which use cases.

Generalization (directed line with hollow triangle) - The word generalization in the UML means "inheritance." When we show a generalization relationship between two actors or two use cases, then we are indicating that the child actor or use case is an instance of the base actor or based use case. In generalization relationships, the arrow points toward the thing on which we are expanding.   

Connector Adornments: Connectors can include text that indicates endpoint multiplicity and text that stereotypes the connector.

Show Multiplicity - Connectors in general can have multiplicity notations at either end of the connector. The multiplicity notations indicate the possible count of each thing.

Stereotyping Connectors - Stereotypes add detail to the relationship between elements in a use case diagram. A stereotype can be used to expand on the meaning of the dependency connector.

A stereotype is shown as text between the guillemots (« and » characters).

Include and extend are important concepts in use case diagrams

 Include Stereotypes

A dependency labeled with the include stereotype means that the dependent use case ultimately is intended to reuse the depended-on use case.

 Extend Stereotypes

The extend stereotype is used to add more detail to a dependency, which means that we are adding more capabilities

 Inserting Notes: Every diagram including use cases, supports adding textual annotations. Notes are represented as a dog-eared piece of paper with a line attaching the textbox to the element being annotated

Use Case - Adding Textual annotation

A use case model is comprised of one or more use case diagrams and any supporting documentation such as use case specifications and actor definitions. Within most use case models, the use case specifications tend to be the primary artifact, with UML use case diagrams filling a supporting role as the “glue” that keeps the requirements model together. Use case models should be developed from the point of view of your project stakeholders and not from the (often technical) point of view of developers.

Tips :

Use case

·         Begin use case names with a strong verb

·         Name use case with domain terminology

·         Imply Timing Considerations by Stacking Use Cases

·         Place the primary actor of the use case on the left-top corner

·         Name actor with singular and domain relevent noun

·         Associate actor with one or more use cases

·         Name actor to model role, not job titles

·         Use <<system>> to indicate System actor

·         Avoid more than two levels of use case association

·         Use notes sparingly because they can clutter up a diagram and make it harder to read.

Inheritance in java

Inheritance is the capability of a class to use the properties and methods of another class while adding its own functionality. An example of where this could be useful is with an employee records system. You could create a generic employee class with states and actions that are common to all employees. Then more specific classes could be defined for salaried, commissioned and hourly employees. The generic class is known as the parent (or superclass or base class) and the specific classes as children (or subclasses or derived classes). The concept of inheritance greatly enhances the ability to reuse code as well as making design a much simpler and cleaner process.

The Object class is the highest superclass (ie. root class) of Java. All other classes are subclasses (children or descendants) inherited from the Object class. The Object class includes methods such as:

clone()	equals()	copy(Object src)	finalize()	getClass()
hashCode()	notify()	notifyAll()	toString()	wait()

Inheritance in Java
Java uses the extends keyword to set the relationship between a parent class and a child class. For example using our Box class from notes about class :

public class GraphicsBox extends Box

The GraphicsBox class assumes or inherits all the properties of the Box class and can now add its own properties and methods as well as override existing methods. Overriding means creating a new set of method statements for the same method signature (name, number of parameters and parameter types). For example:

// define position locations
    private int left, top;
// override a superclass method
    public int displayVolume()
    {
      System.out.println(length*width*height);
      System.out.println("Location: "+left+", "+top);
    }

When extending a class constructor you can reuse the superclass constructor and overridden superclass methods by using the reserved word super. Note that this reference must come first in the subclass constructor. The reserved word this is used to distinguish between the object's property and the passed in parameter.

   GraphicsBox(l,w,h,left,top)
    {
      super (l,w,h);
      this.left=left;
      this.top=top;
    }
    public void showObj()
    {    System.out.println(super.showObj()+"more stuff here");

     }

The reserved word this can also be used to reference private constructors which are useful in initializing properties.
Special Note:You cannot override final methods, methods in final classes, private methods or static methods.

See Further

Inheritance : cpp vs java
Using super in java
Multilevel inheritance : Calling order of Constructors
Abstract classes
Interfaces in java
Multiple inheritance in java
Inheritance among interfaces in java
Multiple inheritance in java
Abstract classes : cpp vs java
Abstract classes vs Interfaces
Abstract-Interface or skeletal implementations
Various interfaces

• Abstract-Interface or skeletal implementations 
• Constant Interfaces 
• Marker Interfaces

Preventing inheritance