corelinux-public — General discussions of CoreLinux++

Re: [Corelinux-public] Document Templates

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

> "Frank V. Castellucci" wrote:
>
> > ----- Original Message -----
> > > We should have an area for document templates.  I am assuming that
our
> > file
> > > format will be HTML.  It would be convenient to have these on the
web,
> > or in
> > > CVS, or both.
> > >
> > > I know that the design documentation will be dictated largely by
UML,
> > but it
> > > would be nice to have templates for these documents, and for the
> > > requirements documents as well.
> > >
> > > Jim Koontz
> > > jrk...@us...
> > >
> >
> > Do you mean cascading style sheets?
> >
> > ---
> > Frank V. Castellucci
>
> Hmm...I actually meant a template for each document type containing
the
> headings in the appropriate type style, but a style sheet that
controls the
> formatting of all documentation is a good idea too.
>
> Jim Koontz
> jrk...@us...

Well, we have the SRS template already in CVS and located in the
/corelinux/doc directory. What other document templates were you
thinking of.
---
Frank V. Castellucci
http://corelinux.sourceforge.net

Re: [Corelinux-public] Changes and Holiday

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

"Frank V. Castellucci" wrote:

> I made the changes I spoke of.
>
> I noticed something as well, in reading the process document I saw that
> all Requirements will be discussed for acceptance while I am merrily
> adding the Pattern requirements as though they are approved. I think
> they are squarley in the target of the CoreLinux++ goals but...let me
> know any objections.
>
> Of the current requirements, listed in the Forum, I DON'T think we have
> implicit approval for:
>
> Persistence
> Java Proxy and JVM Interface
> Meta Class
> Directory and Names
> Smart Pointers
> Herbrand Domains
> Class Context
>
> only because we all might not have an understanding as to "What they
> mean" and "Why do we want them".
>
> Happy Holidays
>
> --
> Frank V. Castellucci
>
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public

I had noticed that there were several requirements in the forum, but
I thought that those had been approved before my participation in the
project.  I'll look at them more closely.  I am sure that they are all
reasonable requirements, and I am also sure that I may not understand all
of them.

JimKoontz
jrk...@us...

Re: [Corelinux-public] Document Templates

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

"Frank V. Castellucci" wrote:

> ----- Original Message -----
> > We should have an area for document templates.  I am assuming that our
> file
> > format will be HTML.  It would be convenient to have these on the web,
> or in
> > CVS, or both.
> >
> > I know that the design documentation will be dictated largely by UML,
> but it
> > would be nice to have templates for these documents, and for the
> > requirements documents as well.
> >
> > Jim Koontz
> > jrk...@us...
> >
>
> Do you mean cascading style sheets?
>
> ---
> 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

Hmm...I actually meant a template for each document type containing the
headings in the appropriate type style, but a style sheet that controls the
formatting of all documentation is a good idea too.

Jim Koontz
jrk...@us...

[Corelinux-public] Changes and Holiday

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

I made the changes I spoke of. 

I noticed something as well, in reading the process document I saw that
all Requirements will be discussed for acceptance while I am merrily
adding the Pattern requirements as though they are approved. I think
they are squarley in the target of the CoreLinux++ goals but...let me
know any objections.

Of the current requirements, listed in the Forum, I DON'T think we have
implicit approval for:

Persistence
Java Proxy and JVM Interface
Meta Class
Directory and Names
Smart Pointers
Herbrand Domains
Class Context

only because we all might not have an understanding as to "What they
mean" and "Why do we want them".

Happy Holidays


-- 
Frank V. Castellucci

[Corelinux-public] Some changes

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

I thank anyone who has pointed documentation errors, spelling or
otherwise, in this list or via e-mail. I would ask that in the future
you enter them as a DEFECT in our project. This enables us to track
these like any other change request.

I have added the most recent submitted by Jim ( Defect 100530 ).

In addition I am making some changes to the Requirement process which
can be viewed on-line sometime today. The additional step includes
creating a Feature (in Bug Tracking). So once we approve a Requirement,
before any of the initial files for the requirement are checked in
(reqXXXX.html, reqs.html), you will need to create a Feature for it.
When the files are checked in, the feature id should be noted in the log
message.

Features are a group in Bug Tracking, and Requirement is a category, so
the Bridge Pattern I am working on has a Bug Track entry of:

ID	: 100531
Category: Requirement
Group   : Feature
Summary : Requirement 3142

when I commit a file I will:

$ cvs commit -m"100531 Added index entry for Requirement 3142" reqs.html

for example.

This Feature ID (100531) will be noted in all files up to an including
the implementation. Once the completed implementation has been checked
in, the feature will be closed.

