Object-Oriented Technology: from Diagram to Code with Visual Paradigm for UML

General Questions/Discussions
1

Hi there,

Last week, I came across your book on your site. Unfortunately, it is very difficult to find. I am wondering if the book will be updated soon again (last version 2005) and adjusted to your latest VP Suite version?

Also, another question I am having is: are you in your book describing in detail how to write a problem statement? cauz in the sample chapters, the discussion is not indepth.

I downloaded the 2 sample chapters, and they look absolutely great.

cheers,
ten

2

Hello ten,

Thank you for your message. We do have plans to renew or rewrite our book, but currently there is no fixed time frame yet. About writing problem statement, actually the problem statement is just a textual description of the system. One of the way obtaining problem statement is through interview with stakeholder or users. There is no specific format on writing problem statement. If you require any further information, please do not hesitate to contact me again.

Best regards,
Rain

3

Thank you very much. If you have a mailing/waiting list for interested people, please add me to the list so that I’d be informed :slight_smile:

4

Sure. I’ll keep you informed about this.

Best regards,
Rain

5

Dear Rain,

I am wondering if you or the authors of the book could possibly provide me with some feedback:

By the beginning of November, I have to give a short presentation concerning the PROBLEM STATEMENT. Reference is hereto made to your sample chapter 3 on use case modelling, which is very good.

Now, on Saturday, I searched for several hours on the internet for research papers as well as on the ACM where I am a member on this topic. Interestingly, there is little information in this field that would address questions like:

  • why is a problem statement critical?
  • what are its benefits?
  • what are drawbacks?
  • how to make / write a problem statement?
  • who should make a problem statement?
  • do bullet points suffice? or should it encompass whole sentences?

I came across some information in the field of SSM. However, I see drawbacks there because from an engineering standpoint, it is critical to avoid vague and open requirements. The only interesting approach may regard the CATWOE approach.

Now, going on to a deeper level, I think that we may even argue that a PROBLEM STATEMENT does not only cover a use model but covers use case models. Working in a large project with a complex (legacy) system, requirements by business cover different areas. One may counter argue that these areas may refer to (use case) packages. However, as soon as subject domains change, I think it would they are rather use case models that can consist of packages.

This thought leads us to hierarchies within subject domains now. Do we subgroup problem statements? Moreover, can we also argue that a use case description is by itself its own problem statement?

If, of course, we merely regard simple ATM system as problem domain, it suffices to only have one problem statement from where we can derive use cases. However, as soon as we change the focus onto large systems, we meet a different angle and reach an enormous level of complexity.

So, I am wondering if you possibly dispose of some more information? Also, although the field of problem statements/textual analysis were hot in the 70’s when even programming languages were developed, it seems to me, that this field leaves space for research.

Any input and maybe even articles or copies of statements with sources would deeply be appreciated.

Anyway, the features that VP UML provide are great and I feel that there should be great potential in this sub domain.

Kind regards,
Ten