You are absolutely correct: one calculates complexity per-module.
Decomposition is accounted for by adding 1 to the module complexity (to
account for calls).
The "things get dramatically worse when complexity exceeds 7" statement was
with reference to any given module, *not* the entire stack. If that was the
case, we never would have made it down the elevator, no less to the moon.
On 10/23/07 6:18 AM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote:
>
>
>
> Eric Burger wrote:
>> Not *factors* of 2 or 4, but cyclomatic complexity increasing by a *count*
>> of 2 or 4.
>>
>> However, the result is similar: there is tons of Software Engineering data
>> that shows when modules get above a cyclomatic comlexity of 7, the number of
>> latent defects raises non-linearly.
>
> I'm not really a student of that stuff, but I believe that is for one
> function or other closed unit of code.
>
> When you take a system, if you add the complexity of each piece then of
> course you get a huge number. In theory you don't have to do that
> because the system is hierarchically decomposed into pieces each with
> acceptable complexity, and in *theory* you can understand them one at a
> time.
>
> However I have yet to see a reasonable sized system where the overall
> structure of all the pieces didn't introduce another kind of practical
> complexity that AFAIK isn't normally measured.
>
>> Henning (or some lurker looking for something to do): an interesting
>> Master's Thesis would be to calculate the theoretical minimum cyclomatic
>> complexity of the current SIP state machine.
>
> For one thing, SIP can't really be evaluated with a state machine
> because it has stacks. (Via and Route headers, etc.) But that doesn't
> really change the discussion.
>
> I'm not sure its a meaningful question. But it seems like if it could be
> answered, the answer would have to be in the thousands, or more, when
> viewed as a whole. (Which is why adding two or four is irrelevant.)
>
> To get a more meaningful number you would have to decompose it into a
> hierarchy of state machines (or functions, objects and methods, ...) and
> then find the worst case complexity of all those.
>
>> That may answer the, "Why SIP
>> does not interoperate" question.
>
> I certainly agree that SIP is very complex, contrary to the claims that
> were made for it early in its life. I don't have enough context to
> compare it complexity to that of earlier systems for the same job - it
> is my impression that they are worse.
>
> The complexity is why we have been writing guides and clarification
> documents, etc. (They don't *fix* the complexity, but they may help
> people to master it.)
>
> I do appreciate the point that the complexity arises one decision at a
> time, and we should always be trying to make things as simple as we can,
> given what we have to do.
>
> It always comes down to: is the benefit of this new feature worth the
> complexity that it brings. Not everybody comes to the same answer about
> such a question.
>
> Paul
>
>> On 10/22/07 3:30 PM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote:
>>
>>> Eric,
>>>
>>> I disagree with your *quantitative* assessments of how much thee things
>>> increase complexity (by factors of 2 or 4). But I certainly agree that
>>> complexity *will* increase.
>>>
>>> In the end everything we are doing increases complexity, so maybe we
>>> should all pack up shop and go home.
>>>
>>> Ultimately this all comes down to deciding how complex things have to
>>> get before people can do what they think they need to do.
>>>
>>> Paul
>>>
>>> Eric Burger wrote:
>>>>
>>>> On 10/17/07 2:18 PM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote:
>>>> [snip]
>>>>> One agreed upon, NOTIFY may be sent in the agreed upon direction(s)
>>>>> within the INVITE dialog usage. Whether an initial NOTIFY is required
>>>>> will be determined on a per-event-package basis. (Its not needed to
>>>>> establish the dialog, so its a matter if it is semantically needed in
>>>>> the context of the event type.)
>>>> Which is not the way NOTIFY works today, which means the sender has to have
>>>> code to the effect:
>>>>
>>>> if( !real_notify(event_object) )
>>>> {
>>>> if( needs_first_notify(event_object) )
>>>> {
>>>> send_event(event_object);
>>>> }
>>>> }
>>>> else
>>>> send_event(event_object);
>>>>
>>>> Just (1) changed NOTIFY behavior, making it "not NOTIFY" and raised the
>>>> complexity of your notification stack by 2.
>>>>
>>>> [snip]
>>>>
>>>>> There is no separate subscription or timer. The dialog usage is
>>>>> refreshed by INVITE or UPDATE in the conventional manner. Events to be
>>>>> exchanged are renegotiated from scratch with every reINVITE or UPDATE.
>>>> So what does the NOTIFY put into expires? I hear hk now: "Just stuff it
>>>> with 99999." OK, this now adds another hack into send_event(), "If I am a
>>>> real SUBSCRIPTION, return the timer; if I am not, return 99999." Just
>>>> upped
>>>> the complexity by 1.
>>>>
>>>> Worse yet, what does the recipient do when it gets a BYE? Now it has
>>>> either
>>>> a resource leak or more code:
>>>>
>>>> if( got_bye(dialog_object) )
>>>> {
>>>> for each pseudo-dialog subscription in the (dialog_object)
>>>> {
>>>> consider the subscription terminated;
>>>> }
>>>> }
>>>>
>>>> Upping the complexity by 2, again.
>>>>
>>>> Hey - we are not done yet! I will leave as an exercise to the reader the
>>>> amount of complexity added to create the implicit subscription in the first
>>>> place.
>>>>
>>>> I forgot, this really is targeted for devices that will hard code
>>>> everything
>>>> and not support any real SUBSCRIBE/NOTIFY packages. [facetious]
>>>>
>>>> It would be much cleaner to call this thing "NOTQUITENOTIFY".
>>>>
>>>> Of course, since we are anal about messages and bandwidth, let's save 300ns
>>>> and just call the method "I". [joking]
>>>>
>>>> [snip]
>>>>
>>>>
>>>> Notice: This email message, together with any attachments, may contain
>>>> information of BEA Systems, Inc., its subsidiaries and affiliated
>>>> entities, that may be confidential, proprietary, copyrighted and/or
>>>> legally privileged, and is intended solely for the use of the individual or
>>>> entity named in this message. If you are not the intended recipient, and
>>>> have
>>>> received this message in error, please immediately return this by email and
>>>> then delete it.
>>>>
>>
>>
>>
>> Notice: This email message, together with any attachments, may contain
>> information of BEA Systems, Inc., its subsidiaries and affiliated
>> entities, that may be confidential, proprietary, copyrighted and/or
>> legally privileged, and is intended solely for the use of the individual or
>> entity named in this message. If you are not the intended recipient, and have
>> received this message in error, please immediately return this by email and
>> then delete it.
>>
>
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
