# orderedItems[].object.content
@raiderrobert
I was procrastinating, but I have put it off until later.

# orderedItems[].object.contentMap.en
@raiderrobert
I was procrastinating, but I have put it off until later.

# orderedItems[].object.content
@nick_tune @xinyao

You seem to be conflating the roles with the people. Who performs what role is obviously dependent on the organisation.

The important point is that someone WILL perform those roles, even if it is implicit, unintentional or accidental!

I would be disappointed if a PM in an IT organisation was unable to prepare a business case for the architectural role.

# orderedItems[].object.contentMap.en
@nick_tune @xinyao

You seem to be conflating the roles with the people. Who performs what role is obviously dependent on the organisation.

The important point is that someone WILL perform those roles, even if it is implicit, unintentional or accidental!

I would be disappointed if a PM in an IT organisation was unable to prepare a business case for the architectural role.

# orderedItems[].object.content
@nick_tune @xinyao
I would put much of those tasks in the project manager's basket.

Obviously the PM and architect need to work closely. The architect should provide a set of alternative implementation schedules for a range of resource vs development time trade-offs. Then its up to the PM to provide the resources and manage the process.

It gets more interesting if the architectural design, and hence the quality of the result, are involved in the trade-off calculations. It is still the PM's task to make those choices (typically with input from the CIO and board).

# orderedItems[].object.contentMap.en
@nick_tune @xinyao
I would put much of those tasks in the project manager's basket.

Obviously the PM and architect need to work closely. The architect should provide a set of alternative implementation schedules for a range of resource vs development time trade-offs. Then its up to the PM to provide the resources and manage the process.

It gets more interesting if the architectural design, and hence the quality of the result, are involved in the trade-off calculations. It is still the PM's task to make those choices (typically with input from the CIO and board).

# orderedItems[].object.content
@xand I would agree that putting ALL the type definitions into one module would be a mistake.
However, types that appear in interfaces might be best defined centrally.
The form of that definition depends on the coupling between modules. It could be in the implementation language, an interface defn. language, or something like XML or JSON.

#SoftwareArchitecture

# orderedItems[].object.contentMap.en
@xand I would agree that putting ALL the type definitions into one module would be a mistake.
However, types that appear in interfaces might be best defined centrally.
The form of that definition depends on the coupling between modules. It could be in the implementation language, an interface defn. language, or something like XML or JSON.

#SoftwareArchitecture

# orderedItems[].object.content
@xand I think I prefer the term "sub-projects".

Large projects are rarely successful, so they need to be subdivided. However this can introduce even more complexity if the sub-projects are interdependent.

My hypothesis is that the architect should define the interfaces between the modules and they should be implemented as a set of test harnesses prior to beginning main development.

#Softwarearchitecture

# orderedItems[].object.contentMap.en
@xand I think I prefer the term "sub-projects".

Large projects are rarely successful, so they need to be subdivided. However this can introduce even more complexity if the sub-projects are interdependent.

My hypothesis is that the architect should define the interfaces between the modules and they should be implemented as a set of test harnesses prior to beginning main development.

#Softwarearchitecture

# orderedItems[].object.content
@xand A modules module can be useful. I have a project that I used to experiment with independently developed modules. This relies on well defined interfaces. The modules module provided stub versions of all the modules so that the other modules could build test harnesses.

https://sourceforge.net/projects/ocrat ato-vici/

# orderedItems[].object.contentMap.en
@xand A modules module can be useful. I have a project that I used to experiment with independently developed modules. This relies on well defined interfaces. The modules module provided stub versions of all the modules so that the other modules could build test harnesses.

https://sourceforge.net/projects/ocrat ato-vici/

# orderedItems[].object.content
@djmoch I recall evenings spent hand setting the bits in an EPROM for a National Semiconductor SC/MP processor. Tedious doesn't begin to describe it.

# orderedItems[].object.contentMap.en
@djmoch I recall evenings spent hand setting the bits in an EPROM for a National Semiconductor SC/MP processor. Tedious doesn't begin to describe it.

# orderedItems[].object.content
#SASSY

This project is going to be very much exploratory programming. I have no idea if this is going to work. It will be fun.

The program will need something to chew on. I think "example data" would be a better term than "test data". Testing is the process of confirming a program coforms to its design. At this stage we have no design.

I have chosen five paragraphs from various design documents. They include a paragraph from a preliminary design, a functional requirement, a use case, an architectural tactic and a component description.

The input to the process is an RDF model that represents the information in the paragraph. This is intended to simulate an extract from what will be in SASSY's knowledge database.

I am currently constucting these models.

#SoftwareArchitecture
#NLG #NaturalLanguageGeneration

# orderedItems[].object.contentMap.en
#SASSY

