METODIKA, SKIRTA ĮMONIŲ Į PASLAUGAS ORIENTUOTOS ARCHITEKTŪROS SISTEMŲ NEFUNKCINIAMS REIKALAVIMAMS RINKTI IR VALDYTI

(angl. A Methodology for Capturing and Managing Non-Functional Requirements for Enterprise Service-oriented Architecture Software Systems)

Sandra SvanidzaitėInformatika (07 T), vadovas prof. dr. A.Čaplinskas

Vilniaus Universitetas, Matematikos ir informatikos institutasProgramų sistemų inžinerijos skyrius

Į paslaugas orientuota paradigma (SOA)

• Į paslaugas orientuota (angl. Service orientation) paradigma tai nauja programų sistemų kūrimo paradigma siūlanti kurti ir komponuoti sistemas iš nepriklausomų paslaugų (angl. services)− Ši paradigma yra kilusi iš prieš tai vyravusių paradigmų tokių kaip:

− Objektinės paradigmos - OOP (angl. Object-oriented paradigm)− Komponentinio programavimo - COP (angl. Component-oriented

programming )− Atvirųjų išskirstytų skaičiavimų – ODB (angl. open distributed

processing )

Paslaugų stiliaus architektūra (angl. Service-oriented architecture - SOA) tai paslaugų kūrimui skirtas architektūrinis

stilius. 2

Paradigmų evoliucija

3

Įmonės į paslaugas orientuota sistemų architektūra (ESOA)

• Vienas iš SOA sub-stilių yra įmonės į paslaugas orientuota sistemų architektūra (angl. Enterprise SOA - ESOA)− Šis stilius pateikia rekomendacijas (gaires), kaip kurti

ir panaudoti į paslaugas-orientuotas sistemas, skirtas vidiniam įmonės naudojimui.

− Šis stilius remia įmonės verslo strategiją bei tikslus - sistemos kūrimas prasideda nuo šių dalykų apibrėžimo.

4

5

Į paslaugas orientuota reikalavimų inžinerija (SoRE)

• Į paslaugas orientuota paradigma kelia naujus iššūkius programų sistemų reikalavimų inžinerijai (angl. Requirements engineering - RE)− Todėl atsiranda nauja reikalavimų inžinerijos atšaka- į

paslaugas orientuotų sistemų reikalavimų inžinerija. − Ši reikalavimų inžinerijos atšaka skirta paslaugų, jų darbų

sekų (angl. workflow) identifikavimui ir modeliavimui. − SoRE sprendžia paslaugų specifikavimo (angl. Service

Specification), paslaugų suradimo (angl. Service Discovery), žinių apie paslaugas valdymo (angl. Service Knowledge Management) ir paslaugų komponavimo (angl. Service Composition) uždavinius. 6

SoRE - Paslaugų specifikavimas• Atliekamame tyrime sprendžiamas paslaugų

specifikavimo uždavinys gilinantis į paslaugas orientuotų sistemų nefunkcinių reikalavimų (angl. Non-functional requirements - NFRs) analizę, specifikavimą, konfliktuojančių reikalavimų radimą bei konfliktų sprendimą sukuriant metodiką, kuriame remiamasi: − Požiūrio (angl. Viewpoint) konceptu, taikomu įmonių

programų sistemų architektūros kūrimo (angl. Enterprise Architecture - EA) metodikose bei tarptautiniuose standartuose ir

− Vartotojo reikalavimų notacijos standarte apibrėžiamomis reikalavimų specifikavimo kalbomis (angl. User Requirements Notation - URN)

7

Architektūros aprašo koncepcinis modelis pagal ISO 42010-2011 standartą

8

Architektūrinio požiūrio apibrėžimas

• Remiantis “Systems and software engineering — Architecture description” standartu (ISO/IEC/IEEE 42010:2011) architektūrinis požiūris turi būti apibrėžtas nurodant:• Interesus (angl. Concerns), kurie yra ribojami požiūriu. Šiuo

atveju, nefunkcinius reikalavimus traktuosime kaip interesus.• Architektūriniu požiūriu suinteresuotas šalis (angl. Stakeholders)• Vieną ar daugiau modelių rūšis (angl. model kinds) kurios yra

