corelinux-public — General discussions of CoreLinux++

Re: [Corelinux-public] Oops

[Frank V. C. <fr...@co...>]

----- Original Message -----
From: Jim Koontz <jrk...@cs...>
To: <cor...@li...>
Sent: Friday, January 14, 2000 1:04 AM
Subject: Re: [Corelinux-public] Oops


> "Frank V. Castellucci" wrote:
>
> > > I agree with your sense of heaviness.  In an ideal world
> > > the requirement originator would be the one to determine
> > > if a design/implementation fufills the requirements,
> > > however once the requirement is fully analyzed and
> > > specified any developer should be capable of designing
> > > and implementing to meet the specifications.
> > >
> > > Tom
> > > --
> >
> > I meant a more granular approach:
> >
> > Someone does the requirement
> > Someone does the analysis based on the requirement
> > Someone does the design
> > Someone implements the design
> >
> > Or one person can do analysis AND design, or...
> >
>
> I like the granular approach myself, depending on the volume of work,
it
> might be nice to be able to delegate Requirements, Analysis, Design or
> implementation to someone else.  This also allows flexibility in
> accomodating different skill sets (as has already been mentioned).
>
> -- Jim
>

Yeah. I won't be able to update the process document today, but I think
it is fine that anyone reading the mailing list understands that your no
longer tied to the "soup to nuts" time debt.

Here is a list of who is working on what, so we don't collide:

Jim - String
Frank - Remaining Structural Patterns

Anyone can check the Bug Tracking and Analysis/Design/Implementation
task lists to see who is working on what.

---
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] Oops

[Jim K. <jrk...@cs...>]

"Frank V. Castellucci" wrote:

> > I agree with your sense of heaviness.  In an ideal world
> > the requirement originator would be the one to determine
> > if a design/implementation fufills the requirements,
> > however once the requirement is fully analyzed and
> > specified any developer should be capable of designing
> > and implementing to meet the specifications.
> >
> > Tom
> > --
>
> I meant a more granular approach:
>
> Someone does the requirement
> Someone does the analysis based on the requirement
> Someone does the design
> Someone implements the design
>
> Or one person can do analysis AND design, or...
>

I like the granular approach myself, depending on the volume of work, it
might be nice to be able to delegate Requirements, Analysis, Design or
implementation to someone else.  This also allows flexibility in
accomodating different skill sets (as has already been mentioned).

-- Jim

Re: [Corelinux-public] Bridge Implementation

[Frank V. C. <fr...@co...>]

Typo comment added to the end of this reply

"Frank V. Castellucci" wrote:
> 
> In light of the recent exchange here in regards to genericity in
> collections, it brought up an interesting conversation I had with Tom
> Maguire (a team member both here and on the job I have so my kids can
> milk me for every dime I have..., sorry), about the Bridge
> implementation.
> 
> As you all know, or maybe don't, I implemented the Bridge pattern where
> the base abstraction has the data member for the implementation:
> 
> class Bridge : public CoreLinuxObject
> {
>         ...
> 
> protected:
> 
>         CoreLinuxObjectPtr getImplementation( void );
> 
> private:
> 
>         CoreLinuxObjectPtr  theImplementation;
> };
> 
> This means that when a derivation is using the protected accessor, in
> order to perform the operation the bridge was called up to do, it would
> have to cast the implementation to the type that the derivation
> expected. In the example code, EngineBridge worked with Engine
> implementations.
> 
> Now, with Tom I mentioned his comment "Typically this is really ugly
> type checking code that is the hallmark of poor or  shortsighted
> analysis." in regards to the Java hashtable thread. I pointed out that
> Bridge requires the derivation to do exactley that!!!
> 
> So I am wondering, should we be offering a choice of implementation
> where possible? In the bridge case a possible scenario would be:
> 
> --------- In libcorelinux++ source -----------
> 
> // We keep the same Bridge we already have AND ADD
> 
> template < class Implementation >
>    class BridgeTemplate : public Bridge
>    {
>       ...
> 
>    protected:
> 
>         Implementation * getImplementation( void )
>         {
>                 return dynamic_cast<Implementation *>
>                         (Bridge::getImplementation());
>         }
> 
>    private:
> 
> };
> 
> // OR We keep the same Bridge we already have AND ADD
> 
> template < class Implementation >
>    class BridgeTemplate : public CoreLinuxObject
>    {
>       ...
> 
>    protected:
> 
>         Implementation * getImplementation( void )
>         {
>            return theImplementation;
>         }
> 
>    private:
> 
>         Implementation * theImplementation;
> };
> 
> ------------------------------------------------------