This project is going to be very much exploratory programming. I have no idea if this is going to work. It will be fun.

The program will need something to chew on. I think "example data" would be a better term than "test data". Testing is the process of confirming a program coforms to its design. At this stage we have no design.

I have chosen five paragraphs from various design documents. They include a paragraph from a preliminary design, a functional requirement, a use case, an architectural tactic and a component description.

The input to the process is an RDF model that represents the information in the paragraph. This is intended to simulate an extract from what will be in SASSY's knowledge database.

I am currently constucting these models.

#SoftwareArchitecture
#NLG #NaturalLanguageGeneration

# orderedItems[].object.content
#SASSY

There is one classification of the RST reationships that we can use. They can be either structural or semantic. The structural relationships will come from the overall design of the document. The semantic ones come from the data properties - i.e. the predicates of the RDF statements.

In practice this means that the sorted order for the RDF statements within a paragraph is based on the semantics.

This SASSY subproject aims to take lists of RDF statements and sort each list based on the semantic ranks. The RDF statements will then be agregated into sentence sized chunks.

The next step is the internal organisation of the sentences, such as adjectival phrases and subordinate clauses.

An interesting step is to identify the flow of focus and use that to replace nouns (Fred) with pronouns (he) or noun phrases (the boy). For a design document it is especially important not to introduce any ambiguity.

The final step is to create a grammar tree for each sentence and pass it to the NLG program.

#SoftwareArchitecture
#NLG #NaturalLanguageGeneration

# orderedItems[].object.contentMap.en
#SASSY

There is one classification of the RST reationships that we can use. They can be either structural or semantic. The structural relationships will come from the overall design of the document. The semantic ones come from the data properties - i.e. the predicates of the RDF statements.

In practice this means that the sorted order for the RDF statements within a paragraph is based on the semantics.

This SASSY subproject aims to take lists of RDF statements and sort each list based on the semantic ranks. The RDF statements will then be agregated into sentence sized chunks.

The next step is the internal organisation of the sentences, such as adjectival phrases and subordinate clauses.

An interesting step is to identify the flow of focus and use that to replace nouns (Fred) with pronouns (he) or noun phrases (the boy). For a design document it is especially important not to introduce any ambiguity.

The final step is to create a grammar tree for each sentence and pass it to the NLG program.

#SoftwareArchitecture
#NLG #NaturalLanguageGeneration

# orderedItems[].object.content
#SASSY

The core observation of Rhetorical Structure Theory (RST) is that text can be recursively subdivided into two parts, termed the "nucleus" and the "satellite". The nucleus can be understood by itself, whereas the satellite depends on the nucleus.

RST researchers spent a lot of time trying to classify the relationships between the nucleus and satellite. Not much agreement was reached.

Their approach to text generation was to select a communicative goal which would indicate a general plan. The plan would suggest relationships and the database would then be searched for matching data.

For SASSY the communicative goal is simply "tell us everything you know". The planning then collapses to a sorting process.

While playing around with ways to sort the data it became apparent that the actual set of RST relationships was not the important aspect. What was driving the algorithm was the ranking of the relationships. This is why the researchers could never agree on what relationships should be used - it doesn't matter.

For an RDF knowledge database I think this means that I just need to assign a "semantic rank" to each property. We shall see ...

#SoftwareArchitecture
#NLG #NaturalLanguageGeneration

# orderedItems[].object.contentMap.en
#SASSY

The core observation of Rhetorical Structure Theory (RST) is that text can be recursively subdivided into two parts, termed the "nucleus" and the "satellite". The nucleus can be understood by itself, whereas the satellite depends on the nucleus.

RST researchers spent a lot of time trying to classify the relationships between the nucleus and satellite. Not much agreement was reached.

Their approach to text generation was to select a communicative goal which would indicate a general plan. The plan would suggest relationships and the database would then be searched for matching data.

For SASSY the communicative goal is simply "tell us everything you know". The planning then collapses to a sorting process.

While playing around with ways to sort the data it became apparent that the actual set of RST relationships was not the important aspect. What was driving the algorithm was the ranking of the relationships. This is why the researchers could never agree on what relationships should be used - it doesn't matter.

For an RDF knowledge database I think this means that I just need to assign a "semantic rank" to each property. We shall see ...

#SoftwareArchitecture
#NLG #NaturalLanguageGeneration

# orderedItems[].object.content
@nick_tune Yes. If the granularity is too small you will either spend all your time fetching and storing state data, or have complex state management in each event handler.

I developed a small Actor & Message library for C++. I gave up on it when it became obvious that the overall process algorithm would become lost in a tangle of event handlers.

I foresee the same problem no matter the granularity for an event driven system.

