Unified modeling language UML tutorial part 3


Training & Tutorials:

*Roles and Responsibilities of a

 Business Analyst

*What is System Analyst

*What is SDLC and different

 Phases of it?

*What is usecase diagram?

 & its Importance.

*How to draw flowchart? And

 its uses?

*What is RUP? Explain in detail.

*What is UML explain in detail?

*Business Analyst Tutorials

*Business Analyst Interview


*Testing (QA) knowledge Required

 for BA

*Business Analyst Healthcare

 domain Tutorials

*Business Analyst Finance

 Domain Tutorials

*Rational Rose Tools Interview


*Diagrams for Business Analyst

*Resumes for Business Analyst

*Jobs for Business Analyst

*Interviews Tips



BA Interview Questions

*BA Interview questions set 1

*BA Interview questions set 2

*BA Interview questions set 3

*BA Interview questions set 4

*BA Interview questions set 5

*Business analyst Interview

 questions 6

*Business analyst Interview

 questions 7

*Business analyst Interview

 questions 8

*Resume writing tips for BA 9

*General business analyst interview

  questions 10

*Mortgage related interview questions

  for BA 11


Business Analyst Tutorials

*Responsibilities of a Business Analyst

*What is Business Analysis

*Sequence diagram Explained

*Class diagram explained

*RUP explained

*UML(unified modelling language)

*SDLC(systems development life cycle)

*Insurance knowledge for BA

*Health care knowledge for BA

*Finance banking knowledge for BA

*Role of a Business Analyst(high level)

*Use case diagram step by step

*Class Diagrams UML

*Responsibilities of BA

*What is RUP ?

*RUP in SDLC process


*Bug Life cycle

*BA Faq

*Business Users of the system

*Class diagrams

*CMM levels

*Collaboration diagram

*Data Mapping & Data modeling

*Data model in data base

*Deliverables in SDLC

*Tools used by BA

*Q-Gate (quality gate)

*RUP (rational unified processing)

*Sequence diagrams

*Deliverables in RUP

*UML (unified modeling language)

*Use case diagram

*Use case examples

*Use case template examples

*what are JAD sessions?

*What is GAP analysis ?

