Today I’ve spent some time reading a set of documents at the company. It is incredible how official documents and manual has a lot of misunderstanding, things take lead to a wrong set of concepts and ideas.
It is important to have good concepts and solid knowledge, mainly to use the tools available for us. In this post I am showing small phrases and I would like you to read it carefully, you will face some amazing texts (by the way, I have translated them to English).
The PowerDesign implements a Use Case Diagram and its objects using a OOM – Object Oriented Model. It was defined by the Methodology that all the Systems will have a OOM, called CAU (Use Cases), and all the functional requirements specification will be inside of this model.
First of all, you cannot implement a Use Case Diagram in a tool, what the tool does is: provide ways to modeling a Use Case Diagram and write a Use Case Specification. Next, Use Cases are not related to Object Oriented Modeling, they are related to UML (Unified Modeling Language), they are used to describe the responsibilities and boundaries of the system.
At the last, functional requirements are not Use Cases or vice-versa, when you put them in the same level you end up having a functional decomposition. Absolutely you don’t have a use case for each functional requirement. Use Cases represent what the actor wants from a system, not the functions of the system.
Lately we will see an example of it.
In truth, the Object Oriented Analysis is quite simple. Their concepts are closer to the human comprehension than the essential or structured analysis. In fact their functional definition is oriented to the user comprehension of the system, which doesn’t need to have any technology concept.
So at the end you cannot show it to your user, unless he know the concepts.
In fact their functional definition is oriented to the user comprehension… well I don’t know why it is true? What do we have is a highlight in the objects of the system, but if it is not well modeled the OOA will not show the user comprehension of the system. If you do the right thing doesn’t matter the tool, it will be right.
The benefits of the OOA are others like abstraction, where you can first look at a high level, and getting deeper and deeper as you know more about the problem scope (but I should say that it is not the only benefit).
The resistance to the Object Oriented Analysis happens because most of the people look at it as something advanced. In fact it has extraordinary concepts, for example, it is possible to automate the code creation
OOA = automate code creation? What kind of insanity is it? You could say that from UML tools can generate code for you, but OOA, no way. From a language you could generate another language, doesn’t matter if it is OO or not.
Code generation is sure before OOA and it is not limited to that, for example: BPMN (Business Process Modeling Notation) is not OO and can be used to generate code.
But to create the methodology documents will be necessary only a small part of the Object Oriented Analysis, the Use Cases. That were already being made in the old documentation, although it was called as Requirements by functionality.
I will say it again: Use Cases are not OOA. If someone makes just Use Cases he doesn’t need to know anything about object. And again: functionalities are not Use Cases.
All the modern tools for system modeling, among them the PowerDesigner, implement the UML
You don’t implement UML, you provide tools to draw, write, read, do whatever with UML, but it cannot be implemented.
In short, each system functionality must have a Use Case, describing how the user will interact with the system, in the strict context of the functionality.
Use Cases are NOT functions. A Use Case represents a situation where the user uses the system, to use the system a user can interact with one or more functions of the system, and a function can be used in one or more use cases, simple as that.
When you put them in the same level, you end up with a lot of small Use Cases that aren’t really cases.
…The UML says that its name may have any amount of letters, numbers and most of the special characters. As we saw, to the Methodology the rules for naming are: CAU-[Verb in the Infinitive + Object]. Let’s take the Order as example:
CAU-Make Order CAU-Verify Order CAU-Cancel Order
First: Use Cases are not bind to specific objects. One of the first steps in OOA is to extract objects from a Use Case (when we are using Use Cases), so you cannot name them by their objects, mainly because a Use Case will interact with more than one object at the same time.
Second: Creating Use Cases like Make Order, Verify Order, Cancel Order, Whatever Order means that we are writing functionalities and Use Cases. In this situation the user is interested in managing his Order, so we should have something like Manage Order; put yourself as a user and imagine what do you want from the system: you want something that allow you to manage your order, so it is your Use Case. For sure inside of this Use Case you will make, verify, cancel, delete the order.
In that situation you could have another Use Case that is something like Audit Order (it is reasonable that the user wants to get information from the Order and some processing on that, so you will have another Use Case).
As people say: not too much to heaven, not too much to hell.
An actor could be anything that communicates with the system. An actor could be the system user, but it could be an equipment, another system, a paper, and so on. The actor always interact with the system, but it doesn’t belong to it.
We should imagine an Actor as someone interested in your system, like the user, another system that receives data from us, and so on.
Um comentário:
You're right, it would be better not writing such things instead of filling documents with whatever comes up in mind without thinking about it. Besides the fact it leads to misunderstandings, it's a waste of time for everyone involved in the process.
Postar um comentário