The above is wrong as I did not clarify that we would LOOSE the data
member in the base Bridge abstraction. Sorry.

[Corelinux-public] Bridge Implementation

[Frank V. C. <fr...@co...>]

In light of the recent exchange here in regards to genericity in
collections, it brought up an interesting conversation I had with Tom
Maguire (a team member both here and on the job I have so my kids can
milk me for every dime I have..., sorry), about the Bridge
implementation.

As you all know, or maybe don't, I implemented the Bridge pattern where
the base abstraction has the data member for the implementation:

class Bridge : public CoreLinuxObject
{
	...

protected:

	CoreLinuxObjectPtr getImplementation( void );

private:

        CoreLinuxObjectPtr  theImplementation;
};

This means that when a derivation is using the protected accessor, in
order to perform the operation the bridge was called up to do, it would
have to cast the implementation to the type that the derivation
expected. In the example code, EngineBridge worked with Engine
implementations.

Now, with Tom I mentioned his comment "Typically this is really ugly
type checking code that is the hallmark of poor or  shortsighted
analysis." in regards to the Java hashtable thread. I pointed out that
Bridge requires the derivation to do exactley that!!!

So I am wondering, should we be offering a choice of implementation
where possible? In the bridge case a possible scenario would be:

--------- In libcorelinux++ source -----------

// We keep the same Bridge we already have AND ADD

template < class Implementation >
   class BridgeTemplate : public Bridge
   {
      ...

   protected:

	Implementation * getImplementation( void )
	{
		return dynamic_cast<Implementation *>
			(Bridge::getImplementation());
	}

   private:

};

// OR We keep the same Bridge we already have AND ADD

template < class Implementation >
   class BridgeTemplate : public CoreLinuxObject
   {
      ...

   protected:

	Implementation * getImplementation( void )
	{
	   return theImplementation;
	}

   private:

	Implementation * theImplementation;
};

------------------------------------------------------

Any opinions?

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] Exceptions Feedback

[Frank V. C. <fr...@co...>]

The past few days have brought e-mails to me from people who are on the
outside of the mailing list. I have directed them to it, but until then
I want to summarize some of the things brought up:

1. Exception specification - Will we include the @exception tag in the
class declaration comments? What strategy is going to be defined for
exception types? 

To the first part, from a documentation standpoint, when I declare a
method and I know it has the potential for a specific assertion
(invarient checkes, assert check, etc) I usually include it in the
signature, as an example:

	/** 
	Set something
	@param SomeArgument [const reference | pointer | whatever ]
	*/

void	setSomething( SomeArugment ) throw(Exception); // or
void	setSomething( SomeArgument) throw(Assertion);

Doc++ will create hyperlinks back to Exception or Assertion because they
are part of the class documentation. Within CoreLinux++ declarations it
is reasonable to omit the @exception tag in this case, it is done for
us. But, this does not help with generation tools that we don't know if
they automatically infer the link from the signature. I believe ( and as
always it is my opinion only ) the safe way to go is to ALSO include the
@exception tag even though it is clear in the declaration.

To the second part, the author and I exchanged e-mails along the likes
of exception type specification. In other words, the generic exception
can not be reasoned with other than to use default behavior. So, the
point being that:

--------------------------------------------------------

class Bridge : public CoreLinuxObject
{
public:
	// ...

	BridgeRef  operator=(BridgeCref) throw(Exception);
};

--------------------------------------------------------

