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


sorry for the others if off-topic.

Remember that a software is good only if it satisfies the users (meet,
or exceed, their requirements).
You can write 'perfect/optimized' code. If the users are not
satisfied; it's a bad software.

Then,
"If you can't explain it simply, you don't understand it well
enough.", Albert Einstein

Challenges are exciting, but sometimes difficult. It's about
motivation and satisfaction.

There is not programming language better than an other (just like OS);
it is just you that can select the best for your needs.

I did a conceptual map for the 'biggest Ruby project of the internet'
(Metasploit Framework), it's just a picture, but represents 100 pages
of documentation.
I think we could optimize (like for a maturity model) our approach of
resolving problems.









2015-11-13 17:02 GMT+03:00 John Anderson <janderson@soltra.com>:
> The list returns my mail, so probably you'll be the only one to get my reply.
>
> Funny, I missed that quote from the document. And it's spot on. As an architect myself, I have built several  "elegant" architectures, only to find that the guys who actually had to use it just. never. quite. got it. (sigh)
>
> My best architectures have emerged when I've written test code first. ("Test-first" really does work.) I've learned that writing code--while applying KISS, DRY and YAGNI--saves me from entering the architecture stratosphere. That's why I ask the architects to express their creations in code, and not only in UML.
>
> I'm pretty vocal about Python, because it's by far the simplest popular language out there today. But this principal applies in any language: If the implementation is hard to explain, it's a bad idea. (Another quote from the Zen of Python.) Our standard has a lot that's hard to explain, esp. to new-comers. How can we simplify, so that it's almost a no-brainer to adopt?
>
> Again, thanks for the article, and the conversation. I really do appreciate your point-of-view,
> JSA
>
>
> ________________________________________
> From: Jerome Athias <athiasjerome@gmail.com>
> Sent: Friday, November 13, 2015 8:45 AM
> To: John Anderson
> Cc: cti@lists.oasis-open.org
> 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
> and
> 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,
>> JSA
>>
>>
>> [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]