Any Tasks created on behalf of the same work will note the Feature ID as
well.

-- 
Frank V. Castellucci

Re: [Corelinux-public] Document Templates

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

----- Original Message -----
> We should have an area for document templates.  I am assuming that our
file
> format will be HTML.  It would be convenient to have these on the web,
or in
> CVS, or both.
>
> I know that the design documentation will be dictated largely by UML,
but it
> would be nice to have templates for these documents, and for the
> requirements documents as well.
>
> Jim Koontz
> jrk...@us...
>

Do you mean cascading style sheets?

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

Re: [Corelinux-public] Review of Documentation

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

----- Original Message -----

> I think the documentation looks good, although the FAQ has a few
errors:
>
> 1.3 Will the class libraries and frameworks be portability?
>
>  ...portable?
>
> 1.5:
> Free time, the belief in Open Source, Linux, other organizations
belief in
> the same, and sweat.
> ...organizations'...
>
> 5.4.2: How is the documentation created?
> We are juggling between two systems that generate HTML from comments
in the
> source headers. Luckily, the both work off of the same style of
commenting.
>
> <sp> ...they both work off the same style of commenting.
> or :  they both work from the same style of comments.
>
> Jim Koontz
> jrk...@us...
>

I can't blame the flu on these 8-^ (  thanks.

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

[Corelinux-public] Document Templates

[Koontz, J. <jam...@ce...>]

We should have an area for document templates.  I am assuming that our file
format will be HTML.  It would be convenient to have these on the web, or in
CVS, or both.

I know that the design documentation will be dictated largely by UML, but it
would be nice to have templates for these documents, and for the
requirements documents as well.

Jim Koontz
jrk...@us...

[Corelinux-public] Review of Documentation

[Koontz, J. <jam...@ce...>]

I think the documentation looks good, although the FAQ has a few errors:

1.3 Will the class libraries and frameworks be portability?

 ...portable?

1.5: 
Free time, the belief in Open Source, Linux, other organizations belief in
the same, and sweat.
...organizations'...

5.4.2: How is the documentation created?
We are juggling between two systems that generate HTML from comments in the
source headers. Luckily, the both work off of the same style of commenting.

<sp> ...they both work off the same style of commenting.
or :  they both work from the same style of comments.

Jim Koontz
jrk...@us...

[Corelinux-public] Updates done

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

I completed the following today

1. Added Date Modified to Web Pages
2. Added link from main web page to our new Process Page
3. Added link from main web page to our new Functional Requirement Index
Page
4. Created these new files in a fog of flu (review would be appreciated)
5. Uploaded all web pages
6. Checked-in all changes and additions.

Have a look by either CVS update, or from the
http://corelinux.sourceforge.net

-- 
Frank V. Castellucci

Re: [Corelinux-public] Unicode support

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

Jim Koontz wrote:
> 
> This message was sent from Geocrawler.com by "Jim Koontz" <jrk...@us...>
> Be sure to reply to that address.
> 
> Is anyone aware of IBM's open source project (IBM
> Classes for Unicode) to create class libraries
> supporting unicode?
> 
> http://www10.software.ibm.com/developerworks/opens
> ource/icu/index.html
> 
> Jim Koontz
> jrk...@us...

I have it...played around with it a bit...pretty powerful stuff. There
is also a libunicode out there somewhere which seems capable, but not as
broad.

-- 
Frank V. Castellucci

[Corelinux-public] Unicode support

[Jim K. <arc...@db...>]

This message was sent from Geocrawler.com by "Jim Koontz" <jrk...@us...>
Be sure to reply to that address.

Is anyone aware of IBM's open source project (IBM 
Classes for Unicode) to create class libraries 
supporting unicode?

http://www10.software.ibm.com/developerworks/opens
ource/icu/index.html

Jim Koontz
jrk...@us...

Geocrawler.com - The Knowledge Archive

Re: [Corelinux-public] Web Page Updates

[Thomas J. <ac...@pr...>]

Not yet.

Just upgraded my system to Mandrake 6.1 and am now
re-establishing my environment.

-- Tom.

"Frank V. Castellucci" wrote:
> 
> Jim Koontz wrote:
> >
> > We should mark updated standards documents on the
> > CoreLinux++ web page with the update date, in
> > addition to the "Updated!" icon.
> > Jim Koontz
> 
> Will do. Have you logged on yet using SSH? Tom?
> 
> --
> Frank V. Castellucci
> 
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public

Re: [Corelinux-public] More reqs coming

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