//
// can't be reasoned with compared to:
//

--------------------------------------------------------

class BridgeException : public Exception {..};

class Bridge : public CoreLinuxObject
{
public:
	// ...

	BridgeRef  operator=(BridgeCref) throw(BridgeException);
};
--------------------------------------------------------

//
// at a minimum, and
//

--------------------------------------------------------

class BridgeException : public Exception {..};
class SetImplementationException : public BridgeException {..};

class Bridge : public CoreLinuxObject
{
public:
	// ...

	BridgeRef  operator=(BridgeCref) throw(SetImplementationException);
};

--------------------------------------------------------

being more useful.

I believe that we SHOULD have an Exception type for each class, and it
would probably be a good idea to have a type hierarchy where applicable.
The user, when extending our classes to their domain, could continue the
extension accordingly.

A recent experience of mine has been that, in addition to Exception
Types, we had an Exception ID (Dword) that addressed two (2)
requirements; 1-The id was useful as a key for faulting in an
internationalized text message, and, 2-Kept the implementation down to a
more generic level although you still could reason with the Exception
ID. 

So:

--------------------------------------------------------

try
{
   ...
}
catch( ExceptionRef aRef )
{
   switch( aRef.getIdentifier() )
   {
      case handled0:
         break;
      case handledN:
         break;
      default:
         throw; // rethrow unhandled
   }
}
catch( ... )
{
   ...
}

--------------------------------------------------------

//
// versus 

--------------------------------------------------------

try
{
   ...
}
catch( SetImplementationExceptionRef aRef )
{
   ...
}
catch( BridgeExceptionRef aRef )
{
   ...
}
catch( ExceptionRef aRef )
{
   ...
}
catch( ... )
{
   ...
}

--------------------------------------------------------

Potentially produce the same results in regards to coverage, the latter
filling in the domain extension need. On the otherhand, the former has
many assumptions at our class library level and is difficult to extend
Exception IDs to new domains.

Anyone?

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] Oops

[Frank V. C. <fr...@co...>]

> I agree with your sense of heaviness.  In an ideal world 
> the requirement originator would be the one to determine 
> if a design/implementation fufills the requirements, 
> however once the requirement is fully analyzed and 
> specified any developer should be capable of designing 
> and implementing to meet the specifications.
> 
> Tom
> --

I meant a more granular approach:

Someone does the requirement
Someone does the analysis based on the requirement
Someone does the design
Someone implements the design

Or one person can do analysis AND design, or...

---
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] Oops

[<t.r...@at...>]

I agree with your sense of heaviness.  In an ideal world 
the requirement originator would be the one to determine 
if a design/implementation fufills the requirements, 
however once the requirement is fully analyzed and 
specified any developer should be capable of designing 
and implementing to meet the specifications.

Tom
--
----------
			
> I was re-reading the documentation and I noticed that I wrote something
> along the lines of "A requirement is owned through to implementation."
> 
> Is this to heavy? I mean, I have received e-mails from people with a
> range of interest and experience but not necessarily across the board.
> Should I change this to be a more modular effort?
> 
> I know there are times when I feel up to Analysis and/or Design, and
> other times I want to follow the recipe and just put out some code.
> 
> ---
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
> 
> 
> 
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public

[Corelinux-public] Oops

[Frank V. C. <fr...@co...>]

I was re-reading the documentation and I noticed that I wrote something
along the lines of "A requirement is owned through to implementation."

Is this to heavy? I mean, I have received e-mails from people with a
range of interest and experience but not necessarily across the board.
Should I change this to be a more modular effort?

I know there are times when I feel up to Analysis and/or Design, and
other times I want to follow the recipe and just put out some code.

---
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] a few questions

[Thomas M. <t.r...@wo...>]

----- Original Message -----
From: Frank V. Castellucci <fr...@co...>
To: CoreLinux mailing list <cor...@li...>
Sent: Monday, January 10, 2000 8:26 PM
Subject: RE: [Corelinux-public] a few questions


