*Roles and Responsibilities of a
& its Importance.
*What is RUP? Explain in detail.
*What is UML explain in detail?
*Testing (QA) knowledge Required
*Rational Rose Tools Interview
Questions
*Diagrams for Business Analyst
BA Interview Questions
*General business analyst interview
*Mortgage related interview questions
Business Analyst Tutorials
*Responsibilities of a Business Analyst
*UML(unified modelling language)
*SDLC(systems development life cycle)
*Finance banking knowledge for BA
*Role of a Business Analyst(high level)
*Use case diagram step by step
*SDLC
*RUP (rational unified processing)
*UML (unified modeling language)
*What is User acceptance
testing (
UAT)?
Testing Knowledge
Business Analyst Finance
*Business Analyst Finance domain
*What is home equity line of credit
*What is Loan to value ratio ?
*What is debt to income ratio &
*What are mutual funds ? Interview
*Trading of Stocks , what are stocks?
*Factors that will affect the change in
*What stocks are treated as equity
*Some more Finance related interview
questions for Business analyst
*Imp finance related interview
*What is SWAP and types of swaps
*What are Options & Bonds and types
*what is a derivative and how it functions
*Commercial bank in brokerage industry
*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 :
*SAS (statistical analysis system)
*Medicare Procedures and policies
*Health care Interview questions for BA
3. The Class Diagram
The class diagram is considered to be the core of the object-oriented design. The class diagram depicts the system object types and the prevalent static relationships between these objects..
Packages
Packages are used to break up a large number of objects into related groups. In many of the object oriented languages (e.g - Java), packages have been used in order to provide to the classes and interfaces more scope and division. In the UML diagrams, packages have a similar and in fact broader perspective.
In Visual Case, any of the UML diagrams can have packages. Each of these packages can contain any of the types and in any number of other UML diagrams, as well as the classes and the interfaces.
Classes
Class is the core element of a class diagram. In any object oriented system, system entities are represented by classes. These entities often relate to real world objects.
Given above is an example of a simple Contact class which stores the location information.
Classes can be classified into three categories:
Top: The name, package stereotype displayed in the upper section compartment of the class. In Visual Case, classes which do not belong to the same package are shown on a diagram with their entire path name. A stereotype can be optionally assigned to a class.
Center: In the center section of the class, the attributes are enumerated.
Bottom: The lower section contains the operations which a class can perform.
In a Visual Case class diagram, both the attribute and operations sections can be both hidden or shown as is required for all or individual classes. It is mostly used when you want your class diagrams to be able to highlight only specific constructs of your system and the superfluous information such as operations and attributes can confuse and clutter the diagram.
Attributes
An attribute is considered as a property of a class. As shown in the above example, Contact class has the attributes such as an address, province, a city, country and a postal code. During the implementation of the class, functionality is provided in such a way so as to set and retrieve the information which has been stored in the attributes. The methods which are used to set and retrieve attribute data are known as accessor methods(also called as getting and setting methods) and are generally not shown as they can be inferred.
The format for the attributes of a class is given as follows:
visibility name: type = default Value
The visibility is as given below:
|
- |
Private |
|
+ |
Public |
|
# |
Protected |
|
~ |
Package |
During the process of object oriented design, most attributes are preferably kept as private so that the accessor methods can control access to the data. The most common exception to this preference are constants.
Visual Case allows you to specify the following properties for an attribute in addition to the name, data type,visibility, and default value,:
Array: an attribute can be set to be treated as an array of attributes and is displayed with square braces [ ]name.
Static: static attributes can exist only once for all of the class instances. As in the example given above, after city is set as static, if at any time the Contact class is used then the city attribute would always give the same value.
Final: final attribute's value cannot be changed i.e. its regarded as a constant.
Operations
The class operations represent the tasks or functions which can be acted upon based on the class data.
In the List class shown above, there are three operations and one attribute (an array of Objects)
The format for operations can be given as:
visibility name (parameters): type
The format for operations can be seen as very similar to the syntax for attribute except for the removal of a default value and the addition of parameters.
Parameters take the format:
direction name: type = default value
The direction can be one of the many options such as in, out, inout or it can be unspecified.
In Visual Case, the parameter list for one or all classes given can be shown or hidden. If the parameters list is hidden for an operation which has parameters, then it will be depicted as three dots (...) to indicate parameters do exist for the operations, but are now hidden. For some operations there are a number of parameters and hence they need not be shown all the time.
Generalization
Two classes can be linked with the generalization link in order to depict that one of the class has all attributes and operations of the other class, but also has additional ones.
Lets look at the above diagram in which the Contact class now has two child classes. So it can be said that the classes Client and Company have inherited, generalized or extended Contact class. In the child classes Client and Company, the attributes of Contact class (address, city, etc.) exists, but in addition there are other attributes. So, as is depicted in the above diagrams, Contact class is said to be the main class or superclass of child classes Client and Company.
The child classes may override the operations in the super class in some cases with the generalization link being used. In such cases, the child classes can include an operation which is actually defined in the superclass, but they can define a new implementation for the operation.
In the above diagram, OntarioTaxCalculator class diagram redefines or overrides the operation implementation in BasicTaxCalculator. That is , the operation is called in the same manner yet the code is different.
Sometimes the child classes need to be forced to override the operations of a parent class. In such a scenario the methods or operations in the superclass can be defined as abstract. The class can be defined as abstract if it has abstract operations. Each of the abstract methods and the classes have been shown in italics. But it is important to note that all of the operations in any of the abstract class don't have to be abstract.
The abstract operation calculateTaxes in AbstractTaxCalculator must be implemented in the child classes OntarioTaxCalculator and NovaScotiaTaxCalculator. As the operations has to be implemented, it is not essential to display them in the child classes, but its actually up to you. The key should be to have the diagrams as simple and clear as possible. The above diagram is simple and its meaning clear, but with the multiple levels of inheritance and more number of attributes and operations, you may choose to specify all of the methods that are overridden
photo