# orderedItems[].object.contentMap.en
@nick_tune Yes. If the granularity is too small you will either spend all your time fetching and storing state data, or have complex state management in each event handler.

I developed a small Actor & Message library for C++. I gave up on it when it became obvious that the overall process algorithm would become lost in a tangle of event handlers.

I foresee the same problem no matter the granularity for an event driven system.

# orderedItems[].object.content
#SASSY

Natural Language Generation has gone through three major phases. Initially templates were used. This evolved into Rhetorical Structure Theory which tried to use planning to deduce the structure of the text. More recently Large Language Models have got the attention of the NLG community.

Templates do not have the flexibility to handle arbitrary software designs. Any novel attribute of a design would likely be overlooked by the templates.

LLMs appear to be non-deterministic. This is a problem for design documents. They need to be able to be regenerated at any time and the only changes should be a direct result of changes in the data.

A lot of work was done on RST in the 80's and 90's. The fact that there is not any readily available RST based software available today is a good clue that it was not a successful endevour.

I found two major issues with RST: Firstly the planning approach could leave important information unreported. This is a show stopper for SASSY. Secondly, in order to get good results it took months long collaboration between linguists and subject matter experts. This would also be an obsticle for SASSY that aims to be an easy to use tool for helping with software design.

Next I will discuss my plan to adapt RST for use in SASSY.

#SoftwareArchitecture
#NLG #NaturalLanguageGeneration

# orderedItems[].object.contentMap.en
#SASSY

Natural Language Generation has gone through three major phases. Initially templates were used. This evolved into Rhetorical Structure Theory which tried to use planning to deduce the structure of the text. More recently Large Language Models have got the attention of the NLG community.

Templates do not have the flexibility to handle arbitrary software designs. Any novel attribute of a design would likely be overlooked by the templates.

LLMs appear to be non-deterministic. This is a problem for design documents. They need to be able to be regenerated at any time and the only changes should be a direct result of changes in the data.

A lot of work was done on RST in the 80's and 90's. The fact that there is not any readily available RST based software available today is a good clue that it was not a successful endevour.

I found two major issues with RST: Firstly the planning approach could leave important information unreported. This is a show stopper for SASSY. Secondly, in order to get good results it took months long collaboration between linguists and subject matter experts. This would also be an obsticle for SASSY that aims to be an easy to use tool for helping with software design.

Next I will discuss my plan to adapt RST for use in SASSY.

#SoftwareArchitecture
#NLG #NaturalLanguageGeneration

# orderedItems[].object.content
#SASSY

The next step in my feasibility study was to generate some English text. After examining some alternatives I selected SimpleNLG. A few tests convinced me that it would be a good basis.

However I was not happy with the way Java was being tortured. The main data structure was trees of lists of Java Objects - basically an unconstrained structure. A lot of the code consisted of tests of the type of Objects, which is an odd way to program a language which supports polymorphism. I did a rewrite in C++.

I added an RDF parser so that the input grammar tree can be supplied as an RDF Model. The result was able to complete the test cases provided for SimpleNLG.

This NLG is only able to create clauses and sentences so it will need to be wrapped in some other module to create the entire document.

This brings the story up to the present.

#SoftwareArchitecture
#NLG #NaturalLanguageGeneration
#TextGeneration

# orderedItems[].object.contentMap.en
#SASSY

The next step in my feasibility study was to generate some English text. After examining some alternatives I selected SimpleNLG. A few tests convinced me that it would be a good basis.

However I was not happy with the way Java was being tortured. The main data structure was trees of lists of Java Objects - basically an unconstrained structure. A lot of the code consisted of tests of the type of Objects, which is an odd way to program a language which supports polymorphism. I did a rewrite in C++.

I added an RDF parser so that the input grammar tree can be supplied as an RDF Model. The result was able to complete the test cases provided for SimpleNLG.

This NLG is only able to create clauses and sentences so it will need to be wrapped in some other module to create the entire document.

This brings the story up to the present.

#SoftwareArchitecture
#NLG #NaturalLanguageGeneration
#TextGeneration

# orderedItems[].object.content
#SASSY

Having the design for a system in a knowledge database allows the use of tools to validate the design, and perhaps, even generate some aspects.

The downside is that humans don't speak RDF. SASSY will need mechanisms for getting the design information into and out of the knowledge database in a way that is easy for the average developer.

My research found a lot of work has been done over the decades to try and generate English text from the contents of a database. As far as I can tell none of it was very successful. If the data structure is well defined it is possible to use templates. Sadly the design of a software system is not going to be able to use a predefined structure. If the design has some features the template designer did not think of they would not be reported. A more flexible approach is required.

Thus the feasibility study was begun. I decided to work from the output back toward the database. This way each step would provide a specification for what the next one would need to create.