>
> >> 2. Is corelinux based on templates?
> >> I read the blurb on the use of templates. Static type checking is a
really
> >> nice feature to have. Yet, if you look at a language like java, where
all
> >> classes inherit from a superclass Object, non static type checking has
its
> >> benefits.. Ie. the ability to stick almost anything in a hashtable. I
see
> >> how this could be resolved using templates and a strict java-like class
> >> heirarchy..

Actually all collections in both Java and C++ are homogeneous.  They don't
let you
"stick almost anything in them" they only allow to stick one thing in them,
in your
example everything would have to be an Object.  The fact that everything in
Java
is derived from Object is of little or no help because you must cast the
Object to
its derivation to do anything meaningful.  Typically this is really ugly
type checking
code that is the hallmark of poor or shortsighted analysis.

Tom

>
> > The lack of genericity is a weakness of Java, not a strength. Sticking
> > all kinds of things into a hashtable is a hack and causes all kinds of
> > nightmares. First of all, why would you want to stick lots of unrelated
> > data into a hashtable? That would certainly reflect a poor design
> > decision somewhere in your code. But if the data are related to each
> > other, why aren`t they in a class together? If they`re in a class, you
> > can store a collection of these classes with templates, thus preserving
> > type safety and more clearly showing yourself and others your coding
> > intentions.
> >
> > --Joe
>
> My $.02
>
> A Bag is an unordered collection of objects that may be repeated and
> don't have to be related.
>
> In Java, all objects ARE related through the Object super class EXCEPT
> scalars and boolean (although this is solved through the wrappers). The
> hashtable won't allow repeats and all objects are related.
>
> I agree that a hashtable is NOT a bag.
>
> For C++ in problem domains like Shopping Carts or Solar Systems bags MAY
> be desired and I would think there is some kind of taxonomy that the
> members belong to (M class planets, produce, etc.). The limitation is
> that unless you use a void pointer as the element you are constrained by
> the template definition type.
>
> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
>
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public
>

[Corelinux-public] Released 0.4.1

[Frank V. C. <fr...@co...>]

I released 0.4.1 today.

It includes implementations for Adapter and Bridge, as well as test
code.
As well as documentation changes up to today. The biggest addition being
"From Design to Implementation" in the process documents.



---
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] Should we 0.4.1 or wait until 0.5.0?

[Neil T. <ab...@ic...>]

Frank,

The Bazaar answer is "release early, release often", and I still think
that is the best way to work.

Cheers! (Relax...have a homebrew)

Neil


On Mon, 10 Jan 2000, Frank V. Castellucci wrote:

> So there it is: Do we create releases at small steps, or wait until a
> bigger milestone is met?

[Corelinux-public] Should we 0.4.1 or wait until 0.5.0?

[Frank V. C. <fr...@co...>]

As I have integrated Adapter, and am well into the same for Bridge and
CoreLinuxObject (need a testdriver example), should we be making
incremental drops for this granularity?

I originally thought that 0.5.0 would have the Structural Patterns and
our definitive string. At the current burn rate, and as a volunteer
effort on ALL our parts is to be expected (actually I don't know what to
expect as I have never taken part in such an effort), it may take a
while and should we be giving the community a sip of something. 

I am still holding strong that for CoreLinux++ the libraries are the
materialization of the process. Damn good ones by the looks of the
requirements, but the code is not all there is. This was the original
intention, to share openly a process that others may feel useful.

Don't read this as a rush into pushing something out, I think I have
wind-bagged the process issues so much even my children have disowned
me. I wouldn't put code into our CVS base without letting everyone know
each step of the way where the Analysis and Design were. And I am my own
worst cop in regards to design and implementation.

And I must admit, but am open to learning from any arguments, that the
patterns, in particular, are so shallow I sometimes wonder if we should
even have the types in the code. Seriously I am a Type kinda OO nut so I
see them as useful to the unexposed.

So there it is: Do we create releases at small steps, or wait until a
bigger milestone is met?

You have five seconds to respond <grin>.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

RE: [Corelinux-public] a few questions

[Frank V. C. <fr...@co...>]

