SPEM czyli Software & Systems Process Engineering

Tym razem arty­kuł adre­so­wa­ny do zaawan­so­wa­nych analityków. 

Ta spe­cy­fi­ka­cja (SPEM) jest dato­wa­na na 2008 rok. Stanowi sobą tło dla MDA oraz uza­sad­nia wzor­ce pro­jek­to­wa­ne opar­te na przy­pad­kach uży­cia (mikro­ser­wi­sy, Use Case 2.0, inne podob­ne). Podstawowa róż­ni­ca mię­dzy spe­cy­fi­ka­cją SPEM a spe­cy­fi­ka­cją UML pole­ga na tym, że UML to pro­fi­le MOF sta­no­wią­ce opi­sy nota­cji i sys­te­mów poję­cio­wych. SPEM to meta­mo­del pro­ce­su wytwór­cze­go opro­gra­mo­wa­nia czy­li gene­ral­ne zasa­dy budo­wa­nia pro­ce­sów wytwa­rza­nia i dostar­cza­nia oprogramowania. 

(wię­cej…)

Czytaj dalejSPEM czyli Software & Systems Process Engineering
(źr. Martin Fowler, Analysis Patterns, 1997)
(źr. Martin Fowler, Analysis Patterns, 1997)

Koncepcja wzorca projektowego dla systemów w chmurze

Wprowadzenie W 2019 opisałem swoistą próbę rewitalizacji wzorca BCE (Boundary, Control, Entity). Po wielu latach używania tego wzorca i dwóch latach prób jego rewitalizacji uznałem jednak, że Zarzucam pra­ce nad wzor­cem BCE. Podstawowy powód to boga­ta lite­ra­tu­ra i utrwa­lo­ne zna­cze­nia pojęć opi­su­ją­cych ten wzo­rzec. Co do zasa­dy rede­fi­nio­wa­nie utrwa­lo­nych pojęć nie wno­si nicze­go do nauki. Moja publi­ka­cja zawie­ra­ją­ca tak­że opis tego wzor­ca bazo­wa­ła na pier­wot­nych zna­cze­niach pojęć Boundary, Control, Entity. Sprawiły one jed­nak nie­co pro­ble­mu w kolej­nej publi­ka­cji na temat dokumentów . Dlatego w mode­lu poję­cio­wym opi­su­ją­cym role kom­po­nen­tów przy­ją­łem nastę­pu­ją­ce bazo­we stwierdzenie:…

Czytaj dalejKoncepcja wzorca projektowego dla systemów w chmurze

Inżynieria oprogramowania z użyciem narzędzia CASE – przykładowy projekt Biblioteka

W dniu 11.12.2020, uda­ło mi się w koń­cu prze­pro­wa­dzić pre­zen­ta­cję on-line. Celem była pre­zen­ta­cja reali­za­cji meto­dy MBSE z narzę­dziem CASE (tu Visual-Paradigm) i jej efek­tów. Adresatem są zarów­no ana­li­ty­cy, archi­tek­ci opro­gra­mo­wa­na jak i deve­lo­per (pro­gra­mi­ści) jako osta­tecz­ny adre­sat doku­men­tu. Podobną pre­zen­ta­cję pro­wa­dzi­łem wcze­śniej na Konferencji beIT 2020. Popularność tych pre­zen­ta­cji spo­wo­do­wa­ła, że całość prze­ro­dzi­ła się w pro­jekt badawczy. 

(wię­cej…)

Czytaj dalejInżynieria oprogramowania z użyciem narzędzia CASE – przykładowy projekt Biblioteka
http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
źr. http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471

Zwinna analiza biznesowa to mit czy fakt?

Agile business analyst has the capability to keep the wheel rolling. They?re a transformative funnel through which a requirement passes down to the delivery path towards an expected outcome. This SDLC machine needs continuous fuel in the form of well-defined and informed information which is provided by an agile business analyst. As long as an agile business analyst does the job, this machine will remain on its course to deliver greater solutions.Coming to our original question, is an agile business analyst a myth or a reality? There is a clear…

Czytaj dalejZwinna analiza biznesowa to mit czy fakt?

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

Miło mi poinformować, że moja publikacja naukowa (tu była zapowiedź) na temat syntezy wzorców architektonicznych i wzorców projektowych, systemów obiektowo-zorientowanych zatytułowana: Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns po długim procesie selekcji i recenzowania, została zakwalifikowana do publikacji i właśnie się ukazała jako jeden z rozdziałów książki: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities. Jeszcze milej mi poinformować, że - jako współautor - mogę Wam zaoferować kod promocyjny dający 40% zniżki na zakup: IGI40. Poniżej informacje o książce i o wydawcy. O…

Czytaj dalejSynthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns

Synteza pojęć i wzorców MOF, MDA, PIM, MVC i BCE. Zintegrowany model struktury procesu projektowania aplikacji.

