OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [cti] The Adaptive Object-Model Architectural Style

Thanks for the feedback.
Kindly note that I'm not strongly defending this approach for the CTI
TC (at least for now).
Since you're using quotes:
"Architects that develop these types of systems are usually very proud
of them and claim that they are some of the best systems they have
ever developed. However, developers that have to use, extend or
maintain them, usually complain that they are hard to understand and
are not convinced that they are as great as the architect claims."

This, I hope could have our developers just understand
that what they feel difficult sometimes, is not intended to be
difficult per design, but because we are dealing with a complex domain
that the use of abstraction/conceptual approaches/ontology have benefits

Hopefully we can obtain consensus on a good balanced adapted approach.

2015-11-13 16:24 GMT+03:00 John Anderson <janderson@soltra.com>:
> Jerome,
> Thanks for the link. I really enjoy those kinds of research papers.
> On Page 20, the section "Maintaining the Model" [1] states pretty clearly that this type of architecture is very unwieldy, from an end-user perspective; consequently, it requires a ton of tooling development.
> The advantage of such a model is that it's extensible and easily changed. But I'm not convinced that extensibility is really our friend. In my (greatly limited) experience, the extensibility of STIX and CybOX have made them that much harder to use and understand. I'm left wishing for "one obvious way to do things." [2]
> If I were given the choice between (1) a very simple data model that's not extensible, but clear and easy to approach and (2) a generic, extensible data model whose extra layers of indirection make it hard to find the actual data, I'd gladly choose the first.
> Keeping it simple,
> [1] The full wording from "Maintaining the Model":
> The observation model is able to store all the metadata using a well-established
> mapping to relational databases, but it was not straightforward
> for a developer or analyst to put this data into the database. They would
> have to learn how the objects were saved in the database as well as the
> proper semantics for describing the business rules. A common solution to
> this is to develop editors and programming tools to assist users with using
> these black-box components [18]. This is part of the evolutionary process of
> Adaptive Object-Models as they are in a sense, “Black-Box” frameworks,
> and as they mature, they need editors and other support tools to aid in
> describing and maintaining the business rules.
> [2] From "The Zen of Python": https://www.python.org/dev/peps/pep-0020/
> ________________________________________
> From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Jerome Athias <athiasjerome@gmail.com>
> Sent: Friday, November 13, 2015 5:20 AM
> To: cti@lists.oasis-open.org
> Subject: [cti] The Adaptive Object-Model Architectural Style
> Greetings,
> realizing that the community members have different background,
> experience, expectations and use of CTI in general, from an high-level
> (abstracted/conceptual/ontology oriented) point of view, through a
> day-to-day use (experienced) point of view, to a technical
> (implementation/code) point of view...
> I found this diagram (and document) interesting while easy to read and
> potentially adapted to our current effort.
> So just wanted to share.
> http://www.adaptiveobjectmodel.com/WICSA3/ArchitectureOfAOMsWICSA3.pdf
> Regards

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]