>> 2. Is corelinux based on templates?
>> I read the blurb on the use of templates. Static type checking is a really
>> nice feature to have. Yet, if you look at a language like java, where all
>> classes inherit from a superclass Object, non static type checking has its
>> benefits.. Ie. the ability to stick almost anything in a hashtable. I see
>> how this could be resolved using templates and a strict java-like class
>> heirarchy..

> The lack of genericity is a weakness of Java, not a strength. Sticking
> all kinds of things into a hashtable is a hack and causes all kinds of
> nightmares. First of all, why would you want to stick lots of unrelated
> data into a hashtable? That would certainly reflect a poor design
> decision somewhere in your code. But if the data are related to each
> other, why aren`t they in a class together? If they`re in a class, you
> can store a collection of these classes with templates, thus preserving
> type safety and more clearly showing yourself and others your coding
> intentions.
> 
> --Joe

My $.02

A Bag is an unordered collection of objects that may be repeated and
don't have to be related. 

In Java, all objects ARE related through the Object super class EXCEPT
scalars and boolean (although this is solved through the wrappers). The
hashtable won't allow repeats and all objects are related.

I agree that a hashtable is NOT a bag. 

For C++ in problem domains like Shopping Carts or Solar Systems bags MAY
be desired and I would think there is some kind of taxonomy that the
members belong to (M class planets, produce, etc.). The limitation is
that unless you use a void pointer as the element you are constrained by
the template definition type.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] a few questions

[Frank V. C. <fr...@co...>]

James Sasitorn wrote:
> 
> Well, I have a few questions, so I'll just enumerate them. Most of which are
> nitpicky, but I'm curious...
> 
> 2. Is corelinux based on templates?

CoreLinux++ is based on good requirement review, good analysis, and good
detailed design, prior to implementation. If the analysis or design
shows that templates are a more qualified approach to a paricular
problem domain then we will use templates.

> I read the blurb on the use of templates. Static type checking is a really
> nice feature to have. Yet, if you look at a language like java, where all
> classes inherit from a superclass Object, non static type checking has its
> benefits.. Ie. the ability to stick almost anything in a hashtable. I see
> how this could be resolved using templates and a strict java-like class
> heirarchy..

I agree that there are times when a pervasive base object has
advantages. The Bridge Pattern uses this. CoreLinux++ is also strongly
supporting the STL standard. So as of now CoreLinux++ has a
CoreLinuxObject base class BUT it is not the base of all objects at this
point.
 
> 3. If you have a subclass specifically for UTF8, are you considering a
> subclass for each of the different regional encodings (theoretically, of
> course)?

This is a good point. Please keep in mind that the StringUtf8 that is in
the current code point is NOT, NOT, NOT what we want as a string. The
requirement is open and I wouldn't mind discussing it in the short term
to get it moving along.

> 4. Have you considered standarizing the types in an abstract header file.
> Similiar to what glib does...
> http://developer.gnome.org/doc/API/glib/glib-basic-types.html

See Types.hpp

> 
> 5. I noticed the use of doc++. Does documentation include the use of the
>     @param, @exception, features?

Yes.

> 6. What is the current stage of development?
> 
> thanks,
> 
> james

Well, the Analysis for the Structural Patterns has just been put up. I
also managed to get the initial design and implementation in for the
Adapter Pattern.

I am putting the final touches on the process to include From Design to
Implementation.

Requirements are still arriving, and anyone who wants to tackle the
process needs to own the requirement to implementation. But at this
point, no one has grabbed any except myself (I hope it is because of the
holidays, but some people e-mailed me that the process was to involved).

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] a few questions

[Joe N. <3ne...@pr...>]

> 2. Is corelinux based on templates?
> I read the blurb on the use of templates. Static type checking is a really
> nice feature to have. Yet, if you look at a language like java, where all
> classes inherit from a superclass Object, non static type checking has its
> benefits.. Ie. the ability to stick almost anything in a hashtable. I see
> how this could be resolved using templates and a strict java-like class
> heirarchy..

