Book a Demo

Author Topic: When to use instance and property  (Read 5298 times)

Hurra

  • EA User
  • **
  • Posts: 184
  • Karma: +0/-0
    • View Profile
    • Find me at LinkedIn!
When to use instance and property
« on: October 29, 2018, 06:49:13 pm »
Hello!

We are modelling with the UAF-mdg, and we would say we follow the framework correctly.

I do wonder though, is there any "correct" situation when to use instance instead of property or vice versa?

The new objects which are created when making an instance/property are not the same. Is there any "golden rule" for when to create an instance or property?

The problem we encountered was when setting multiplicity on inherited roles.

Situation A use role 1 (inherited), with multiplicity 3.

In situation B role 1 (inherited) is used as well but with multiplicity 2. Since the role is inherited it changes the role 1 in situation A multiplicity to 2 also. This is a situation where we decided to create instances instead.

Is the use of instances/properties situational? Use what best fits your demands?

I would appreciate guidance!

Thank you!
always learning!

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +397/-301
  • I'm no guru at all
    • View Profile
Re: When to use instance and property
« Reply #1 on: October 29, 2018, 07:50:46 pm »
Hmm, apples and pears being compared here? An instance is something concrete made from a blueprint. A property is something that makes the blueprint (and its instance) unique.

q.

Hurra

  • EA User
  • **
  • Posts: 184
  • Karma: +0/-0
    • View Profile
    • Find me at LinkedIn!
Re: When to use instance and property
« Reply #2 on: October 29, 2018, 09:42:02 pm »
Hmm, apples and pears being compared here? An instance is something concrete made from a blueprint. A property is something that makes the blueprint (and its instance) unique.

q.

I define a System-of-systems where a system is defined as
Quote
An integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements.

Every system is consists of an organization and a technical subsystem (which can consist of several systems).

The organization have roles.

What I have a hard time grasping is how "deep" the blueprint should be.

We want to use the blueprint for different occasions, let's say two times a year. Role A and Role B are defined as properties, blueprinted, of the organization for System 1.

I create an instance of System 1 for the first occasion, and inherit, the organization and roles. I can select from the parts/properties window which role should be a part of the system 1 organization instance.

Lets say for the first occasion and instance we only have Role A, and the multiplicity is 3.

The next occasion, I create a new instance of System 1, inherit the Organization and once again use the parts/properties window to select roles. This time I choose both Role A and Role B. For Role A I change the multiplicity to 2, and the multiplicity for Role B is 1.

But since I now changed the multiplicity for Role A, if I have a look at the instance for the first occasion and organization, it says Role A has a multiplicity of 2, which is not correct.

I might be over explaining this, because I think you all catch my drift, and I guess my main issue is:

What should be blueprinted (parts/properties) and what should be instances? When do I inherit parts/properties?
always learning!

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +397/-301
  • I'm no guru at all
    • View Profile
Re: When to use instance and property
« Reply #3 on: October 29, 2018, 11:48:16 pm »
Well, an instance (in UML) is the representation of something concrete. A company orders a certain type of hardware from a certain company. Those are blueprints (classes). Once you purchase a piece with a serial number you have an instance. Of course you can have this configured with different parts. They are also taken from a drawer (have a blueprint). So you get an assembled device instances consisting of likewise instantiated parts.

Abstraction is something very abstract. Classes are an abstraction of things. And you have even abstract classes (which can not be instantiated). Now, what is an instance? You know what an oak is. Probably when looking out of the window you can see several (like I can right now). You clearly recognize them as oaks. But when you look just a bit closer you see that they differ completely. I mean not just a bit, but heavily. Now, what you do in your model is to leave out things. The more you leave out, the more abstract it is. If you leave out very much you end up in "plant", rather than oak. Being more specific you have "black oak". And so on...

q.