Streszczenie: Wiele publikacji, w tym podręczniki akademickie, zawiera niespójności w opisach zastosowań metod i wzorców architektonicznych, kryjących się pod skrótami MOF, MDA, PIM, MVC, BCE. Skuteczna analiza oraz następujące po niej projektowanie oprogramowania, szczególnie gdy są to projekty realizowane w dużych zespołach, wymaga standaryzacji procesu wytwórczego i stosowanych wzorców i frameworków. W pracy tej podjęto próbę uporządkowania systemu pojęć opisujących ten proces , stosowanych do opisu wzorców architektonicznych. Przeprowadzono analizę kluczowych pojęć MOF i MDA, wzorców MVC i BCE, stworzono spójny opis łączący je w jeden system. 1. Wprowadzenie Celem badań było zweryfikowanie obecnego stanu metod projektowania i opracowanie spójnego systemu pojęć i wzorców…

Czytaj dalejSynteza pojęć i wzorców MOF, MDA, PIM, MVC i BCE. Zintegrowany model struktury procesu projektowania aplikacji.

MDE czyli Model Driven Engineering

MDE to skrót od Model Driven Engineering, nazwy ogólnego trendu w świecie inżynierii. Od pewnego już czasu  da się zaobserwować, że ludzie i ich umiejętności nie nadążają za złożonością systemów... Nie jest to jakieś wielkie odkrycie, bo problem ten wystąpił w inżynierii maszyn kilkadziesiąt lat temu... mniej więcej w czasie gdy zaczęły się pojawiać pierwsze samochody, potem było już coraz gorzej: liczba detali maszyn idzie w tysiące  (pojazdy) a nie raz i miliony (samoloty pasażerskie, pociągi). Jedynym sposobem zapanowania nad złożonością obecnych konsytuacji inżynierskich jest redukcja złożoności ich opisów, a…

Czytaj dalejMDE czyli Model Driven Engineering

Przypadki użycia czy model procesu, czego używać?

Dość często spotykam sie z tezami, że użycie przypadków użycia nie wymaga modelowania procesów i odwrotnie, albo że są to "narzędzia" oferujące podobne lub takie same korzyści, np. tak jak tu: So, as you can see we used different techniques and basically the result is the same. It was not really important what techniques were used unless solution design is complete. It?s just a matter of a habit so if you?re more comfortable with use cases then stick to them or if you?re more familiar with process maps then draw…

Czytaj dalejPrzypadki użycia czy model procesu, czego używać?

OMG’s MetaObject Facility

Końcówka roku, wręcz ostat­ni jego dzień 😉 …

Mając przed ocza­mi kolej­ny pro­jekt badaw­czy, kolej­ny raz gapię się na stro­ny OMG i mała reflek­sja: porząd­ki dobie­ga­ją koń­ca. W arty­ku­le o UML v.2.5. wspo­mi­na­łem, że zre­zy­gno­wa­no w koń­cu z poję­cia agre­ga­cji” (zwa­nej cza­sa­mi sła­bą kom­po­zy­cją”), odcho­dzi się od cał­ko­wi­cie zbęd­nych związ­ków extend” i inc­lu­de” w przy­pad­kach uży­cia (kon­struk­cje te nadal pozo­sta­ją w spe­cy­fi­ka­cji z uwa­gi na kom­pa­ty­bil­ność wstecz narzę­dzi CASE i doku­men­tów jakie w nich są nadal two­rzo­ne lub archi­wi­zo­wa­ne). Paradoksalnie spe­cy­fi­ka­cja UML jest uprasz­cza­na (sta­le tkwi w niej echo pier­wot­ne­go zlep­ku kil­ku nota­cji z lat 99-tych). Oczyma wyobraź­ni widzę jak ktoś, w toku prac nad UML, sta­le wyma­chu­je brzy­twą Ockhama”… 

(wię­cej…)

Czytaj dalejOMG’s MetaObject Facility

MDA – Cztery produkty czyli dwa etapy: wymagania i produkt

Ten artykuł można czytać na dwa sposoby: analitycy czytają od dechy do dechy po kolei ;). Menedżerowie i tak zwany biznes czytają od razu koniec, to jest część Na zakończenie, gdy uznają, że nie wierzą w te wnioski (wyrok) to zaczynają od początku czyli czytają uzasadnienie :). Niedawno napisałem: Pomiędzy pojęciami abstrakcja i model jest pewna kluczowa różnica: abstrakcja to pojęcie zaś model to opis mechanizmu, jego konstrukcja, działanie, budowa. Prosty przykład: nazwane prostokąty na typowym diagramie struktury organizacyjnej to abstrakcje komórek organizacyjnych i osób w nich zatrudnionych, prostokąty te…

Czytaj dalejMDA – Cztery produkty czyli dwa etapy: wymagania i produkt

Różne perspektywy wymagań

Nie powinniśmy zapominać, że model Kruchtena to połowa lat 90-tych, szczyt rozkwitu metod strukturalnych i raczkujące metody i narzędzia obiektowe. To stare systemy i ich relacyjne bazy danych wymusiły stosowanie [[mapowania ORM]] i takich narzędzi jak [[Hibernate]]. Dzisiaj mamy rok 2015, od tamtej pory minęło 20 lat. Nie musimy się cofać do początków inżynierii oprogramowania w wersji obiektowej. Coś takiego jak perspektywa danych to anachronizm. Podejście to w 100% zostały już dawno zastąpione przez MDA.

Czytaj dalejRóżne perspektywy wymagań

Koniec treści

Nie ma więcej stron do załadowania