The lack of genericity is a weakness of Java, not a strength. Sticking
all kinds of things into a hashtable is a hack and causes all kinds of
nightmares. First of all, why would you want to stick lots of unrelated
data into a hashtable? That would certainly reflect a poor design
decision somewhere in your code. But if the data are related to each
other, why aren't they in a class together? If they're in a class, you
can store a collection of these classes with templates, thus preserving
type safety and more clearly showing yourself and others your coding
intentions.

--Joe

[Corelinux-public] a few questions

[James S. <ca...@ri...>]

Well, I have a few questions, so I'll just enumerate them. Most of which are
nitpicky, but I'm curious...

1. Why use .cpp and .hpp, instead of the more unix .cc and .hh?

2. Is corelinux based on templates?
I read the blurb on the use of templates. Static type checking is a really
nice feature to have. Yet, if you look at a language like java, where all
classes inherit from a superclass Object, non static type checking has its
benefits.. Ie. the ability to stick almost anything in a hashtable. I see
how this could be resolved using templates and a strict java-like class
heirarchy..

3. If you have a subclass specifically for UTF8, are you considering a
subclass for each of the different regional encodings (theoretically, of
course)?

4. Have you considered standarizing the types in an abstract header file.
Similiar to what glib does...
http://developer.gnome.org/doc/API/glib/glib-basic-types.html

5. I noticed the use of doc++. Does documentation include the use of the
    @param, @exception, features?

6. What is the current stage of development?

thanks,

james

[Corelinux-public] Re: Prof. 3.5 issues

[Frank V. C. <fr...@co...>]

These guys are quick to respond:


"Frank V. Castellucci" wrote:
> 
> Saulius Kaukenas wrote:
> >
> > Frank,
> >
> > I have another question regarding #6: do you see all the operations listed in
> > report? If you do then it is normal application behavior (we do not add "virtual"
> > and other specific code generation tags to the report).
> >
> 
> Ok, fair enough.
> 
> Then I would like to request that, as an option, we be able to configure
> WHICH language elements to include in the report.
> 
> Rationale: As our reports are public (we post them to the web) it would
> be desired to have all aspects of a class specification generated so
> that a developer may correctly implement.
> 
> Addendum to problems:
> 
> 7. And I also found that the roles are not being generated. So if we
> design with roles (instead of relegating them to attributes or having to
> do both), in the report it as though they don't exist.
> 

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] Feedback on the MagicDraw issues

[Frank V. C. <fr...@co...>]

