Models and architecture

now browsing by category

The main cat­egory of my posts, my exper­i­ence and research as well.


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

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


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


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

Business continuity management – how to model it

Busi­ness Con­tinu­ity Man­age­ment (BCM) pro­jects are really dif­fi­cult . The main reas­on is the sys­tem com­plex­ity: many doc­u­ments, many tasks, many pro­cesses, many asso­ci­ations between all of them. Each task con­nec­ted to one or more busi­ness applic­a­tion. Each doc­u­ments stored in dif­fer­ent data­base. The applic­a­tions are integ­rated. Everything works like one chain … but one broken link can crash everything .

How we can man­aging risks? We can cre­ate Busi­ness Archi­tec­ture mod­el and expand this up to Enter­prise Archi­tec­ture, as a mod­el for trace pro­cess, data, IT sys­tem and infrastructure.


How we pre­pare Enter­prise Archi­tec­ture mod­el? Simple ver­sion: pre­pare busi­ness mod­el :

Trans­form this to use case mod­el (applic­a­tion ser­vices) :

Build mat­rix for trace map­ping con­trol :

Trace (map) use case to soft­ware com­pon­ents :

We have com­pleted mod­el, we can do impact ana­lys­is, e.g. what hap­pens and where, when the Ruter go down: 

Some­times we ask: what does the pos­sib­il­ity of car­ry­ing out the Pack­age Goods task depend on?

How can we do this and what tools do we need? Wel­come in my courses, hire me …


Kama, N., French, T., & Reyn­olds, M. (2011). Design Pat­terns Con­sid­er­a­tion in Class Inter­ac­tions Pre­dic­tion Devel­op­ment. Inter­na­tion­al Journ­al of Advanced Sci­ence and Tech­no­logy, 28, 21.
Poels, G., Gar­cía, F., Ruiz, F., & Piat­tini, M. (2020). Archi­tect­ing busi­ness pro­cess maps. Com­puter Sci­ence and Inform­a­tion Sys­tems, 17(1), 117–139.
Kacem, M. H., Jmaiel, M., Kacem, A. H., & Dri­ra, K. (2006). Trends in Enter­prise Applic­a­tion Archi­tec­ture. Lec­ture Notes in Com­puter Sci­ence, 158–171.
McDavid, D. W. (1999). A stand­ard for busi­ness archi­tec­ture descrip­tion. IBM Sys­tems Journ­al, 38(1), 12–31.
Gomes, S. B., San­toro, F. M., & Mira da Silva, M. (2020). An Onto­logy for BPM in Digit­al Trans­form­a­tion and Innov­a­tion: Inter­na­tion­al Journ­al of Inform­a­tion Sys­tem Mod­el­ing and Design, 11(2), 52–77.
Shishkov, B. (2020). Design­ing enter­prise inform­a­tion sys­tems mer­ging enter­prise mod­el­ing and soft­ware spe­cific­a­tion.
Hawryszkiewycz, I. T. (2012). Agile Busi­ness Sys­tem Design: Using Inform­a­tion Tech­no­logy to cre­ate busi­ness value (1 edi­tion). Vivid Publishing.

Types instead of inheritance

Many time we can see require­ment writ­ten as a “class dia­gram for pro­ject”. What “class dia­gram” mean? We can use UML class dia­gram for: archi­tec­ture mod­el, notions mod­el, some­times oth­er. Which type of mod­el do you need? Class dia­gram is a tool. When we say mod­el, we have to provided con­text: mod­el of what?

We use inher­it­ance in mod­els of notions (for build­ing tax­onom­ies), nev­er in archi­tec­ture.. In archi­tec­ture mod­els we use types. In 2015 OMG pub­lished UML v.2.5. Inher­it­ance was removed from UML . Why? Wel­come in my courses…

References (2017, Decem­ber). Uni­fied Mod­el­ing Lan­guage (UML) []. UML. (2017, Decem­ber 8). Sys­tems Mod­el­ing Lan­guage (SysML).
Weilki­ens, T. (2007). Sys­tems engin­eer­ing with SysML/UML: mod­el­ing, ana­lys­is, design (1. Aufl). Mor­gan Kaufmann OMG Press/Elsevier.
Friedenth­al, S., Moore, A., & Stein­er, R. (2015). A prac­tic­al guide to SysML: the sys­tems mod­el­ing lan­guage (Third edi­tion). Elsevi­er, MK, Mor­gan Kaufmann is an imprint of Elsevi­er.‑practical-guide-to-sysml

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, 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, 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, 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, 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, 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, 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 (2017, Decem­ber). Uni­fied Mod­el­ing Lan­guage (UML) []. 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.‑2959‑x