now browsing by tag


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…

PIM modelling ‑Reduction of UML notation

The work is an attempt to sys­tem­at­ise the use of key 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…

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)

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?


Object Man­age­ment Group. (2017, Decem­ber). Uni­fied Mod­el­ing Lan­guage (UML) []. UML.
Object Man­age­ment Group. (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

Systems analysis and design

Many time we heard about agile in soft­ware devel­op­ment. Many times authors wrote that agile provide us to fast and cheapest solu­tions. It is true but not all the times. Chaos Report (see Standish Group) show us, that is not true all the times.

Few comments…

Gen­er­ally small pro­jects are not a (big) problem..


Water­fall vs. agile: first one meth­od con­sume many more time than second one, but we have no time to «big ana­lys­is». Second one mean «work­ing too fast», and effect is more pro­to­typ­ing mean cost increas­ing… many time mean: can­cel pro­ject before fin­ish caused by budget:


A water­fall is not a solu­tion, but agile is not a good rem­edy for it. A com­mon prob­lem in soft­ware design is sys­tem size and complexity:


How to improve qual­ity and chance to suc­ceed soft­ware pro­ject? We need really good per­son to busi­ness ana­lys­is role and only one. More than one per­son in a first stage, mean more prob­lem with mer­ging parts to one com­pleted and unam­bigu­ous require­ments doc­u­ment :


Dis­cip­lined agile, what is it? Using mod­els in agile, why and for what? Mod­ern sys­tem ana­lys­is and design is not a water­fall and not a agile style? It is sci­ence meth­od used for soft­ware engin­eer­ing . Dis­cov­er the MDA and pat­terns as a wand for your suc­cess in soft­ware pro­jects. See the sys­tem as a archi­tec­ture .

More about gen­er­al sys­tems and SysML nota­tion com­ing soon ?

Try my courses for improve your skills and your team­mates, hire me as a gif­ted per­son in your project.


Kurt Bittner. (2011). Use-Case 2.0: Scal­ing up, scal­ing out, scal­ing in for agile pro­jects.
Lar­man, C. (2005). Apply­ing UML and pat­terns: an intro­duc­tion to object-ori­ented ana­lys­is and design and iter­at­ive devel­op­ment (3rd ed). Pren­tice Hall PTR, c2005.
Shar­baf, M., Zamani, B., & Sun­yé, G. (2020, Octo­ber). A Form­al­ism for Spe­cify­ing Mod­el Mer­ging Con­flicts. Sys­tem Ana­lys­is and Mod­el­ling (SAM) Con­fer­ence.
Gra­ics, B., Mol­nár, V., Vörös, A., Majzik, I., & Var­ró, D. (2020). Mixed-semantics com­pos­i­tion of stat­e­charts for the com­pon­ent-based design of react­ive sys­tems. Soft­ware and Sys­tems Mod­el­ing.–00806‑5
Gha­ra­jed­aghi, J. (2011). Sys­tems think­ing: man­aging chaos and com­plex­ity: a plat­form for design­ing busi­ness archi­tec­ture (Third Edi­tion). Elsevi­er Inc.
Evans, E. (2014). Domain-driv­en design: tack­ling com­plex­ity in the heart of soft­ware. Addis­on-Wes­ley.
Fowl­er, M. (1997). Ana­lys­is pat­terns: reusable object mod­els. Addis­on Wesley.
Ambler, S. W. (2002). Agile mod­el­ing. John Wiley & Sons.
Gar­cía Díaz, V., Cueva Lov­elle, J. M., Pelayo Gar­cía-Buste­lo, B. C., & San­juán Martínez, O. (Eds.). (2014). Advances and applic­a­tions in mod­el-driv­en engin­eer­ing. Inform­a­tion Sci­ence Reference.
Ambler, S. W. (2004). The object primer. Agile Mod­el-Driv­en Devel­op­ment with UML 2.0 (Third Edi­tion). Cam­bridge Uni­ver­sity Press.

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… 


Object Man­age­ment Group. (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