Hi Jeff,
I am sending you an attachment so that you can have a bit more clear idea about my current work. This is my research proposal. I need more specific problem and scope to work here. Could you suggest me anything?
Thank you.
Afroza
| Attachment | Size |
|---|---|
| New idea.pdf | 210.97 KB |
Use Case Modeling - FDD sinergy
Hi, I am a bystander following this thread. Jeff, I am very interested in knowing your opinion concerning this specific topic presented by Afroza and, in general, about how FDD and UML come together. I am new to FDD and Agile principles en general. I hope the question is not too dumb.
Alejandro
Comments on New idea.
afroza,
In the first paragraph of your idea, you are basically saying that the domain model that is built by focusing on features may not be enough and that there needs to be an additional view of the model. Then you go on to justify using Use Cases to elaborate the model further. If this is a correct summary, read on.
The UML offers other views of the model. At my company, we tend to use the whole tool box. One way that we teach people on how to express use cases (not to be confused with 'use case diagrams'), is to visually represent them in an activity diagram, which has the necessary syntax defined to express use cases, scenarios, or user stories. Also, we teach moving back and forth between the various views depending on the type, amount and quality of information we have in order to get a clear picture and understanding of the system. It's not all one or the other, it's the combination of views through the various types of models that is really powerful.
Also, FDD does not limit the use of other types of models in expressing the system. It focuses on techniques that allow you to quickly and accurately define the domain of the system.
I also tend to use tools that have automatic reverse engineering capabilities that will keep the diagrams in sync as I elaborate the code. This also ensures that my models represent what is being built and will contain the complete elaboration of the system.
What I'm suggesting is that your approach to the problem you express take advantage of not just one tool or one view of a system, but recognise that the real answer lies in more than just one approach and using combinations of techniques. As an example, observe how people in the workplace solve a given problem. It's usually a combination of things, and that combination is dynamic, based on the experience, knowledge and the specific instances of the problem being solved.
This is very brief, but I hope it gives you some food for thought. I can elaborate on this more if necessary
Mac Felsing,
CTO, Principal, Co-Founder
PROCESSexchange
www.processexchange.com
Questions on Comments
Hi Mac,
Thanks for your time and suggestion. You are right, using more than one view and various types of models can depict fine points of a system. But I have few questions:
1) What are the fine points I need to model in use case which are not possible in feature model? How much information do I need to get a clear picture? (as you told, you teach ppl about the amount and quality of information)
2)You told you deal with moving back and forth between the various views. Could you please elaborate it?
3) Use case can identify the relationship between users and functionality (which feature model can't). Now can you tell me if it is really necessary to model variability?
It'd definitely help me if you explain a bit more. Thank you in advance.
Afroza