Saulius Kaukenas wrote:
> 
> Frank:
> 
> Thank you for feedback. We do appreciate your efforts to make MagicDraw
> product better. See my comments below:
> 
> "Frank V. Castellucci" wrote:
> 
> > I have found a couple of problems with MagicDraw UML 3.5 , no show
> > stoppers, mainly report issues:
> >
> > 1. The diagram display of methods is not consistent with the order they
> > are entered, they seem to be sorting on stereotypes, we may not use them
> > (stereotypes) for the time being.
> 
> The attributes (and operations) may be sorted according their name
> (alphabetically), stereotype or visibility. They also can be unsorted (i.e.
> they are displayed in the order they were entered). The sorting rule can be
> changed from popup menu of the class (you can select either the
> "presentation options" or "edit view" and then "sort attributes" ("sort
> operations").
> 
> > 2. There does not seem to be a way to order functions within a class, in
> > the class diagram object it seems that you are supposed to be able to
> > drag the order, but it does not fully work (maybe because of #1).
> >
> > 3. Constraints require a name and appear as "{name = expression}". I
> > would suggest we stick to the standard "pre:", "post:" and "invariant:"
> > of OCL 1.1.
> 
> That's a reasonable suggestion. Probably we will go that way.
> 
> > 4. While you can specify an exception in the Language Settings, they do
> > not appear as part of the specification in the Class report and it
> > doesn't appear that there can be more than one (1) specified.
> 
> This is a functional limitation. We will fix it in next version.
> 
> > 5. Documentation assigned to the top level diagram is not generated in
> > any report. The classes, use-cases, etc. documentation is generated, but
> > not the diagram view itself.
> 
> This is another functional limitation (diagram images aren't present in
> reports therefore documentation isn't generated for them either).
> 
> > 6. Methods marked as virtual (Language settings) do not appear in the
> > class report.
> 
> I was not able to regenerate that situation. I can guess that you have made
> some other changes in report options (e.g. checked "public members only").
> 
> --
> Saulius Kaukenas
> Product Manager,
> No Magic, Lithuania
> P.O. box 2166, LT- 3000, Kaunas
> Phone: +370-7-229424, Fax +370-7-200536
> email: sa...@no...
> WWW: http://www.nomagic.com
> --
> MagicDraw UML page: http://www.magicdraw.com

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://www.colconsulting.com 
Object Oriented Analysis and Design |Java and C++ Development

[Corelinux-public] Bridge Design In

[Frank V. C. <fr...@co...>]

Checked in and posted updates for Bridge Design

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] References Tag

[Frank V. C. <fr...@co...>]

"Frank V. Castellucci" wrote:
> 
> As I am working through some of the analysis it is becoming apparent
> that some of the requirements will reference work done elsewhere.
> 
> For example, in the Bridge requirement we are going to provide the base
> Bridge class and a derivation that enables reference counting. The
> ReferenceCount class will be used (projecting here) by the Bridge
> derivation. It seems reasonable that in the SRS for Bridge there is a
> reference to the SRS for ReferenceCount (or whatever).
> I can make the change to the template and the existing requirement
> documents without much hassle at this point.
> 
> Any objections, issues, etc?

I have updated the SRS template and all existing SRS documents on the
web and cvs. The update was including a line below the Design documents
line. Hyperlinks (as required) will point to the referenced SRS.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] Process document updates and FYI

[Frank V. C. <fr...@co...>]

I have updated and uploaded, commited, etc. the process.html document to
cover admin steps in the design work.

I have found a couple of problems with MagicDraw UML, no show stoppers,
but mainly report issues:

1. The diagram display of methods is not consistent with the order they
are entered, they seem to be sorting on stereotypes, we may not use them
for the time being.

2. There does not seem to be a way to order functions within a class, in
the class diagram object it seems that you are supposed to be able to
drag the order, but it does not fully work (maybe because of #1).

3. Constraints require a name and appear as "{name = expression}". I
would suggest we stick to the standard "pre:", "post:" and "invariant:"
of OCL 1.1.

4. While you can specify an exception in the Language Settings, they do
not appear as part of the specification in the Class report and it
doesn't appear that there can be more than one (1) specified.

5. Documentation assigned to the top level diagram is not generated in
any report. The classes, use-cases, etc. documentation is generated, but
not the diagram view itself.

6. Methods marked as virtual (Language settings) do not appear in the
class report.

I am posting these issues to NoMagic and will let everyone know the
outcome.
-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] Adapter checked in

[Frank V. C. <fr...@co...>]

Checked in the Adapter pattern:

Analsis,
Design
Update to libcorelinux library
Sample code (src/testdrivers/ex3)
Web page updates

I still need to describe From Analysis to Design in more detail, maybe
before Monday US.

In doing the design it became apparent that MagicDraw UML is missing
some ease of use functionality. I will be reporting that to their
support team.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] Next steps

[Frank V. C. <fr...@co...>]

All Analysis steps have been followed for the Structural Patterns.

I have started on Design steps for same (Adapter at the moment).
I will update the process document for design
After design of Structural I will implement and create examples in
testdrivers
I will update the process document for implementation

I will release 0.5.0 at this point.

I have expanded the Creational Patterns requirements in the Project
Forum. They will be next.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] Last of the batch

[Frank V. C. <fr...@co...>]

I have created, checked-in, and uploaded models, reports, etc. for:

Facade
Flyweight
Proxy

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] Decorator Updated

[Frank V. C. <fr...@co...>]

The Decorator requirement, model, etc. is CVS and web.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux