cobold-developer — developer discussions and announcements

[Cobold-developer] towards a whitepaper

[joern t. <joe...@we...>]

Hi *,

i'd like to initiate the next step in the discussion about the cobold
platform. since a lot of issues, thoughts and wishes have been gathered
its about time to transform these into a more structured document which
may become the first whitepaper/documentation of the system.

although we all have some very concrete ideas in our heads that's still
the problem - there still in our heads and not written down somewhere
for reference. therefore it seems valuable to gather the fragments we
have and form them into a new more elaborated structure for further
development. we may e.g. share the document via sourceforge simply as an
openoffice document.

i've another thought in mind when proposing this document: since we have
a lot of ideas these still have to be structured to become one whole
thing. i've recently read an article about how software is build in the
aviation industry where highest reliability and robustness is needed;
they first implement all testcases of the system *and* the complete
documentation! then coding is started  with clear, well documented
requirements. of course, this is an extreme, but a bit of it may be
helpfull for us now. - in documenting the details of how our system
should behave and be used in future we fix the requirements by the way.
this is quite the same viewpoint like that of a test but from a higher
perspective - you look from outside and define how the system should
look and behave.

i think we already discussed a document structure and should restart
this. anybody?

now some content:
in the meantime i've learned that the common wording for what we've
named 'usecase realisation' maps quite good to the term 'process
definition' which seems to be common in business process modelling.

free citation:
process modelling is the activity which analyses a business and
translates these into a set of activities and transitions (a process model).

so a process definition seems to be the missing part which we need to
formalize our autmated process. - and of course we'd like to express it
in XML.

the process model is expressed in terms of UML activity diagrams cause
these already provide all needed constructs like
- activity
- transition
- conditional
- forks and joins in transitions
- loops

the neat advantage of this is quite clear. you can use any UML tool to
define the business process and as long as it supports XMI it should be
easy to transform the diagram into a process-definition.

i won't go into detail about the possible structure but i have a good
proposal for that on my desk if you like the overall idea.

if this model will be adopted we'll need a process-engine which works on
the process-model and manages the flow. here we come back to
XForms/Chiba and i guess that its would be possible to express/transform
the process-model into one (or a set of related ones) XForms.

in this case there will be a layer (lets call it ProcessEngine in
contrast to XFormsProcessor) which is responsible to start business
processes by loading some specified xforms and maybe routing data
between several different forms in more complex scenarios.

'below' this layer there will be the xforms processor which executes the
details of a activity as described by the processmodel. for this to be
possible, the xforms processor must be able to make use of services
(like fetching some data from a db). these should perfectly be possible
with the current implementation via connectors.

much more could be said but this should be enough for today.

comments?

cheers,

Joern











-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Cobold-developer mailing list
Cob...@li...
https://lists.sourceforge.net/lists/listinfo/cobold-developer

[Cobold-developer] towards a whitepaper

[joern t. <joe...@we...>]

Hi *,

i'd like to initiate the next step in the discussion about the cobold 
platform. since a lot of issues, thoughts and wishes have been gathered 
its about time to transform these into a more structured document which 
may become the first whitepaper/documentation of the system.

although we all have some very concrete ideas in our heads that's still 
the problem - there still in our heads and not written down somewhere 
for reference. therefore it seems valuable to gather the fragments we 
have and form them into a new more elaborated structure for further 
development. we may e.g. share the document via sourceforge simply as an 
openoffice document.

i've another thought in mind when proposing this document: since we have 
a lot of ideas these still have to be structured to become one whole 
thing. i've recently read an article about how software is build in the 
aviation industry where highest reliability and robustness is needed; 
they first implement all testcases of the system *and* the complete 
documentation! then coding is started  with clear, well documented 
requirements. of course, this is an extreme, but a bit of it may be 
helpfull for us now. - in documenting the details of how our system 
should behave and be used in future we fix the requirements by the way. 
this is quite the same viewpoint like that of a test but from a higher 
perspective - you look from outside and define how the system should 
look and behave.

i think we already discussed a document structure and should restart 
this. anybody?

now some content:
in the meantime i've learned that the common wording for what we've 
named 'usecase realisation' maps quite good to the term 'process 
definition' which seems to be common in business process modelling.

free citation:
process modelling is the activity which analyses a business and 
translates these into a set of activities and transitions (a process model).

so a process definition seems to be the missing part which we need to 
formalize our autmated process. - and of course we'd like to express it 
in XML.

the process model is expressed in terms of UML activity diagrams cause 
these already provide all needed constructs like
- activity
- transition
- conditional
- forks and joins in transitions
- loops

the neat advantage of this is quite clear. you can use any UML tool to 
define the business process and as long as it supports XMI it should be 
easy to transform the diagram into a process-definition.

i won't go into detail about the possible structure but i have a good 
proposal for that on my desk if you like the overall idea.

if this model will be adopted we'll need a process-engine which works on 
the process-model and manages the flow. here we come back to 
XForms/Chiba and i guess that its would be possible to express/transform 
the process-model into one (or a set of related ones) XForms.

in this case there will be a layer (lets call it ProcessEngine in 
contrast to XFormsProcessor) which is responsible to start business 
processes by loading some specified xforms and maybe routing data 
between several different forms in more complex scenarios.

'below' this layer there will be the xforms processor which executes the 
details of a activity as described by the processmodel. for this to be 
possible, the xforms processor must be able to make use of services 
(like fetching some data from a db). these should perfectly be possible 
with the current implementation via connectors.

much more could be said but this should be enough for today.

comments?

cheers,

Joern

Re: [Cobold-developer] [proposal] cobold use cases

[joern t. <joe...@we...>]

Ulrich Nicolas Liss=E9 wrote:

> hi *,
>=20
> i'd like to propose the following (sorry for the wording):
>=20
> *cobold self reflectiveness*
>=20
> since cobold aims to provide tool support for a use case driven
> approach, itself should be developed using this approach. this means
> that we should start an analysis on cobold's use cases.
agree: +1


would be a start to collect use cases in a first unordered list here. my=20
cents...

>=20
> here are some candidates, based on our former ideas.
>=20
> - admin cobold projects
> - manage use case descriptions
> - manage use case realisations
> - manage logical views
> - manage data entities
> - view todo list
> - generate project ;-)

other candidates:

actor: Admin - manages runtime aspects and configuration of Cobold apps
actor: developer - creates and maintains cobold apps
actor: user - runs (and possibly installs) cobold apps

- developer:create project
- developer:generate docs
- developer:create layout
- developer:create scenario
- developer:use datasource

joern

>=20
> regards, uli.

[Cobold-developer] [proposal] cobold use cases

[<u....@gm...>]

hi *,

i'd like to propose the following (sorry for the wording):

*cobold self reflectiveness*

since cobold aims to provide tool support for a use case driven
approach, itself should be developed using this approach. this means
that we should start an analysis on cobold's use cases.

here are some candidates, based on our former ideas.

- admin cobold projects
- manage use case descriptions
- manage use case realisations
- manage logical views
- manage data entities
- view todo list
- generate project ;-)

regards, uli.
--=20
Ulrich Nicolas Liss=E9

Re: [Cobold-developer] ideas and discussion issues

[<u....@gm...>]

hi *,

joern turner wrote:

> hello *,
>=20
> oliver charlet wrote:
>=20
>> hello cobolds,
>>
>> this is a short protocol about the dicussion we had yesterday:
>>
>> please feel free to correct and change!
>>
>> - separation of entities and behaviour
>> a basic pattern must be, to separate value objects and business logic.=
in
>> that way the datamodel can be modeled and implemented regardless of an=
y
>> semantic functions that use a lot of different entities. if the behavi=
our
>> would be inside the data objects, there would exist a very ugly=20
>> network of
>> close coupled objects.
>=20
> i would prefer to speak of logic or behaviour instead of just business =

> logic cause this is only a small subset of the code to be created for a=
=20
> full application. additionally this may be misleading cause the busines=
s=20
> logic normally is the part with the smallest potential of automization =

> in generative development.
>=20

agree. business logic is a quite fuzzy term with many different notions.
i'd too prefer to speak of behaviour. moreover i'd suggest to think of a
logical view layer which is created on top of the loosely coupled data
entities. behaviour is implemented on top of this logical view layer.
this may lead to complete decoupling of behaviour and data which is
desirable in terms of roundtrip engineering. additionally, the logical
view layer becomes subject to generation which seems desirable too.

>>
>> - back end design
>> given the fact, that Chiba is a fix component of the cobold architectu=
re,
>> the other major issue to think about is the creation of a back end=20
>> that fits
>> into the Chiba architecture. It needs tests and prototyping to develop=
an
>> efficient work flow to achieve 1) a well defined application framework=
=20
>> and
>> 2) a pragmatic software development process.
>>

just to be clear: i don't think that the current chiba architecture
should completely determine the cobold back end architecture. chiba is
targeted to become a flexible and generally usable component. when
difficulties arise during back end integration we have to think over
chiba's integration facilities too.

>> - GUI / navigation
>> since the GUI part of chiba as today is suboptimal in terms of easy
>> deployment of individual design, it seems to be a good idea to embed=20
>> chiba
>> inside another front end component like a cms or portal framework=20
>> (e.g. jet
>> speed etc.).
>> it is an unsolved issue to integrate a modular and flexible front end =

>> design
>> into xForms.
>=20
> i'd like to paraphrase this as: its not the goal of XForms to provide a=
=20
> presentation/layout facility - this is always the responsibility of the=
=20
> embedding language may it be XHTML, SVG or whatever. site- or=20
> application navigation shouldn't be handled with xforms; established=20
> technologies like portals or jsp are more suitable for this level.
>=20

again agree. since it is platform independent (or, at least, agnostic)
xforms - and therefore chiba - simply doesn't deal with layout. i don't
see an issue in integrating front end design into xforms, but in
integrating xforms with a presentation layer (which essentially has to
provide design facilities).

>>
>> - Chiba integration
>> being the first and only applicable software component of cobold,=20
>> chiba is
>> to be beta tested to develop a prototype for a complete system. first =

>> steps
>> will be to port the form4 jforce framework and adapt it to the chiba
>> controller.
>>
>> - Use Case XML / documentation
>> with the goal of a generative system in mind, there could be first=20
>> versions
>> of descriptive XML for UseCases, data model and business logic. Since =

>> form4
>> already has some experience in usecase implementations, a basic XML to=

>> describe the requirements to generate UseCase source code should be
>> developed in the next time.
>=20
> yes. very interesting. we could then take this as a testcase and build =

> XForms for it to get a feeling how this might fit together.
>=20
>=20
>>
>> - MDA / UML 2.0
>> since the generative view of software development is becoming more com=
mon
>> and is in the press constantly, it must be validated, how MDA=20
>> specifications
>> and UML 2.0 can be deployed to be a part of the cobold project.
>=20
>=20
> interesting to look at:
> - EMF (Eclipse project)
> - http://www.architectureware.de/ Open Source MDA tool / Generative=20
> Umgebung

regards, uli.

>=20
> Joern
>=20
>>
>>
>> so far for now...
>> :olliC
>>
>> -----------------------
>> oliver charlet
>> form4 gmbh & co. kg
>> rungestr. 19
>> 10179 berlin
>> fon +49 (30) 27 87 84 -0
>> fax +49 (30) 27 87 84 -10
>> oli...@fo...
>> http://www.form4.de
>> -----------------------
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> Cobold-developer mailing list
>> Cob...@li...
>> https://lists.sourceforge.net/lists/listinfo/cobold-developer
>>
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Cobold-developer mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobold-developer
>=20
>=20


--=20
Ulrich Nicolas Liss=E9

Re: [Cobold-developer] ideas and discussion issues

[joern t. <joe...@we...>]

hello *,

oliver charlet wrote:

> hello cobolds,
> 
> this is a short protocol about the dicussion we had yesterday:
> 
> please feel free to correct and change!
> 
> - separation of entities and behaviour
> a basic pattern must be, to separate value objects and business logic. in
> that way the datamodel can be modeled and implemented regardless of any
> semantic functions that use a lot of different entities. if the behaviour
> would be inside the data objects, there would exist a very ugly network of
> close coupled objects.
i would prefer to speak of logic or behaviour instead of just business 
logic cause this is only a small subset of the code to be created for a 
full application. additionally this may be misleading cause the business 
logic normally is the part with the smallest potential of automization 
in generative development.

