Author Topic: Can I show one object in different diagrams in different levels of abstraction.  (Read 2474 times)

ghdunn

  • EA Novice
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Hi,

I know I can place the same object on more than one diagram.

However, can I represent the same object in different diagrams to levels of abstraction?

So, in one high level view can show a database deployment as one simple 'square' object but elsewhere in the model show that as part of a more detailed deployment...perhaps showing it as a Server/OS/DB.

The ideal would be to 'drill' from one level of abstraction to another.

Any hints?

Thanks

Gerald
 

 

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8135
  • Karma: +228/-128
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Hi,

I know I can place the same object on more than one diagram.

However, can I represent the same object in different diagrams to levels of abstraction?

So, in one high-level view can show a database deployment as one simple 'square' object but elsewhere in the model show that as part of a more detailed deployment...perhaps showing it as a Server/OS/DB.

The ideal would be to 'drill' from one level of abstraction to another.

Any hints?

Thanks

Gerald
Hi Gerald,
Have a look at the Composite Structure Diagram.  That's essentially what it is there for.  However, you need to decide how you're going to model what you are seeing.  The single object "Database" CANNOT be composed of a Server / OS/ and Database.  You could say the Database is composed of Server Software, OS Software and DB Software.  Or Sever hardware, OS Software and DB Software.   That is, a DB cannot be composed of a DB.

If you have more questions, just ask.

HTH,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Modesto Vega

  • EA User
  • **
  • Posts: 791
  • Karma: +22/-8
    • View Profile
You could represent a database as a component with a composite structure or as a component (higher level of abstraction) and package (lower level of abstraction), with the package containing all the objects that make a database. Sparx has this concept of Packaging Component that is supposed to achieve the later but triggers some very strong opinions each time it is discussed in this forum.

The advantage of the 2nd approach is that you can easily draw a diagram describing that the database component is hosted on a server (a node) with the server also running a particular OS (another component) and RDMS (yet another component).

Richard Freggi

  • EA User
  • **
  • Posts: 383
  • Karma: +14/-7
    • View Profile
methinks if it's an object, then it's an object - a class instantiation.  What other levels of abstractions could be possible?  Higher level = a class.  Lower level = an artifact (code fragment, bunch of bits on a had disk somewhere...).  Not a lot of wiggle room.

Modesto Vega

  • EA User
  • **
  • Posts: 791
  • Karma: +22/-8
    • View Profile
methinks if it's an object, then it's an object - a class instantiation.  What other levels of abstractions could be possible?  Higher level = a class.  Lower level = an artifact (code fragment, bunch of bits on a had disk somewhere...).  Not a lot of wiggle room.
A class can be used to represent many levels of abstraction: conceptual (attribuless), logical (with attributes), physical (with attributes and physical data types as specified by the programming language or RDBMS).

A component can be used to represent many levels of abstraction, a physical database is not the same as it logical or conceptual representation.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8135
  • Karma: +228/-128
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Abstraction: the act of considering something as a general quality or characteristic, apart from concrete realities, specific objects, or actual instances.
I took Gerard as meaning that he wanted to show the database (system/environment) at different levels of detail.  That's not the same as abstraction, but we often use the term not quite correctly.
Perhaps Gerard could clarify?
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Richard Freggi

  • EA User
  • **
  • Posts: 383
  • Karma: +14/-7
    • View Profile
methinks if it's an object, then it's an object - a class instantiation.  What other levels of abstractions could be possible?  Higher level = a class.  Lower level = an artifact (code fragment, bunch of bits on a had disk somewhere...).  Not a lot of wiggle room.
A class can be used to represent many levels of abstraction: conceptual (attribuless), logical (with attributes), physical (with attributes and physical data types as specified by the programming language or RDBMS).

A component can be used to represent many levels of abstraction, a physical database is not the same as it logical or conceptual representation.

A class, yes.  An object, not really.

Modesto Vega

  • EA User
  • **
  • Posts: 791
  • Karma: +22/-8
    • View Profile
methinks if it's an object, then it's an object - a class instantiation.  What other levels of abstractions could be possible?  Higher level = a class.  Lower level = an artifact (code fragment, bunch of bits on a had disk somewhere...).  Not a lot of wiggle room.
A class can be used to represent many levels of abstraction: conceptual (attribuless), logical (with attributes), physical (with attributes and physical data types as specified by the programming language or RDBMS).

A component can be used to represent many levels of abstraction, a physical database is not the same as it logical or conceptual representation.

A class, yes.  An object, not really.
Agreed, but a component is not an object.
Quote
A Component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment.

(page 209 of the UML 2.5.1 specification.
The Component classifier specialises a Class.

As a result I would expect abstraction to apply to component but not to objects.