Business Analyst Community & Resources | Modern Analyst

What is the difference between a Primary and Secondary Actor in Use Case Modeling?

cadams5 — Sat, 09 May 2009 23:10:00 GMT

What is an Activity Diagram and what is its purpose?

cadams5 — Sat, 05 Jul 2008 21:05:00 GMT

An Activity Diagram is a behavioral diagram that shows the flow or sequence of activities through a system. The terms activity diagram and process flow are often used interchangeably. However, the term activity diagram is typically more restrictive as it refers to one of thirteen standard Unified Model Language (UML) diagrams. Activity Diagrams are one of the most commonly used diagrams since its notation and origin are based on the widely known flowchart notation.

What are the basic elements of an Activity Diagram?

cadams5 — Sat, 05 Jul 2008 20:42:00 GMT

UML defines a specific notation and set of rules for creating Activity Diagrams. The following are the most commonly used:

Initial Node - The initial node represents the starting point of the activity diagram.
Activity Final Node - The activity final node represents the termination point of the activity.
Action Node - An action node is a type of activity node that represents a single action or behavior of the activity being modeled.
Activity Edge - An activity edge creates a directed connection between two activity nodes. It represents the path that a token can take between two activity nodes.
Decision - A decision has one flow entering and several exiting. The exiting flows each have a condition that must be met in order to traverse the flow.
Merge - A merge has several flows entering and one exiting. The merge denotes that multiple parallel flows are merging at a single point. Only one flow must reach the merge point in order to continue to traverse the flow to the next activity.
Fork - A fork has one flow entering and several exiting. A fork denotes that several processes are occurring in parallel.
Join - A join has several flows entering it and one exiting it. A join denotes that multiple parallel flows are merging at a single point. All flows going into the join must be completed before the next activity can start.

There are others, but these eight symbols constitute the basic notation used by nearly every Activity Diagram.

What is use case generalization?

sekharny — Tue, 27 May 2008 19:10:00 GMT

In the context of use case modeling the use case generalization refers to the relationship which can exist between two use cases and which shows that one use case (child) inherits the structure, behavior, and relationships of another actor (parent). The child use case is also referred to the more specialized use case while the parent is also referred to as the more abstract use case of the relationship.

For those of you familiar with object oriented concepts: use cases in UML are classes and the generalization is simply the inheritance relationship between two use cases by which one use case inherits all the properties and relationships of another use case.

You can use the generalization relationship when you find two or more use cases which have common behavior/logic. In this instance, you can describe the common parts in a separate use case (the parent) which then is specialized into two or more specialized child use cases.

Example:

If you are creating a payment system which allows students of a training provider to pay for courses both on-line and by phone, there will many things in common between the two scenarios: specifying personal info, specifying payment info, etc. However, there would also be differences between the two. So, the best way to accomplish this is to create one use case (the parent) which contains the common behavior and then create two specialized child use cases which inherit from the parent and which contain the differences specific to registering on-line vs. by phone.

What is actor generalization?

sekharny — Tue, 27 May 2008 18:18:00 GMT

In the context of use case modeling the actor generalization refers to the relationship which can exist between two actors and which shows that one actor (descendant) inherits the role and properties of another actor (ancestor). The generalization relationship also implies that the descendant actor can use all the use cases that have been defined for its ancestor.

For those of you familiar with object oriented concepts: actors in UML are classes and the generalization is simply the inheritance relationship between two actors by which one actor inherits all the properties and relationships of another actor.

Example 1:

When it comes to air travel, both a "Business Traveler" and a "Tourist" are "Passengers". The fact that they are passengers allow them to have common behavior such as "Buy Ticket" but the fact that they are separate actors implies they can also have differences. The "Business Traveler" might be able to "Redeem Business Miles" while the "Tourist" cannot.

Example 2:

Another scenario often found in many systems is when the system administrator, who gets additional functionality, is actually one of the normal users. So let's say that the system is an accounting system with the main actor being "Accountant" and with another actor called "Administrator". In our scenarios the Administrator should be able to perform all the normal accounting functions in addition to his/her administrator role.

The way to model this would be to show relationships between the Administrator actor and all the admin only use cases, then show all the accounting specific use cases related to the "Accountant" actor. And now, the only other thing you need to do for the "Administrator" to have access to the accounting features is to use the generalization relationship between the "Accountant" and the "Administrator" with the Administrator actor (descendant) inheriting from the Accountant actor (the ancestor).

Is it the job of a business analyst or systems analyst to draw the class diagram?

admin — Sat, 17 May 2008 07:00:00 GMT

It depends, it depends, and it depends!

As for most questions in business analysis, there isn’t only one answer. Whose job is to create a class diagram depends on the purpose of the class diagram.

First of all, the question implies that there is only one class diagram for a given project: “The Class Diagram”. For the most part, this is not the case. On some projects there may be a multitude of class diagrams while in others there may be none.

Second, the question implies that only one of the person/role on a given project would be task with creating class diagram. This is also not the case! There are many folks (business analyst, systems analysts, developers, etc.) who might have the need to create a class diagram in order to communicate a given concept or to solve a given problem.

So let’s rephrase the question:
“Who would use a class diagram and why?”

The business analyst might chose to create a class diagram in order to model the business domain showing the things of the business (the business domain/industry specific nouns found in the business lingo).

The systems analyst could use a class diagram to develop the logical data model for the system being designed.

The developer may also use a class diagram but for a different purpose: to show the actual classes, interfaces, and types being implemented in a given system.

In which document do you include the Class Diagram (business requirements, functional requirements, software specification document)?

sonavi — Fri, 16 May 2008 16:10:00 GMT

The easy answer is “It depends!”