> How about KUML? It's free, and lots of work is being done on it.
> http://www.informatik.fh-hamburg.de/~kuml/
>
> --Joe

Joe,

I had looked at KUML a bit back. I even conversed with some of the
developers on the lack of constraints (OCL). They indicated that they
would like to add them, but it was not a priority. As with Argo/UML
there are a few key UML pieces missing.

In addition their host page states

"The program isn't useable currently. Don't start to do your work with
it. Your work maybe will lost. "

which is understandable given it is WIP.

Another problem I see is that it would require KDE installed. While I
personally do have this, I don't know about everyone else. I guess the
same argument can be said about Java.

Finally, with KUML it is not clear as to what format the diagrams are
saved in. They have a feature for XML/XMI but I don't think it is ready.

My thoughts are to keep an eye on all the possible, but I also think
that we need usable solutions now.

Thoughts?

Frank

Re: [Corelinux-public] More reqs coming

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

> As far as Argo/UML I have yet to hear back from the author about the
> future work. It lacks some key UML features yet.
> 
> As far as MagicDraw UML I have posted a e-mail looking for a "controlled
> donation" of fully capable versions as a good-will gesture for our
> effort. I offered a reference to their site on each document we generate
> from the tool. No word. Worst case, we should hopefully be done with
> diagrams by April 1st 2000 for at least libcorelinux++. The caveat here
> is that all the requirements are not in.

How about KUML? It's free, and lots of work is being done on it.
http://www.informatik.fh-hamburg.de/~kuml/

--Joe

[Corelinux-public] More reqs coming

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

My apologies for the sudden black out, I was (still am) being wracked by
this weeks favor of flu.

I have expanded the Patterns Structural requirements in the forum so
each pattern has a req ID. I will be posting the initial functional
requirement for each as I did with the Adapter Pattern. In addition I
will be:

1. Making the spelling corrections pointed out in the From Analysis To
Design document and posting
2. Adding Date Last Updated to the web pages
3. Turning the Req Docs into HTML for posting on the web.
4. Posting the remaining Patterns Requirement (Structural) Functional
Requirement Document on the mailing list then #3.

If anyone is looking for something to do, you can expand the Patterns
Creational or Behavioral in like fashion and take a whack at a
Functional Requirement doc.

As far as Argo/UML I have yet to hear back from the author about the
future work. It lacks some key UML features yet.

As far as MagicDraw UML I have posted a e-mail looking for a "controlled
donation" of fully capable versions as a good-will gesture for our
effort. I offered a reference to their site on each document we generate
from the tool. No word. Worst case, we should hopefully be done with
diagrams by April 1st 2000 for at least libcorelinux++. The caveat here
is that all the requirements are not in.

If you got 'em, lets here 'em so we can figure them in.

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

Re: [Corelinux-public] Web Page Updates

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

"Frank V. Castellucci" wrote:

> Jim Koontz wrote:
> >
> > We should mark updated standards documents on the
> > CoreLinux++ web page with the update date, in
> > addition to the "Updated!" icon.
> > Jim Koontz
>
> Will do. Have you logged on yet using SSH? Tom?
>
> --
> Frank V. Castellucci
>
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public

I have not yet attempted to login using SSH, but I will give it a try
and see how it works.

Jim Koontz
jrk...@us...

[Corelinux-public] UML Tool

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

I have found a tool that (in the demo anyway) has much more diagrams and
function for what we need. It is called MagicDraw. It requires Java (as
most seem to). It can generate HTML reports and IMGs of the diagrams.

I downloaded the Pro version demo (some restrictions and expires April
1, 2000) from:

http://www.nogmagic.com


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

Re: [Corelinux-public] Web Page Updates

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

Jim Koontz wrote:
> 
> We should mark updated standards documents on the
> CoreLinux++ web page with the update date, in
> addition to the "Updated!" icon.
> Jim Koontz

Will do. Have you logged on yet using SSH? Tom?


-- 
Frank V. Castellucci

[Corelinux-public] Web Page Updates

[Jim K. <arc...@db...>]

This message was sent from Geocrawler.com by "Jim Koontz" <jrk...@us...>
Be sure to reply to that address.

We should mark updated standards documents on the 
CoreLinux++ web page with the update date, in 
addition to the "Updated!" icon.

Jim Koontz
jrk...@us...

Geocrawler.com - The Knowledge Archive

[Corelinux-public] UML Tools

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

Has anyone used or looked at Argo/UML?  It supports XLI, and has some
code generation capabilities.    Its listed on Freshmeat, heres the URL
to its web page:

http://www.ics.uci.edu/pub/arch/uml/index.html