naudojamos architektūriniam požiūriui modeliuoti• Kiekvienai naudojamai modelių rūšiai nurodomos kalbos,

notacijos, susitarimai, modeliavimo technikos, analitiniai metodai (angl. languages, notations, conventions, modeling techniques, analytical methods)

• Nuorodomis į architektūrinio požiūrio šaltinius. 9

Vartotojo reikalavimų notacijos standarto kalbos

• URN yra pirmas tarptautinis standartas skirtas verslo tikslų, verslo scenarijų ir ryšių tarp jų atvaizdavimui grafiniu būdu. • GRL (angl. Goal-oriented Requirement Language -GRL) yra grafinė

(vizuali) notacija skirta modeliuoti skirtingų suinteresuotų šalių verslo tikslams, nefunkciniams reikalavimams. Ji parodo konfliktuojančių reikalavimų poveikį bei galimus alternatyvius sprendimus, kurie gali būti naudojami verslo tikslams pasiekti.

• UCM (angl. Use Case Maps) yra grafinė (vizuali) notacija skirta sistemos komponentų veiklos scenarijų analizei. Analizuojama sistemos komponentų struktūra siekiant išsiaiškinti, kaip komponentų struktūros pokyčiai paveiktų nefunkcinius reikalavimus bei realizuojamus verslo scenarijus.

10

Tikslams modeliuoti skirta reikalavimų modeliavimo kalba

• Verslo tikslas nusako, kodėl kuriama sistema turi atlikti tam tikras funkcijas.

• Sistemos modeliavimas vyksta strateginiame lygmenyje.

• Dėmesio centre – sistemos evoliucija

• Galima ištirti būsimos sistemos privalumus ir trūkumus.

11

Panaudojimo būdų žemėlapiai• Naudojant UCM modeliuojami sistemos panaudos

scenarijai, siekiant išsiaiškinti atskirų sistemos komponentų atliekamas funkcijas, jų tarpusavo ryšius bei atsakomybes.

Struktūros ir alternatyvos, kurios buvo atrastos GRL modeliavimo metu, gali būti įvertintos lokalizuojant atsakomybes UCM komponentams

komponentai

atsakomybės 12

ESOA nefunkcinių reikalavimų modeliavimo metodika

ESOA nefunkcinių reikalavimų modeliavimo metodika susideda iš šių žingsnių:− ESOA požiūrių apibrėžimas− Nefunkcinių reikalavimų priklausančių kiekvienam ESOA

požiūriui apibrėžimas− Nefunkciniu reikalavimu suinteresuotos šalies (angl.

Stakeholder) apibrėžimas − Konfliktuojančių nefunkcinių reikalavimų radimas ir

reikalavimų derybų proceso apibrėžimas.

13

ESOA požiūrių apibrėžimas• ESOA požiūriai yra apibrėžti remiantis:

• SOA sluoksnių apibrėžimu pateiktu OASIS SOA pavyzdinėje architektūroje (žr. kitą skraidrę SOA-RA, 2010),

• Įmonių architektūros kūrimo standartais (angl. EA standards):• ISO/IEC/IEEE 42010:2011, IEEE Std 1471:2000

• Įmonių architektūros kūrimo karkasais (angl. EA frameworks)• Zachman Enterprise Architecture Framework (ZIFA)• The Open Group Architecture Framework (TOGAF) • Extended Enterprise Architecture Framework (E2AF)• DoD Architecture Framework (DoDAF)• Kruchten’s “4+1” view model/ RUP’s 4 + 1 Views (Kruchten, P., 1995)• Siemens’ 4 views method (Hofmeisteret al., 1999)• Reference Model for Open Distributed Processing (RM-ODP)

• SOA sistemų analizės ir kūrimo metodais ir metodikomis:• Service-oriented modelling and architecture (IBM RUP/SOMA)• An Architectural Framework for Service Definition and Realization (SOAF) (Erradi, et al, 2006)• Service-oriented Unified Process (SOUP) • Thomas Erl suggested methodology (Erl, T., 2005, Erl, T., 2008) • Michael Papazoglou methodology (Papazoglou, M.P., 2006)

14

