Hello nosredla-ga,
I'm very happy to to clarify how your role as a Business Analyst is
impacted by the de facto standards of the UML, and Object Oriented
Analysis and Design (OOAD). On a daily basis, I come across people
with varying levels of technical expertise and familiarity with the OO
realm. Many express their confusion and frustration regarding what
they need to know and how technical they need to become within their
BA role. My response to your concerns is therefore meant to be a
clarification of the expectations a typical Business Analyst faces
within a UML/OO-driven environment.
There are several statements in your question that concern me,
primarily because I get the perception that you are overlooking some
nuances and key tools that will simplify your OO experience. I've
picked these out as quotes and have followed with a brief
clarification.
1. "I understand what a Class is (I am very proficient in traditional
data modeling) and that it has(unlike an entity in an ERD)both
attributes and operations"
This simplification of the concept of a class is a common pitfalls for
BAs. In order to fully understand how a fully formed Class comes into
being, you need to familiarize yourself with the differences between
an "analysis class" and a "design class", which are derived at their
respective points in the development cycle. Your role typically
requires involvement during both analysis and design (there is other
design work that needs to be done aside from the technically driven
solution design).
In general, a Class definition (after OOA and OOD are complete) should
provide the developer with the ability to understand what instances of
this Class know about (ie. attributes) and what they can do (ie.
operations). The methods used to derive the details for a Class
definition are important, and I will discuss that further shortly.
2. "I understand that a developer will use the Use Case descriptions
to identify classes, and that I could assist this process by giving
(in addition to Use Cases) one or more Class Diagrams"
This understanding is narrow in scope compared to what most OO
methodologies (like the Rational Unified Process) would include in the
Business Analyst role. By providing just Use Cases and a Class diagram
(no matter how detailed), you are leaving out information that not
only justifies your solution, but also provides important information
when developers are making technical design decisions. This missing
information is captured in Sequence and Interaction Diagrams, which
show how different classes communicate with each other within the
context of a use case. It is during the creation of these diagrams
that you realize why (or why not) to include operations and attributes
into particular classes.
3. "What makes me unsure is that many texts on OO/UML show examples
where business functions have been assigned as operations to classes,
so perhaps I should be doing this?"
The examples you refer to are just that, *business functions*. While
you are creating sequence diagrams, your objective is to map out the
steps of a use case by passing messages between instantiations of
different classes. So although as a BA you may include an operation in
a class (like placeOrder), think in terms of the message that such an
operation would require.
What input is required before an order can be placed?
What classes need to be involved during the placement of an order and
what is the sequence of this?
How is this operation instantiated?
These are the types of questions your developers are going to be
trying to figure out, but by thinking in terms of generic messages,
you are going a long way in providing a crystal clear picture.
4. "Also does not each Class create instances of itself, therefore
Orders will be created by theOrder class?"
Actually, this is not usually the case (although it is possible). If
you think about it, Classes are instantiated when some sort of state
needs to be maintained and/or an operation needs to be performed. How
would a Class instance (which doesn't exist yet) know when and if this
is needed? The answer is that instantiation of a class is typically
done by another object that needs it's services.
The distinction between a Class and an Object is critical in OOAD. The
Class is the template, the boilerpate on which Objects can be
instantiated. It is not possible to instantiate a Class.
5. "Also, if in the real world the Customer clicks on a menu item that
brings up a screen on which Order details are input and from which an
Order is then created, does this not mean that boundary classes are
telling an Entity Class to create an instance of itself with the data
it provides?"
Now you're probably getting more technical than you need to be. You
can simply state that your Actor (I'm sure you've seen those little
stick men symbols) is the trigger for the whole process. Now if we
were dealing with a Use Case called "Place Order" I seriously doubt
that any robust system would allow direct access to a business object
directly. Chances are, it would go through different types of
validation and various other "chatter" between objects before an
operation called placeOrder is ever called. This is the basis behind a
multi-layer architecture, which you can simplify as groupings of
similar types of objects (ie. presentation, business, data,
communication, security, etc.)
OK I see that I have reached your "official questions" so I will field those now:
1. Does it make sense for me, in the requirements analysis phase, to
attempt to assign operations to classes?
Yes, absolutely, as long as you understand that at this point those
operations are simply a way of describing how messages are being
passed between different objects. The key to doing this properly is
via SEQUENCE DIAGRAMS - these are the critical link between your
written use cases and your Class Diagrams.
By this I mean that you should not try to assign operations when you
are defining classes. Instead, follow these steps:
a) Write your use cases
b) Take a stab at your class diagram without any details for the
classes (at this point it would look more like a domain model)
c) Build a sequence diagram for each use case (even alternate flows if
you feel the need) and add attributes and operations to your class
model when you find that you require a class to contain certain
information or perform a certain action.
Lastly, keep in mind that by assigning operations to classes you are
not necessarily binding developers to a particular implementation.
Rather, you are providing a mechanism whereby classes can communicate
with each other - how work is done within a class is still within the
developer's control. This is extremely valuable if you have large
teams working on different classes that will eventually interact.
2. What are useful quidelines for deciding to which class I should
assign an operation?
Hopefully you should know the answer to this question already :-)
An operation is a way for the outside world to communicate with an
object, either by changing it's state or having it perform some work.
If, in the process of creating a sequence diagram, you find that you
need to perform a step that uses or affects attributes within a Class
instantiation, the operation should be included in the Class where the
attributes reside. By calling this operation, other objects will be
able to send a message, either to change the state of the object or
request that the object pass some information back to the caller (or
both).
I hope I have sufficiently answered your question - it can certainly
be a vague topic! If you have any problems understanding the
information above or have any other concerns, please post a
clarification and I will be happy to respond.
Cheers,
answerguru-ga |
Request for Answer Clarification by
nosredla-ga
on
17 Nov 2005 13:43 PST
I'm afraid I am disappointed. I priced my question at $100 because
"Researchers will typically spend between two-four hours and will do
highly thorough research for questions at the $100 price level" Your
answer gives me your opinion, but no references or citations to
support it. Therefore it is difficult (forgive me for being blunt) to
see any evidence of research. Your answer to my second question (the
crucial one) is "you should know the answer to this question already"!
If I did, I would not have asked it! Or did you think that your
critique of my question provided the answer?
I would like to try to get more out of this by pushing further. We
seem to disagree on the role of the Business Analyst. The common view
(and mine) of a Business Analyst (BA), is that the BA is responsible
for defining "what" the system should do (a black box view) but has no
responsibility for the internal design of the solution(the "how").
Your view seems to be different since you say "your role typically
requires involvement during both analysis and design". I have the
feeling you may be equating Business Analyst with Systems Analyst. For
the purpose of our discussion, can we work from the assumption that
the BA's work comes before design, therefore the BA has no knowledge
of the internals of the system?
You recommend that the BA build a sequence diagram for each Use Case.
I believe this is a non-trivial task and note that some practitioners
even recommend doing a Robustness Diagram to work through this
transition. All examples I have seen of such diagrams (Robustness and
Sequence)include Boundary, Control and Entity Objects. This is where I
have difficulty seeing the BA (per my definition) completing them. The
BA by this time should have a good understanding of the Entity Classes
(from the domain model) but has no knowledge of Boundary or Control
Classes/Objects since they are arrived at later during design. Thus,
if the Sequence Diagram helps assign operations to classes, and the BA
can not be expected to do Sequence Diagrams (my view, but perhaps not
yours), then the BA cannot assign operations to classes, which was my
starting point.
I can see that if a BA has done a model of the business operation,
then s/he might do a sequence diagram that reflected the sequence of
events in the business, but I cannot see how that is useful to the
designer thinking about the operational responibilities of Objects
within the system. However I am not a designer and am open to having
such value explained to me, if it is there.
At the end of your response you state that it does make sense for a BA
to assign operations to classes "as long as you understand ....
operations are a way of describing how messages are being passed
between different objects". I believe that the description of how
messages are passed between objects is a design consideration and
therefore outside the scope of a BAs responsibilities and skills. If
you were to agree to work from my definition of a BA, would you agree
with this.
|
Clarification of Answer by
answerguru-ga
on
17 Nov 2005 16:05 PST
Hi nosredla-ga,
I am sorry that you are disappointed in my response to your question.
I am going to try to clarify a few things and work within your newly
stipulated assumptions. Hopefully this will result in a more
satisfactory result.
I think the problem is that the "Business Analyst" has been a term
used to describe many very different things depending on the
environment the BA is situated in. I was most certainly not equating a
BA with either a Systems Analyst or a Business Systems Analyst.
However, as per your request, I will adjust my definition of a BA to
someone whose work is focuses on stages prior to design. This does,
however, immediately limit the level of support your can provide to
your development team.
You mentioned that the sequence diagrams you have seen all contain
boundary and control classes. I am not surprised at this, especially
since you had noted that the books you have seen assume technical
backgrounds. It is important to understand that artifacts like
sequence diagrams are living and will continue to evolve. The type of
sequence diagram I was referring to only contains Entity Classes and
Actors. If you pass this forward to a developer, they can then add
boundary and control classes where needed. This is something that a
systems analyst would typically undertake. This still does not prevent
you from assigning operations to send messages between your entity
objects. Remember that OO methodologies are typically iterative, so
what you do in the requirements phase is something you expect to have
reworked by someone else in a future iteration or phase (depending on
the process that has been adopted).
You asked about the value to a designer of having a sequence diagram
developed by a BA. There are several reasons why a designer would (and
should) value this preliminary legwork:
a) There are many things that a class diagram alone cannot capture
effectively. By providing a sequence diagram you are justifying your
choices made in the class diagram.
b) If the designer wants to make an adjustment to your initial model
to accomodate a technical decision, they can look back at your class
model and adjust rather than trying to invent from scratch. Much of
what they are likely to try and change is tightly coupled to the
business domain - and who knows that better than the BA?
c) You are not forcing decisions on the part of the designer based on
best guesses on their part concerning what business objects know and
can do. Decisions at the design phase often trigger the urge to mutate
a business object to fit a solution (even though the solution should
not actually be considered during design). This is how inaccuracies
are often introduced into a class diagram, and it can cause severe
headaches later on with security and organization of layers.
I would finally like to address your belief "that the description of how
messages are passed between objects is a design consideration and
therefore outside the scope of a BAs responsibilities and skills".
While you are free to believe whatever you like, this particular
belief is likely to cause you tremendous challenges in performing
effectively as a BA (even one that is focused on the requirements
phase). Here is why:
a) You seem to equate "messages" with something technical, when in
fact it is entirely conceptual during requirements analysis. You have
no need to prove that a message that is being sent from A to B is
technically feasible or efficient. All that is needed of you is to
describe how your Classes talk to one another.
b) Since the technical people you deal with are unlikely to approach
you with technical concerns, it hardly seems fair that you expect them
to define business behavior. Remember, an "operation" is something
very different as you move from analysis --> design --> development.
It should start off as a conceptual business action that an actor
(stick man) invokes on an object, or that objects invoke on each
another.
c) Holding such a belief makes you susceptible to a communication
barrier with your technical colleagues. Resist the technical talk -
make it clear this is not your domain! So how can you communicate with
the technical folks without trying to speak in jargon? Use pictures!
The basic tennet of UML is 'model visually', so let this be the common
language that everyone understands. The whole point is that a very
business-focused requirements phase diagram can be picked up by
someone else and be transformed into a technically-geared design with
relative ease.
Overall, my intention was not to criticize or question the knowledge
you have accumulated to this point. Doing so would be unprofessional
and without purpose.
Due to the way this question was framed, this became more of a
theoretical discussion that wouldn't have been greatly served by a
page of references. I'm hoping you take what I have said above as
words of advice from a colleague, because at the end of the day you
are essentially a colleague to everyone around you.
I hope this clarification has given you a better grasp of my
reasoning. Rather than state that what I preach is a best practice and
you shouldn't question the value it brings, I wanted for you to
understand the benefits of adopting such a viewpoint. I realize it is
a bit of a different way of thinking but it will be of great benefit
to you as you progress in your career.
All the best to you in your future endeavours.
Best regards,
answerguru-ga
|
Request for Answer Clarification by
nosredla-ga
on
17 Nov 2005 19:09 PST
Thanks for the clarification. I will ask for a little more.
Let us suppose I am developing requirements for a software application
which allows customers to place orders for products. I can easily
imagine writing a Use Case that describes the interaction of the
customer with the application to achieve this goal. I can easily
imagine preparing a Class Diagram that shows such Entity Classes as
Customer, Order, Order Item and Product together with their attributes
and relationships. I have great difficulty imagining what a Sequence
Diagram would look like that included only the Entity Classes, or what
the messages might be that I might show between them.
I realize that you can't show me a diagram, but might you be able to
describe what such a diagram might show and what operations it might
indicate for the Entity Classes?
To rambler-ga: I did not mean to imply an opinion that the BA has no
involvement in a project after requirements analysis. The BA clearly
continues to be involved in many aspects, especially testing and
documentation. I meant only to say that decisions about "how"
requirements will be implemented within the system are generally not
the BA's responsibility. Regarding a book, I strongly recommend "UML
for the IT Business Analyst" by Howard Podeswa.
|
Clarification of Answer by
answerguru-ga
on
17 Nov 2005 20:40 PST
You're right about the limitations on being to diagram - although I
will do my best to describe how you can think about sequencing. I'm
assuming your actors are Customer and System. In addition to the
entity classes, we also need a sequence of interactions between actor
and system (ie. the main scenario of your use case). Could you provide
a simplified version of this sequence in writing? I can show you how
to then view the same steps in terms of a sequence diagram.
answerguru-ga
|
Request for Answer Clarification by
nosredla-ga
on
18 Nov 2005 02:27 PST
Thanks. I tried to keep this simple
1. Customer indicates he wishes to place an order
2. System displays available products
3. Customer selects a product, enters quantity required and requests
item to be added to order.
4. System verifies sufficient quantity on hand, adds item to order and
offers customer choices to continue ordering or finalize the order
5. Customer chooses to continue ordering
6. Steps 3 to 5 are repeated until customer chooses to finalize the order
7. System creates a new order, assigns an order number and gives the
customer a confirmation. The Use Case ends.
|
Clarification of Answer by
answerguru-ga
on
18 Nov 2005 09:04 PST
Thanks for trying to simplify your scenario - I'm going to describe
how you can look at sequencing during requirements phase by placing an
order with a single item.
You will notice that I use some abstraction of concepts to accomodate
the diagram due to the lack of boundary and control classes. These
"helper" classes allow a designer to substitute boundary and control
classes while at the same time prevent you from getting involved in
technical details. It is important to notes that these are not in the
same realm as boundary and control classes, but are in fact a
precursor which will aid their future creation.
The place where most people have difficulty understanding sequence
diagrams is in the initial interaction between the actor and the
system. Since actors cannot invoke and act on entity objects directly,
a common practice is to use a Factory object. In our example I will
call this the OrderFactory - it is a singleton (only one instance)
which has already been initiated prior to the first interaction.
The first message to kick off the sequence is from the actor to the
factory to indicate the desire to place an order. Since the user is
invoking it, this initiateOrderProcess(customerObject) operation must
reside within the factory. I assume that the Customer is already
logged in (a precondition) and by invoking this operation is capable
of passing along his/her own customer information. The OrderFactory
then sends a create(customerObject) messages to instantiate an Order
object for that customer.
Since we now need a product list, I'll assume the system is capable of
doing so via another abstraction, a ProductList class. The
OrderFactory can invoke a create() message to instantiate a
ProductListObject (if one was previously not instantiated), and then a
retrieve() message to get the information required. So the ProductList
will need to contain create() and retrieve() operations.
Control now comes back to the Actor, who wants to select a certain
quantity of an item. A message is sent to the OrderFactory called
requestAddToOrder(product, quantity). Again we need an abstraction to
communicate our desire to validate the request so we use a class
called OrderValidator which is a singleton that has already been
instantiated by the OrderFactory upon its own creation. We now send a
checkInventory(product, quantity) message from factory to validator,
so this operation needs to be added to the validator. Assuming the
main flow that the order request can be filled, the OrderFactory
instantiates an OrderItem using a create(product, quantity) message.
This operation needs to be added to the OrderItem class. The factory
then adds the OrderItem to the Order by passing an
addItemToOrder(OrderItem) message. This operation needs to be added to
the Order class.
Control returns to the actor, who wants to finalize the order. I
notice in the Use Case that you are creating a new order at the end,
which doesn't work since you want to add OrderItems somewhere prior to
creating the actual Order object. Thus, this analysis gives you reason
to adjust your use case appropriately (which is exactly the point).
The ammended step 7 could read:
"7. System finalizes the order, and gives the customer a confirmation
containing an order number. The Use Case ends."
A message is passed from Actor to OrderFactory called
completeOrder(Order) - add this to the OrderFactory class. The factory
sends a finalize() message to the Order that was passed in - add this
operation to the Order class. The order number is generated here, and
passed back to the factory as a return value of finalize(). The
factory proceeds to relay this information back to the Actor.
You will notice that there are several technical details (generating
the order number, writing the completed order to a database) that I
have not included. A designer's job is to come in and rework the
sequence diagram above into something more details that considers
these issues. I would also expect that the Classes we created to
abstract certain ideas (OrderFactory, ProductList, OrderValidator)
would be reworked as other use cases enter the mix.
But you have nonetheless fulfilled your commitment as a BA, which is
to provide a business-focused basis from which the designer can
consider technical issues around your abstractions. Entity objects
should not need to be changed drastically because the BA typically
dictated the state and behavior of those Classes.
I hope this has given you something to sink your teeth into and
although it went far beyond the scope of your initial question I
understand the feeling of going against your gut with this subject
matter. I wish you all the best in your learning process and believe
me, your technical colleagues will benefit tremendously from your
initiative!
Cheers,
answerguru-ga
|
Request for Answer Clarification by
nosredla-ga
on
18 Nov 2005 11:34 PST
This is not a request for clarification, but my opportunity to comment
on what you have given me. Please do not feel you need to respond.
First, I really do appreciate the effort you have taken to satisfy my
"need to know" and accommodate my difficulty in stating my question
exactly. You have given me much to think about and a number of
directions for continued inquiry.
Second, though I will do further research and may change may mind, I
feel your response has confirmed my opinion that a Business Analyst
who is going to stand back from design can offer most to a developer
with a well documented Use Case and a good Class Diagram representing
the major business Classes with attributes but no operations and
without going further. I say this because I (and I think I am typical
of most BAs) do not think in terms of such abstractions as
"OrderFactory" which I still think are design considerations. Thus I
would have great difficulty doing what you suggest and since the
designer would need to rethink it anyway, I question the value.
That said, I acknowledge that the traditional role of the BA may need
to be revised (see http://www.agilemodeling.com/essays/businessAnalysts.htm).
You have given me some hard thinking to do about how I may need to
stretch myself.
This has been useful - I am not disappointed!
|
Clarification of Answer by
answerguru-ga
on
18 Nov 2005 16:16 PST
Thanks for your feedback - I'm glad you felt you got your money's worth.
answerguru-ga
|
,
6 Comments
)