> 
> - back end design
> given the fact, that Chiba is a fix component of the cobold architecture,
> the other major issue to think about is the creation of a back end that fits
> into the Chiba architecture. It needs tests and prototyping to develop an
> efficient work flow to achieve 1) a well defined application framework and
> 2) a pragmatic software development process.
> 
> - GUI / navigation
> since the GUI part of chiba as today is suboptimal in terms of easy
> deployment of individual design, it seems to be a good idea to embed chiba
> inside another front end component like a cms or portal framework (e.g. jet
> speed etc.).
> it is an unsolved issue to integrate a modular and flexible front end design
> into xForms.
i'd like to paraphrase this as: its not the goal of XForms to provide a 
presentation/layout facility - this is always the responsibility of the 
embedding language may it be XHTML, SVG or whatever. site- or 
application navigation shouldn't be handled with xforms; established 
technologies like portals or jsp are more suitable for this level.

> 
> - Chiba integration
> being the first and only applicable software component of cobold, chiba is
> to be beta tested to develop a prototype for a complete system. first steps
> will be to port the form4 jforce framework and adapt it to the chiba
> controller.
> 
> - Use Case XML / documentation
> with the goal of a generative system in mind, there could be first versions
> of descriptive XML for UseCases, data model and business logic. Since form4
> already has some experience in usecase implementations, a basic XML to
> describe the requirements to generate UseCase source code should be
> developed in the next time.
yes. very interesting. we could then take this as a testcase and build 
XForms for it to get a feeling how this might fit together.


> 
> - MDA / UML 2.0
> since the generative view of software development is becoming more common
> and is in the press constantly, it must be validated, how MDA specifications
> and UML 2.0 can be deployed to be a part of the cobold project.

interesting to look at:
- EMF (Eclipse project)
- http://www.architectureware.de/ Open Source MDA tool / Generative Umgebung

Joern
> 
> 
> so far for now...
> :olliC
> 
> -----------------------
> oliver charlet
> form4 gmbh & co. kg
> rungestr. 19
> 10179 berlin
> fon +49 (30) 27 87 84 -0
> fax +49 (30) 27 87 84 -10
> oli...@fo...
> http://www.form4.de
> -----------------------
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Cobold-developer mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobold-developer
> 

[Cobold-developer] ideas and discussion issues

[oliver c. <oli...@fo...>]

hello cobolds,

this is a short protocol about the dicussion we had yesterday:

please feel free to correct and change!

- separation of entities and behaviour
a basic pattern must be, to separate value objects and business logic. in
that way the datamodel can be modeled and implemented regardless of any
semantic functions that use a lot of different entities. if the behaviour
would be inside the data objects, there would exist a very ugly network of
close coupled objects.

- back end design
given the fact, that Chiba is a fix component of the cobold architecture,
the other major issue to think about is the creation of a back end that fits
into the Chiba architecture. It needs tests and prototyping to develop an
efficient work flow to achieve 1) a well defined application framework and
2) a pragmatic software development process.

- GUI / navigation
since the GUI part of chiba as today is suboptimal in terms of easy
deployment of individual design, it seems to be a good idea to embed chiba
inside another front end component like a cms or portal framework (e.g. jet
speed etc.).
it is an unsolved issue to integrate a modular and flexible front end design
into xForms.

- Chiba integration
being the first and only applicable software component of cobold, chiba is
to be beta tested to develop a prototype for a complete system. first steps
will be to port the form4 jforce framework and adapt it to the chiba
controller.

- Use Case XML / documentation
with the goal of a generative system in mind, there could be first versions
of descriptive XML for UseCases, data model and business logic. Since form4
already has some experience in usecase implementations, a basic XML to
describe the requirements to generate UseCase source code should be
developed in the next time.

- MDA / UML 2.0
since the generative view of software development is becoming more common
and is in the press constantly, it must be validated, how MDA specifications
and UML 2.0 can be deployed to be a part of the cobold project.


so far for now...
:olliC

-----------------------
oliver charlet
form4 gmbh & co. kg
rungestr. 19
10179 berlin
fon +49 (30) 27 87 84 -0
fax +49 (30) 27 87 84 -10
oli...@fo...
http://www.form4.de
-----------------------

[Cobold-developer] test

[<u....@gm...>]

--=20
Ulrich Nicolas Liss=E9