use case

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 September 12, 2020

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.

Posted in General | 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: , , , , , , ,