SysML

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

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

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/
Object Man­age­ment Group. (2017, Decem­ber 8). Sys­tems Mod­el­ing Lan­guage (SysML). http://www.omgsysml.org/
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. https://www.sciencedirect.com/book/9780128002025/a‑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..

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