Step one was to create a nice PDF document. For this I used Pandoc to convert a Markdown document into PDF. Step two was to create an RDF description of the document and generate the Markdown. This worked better than I expected.

To be continued...

#SoftwareArchitecture

# orderedItems[].object.contentMap.en
#SASSY

Having the design for a system in a knowledge database allows the use of tools to validate the design, and perhaps, even generate some aspects.

The downside is that humans don't speak RDF. SASSY will need mechanisms for getting the design information into and out of the knowledge database in a way that is easy for the average developer.

My research found a lot of work has been done over the decades to try and generate English text from the contents of a database. As far as I can tell none of it was very successful. If the data structure is well defined it is possible to use templates. Sadly the design of a software system is not going to be able to use a predefined structure. If the design has some features the template designer did not think of they would not be reported. A more flexible approach is required.

Thus the feasibility study was begun. I decided to work from the output back toward the database. This way each step would provide a specification for what the next one would need to create.

Step one was to create a nice PDF document. For this I used Pandoc to convert a Markdown document into PDF. Step two was to create an RDF description of the document and generate the Markdown. This worked better than I expected.

To be continued...

#SoftwareArchitecture

# orderedItems[].object.content
@djmoch Ineresting. That defn seems to be based on "Any sufficiently advanced technology is indistinguishable from magic"

I tend to reserve the term for modules whose output data cannot possibly be derived from the available inputs - "Magic happens here."

# orderedItems[].object.contentMap.en
@djmoch Ineresting. That defn seems to be based on "Any sufficiently advanced technology is indistinguishable from magic"

I tend to reserve the term for modules whose output data cannot possibly be derived from the available inputs - "Magic happens here."

# orderedItems[].object.content
#PriceGouging
The underlying reason is a lack of competition or market dominance.

Perhaps we need a market share tax.

# orderedItems[].object.contentMap.en
#PriceGouging
The underlying reason is a lack of competition or market dominance.

Perhaps we need a market share tax.

# orderedItems[].object.content
#SASSY

An introduction to my SASSY project. Its name is short for Software Architecture Support System. The basic idea is to store the architectural design for software projects in a knowledge database so that the information is available for anyone that needs it.

My motivation was seeing too many projects where the design was unmaintained, inconsistent, incomplete, or simply non-existent.

Storing the information in a knowledge database would allow the construction of tools to highlight issues with the design.

My first attempt at prototyping SASSY used OWL for the knowledge database, with Protege as the user interface and Java code to create reports. While this did produce some nice results It was not a very friendly thing to use and was not flexible enough.

Now that I have time to spend on my own projects I have started a second attempt using RDF.

Web page for SASSY:
https://ocratato-sassy.sourceforge.io/

#SoftwareArchitecture

# orderedItems[].object.contentMap.en
#SASSY

An introduction to my SASSY project. Its name is short for Software Architecture Support System. The basic idea is to store the architectural design for software projects in a knowledge database so that the information is available for anyone that needs it.

My motivation was seeing too many projects where the design was unmaintained, inconsistent, incomplete, or simply non-existent.

Storing the information in a knowledge database would allow the construction of tools to highlight issues with the design.

My first attempt at prototyping SASSY used OWL for the knowledge database, with Protege as the user interface and Java code to create reports. While this did produce some nice results It was not a very friendly thing to use and was not flexible enough.

Now that I have time to spend on my own projects I have started a second attempt using RDF.

Web page for SASSY:
https://ocratato-sassy.sourceforge.io/

#SoftwareArchitecture

# orderedItems[].object.content
#introduction

I am a retired software architect who is now messing about with impossible software projects.

My current crazy idea is to develop something that uses a knowledge database to store the architectural design for large software projects. I have called this project SASSY, and will post more on it later.

Other things that get my attention are astrophysics, old sci-fi movies, and dabbling in electronics.

# orderedItems[].object.contentMap.en
#introduction

I am a retired software architect who is now messing about with impossible software projects.

My current crazy idea is to develop something that uses a knowledge database to store the architectural design for large software projects. I have called this project SASSY, and will post more on it later.

Other things that get my attention are astrophysics, old sci-fi movies, and dabbling in electronics.

# orderedItems[].object.content
@nick_tune All of the above would be my approach.

Put the legacy specific parts of the ACL in the Legacy system where it can be developed using existing legacy code by the developers familiar with that system.

Similarly for the new system. A separate ACL module can then handle the stuff that is independent of both the old and new systems.

# orderedItems[].object.contentMap.en
@nick_tune All of the above would be my approach.

Put the legacy specific parts of the ACL in the Legacy system where it can be developed using existing legacy code by the developers familiar with that system.

Similarly for the new system. A separate ACL module can then handle the stuff that is independent of both the old and new systems.