OOAD

now browsing by tag

 
 

Mechanism of operation vs. system model

Most often in the course of ana­lys­is we use the term mod­el, less often mech­an­ism. The thing is that the term mech­an­ism appears when we want to explain some­thing, e.g. “the mech­an­ism of gen­er­at­ing a dis­count on an invoice”. The thing is that the term mech­an­ism appears when we want to explain some­thing, e.g. “the mech­an­ism for gen­er­at­ing a dis­count on an invoice”. But here beware! A mod­el (block dia­grams, for­mu­lae, etc.) is doc­u­ment­a­tion, a copy­righted descrip­tion. The mech­an­ism is what we under­stood by read­ing these doc­u­ment­a­tion (mod­el), because the mech­an­ism is pro­tec­ted know-how. The con­tent of the applic­a­tion to the Pat­ent Office is the mod­el (descrip­tion), but what we pat­ent is the mech­an­ism invented/developed.

Source: Mech­an­ism of oper­a­tion vs. sys­tem mod­el – Jarosław Żeliński IT-Consulting

ICONIX as an object-oriented, agile software design process using UML notation

The fact that ICONIX, as a pro­cess, is rel­at­ively rarely used (this has been chan­ging over the last few years, how­ever), is rooted in the fact that, first and fore­most, it requires an under­stand­ing of the com­pon­ent-ori­ented archi­tec­ture pro­cess, it also requires know­ledge and under­stand­ing of the concept of hexagon­al archi­tec­ture and the asso­ci­ated MVC pat­tern. Requires know­ledge and under­stand­ing of many oth­er object-ori­ented design pat­terns, requires, above all, abstract think­ing and mod­el­ling (UML) skills. It requires an under­stand­ing that z cod­ing must be pre­ceded by design, because «design­ing» in code is the least effect­ive form of design (Bör­ger, 2018).The pro­cess is also sup­por­ted by the divi­sion into ana­lys­is and design and imple­ment­a­tion stages (see above dia­gram: Struc­ture of pro­ject roles and products in the ICONIX pro­cess). ICONIX is some­times wrongly asso­ci­ated with a “heavy” soft­ware devel­op­ment pro­cess such as the Ration­al Uni­fied Pro­cess (which I have hardly writ­ten about on my blog). The reas­on ICONIX is rarely used, is also that, unfor­tu­nately, the world was, already in the 1990s, heav­ily “spoiled” by C++ and Java (archi­tec­tures built on cas­cades of inher­it­ance). These are often heavy, mono­lith­ic frame­works based on a rela­tion­al data mod­el, where there is no strict sep­ar­a­tion between domain logic and envir­on­ment (MVC). Java is still one of the most costly and least effect­ive applic­a­tion devel­op­ment meth­ods. The EJB frame­work is to this day described as the source of an object-ori­ented design anti-pat­tern called the «anem­ic domain mod­el». How­ever, the grow­ing developer interest in the C4 mod­el over the last few years shows that ana­lys­is and mod­el­ling are needed and quietly enter­ing through the back door….The fact that ICONIX, as a pro­cess, is rel­at­ively rarely used (this has been chan­ging over the last few years, how­ever), is rooted in the fact that, first and fore­most, it requires an under­stand­ing of the com­pon­ent-ori­ented archi­tec­ture pro­cess, it also requires know­ledge and under­stand­ing of the concept of hexagon­al archi­tec­ture and the asso­ci­ated MVC pat­tern. Requires know­ledge and under­stand­ing of many oth­er object-ori­ented design pat­terns, requires, above all, abstract think­ing and mod­el­ling (UML) skills. It requires an under­stand­ing that z cod­ing must be pre­ceded by design, because «design­ing» in code is the least effect­ive form of design (Bör­ger, 2018).The pro­cess is also sup­por­ted by the divi­sion into ana­lys­is and design and imple­ment­a­tion stages (see above dia­gram: Struc­ture of pro­ject roles and products in the ICONIX pro­cess). ICONIX is some­times wrongly asso­ci­ated with a “heavy” soft­ware devel­op­ment pro­cess such as the Ration­al Uni­fied Pro­cess (which I have hardly writ­ten about on my blog). The reas­on ICONIX is rarely used, is also that, unfor­tu­nately, the world was, already in the 1990s, heav­ily “spoiled” by C++ and Java (archi­tec­tures built on cas­cades of inher­it­ance). These are often heavy, mono­lith­ic frame­works based on a rela­tion­al data mod­el, where there is no strict sep­ar­a­tion between domain logic and envir­on­ment (MVC). Java is still one of the most costly and least effect­ive applic­a­tion devel­op­ment meth­ods. The EJB frame­work is to this day described as the source of an object-ori­ented design anti-pat­tern called the «anem­ic domain mod­el». How­ever, the grow­ing developer interest in the C4 mod­el over the last few years shows that ana­lys­is and mod­el­ling are needed and quietly enter­ing through the back door.…

