MDA

now browsing by tag

 
actor agile architecture BCE BPMN business architecture Business Continuity Management CIM courses design enterprise architecture extend ICONIX impact analysis include inheritance learn MBSE MDA MOF MVC objectt oriented omg.org OOAD patterns PIM practice PSM SBVR skills SysML system system design Systems analysis and design trace UML use case
 

Posted by: | on March 19, 2024

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

Posted in Models and architecture | No Comments »
Tags: , , , , , , ,

Posted by: | on March 29, 2021

Ontology-Oriented Data Management and Document Databases

This study presents a meth­od for the stor­age of data organ­ized in digit­al doc­u­ments, which is proven in prac­tice. The dis­cussed meth­od does not bear any dis­ad­vant­ages of the rela­tion­al mod­el used for data organ­iz­a­tion, such as the loss of data con­text and com­plic­a­tions evoked by the lack of data redund­ancy. The meth­od presen­ted here can be used for data organ­iz­a­tion into doc­u­ments (digit­al and paper) as clas­si­fied aggreg­ates and for data clas­si­fic­a­tion. The study also describes a new metamod­el for the data struc­ture which assumes that doc­u­ments, being data struc­tures, form com­pact aggreg­ates, clas­si­fied as objects, or event descrip­tions, thus always assign­ing them a spe­cif­ic and unam­bigu­ous con­text. Fur­ther­more, the study presents a design meth­od for doc­u­ments as con­text aggreg­ates that allows lev­el­ing the dis­ad­vant­ages of the rela­tion­al mod­el and ensures effi­cient inform­a­tion man­age­ment. The work also con­tains prac­tic­al examples of the applic­a­tion of the described method.

Digit­al Doc­u­ments as Data Car­ri­ers and a Meth­od of Data Man­age­ment Guar­an­tee­ing the Unam­bi­gu­ity of the Recor­ded Inform­a­tion: Onto­logy-Ori­ented Data Man­age­ment and Doc­u­ment Databases

Buy and read more…

Posted in Models and architecture | No Comments »
Tags: , , ,

Posted by: | on January 10, 2021

PIM modelling ‑Reduction of UML notation

The work is an attempt to sys­tem­at­ise the use of key OMG.org nota­tions in the pro­cess of sys­tem ana­lys­is and design. Under the term. and UML of know­ledge in the field of object-ori­ented ana­lys­is and design and the nota­tion sys­tems used in this area. The author pays spe­cial atten­tion to the dif­fer­ences between data-and respons­ib­il­ity-ori­ented design meth­ods (chapter Ana­lys­is and object-ori­ented design). The fol­low­ing sec­tion describes the con­cep­tu­al basis described in the SBVR, MOF, MDA spe­cific­a­tions and the mod­el­ling meth­od using UML nota­tion. The author argues that onto­logy is not a mod­el of the world, it only describes it.

Read art­icle…

Posted in General | No Comments »
Tags: , , ,

Posted by: | on December 4, 2020

What is Computation Independent Model

1.A Com­pu­ta­tion Inde­pend­ent Mod­el (CIM) is a mod­el defined with­in OMG Mod­el-Driv­en Archi­tec­ture as a primary mod­el. This mod­el reflects sys­tem and soft­ware know­ledge from the busi­ness per­spect­ive. The CIM may con­tain busi­ness know­ledge about sys­tem organ­iz­a­tion, roles, func­tions, pro­cesses and activ­it­ies, doc­u­ment­a­tion, con­straints etc. The CIM must con­tain busi­ness require­ments for the soft­ware system.

(read more)

Posted in General | No Comments »
Tags: , , , , ,

Posted by: | on October 30, 2020

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

Posted in Models and architecture | No Comments »
Tags: , , , , , , , , , ,

Posted by: | on August 30, 2020

Why using extend and include stereotypes in OOAD projects is wrong?

Many ana­lyst and UML prac­ti­tion­er use Use Cases as a “pro­cess mod­el”. It is really bad idea. As we say “we use OOAD meth­ods”, it means we use object paradigm. The fund­at­in of OOAD is her­met­iz­a­tion, but «include» and «extend» depend­encys break this rule.