There is also a diagramming package called Dia that is the open source
equivalent of Visio, it can do UML diagrams, but has no CASE features.

http://www.lysator.liu.se/~alla/dia/


Jim Koontz
jrk...@us...

[Corelinux-public] From Analysis To Design

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

Here are some comments on the Analysis to Design doc:

The assumptions I am making about the reader at this point are:

A. That the effort of Analysis has is that the focus is on the problem
domain, not on a specific technical solution.
/*
 -- I understand the meaning here, but the verbage is confusing.  Remove
"has"?
*/

B. Class, Sequence, Collaboration, State, and Activity diagrams are
             understood. If you are unsure about these let me know and I
will post
             links to where you can find out more. For immediate
consumption
             http://www.cetus-links.org has a tremendous reference list.

/*
-- I need to familiarize myself with these diagrams, thanks for the
reference link!
*/

In general, the design is a technical expansion and adaptation of the
             analysis results. The classes, realtionships, and
collaborations from
             the analysis are complemented with new elements, now
focusing on how to
             implement the requirement.
/*
-- <sp.>  ... realtionships...
--  <?> ...now focusing on how to....
*/

1. Once a Analysis has been checked in it will move into the Design

/*
-- an Analysis... <?>
*/
<cut to the end>

I like this description of the process, it is very detailed, and covers
some important points.

Jim Koontz
jrk...@us...

[Corelinux-public] Requirements Document

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

...I would like to propose a template for the Requirements Document....

I'll let you know what I think of this one after I have to fill one
out!  Seriously, it seems to cover all the bases, and as you say,
discussion of the requirement should provide the information to complete
the document.

Jim Koontz
jrk...@us...

[Corelinux-public] From Requirements to Analysis

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

>Following is the process that will be used by CoreLinux++ in regards to

>             Requirements moving into Analysis, as well as what the
analysis will
>             achieve. I will follow this in latter posts with From
Analysis to Design
>             and From Design to Implementation.

>             THIS IS OPEN FOR DISCUSSION!!! I just felt we needed to
start drawing
>             the lines in the sand as to the rules of engagement (ROE).

>             Following any changes to this, I will begin to add this to
the
>             CoreLinux++ OOA/OOD document.
<snip>

I have no objections to the process you have described, I think its a
good starting point.  Exposing the process to our own "use case" will
reveal any areas that need improvement.

Jim Koontz
jrk...@us...

[Corelinux-public] Functional Requirement 2872 - Adapter Pattern

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

Title         : Adapter Pattern
Requirement ID: 2872

1. Introduction

Design Patterns (Gamma et al) page 139

An Adapter converts the interface of a class into another interface that
clients expect. This allows classes work together that couldn't
otherwise because of the incompatible interfaces.Sometimes a toolkit
class that's designed for reuse isn't reusable only because its
interface doesn't match the domain specific interface an application
requires.

1.1 Deliverables Overview

In review of some of the requirements for libcorelinux++ and applying
some foresight, it became apparent that there will be times when either
the library, framework, or user extensions will want to use the
implementation of other class libraries without loosing the type
relationships in libcorelinux++.

For example, if we state that in some class requirement there is a need
for a String, but as application needs change a particular case wants to
use a UCS2 string or UCS4 string then any of our core classes that had a
dependency on a UTF8 string would potentially break. With an Adapter
class we could have our core classes use a base or Abstract string and
provide Adapaters that maintain the interface our core objects would
expect (through delegation).

This deliverable is very light weight in that we want to capture the
Adapter type class and not much more at this point.

The CoreLinux++ team will deliver Adapter implementations for specific
cases as needed.

Users can use this as a basis for creating their own Adapter hierarchies
outside of the libcorelinux++ library.

2. Functional Requirements

Adapter will be publically available for extension.

2.1 User Interface Specifications

NA

2.2 Product Services

NA

2.3 External Interfaces and Database Requirements

NA 

2.4 Error Handling

NA 

2.5 Foreseeable Functional Changes and Enhancements

At this level, the only consideration may be the factoring of some
method or data member that is recognized across many domains, in other
words not likely.

3. Non-Functional Requirements

Precondition constraints: None
Postcondition constraints: None
Invarient constraints: None 

3.1 Performance Requirements

NA

3.2 User Documentation and Other User Aids

This Document
Analysis Use-Case diagrams
Design class diagrams

3.3 Development Requirements

Standards: CoreLinux++ C++ Standards and Guidelines
Will be part of the libcorelinux++ shared library.

3.5 Foreseeable Non-Functional Changes

NA

4. Remarks and Guidelines for Later Life Cycle Phases

TBD

5. Term Glossary 

TBD

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