Source: ICONIX jako obiek­to­wo zori­entow­any, zwinny pro­ces pro­jek­tow­ania opro­gramow­ania z uży­ciem not­acji UML – Jarosław Żeliński IT-Consulting

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns

Exactly one year ago my first paper in US ? (see lif­let)

Abstract

Pub­lic­a­tions, includ­ing aca­dem­ic hand­books, con­tain numer­ous incon­sist­en­cies in the descrip­tions of applic­a­tions of archi­tec­tur­al meth­ods and pat­terns hid­den under the abbre­vi­ations such as MOF, MDA, PIM, MVC, BCE. An effi­cient ana­lys­is and the fol­low­ing soft­ware design, par­tic­u­larly when we are speak­ing of pro­jects real­ized in large teams, requires stand­ard­iz­a­tion of the pro­duc­tion pro­cess and the applied pat­terns and frame­works. This study attemp­ted to sort out the sys­tem of nota­tions describ­ing this pro­cess and used to describe archi­tec­tur­al pat­terns. Ana­lys­is of key notations?MOF and MDA, pat­terns MVC and BCE?was car­ried out, and a con­sist­ent sys­tem com­bin­ing them into a whole was created.Chapter Pre­view Top

Background

In this study, Object Man­age­ment Group nota­tion sys­tems have been used. MOF (Meta Object Facil­ity) spe­cific­a­tion describes three abstrac­tion levels: M1, M2, M3 and level M0 that is real items (OMG MOF, 2016). M0 is a real sys­tem, M1 level is abstrac­tion of the items of this sys­tem (its mod­el). Level M2 com­prises of rela­tion­ships between classes of these objects (names of their sets) that is sys­tem metamod­el. M3 level is a meta-metamod­el describ­ing the mod­el­ing meth­od with the use of named ele­ments with spe­cified semantics and syntactic.

The ana­lys­is and design pro­cess is based on the MDA (Mod­el Driv­en Archi­tec­ture) spe­cific­a­tions. This pro­cess has three phases under­stood as cre­ation of sub­sequent mod­els: CIM (Com­pu­ta­tion Inde­pend­ent Mod­el), PIM (Plat­form Inde­pend­ent Mod­el), PSM (Plat­form Spe­cif­ic Mod­el) and code cre­ation phase. The CIM mod­el is doc­u­mented with the use of BPMN (Busi­ness Pro­cess Mod­el and Nota­tion) (OMG BPMN, 2013) and SBVR nota­tion (Semant­ic of Busi­ness Vocab­u­lary and Rules) (OMG SBVR, 2017). These are, respect­ively: busi­ness pro­cess mod­els and nota­tion mod­els and busi­ness rules. PIM and PSM mod­els are doc­u­mented with the use of UML nota­tion (Uni­fied Mod­el­ing Lan­guage) (OMG UML, 2017).

Between CIM and PIM mod­els, determ­in­a­tion of the list of applic­a­tion ser­vices (sys­tem reac­tions) occurs, whose real­iz­a­tion mech­an­ism is described by PIM mod­el. The stand­ard pat­tern used for mod­el­ing applic­a­tion archi­tec­ture is MVC pat­tern. Com­pon­ent Mod­el of this pat­tern is modeled with the use of the BCE archi­tec­tur­al pattern.

Semiotics vs. UML

Semi­ot­ics, as a sci­ence deal­ing with sym­bols and their mean­ings, provides us with the tool enabling determ­in­a­tion of rela­tion­ships between an object (thing), its name (expres­sion) and defin­i­tion of nota­tion rep­res­en­ted by the name (or sign, mean­ing). These rela­tion­ships are referred to as the semi­ot­ic tri­angle. Fig­ure 1 rep­res­ents this tri­angle on the left (OMG SBVR, 2017).

The UML nota­tion (OMG UML, 2017) oper­ates instance clas­si­fi­er and class nota­tions. To the right, Fig­ure 1 demon­strates an equi­val­ent to semi­ot­ic tri­angle expressed with those terms.

The UML nota­tion fur­ther oper­ates the gen­er­al struc­ture nota­tion, which is the con­tent of each cor­rect UML dia­gram. Struc­tures may express a con­cep­tu­al mod­el (Namespace) or mod­el (also metamod­el) of sys­tem archi­tec­ture (e.g. soft­ware) in the form of a chart (Archi­tec­ture).

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns

Jaroslaw Zel­in­ski (Inde­pend­ent Research­er)
Source Title: Applic­a­tions and Approaches to Object-Ori­ented Soft­ware Design: Emer­ging Research and Oppor­tun­it­iesCopy­right: ? 2020 |Pages: 12DOI: 10.4018/978–1‑7998–2142‑7.ch003