A lots of time we see dia­grams like this:

A few citation (UML specification): A UseCase is a kind of Behaviored Classifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. UseCases define the offered Behaviors of the subject without reference to its internal structure. These Behaviors, involving interactions between the Actors and the subject, may result in changes to the state of the subject and communications with its environment. A UseCase can include possible variations of its basic behavior, including exceptional behavior and error handling. (UML, 18.1.3.1 Use Cases and Actors) An Extend is a relationship from an extending UseCase (the extension) to an extended UseCase (the extendedCase) that specifies how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase. The extension takes place at one or more specific extension points defined in the extended UseCase. (UML, 18.1.3.2 Extends) The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common. As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful. (UML, 18.1.3.3 Includes). Object oriented paradigm based on main concepts: object (part of system) encapsulation (objects hides their implementation) polymorphism (one operation could be implemented by more then one methods) cooperation (objects cooperate to achieve the particular goal) In OOAD <<include>> and <<extend>> breaks encapsulation (we can't use use diagram to modeling any internal application or component structure/architecture). Need more arguments and explanation? Try my courses...

Uses Case mod­els with include and extend stereotypes 

A few cita­tion (UML spe­cific­a­tion) :

A UseCase is a kind of Beha­viored Clas­si­fi­er that rep­res­ents a declar­a­tion of a set of offered Beha­vi­ors. Each UseCase spe­cifies some beha­vi­or that a sub­ject can per­form in col­lab­or­a­tion with one or more Act­ors. UseCases define the offered Beha­vi­ors of the sub­ject without ref­er­ence to its intern­al struc­ture. These Beha­vi­ors, involving inter­ac­tions between the Act­ors and the sub­ject, may res­ult in changes to the state of the sub­ject and com­mu­nic­a­tions with its envir­on­ment. A UseCase can include pos­sible vari­ations of its basic beha­vi­or, includ­ing excep­tion­al beha­vi­or and error hand­ling. (UML, 18.1.3.1 Use Cases and Actors) 

Import­ant sen­tence: without ref­er­ence to its intern­al struc­ture (see what encap­su­la­tion means below).

An Extend is a rela­tion­ship from an extend­ing UseCase (the exten­sion) to an exten­ded UseCase (the exten­ded­Case) that spe­cifies how and when the beha­vi­or defined in the extend­ing UseCase can be inser­ted into the beha­vi­or defined in the exten­ded UseCase. The exten­sion takes place at one or more spe­cif­ic exten­sion points defined in the exten­ded UseCase. (UML, 18.1.3.2 Extends) 

The Include rela­tion­ship is inten­ded to be used when there are com­mon parts of the beha­vi­or of two or more UseCases. This com­mon part is then extrac­ted to a sep­ar­ate UseCase, to be included by all the base UseCases hav­ing this part in com­mon. As the primary use of the Include rela­tion­ship is for reuse of com­mon parts, what is left in a base UseCase is usu­ally not com­plete in itself but depend­ent on the included parts to be mean­ing­ful. (UML, 18.1.3.3 Includes). 

Object ori­ented paradigm based on main concepts: 

  • object (part of system) 
  • encap­su­la­tion (objects hides their implementation) 
  • poly­morph­ism (one oper­a­tion could be imple­men­ted by more then one methods) 
  • coöper­a­tion (objects coöper­ate to achieve the par­tic­u­lar goal) 

In OOAD «include» and «extend» breaks encap­su­la­tion (we can­’t use use dia­gram to mod­el­ing any intern­al applic­a­tion or com­pon­ent structure/architecture). , .

Need more argu­ments and explan­a­tion? Try my courses… 

References

Object Man­age­ment Group. (2017, Decem­ber). Uni­fied Mod­el­ing Lan­guage (UML) [OMG.org]. UML. https://www.omg.org/spec/UML/
Vogel, S., & Arnold, P. (2020). Towards a more com­plete object-ori­ent­a­tion in graph-based design lan­guages. SN Applied Sci­ences, 2(7), 1235. https://doi.org/10.1007/s42452-020‑2959‑x

Posted in Models and architecture | No Comments »
Tags: , , , , , , ,