Business Analyst Essentials:
Responsibilities of a Business Analyst
UML(unified modelling language)
SDLC(software development life cycle)
Finance banking knowledge for BA
BA Interview Questions & related:
Imp BA Interview questions set 1
Imp BA Interview questions set 2
Imp BA Interview questions set 3
Imp BA Interview questions set 4
Business analyst Interview questions 1
Business analyst Interview questions 2
Business analyst Interview questions 3
Business analyst Interview questions 4
Business Analyst Health care Related:
SAS (statistical analysis system)
BA Finance Interview questions
Business Analyst Finance domain Interview
What is home equity line of credit (HELOC) ?
What is debt to income ratio &
What are mutual funds ? Interview questions
Trading of Stocks , what are stocks?
Factors that will affect the change in price
What stocks are treated as equity
Business Analyst Tutorials:
Role of a Business Analyst(high level)
RUP (rational unified processing)
Testing skills required
Instances and Messages
Interaction diagrams mainly consist of instances and messages. An instance can be considered as the realization of a class. So if there is a class Doctor, then the instances of the class can be Dr. Jones, Dr. Smith, etc.. In any of the object oriented application, instances are what exists when you instantiate a class (that is create a new variable with the class as its data type).
In the UML diagram , instances can be represented as rectangles with a single label which is formatted as:
InstanceName: data type
You can also choose whether to name the instance or not. But the data type has to be specified at all times. After the name, the attributes and their values can be listed. In Visual Case tool, the attributes from your class can be mapped and new values specific to that instance can be entered. Attributes need to be shown only when they are vital and you don't have to specify and display all of the class attributes.
Messages actually represent operation calls. So, in case an instance calls an operation in itself or in another class, a message will be passed. Also, on the completion of this operation a return message will also be sent back to the instance which had initiated the call.
The format for message labels can be given as:
Sequence Iteration [Guard] : name (parameters)
Sequence: actually represents the sequence in which the message will be called. The sequence is redundant on the sequence diagrams, but is required on collaboration diagrams
Iteration: an asterisk (*) is shown to represent iteration if the message is called repeatedly
Guard: is an optional boolean expression (the result can either be true or false)
which actually determines if the message is called
Name: represents the operation which is called
Parameters: represent the parameters on the operation which is called
Sequence Diagrams
The two types of Interaction Diagrams are - Sequence and Collaboration. Sequence diagrams emphasize the sequence in which the things happen. On the other hand collaboration diagrams provide more flexibility in their layout. When drawing interactions you can choose between these two depending on your preference, since both show the same information.
An example of a sequence diagram for our logon collaboration is gicen as below:
Things which should be noted:
ｷ The flow of time is depicted from top to bottom, that is messages which are higher on the diagram occur before those which are lower down
ｷ The blue boxes are actually instances of the represented classes, while the vertical bars below them are the timelines
ｷ The arrows (or links) are the messageswhich are either the operation calls or return calls from operations
The hide and show messages use guards in order to determine which to call. Guards are always displayed in square braces [ ]and they represent the constraints present on the message (the message will be sent only if the constraint is satisfied)
ｷ The messages are labeled with the operation which is being called and parameters are displayed. It can be chosen whether to enter the parameters or not - this is dependent upon their importance to the collaboration which is being shown
The sequence numbers are not depicted on the messages as the sequence is intrinsic to the given diagram
Asynchronous Messages
A message can be specified as asynchronous in case the processing continues while the message is being executed. In the below given example, the asynchronous call does not block the processing for the regular call which is there right below. This is useful in case the operation which is being called is run remotely, or in another thread.