ESOA požiūriai• Apibrėžti tokie ESOA požiūriai:

• Įmonės verslo procesų požiūris (angl. Enterprise Business Processes Viewpoint),

• Vartotojo požiūris (angl. Consumer Viewpoint) (žr. 23- 24 skaidrė), • Verslo proceso požiūris (angl. Business Process Viewpoint) , • Paslaugų požiūris (angl. Services Viewpoint), • Paslaugų komponentų požiūris (angl. Services Components

Viewpoint), • Operacinių sistemų požiūris (angl. Operational Systems Viewpoint) ,• Integracinių sistemų požiūris (angl. Integration Viewpoint) ,• Paslaugų kokybės požiūris (angl. Quality of Service Viewpoint),• Informacijos architektūros požiūris (angl. Information Architecture

Viewpoint) ,• ESOA valdymo požiūris (angl. ESOA Governance Viewpoint).

15

ESOA suinteresuotų šalių apibrėžimas

• Apibrėžtos tokios ESOA sistemų suinteresuotos šalių grupės (SOA, SGRM, 2009): • Verslo/ IT valdymo grupė (angl. Business/IT Steering Group), • ESOA valdymo komisija (angl. ESOA Steering Board, ESOA

Governance Board), • Įmonės architektūros valdymo komisija (angl. EA Governance

Board),• ESOA kompetencijos centras (angl. ESOA Center of Excellence),• Verslo srities atstovai (angl. Business Domain Representatives),• Programinio sprendimo kūrimo grupė (angl. Solution

Development Team) ,• Paslaugų kūrimo grupė (angl. Service Development Team),• IT operacijų priežiūros grupė (angl. IT Operations)• ESOA sistemų vartotojai (angl. Consumers Group)

16

ESOA nefunkcinių reikalavimų apibrėžimas

• Apibrėžtas sąrašas ESOA nefunkcinių reikalavimų remiantis (Choi, et al., 2007, O'Brien, et al., 2005): • Pasiekiamumas (angl. Availability), Našumas (angl. Performance),• Patikimumas (angl. Reliability), Panaudojamumas (angl. Usability) ,• Randamumas (angl. Discoverability), Adaptuojamumas (angl.

Adaptability),• Komponuojamumas (angl. Composability), Interoperabilumas

(angl. Interoperability), • Saugumas (angl. Security), Skaliuojamumas (angl. Scalability) ,• Praplėtimas (angl. Extensibility), Testuojamumas (angl. Testability),• Auditas (angl. Auditability), Modifikacija (angl. Modifiability)• Operabilumas (angl. Operability and Deployability) .

• Nefunkciniai reikalavimai ESOA požiūriuose traktuojami interesai (angl. Concerns).

17

ESOA konfliktuojančių nefunkcinių reikalavimų radimas

18

Požiūrių susikirtimas

19

Reikalavimų derybų proceso apibrėžimas

• Siūlome reikalavimų derybų procesą, kuris yra paremtas pagrindiniu paslaugų orientacijos paradigmos tikslu - remti įmonės verslo strategiją bei tikslus. • Reikalavimų derybų proceso metu atskleidžiame „kodėl“

(modeliuodami verslo tikslus) vieni nefunkciniai reikalavimai yra svarbesni už kitus.

• Verslo tikslų modeliavimui pasitelkiame Vartotojo reikalavimų notacijos (angl. User Requirements Notation - URN) standarte apibrėžiamomis reikalavimų specifikavimo kalbomis (Amyot, D., & Mussbacher, G., 2011).

Reikalavimų derybų proceso veiklos pavaizduotos kitoje - 21 skaidrėje. 20

1. ESOA požiūrių, jiems priklausančių NFR ir suinteresuotų šalių apibrėžimas konkrečiai dalykinei sričiai

2. Konfliktuojančių reikalavimų radimas

3. ESOA požiūrių, suinteresuotų šalių NFR modeliavimas su GRL ir UCM

4. Alternatyvių spredimų paieška

5. Sprendimų detalizavimas

6. Sprendimų vertinimas, analizė ir galutinis susitarimas

21

22

GRL ir UCM diagramų pavyzdys

