Discussions

News: Tree Oriented Perspective for Software Architecture and Design

Bookmark and Share Get thread feed

  1. Tree Oriented Perspective for Software Architecture and Design (3 messages)

    In this article, Venkata Reddy introduces the Tree Oriented Perspective (TOP), which is about standardized roles recursively applied using a hierarchical model for designing Enterprise Java systems. Role based design is not new; however, the perspective of hierarchical, recursive roles, standardized for common application needs may open up new schools of thought.

    Read Tree Oriented Perspective for Software Architecture and Design
    Reply to this

    Threaded Messages (3)

  2. This idea at the core of an approach called KobrA[ Go to top ]

    The idea of a tree-structured component hierarchy is the foundation of the KobrA software product line approach [Component-based Product Line Engineering with UML, 2002, Addison-Wesley], in which every behaviour-rich software entity is treated uniformly, regardless of its granularity or location in the "containment tree" that describes a software system. In other words software entities - which in KobrA are called "Komponents" - have the property of a fractal.

    Such an approach can indeed be used very effectively to manage dependencies in large code bases. See also http://www.softmetaware.com/complexity-and-dependency-management.pdf on this topic.
    Reply to this Reply to original

  3. komponents are components[ Go to top ]

    Hi Jorn, you might find very interesting this very mature ObjectWeb project: http://fractal.objectweb.org take a look around, read the specs, the implemenentations in the different languages, and go through some tutorials. cheers, valerio
    Reply to this Reply to original

  4. Role **instances** and role types, not just role types[ Go to top ]

    Generally, an object can be assigned with a role by means of class inheritance or interface implementation.
    I just wanted to point out that using this design is more limited than another design, where you actually instantiate the role types that you define separately from the actors that play them.

    If you declare that "Seller extends Person", that is to say that Sellers can only be Persons -- nothing else in your system can act as a Seller, but it is feasable that a Company could also act as a Seller, which wouldn't be possible in a single-inheritance language.

    Another frequently used design is "Person implements Seller"; this is a little more flexible, because now Company can also implement Seller. However, this design dictates that **every** Person and **every** Company is a Seller. Perhaps this shouldn't be possible, for example, if a Person or Company has to go through some sort of approval workflow before being allowed to be a Seller in the system.

    A design that allows for more flexibility is to define Person, Company, and Seller (and Buyer) separately as independent classes, with the Seller-specific behavior in the Seller class. Then, create Person and Company instances to your heart's content in the system, but none of them need be Sellers or Buyers right off the bat. Later (or at the same time, depending on your needs), you can associate a distinct Seller instance with a Person, and another distinct Seller instance with a Company. The association is the manifestation of the participation of the actor (Person, Company) in the system as the associated role (Seller, Buyer). It is actually a compositional relationship between actor and role, in general, where the actor composites the role.

    This is a key difference that has many benefits, as it allows one to differentiate instances of Person, Company, Buyer and Seller.

    Google "Streamlined Object Modeling" for more information on a full treatise of this design. Also, check out "Domain Driven Design" as well.

    HTH,
    Matthew
    Reply to this Reply to original