system design

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

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…

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..

(https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf)

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:

(https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf)

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:

(https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf)

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 :

(https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf)

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.

References

Kurt Bittner. (2011). Use-Case 2.0: Scal­ing up, scal­ing out, scal­ing in for agile pro­jects. https://www.ivarjacobson.com/publications/white-papers/use-case-ebook
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. https://doi.org/10.1145/3419804.3421447
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. https://doi.org/10.1007/s10270-020–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.