tag:blogger.com,1999:blog-8700638167558123992.post7090522135251931248..comments2023-09-07T08:55:25.307+01:00Comments on Shlaer-Mellor and Executable UML Portal: Week 25 of 2010Unknownnoreply@blogger.comBlogger4125tag:blogger.com,1999:blog-8700638167558123992.post-39076384648086629572010-07-01T17:38:59.738+01:002010-07-01T17:38:59.738+01:00Then you would define an "Object Instance Cre...Then you would define an "Object Instance Creation Constraint" object (or something similar) in your architectural domain, create an instance of that architectural object (with maximum number set to 5) as part of your input data. You could then associate a colour with that constraint and with any object that you want to constraint in such a way. Your architecture will then have to implement some additional constraint checking to ensure the user doesn't create more than 5 instances.<br /><br />The interesting point here is that you will probably want to associate some kind of error handling logic with constraint failure and that can easily be done by setting additional attributes in your new architectural object. This shows the fallacy of associating values with colours/tags/marks and ever thinking that will be enough. In my view, colours should only be used to make yes/no decisions with regard to options provided by an architecture. Any tagged values should be defined in an architectural domain.<br /><br />OOA Tool will (in future) deal with the above by allowing the architecture developer to:<br />1) create an architectural domain with an information model defining architectural concerns,<br />2) create a default input population (of the architectural domain) with default/basic choices for those concerns,<br />3) create a default colour model for selecting those choices,<br />4) and create a set of archetype templates which check whether particular model elements/data have been associated with a colour and also associated with a particular choice.<br /><br />Then allowing the application developer to:<br />1) create an additional input population (of the architectural domain) if some custom choices need to configured,<br />2) colour model elements/data with colours associated with particular choices,<br />3) and finally run a translation with all input data to generate their application code.<br /><br />I should point out that particular visual colours will obviously be heavily overloaded within a project. Users will be allowed to enable/disable visual colour coding for particular colour models. All colours will also have names/descriptions.Sean Kavanaghhttps://www.blogger.com/profile/07779604753710998229noreply@blogger.comtag:blogger.com,1999:blog-8700638167558123992.post-43068901978201959002010-07-01T16:45:46.857+01:002010-07-01T16:45:46.857+01:00You said: I'm not planning on allowing arbitr...You said: I'm not planning on allowing arbitrary values to be associated with colours.<br /><br />Say I needed to tag a class in my Application Domain model with the information that there were always going to be a maximum of 5 instances.<br /><br />Obviously, that would be a very useful piece of information for the architecture since it could optimise the data structures used to implement the instance data (for example, array instead of a linked list).<br /><br />How would OOA Tool Colouring deal with this situation?Mike Finnhttps://www.blogger.com/profile/17974702391526096956noreply@blogger.comtag:blogger.com,1999:blog-8700638167558123992.post-42125815845610058532010-07-01T12:52:00.172+01:002010-07-01T12:52:00.172+01:00I agree with the "'orrible UML" comm...I agree with the "'orrible UML" comment. However, any Shlaer-Mellor diagram that I show can also be viewed at a click as Executable UML in OOA Tool.<br /><br />I prefer to keep the term "colouring" when referring to Shlaer-Mellor stuff to keep it distinct from the term "marking" which is very much associated with UML and MDA. A major benefit for me is that I plan to support colouring within OOA Tool using colour highlighting. Colouring is very much an abstract concept representing some arbitrary distinction.<br /><br />I'm not planning on allowing arbitrary values to be associated with colours. The idea is that you would model some concept in your architectural domain (e.g. thread pool) and then colour objects and/or instances in your application model and/or input populations and also colour an instance of the concern in an architectural population (e.g. a thread pool instance). Your archetype could then determine where to go from there.<br /><br />Domains and subsystems are very different things. I'm currently defining colour models in a OOA of OOA subsystem because it directly relates to population instances and transformations and I'm using colour in the Shlaer-Mellor sense here. I would only define a colours domain if I wanted to model RGB and other colour representations.<br /><br />Thanks for the comment.Sean Kavanaghhttps://www.blogger.com/profile/07779604753710998229noreply@blogger.comtag:blogger.com,1999:blog-8700638167558123992.post-82664257686968715272010-07-01T11:37:36.177+01:002010-07-01T11:37:36.177+01:00Hi Sean,
How refreshing to be shown some Shlaer-M...Hi Sean,<br /><br />How refreshing to be shown some Shlaer-Mellor notation instead of that ‘orrible UML.<br /><br />We should standardise on a term for Marking/Tagging/Colouring. I would prefer tagging as this implies augmenting with a value or classification. This may reflect my KC background too! Colouring is my least favourite as it sounds too abstract. <br /><br />Software architectures are a whole new ball game and I would advise you to implement the simplest possible architecture. A dead simple one state at a time architecture is fine for simulation and this is the way humans run the model anyway. Code Generation is where it gets interesting and complex.<br /><br />The issue with colours can be solved by having a Colours domain (or subsystem in your terminology?).<br /><br /><br />Regards,<br />MikeMike Finnhttps://www.blogger.com/profile/17974702391526096956noreply@blogger.com