Just like any other diagram, the Class Diagram is just a tool at the disposal of the analyst. In the absence of a set process, it is at the analyst’s discretion to determine when to use a class diagram. Therefore, in which analysis artifact/document a class diagram should be included depends on its use.

But first, let’s determine what a Class Diagram can do for you by looking at some of its characteristics:

A Class Diagram models “classes” also known as types. It shows what types of things can exist in the domain being analyzed. Remember: things = nouns!
A Class Diagram can show the “attributes” of the classes, that is it shows what type of data can be used to describe a given thing.
A Class Diagram illustrates how “classes” are related to each other. It depicts the relationships which can exist among the various things which exist in a given domain.
A Class Diagram shows “multiplicity” also known as “cardinality”. This concept is used to further clarify the relationships between things by specifying how many things of one type can related to how many things of another type.

Therefore, if the analyst uses the Class Diagram to depict the key nouns found in the lingo of the business users (aka the business domain) and the relationships among those things, then this class diagram would represent a domain model and would probably belong in one of the earlier artifacts of the project such as the Business Requirements Document (BRD).

On the other hand, if the Class Diagram is used to explain what C# classes will be used to realize the functional requirements and the types of data attributes which describe those classes, then this diagram would be considered a design artifact and would probably belong in the System Specification/Technical Specification document.

What is a use case diagram?

cadams5 — Tue, 25 Sep 2007 00:21:00 GMT

[Be the first to post an answer to this question!]

What is a use case?

cadams5 — Tue, 25 Sep 2007 00:18:00 GMT

A use case is a representation of an interaction between business worker and a business process or a user and an IT system in order to achieve something of value (a goal). Use cases are the ovals that appear in a use case diagram. A use case and a use case description or specification are different. While use cases represent an interaction (usually with a simple verb-noun phrase) use case descriptions/specifications describe the interaction in detail form.

Use cases can be subdivided into business use cases and system use cases. Business use cases represent the interaction between a business actor and a business process in order to achieve a goal, while system use cases represent the interaction between a system actor, which can be a system user or another system, and an IT system in order to achieve something of value.

Would you use a sequence diagram or an activity diagram to model a process flow that has lot of conditional flows and concurrent processing?

cadams5 — Mon, 24 Sep 2007 22:28:00 GMT

Modeling of processes that contain a lot of conditional flows and concurrent processing is typically done using an activity diagram. Showing decision points with multiple outcomes and parallel processes is not only easy to accommodate using the standard UML activity diagram, it is more readily understood by an audience that doesn't have a detailed understand of the UML notation. It's intuitive.

While UML 2.0 incorporates significant improvements over prior versions for supporting conditional processes, parallel processes and loops, using these features tend to be a little more cumbersome without the help of a very specialized or easy to use tool. In addition, the notation is not quite as intuitive to the untrained document reviewer.

Is there anything in RUP that you would change in order to improve the efficiency of the system development process?

cadams5 — Thu, 20 Sep 2007 23:22:00 GMT

[Be the first to post an answer to this question!]

What is UML?

cadams5 — Thu, 20 Sep 2007 02:27:00 GMT

UML stands for Unified Modeling Language. UML is an industry standards used to assist analysts and programmers with developing scalable, extendable, maintainable, secure, and robust applications. Large systems tend to be very complex and structure is one way of dealing with complexity. UML provides a common language for analysts and programmers throughout the IT industry to organize and structure complex systems in a way that can be understood by everyone involved. It allows IT professionals to specifiy, visualize, and document models of a software system, both structurally and behaviorally.

Name a few of the industry standards, methodologies, or best practices used by business analysts and systems analysts?

cadams5 — Thu, 20 Sep 2007 01:57:00 GMT

-UML

-BPMN

-RUP

What are the most relevant UML diagrams for Systems Analysts?

cadams5 — Thu, 20 Sep 2007 01:49:00 GMT

While opinions may vary based on the role of the Systems Analyst from organization to organization, the following UML diagrams are probably the most predominantly used by Systems Analysts:

-Class Diagram

-Use Case Diagram

-Package Diagram

-Activity Diagram

-Sequence Diagram

-State Machine Diagram

-Communication Diagram

What are the most relevant UML diagrams for Business Analysts?

cadams5 — Thu, 20 Sep 2007 01:43:00 GMT

While opinions may vary based on the role of the Business Analyst from organization to organization, the following UML diagrams are probably the most predominantly used by Business Analysts:

-Class Diagram

-Use Case Diagram

-Activity Diagram

-Sequence Diagram

Name and describe the different categories of UML diagrams.

cadams5 — Thu, 20 Sep 2007 01:37:00 GMT

There are 3 categories of UML Diagrams:

Structure Diagrams: Diagrams that model elements of a business domain or system irrespective of time.

Behavior Diagrams: Diagrams that model the functional or behavioral aspects of a system or business process. These diagrams place less emphasis on detailed interactions and focus more on the overall functionality and flow of a business process or system.

Interaction Diagrams: A subset of behavior diagrams, these diagrams place a heavy emphasis on the interactions between object of a business process or system.

What UML diagrams are available to analysts and developers?

cadams5 — Thu, 20 Sep 2007 01:21:00 GMT

UML 2.0 contains 13 different diagrams (up from 9 in the previous versions of UML) that can be grouped into 3 different categories. These categories are:

1. Structure Diagrams

2. Behavior Diagrams

3. Interaction Diagrams

There are 6 Structure Diagrams which include:

-Class Diagram

-Object Diagram

-Component Diagram

-Composite Structure Diagram

-Package Diagram

-Deployment Diagram

There are 3 Behavior Diagrams which include:

-Use Case Diagram

-Activity Diagram

-State Machine Diagram

There are 4 Interaction Diagrams which include:

-Sequence Diagram

-Communication Diagram

-Timing Diagram

-Interaction Overview Diagram