CODEWITHSUNDEEP
c++oopuml
ST Renegade
ST Renegade

Reputation: 311

UML modeling without deep knowledge of underlying libraries

For my next project I would like to try UML modeling. There are several reason - mainly documentation + to break ground for development to avoid re-coding everything over and over again.

I've tried it several times in the past, but I had a feeling like without a deep knowledge of the background libraries my work will depend on, It's not a trivial task, as at the very beginning I don't know, what kind of member variables and functions I would need.

Usually I was coding to get familiar with the libraries and API my app was interface and I get into a state, where the work was almost done or let's say it was from 50% ready, where it made no sense to me to start modeling something.

Am I true you really need to understand well the background or there are ways/techniques how to overcome this?

Another point is, do you built up the model from bottom to top or from top to bottom or it depends on the use case?

Thank you for any recommendations how to proceed.

Upvotes: 1

Views: 96

Answers (2)

Gerd Wagner
Gerd Wagner

Reputation: 5683

The three main purposes of making UML class models when developing an app are:

  1. Describing the entity types of the app's problem domain for analyzing and better understanding the requirements for the app in a conceptual (domain) model.
  2. Designing the schema of the app's underlying database (this is typically an RDB schema defined with a bunch of CREATE TABLE statements).
  3. Designing the model classes of the data model of your app, which will be coded, e.g., as Java Entity classes or C# classes with EF annotations.

For 1 and 2, you may take a look at my book An introduction to information modeling and databases, while for 3 you may check out a book on model-based development, e.g. for Java Backend Apps or JavaScript Frontend Apps.

enter image description here

If your goal is to model the dependencies of your app, this may indeed be another purpose. However, as argued by @Christope, reverse-engineering a library is itself a big project that may easily consume more time than you have for developing your app.

Upvotes: 1

Christophe
Christophe

Reputation: 73446

If I understand well, your main challenge is to get an understanding of the libraries and API that you are using.

If you intend to create an UML diagram for reverse-engineering the library and understand it, you might loose your time: You'd be able to make a meaningful model only once you've understood how the pieces fit together. And for this discovery and knowledge acquisition, you already use the most effective approach:

Usually I was coding to get familiar with the libraries and API my app was interfaced.

Now, if the library or the API is delivered with an UML model, it's another story: an existing design model (not all the details of the implementation, but the core elements of the design, and interaction scenario that are difficult to grasp from the code) could help you to grasp faster how the library works, which will help you to go faster through the exploratory phase.

It's also a different story when you are reverese-engineering an undocumented app: there you don't have a tutorial, and it's difficult to write code to use the existing elements in a meaninful way. There it could make sense to document the system post-mortem. But again, do not lose yourself in a detailed implementation model with all the details: focus on the core elements, whose understanding will really matter for your maintenance fellows.

Upvotes: 1

Related Questions