*What is User acceptance testing (

*Daily duties of a BA

*What is System analyst ?

*UML Tutorial Part 1

*UML Tutorial Part 2

*UML Tutorial Part 3

*UML Tutorial Part 4

*UML Tutorial Part 5

*UML Tutorial Part 6

*UML Tutorial Part 7

*UML Tutorial Part 8


Testing Knowledge

*Testing processes

*QTP recording flow

*Break points in qtp

*Split actions in qtp


*Check Points in QTP

*Integrated testing

*What is QTP ?

*Loadrunner step by step


Business Analyst Finance

*Business Analyst Finance domain

 Interview questions set 1

*What is Fixed rate Loan?

*What is home equity line of credit

  (HELOC) ?

*What is Loan to value ratio ?

*What is debt to income  ratio &

*What is lien Lien holder ?

*What are mutual funds ? Interview


*Trading of Stocks , what are stocks?

*New york Stock exchange

*What is NASDAQ ?

*Stock exchanges in USA

*Factors that will affect the change in

 price of STOCKS

*How to buy a STOCK ?

*What stocks are treated as equity

 while bonds as debt ?

*Some more Finance related interview

  questions for Business analyst

*Imp finance related interview

 questions for BA

*What is SWAP and types of swaps

*What are  Options & Bonds and types

Bonds in finance

*what are Options in finance

*what is a derivative and how it functions

*Who is a broker dealer

*Commercial bank in brokerage industry

*Who is a market maker?

*who is a specialist ?

*What are bond and types of bonds

*Steps for writing use case diagram

*What is SOX (Sarbanes Oxley act)

*CMM Capability maturity model


Business Analyst Health care :

*BA Health Care Claims

*SAS (statistical analysis system)

*Clinical Trials

*What are FACETS

*Health care fraud detection

*What is HIPAA

*Medicare Procedures and policies

*Health care Interview questions for BA


Share on Facebook










Many of the object oriented programming languages do not allow multiple inheritance. The interface can be utilized to solve the limitations posed by this problem. For e.g, in the class diagram given earlier Client and Company classes generalize Contact class and one of the child classes may have something in common with a third class which we do not wish to copy in multiple classes.

The interface Sortable, is used in the above diagram to depict the child classes Company and Product can implement the operation sort. It can be said that Company and Product implement Sortable or they are Sortable. Because Product class already generalizes Contact, we cannot allow the same to generalize Sortable. So, we can make Sortable an interface and add a realization link to depict the implementation.

Interfaces are similar in structure and functionality to abstract classes but they do not have any attributes. All of the operations in an interface have no implementation, unlike that of a class. The child classes Company and Product are forced to implement the sort operation in it's totality.



Classes can also have references to one another. In the diagram below, he Company class has two attributes which actually reference the Client class.

This is technically correct, but it can be more expressive to display the attributes as associations.

In the above diagram, the two associations have the exact same meaning as the attributes in the earlier version of the Contact class.

The first association (the top one) represents the old contactPerson attribute. There is one contact person in a single Company. The multiplicity of this association is one to one meaning that for every Company there is one and only one contactPerson and for each contactPerson, there is only one Company.

In the second (bottom) association, there are zero to many employees for each of the company. Multiplicities can be specified by you as anything such as  given below:






one or many

1..2, 10..*

one, two or ten and above but not three through nine

At the end of each association , the arrows represent their navigability. In the above given examples, the Company class references the Client class, but the Client class does not have any idea of the Company. So, the navigability on either, neither or both ends of your associations can be set accordingly. If no navigability is to be shown then the navigability is unspecified in the diagram.



Aggregation and Composition


 The above given example displays an aggregation association and a composition association.  composition is depicted by a solid diamond. The ProductGroup composed Products. This in turn means that in case a ProductGroup destroyed, the Products the group will be destroyed as well. The aggregation association can be depicted by a hollow diamond. PurchaseOrder is an aggregate of Products. Even if PurchaseOrder will be destroyed, the Products will still exist.

In case you have confusion regarding the difference between the composition and aggregation, all you have to do is to just think of the alphabet of the word Composition which means destroy and the letters 'c' and 'd' are right next to each other.


A dependency can exist between two elements in a way that in case there are any changes to one of the elements then it will also affect the other. For e.g, a class calls an operation in another class, then there is a dependency between the two classes. If the  operation is changed, then the dependent class will also change. The goal should be to minimize the dependencies, while designing the system,

To help get clarifications on the dependencies in the design, you can draw a Package Diagram. A package diagram is nothing but a class diagram in which the packages and dependencies are displayed. Dependencies may exist between any of the components in the UML diagram. However at the highest level, dependencies will actually exist between packages. In a package, the dependencies can be numerous more than can be specified. But it's not that such numerous dependencies are okay. Even within a package its better to limit the dependencies,  particularly between the packages and be strict about the number of dependencies which exist. In general, lesser the dependencies the more scalable and maintainable the system will be.

Putting it all Together

Class diagrams  are considered to be the core of most object oriented designs so you will be finding yourself using them most of the times. Class diagrams actually closely relate to most of the object oriented languages, so the basics such as the classes, the operations, the attributes, and generalizations, etc. should be fairly easy enough to be grasped. You should start with what you know and then probably move forward.

The most important thing which should be said about design is that you should not feel bogged down by it. In fact it will be better to have a collection of clear diagrams than many confusing and complex diagrams. In a previous example we saw the AbstractTaxCalculator was generalized by OntarioTaxCalculator and NovaScotiaTaxCalculator. If we tried to create a diagram with all ten of the Canadian provinces and three territories we would have built a huge and complex mess. In case we were designing a tax system for United States and suppose we tried to depict all of the states, we would land up in even more trouble. It will be clearer, and maybe just as expressive to show two or even three child classes and to add a note or comment to the diagram which explains that the other provinces and territories are to be implemented in the same way.

To keep the designs simple will allow you to be more productive and make your designs more usable and understandable. To add, as the system will be implemented and upgraded, the design should be kept in sync with your implementation. This will be far more easier with a simple and clear design of the key system concepts.

4. Interaction Diagrams - Sequence and Collaboration

After the use cases have been specified, some of the core system objects can be  prototyped on class diagrams so that the designing of the system dynamic behavior can be done. If you recall the Use Case section of the tutorial, a use case encompasses an interaction in between a user and a system. Typically, an interaction diagram captures the behavior of a single case by depicting the collaboration of the system objects in order to accomplish the task. The diagram given below displays the system objects and the messages which are to be passed between them.

We can start with a simple example which is given above: that of a user logging on to the system. The Logon use case can be specified by the following steps:

Ideal Flow:

1)      Log on dialog is displayed

User name and password is entered by the user

OK button is clicked or the enter key is pressed by the user

The user name and password are checked and then approved

The user is allowed to log onto the system

Alternative Flow: Log on Failed

            If at step 4 the user name and password are not approved, allow the user to try           again

We can now have a simple Use Case with which to work with and some of the classes involved in the interaction can now be specified.

The LogonDialog has public methods to display and hide the window, and a private method which can be called when the user clicks the OK button or presses enter. In our example (and most of the cases) you need not specify the interface dialog elements.

Our design also includes a LogonManager class that will include one method which  returns true if the log on is successful, and false in case it fails..

A DatabaseAccess class will allow us to run queries for our database. A query string can be passed and a ResultSet of data will be returned.

Now that we have prototyped the classes involved in our interaction, we can begin to make our interaction diagrams.