METODIKA, SKIRTA ĮMONIŲ Į PASLAUGAS ORIENTUOTOS ARCHITEKTŪROS SISTEMŲ NEFUNKCINIAMS REIKALAVIMAMS RINKTI IR VALDYTI (angl. A MethodologyforCapturingandManagingNon-FunctionalRequirements forEnterpriseService-orientedArchitectureSoftware Systems) Sandra Svanidzaitė Informatika (07 T), vadovas prof. dr. A.Čaplinskas Vilniaus Universitetas, Matematikos ir informatikos institutas Programų sistemų inžinerijos skyrius
26
Embed
Metodika, skirta įmonių į paslaugas orientuotos architektūros sistemų nefunkciniams reikalavimams rinkti ir valdyti
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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,
• 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).
• 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
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.