• Kuriama sistema skirta įmonės vykdomai draudimo veiklai kompiuterizuoti,• kuri sudaryta iš 4 pagrindinių posistemių: 1) Klientų

duomenų valdymo (angl. CRM), 2) Draudimo sutarčių kūrimo bei valdymo (angl. Policy), 3) Apskaitos valdymo (angl. Billing) ir 4) Draudiminių įvykių valdymo (angl. Claims)

• Pateikiamos vartotojo požiūrio diagramos, kuriose suinteresuota šalis yra pats sistemos vartotojas

• Diagramose pateikiami du galimi panaudos scenarijai (GRL – 23 skaidrė, UCM-24 skaidrė):• 1. Apdraustam asmeniui registruojamas naujas draudiminis įvykis ir

apmokama patirta žala• 2. Registruojamas naujas apdraustas asmuo, jam sukuriama draudimo

sutartis, paskaičiuojama draudimo įmoka ir sudaromas įmokos mokėjimo planas.

23

24

Literatūra• The Open Group SOA Reference Architecture (SOA-RA), 2010. Technical Standard, refer to:

http://www.opengroup.org/soa/source-book/soa_refarch/index.htm• ISO/IEC/IEEE 42010:2011, Systems and software engineering - Architecture description• IEEE Std 1471:2000, Recommended Practice for Architectural Description of Software-

intensive Systems• Zachman Institute for Framework Advancement (ZIFA), refer to: http://www.zifa.com/ • TOGAF®, an Open Group standard, refer to:

http://www.opengroup.org/subjectareas/enterprise/togaf • Extended Enterprise Architecture Framework Essentials Guide v1.5, 2001-2006. Institute For

Enterprise Architecture Developments. Refer to: http://www.enterprise-architecture.info/Images/E2AF/Extended%20Enterprise%20Architecture%20Framework%20Essentials%20Guide%20v1.5.pdf

• DoDAF Architecture Framework Version 2.02, 2010. Refer to: http://dodcio.defense.gov/dodaf20.aspx

• Kruchten, P., 1995. Architectural Blueprints — The “4+1” View Model of Software Architecture. IEEE Software 12 (6), pp. 42-50.

• Hofmeister, C., Nord, R., Soni, D., 1999. Applied Software Architecture. Addison-Wesley, Boston

• Reference Model of Open Distributed Processing (RM-ODP). Refer to: http://www.rm-odp.net/

• IBM RUP/SOMA. Refer to: http://www.michael-richardson.com/rup_classic/#core.base_rup/guidances/supportingmaterials/introduction_to_rup_36B63436.html

25

Literatūra• Erl, T., 2005. Service-Oriented Architecture: Concepts, Technology and Design. Prentice

Hall PTR.• Erl, T., 2008. SOA Principles of Service Design. Prentice Hall PTR• Papazoglou, M.P., 2006. Service-Oriented Design and Development Methodology. Int. J. of

Web Engineering and Technology (IJWET).• Erradi, A., Anand, S., Kulkarni, N., 2006. SOAF: An Architectural Framework for Service

Definition and Realization. IEEE International Conference on Services Computing (SCC'06).

• SOUP. Refer to: http://www.kunalmittal.com/html/soup.html• SOA Source Book, 2009. Van Haren Publishing.• SOA Governance Technical Standard: SOA Governance Reference Model (SGRM). Refer

to: http://www.opengroup.org/soa/source-book/gov/sgrm.htm• O'Brien, Liam., Bass, Len., Merson, P. F., 2005. Quality Attributes and Service-Oriented

Architectures. Software Engineering Institute. Paper 449. Refer to: http://repository.cmu.edu/sei/449

• Choi, S. W.; Her, J. S. & Kim, S. D., 2007. Modeling QoS Attributes and Metrics for Evaluating Services in SOA Considering Consumers' Perspective as the First Class Requirement. APSCC, IEEE, pp. 398-405.

• Errikson, I., & McFadden, F., 1993. Quality Function Deployment: A Tool to Improve Software Quality. Information and Software Technology 35, 9.

• Amyot, D., & Mussbacher, G., 2011. User Requirements Notation: The First Ten Years, The Next Ten Years. Journal of Software Vol. 6, No. 5.

26