IS&BP. Research proposal Debbie Tarenskeen. Overview. Maart 2012

Transcription

1 Research proposal Debbie Tarenskeen Maart 2012 Non-functional requirements in software architectures with Ampersand as an architectiural description language Overview 1. Research objective 2. Central research question 3. Relation with research program IS&BP 4. PhD Supervisor - Reviewers 5. Scope 6. Methodology 7. Reactions 2

2 Research objective Modelleren van non-functional requirements in architectuur van informatiesystemen. In the context of: Communicating alternatives and possibilities to contractors, to enable them to govern the architects of the IT architecture Teach students to construct arcjitectural models Stakeholders are: Health care organisations, ICA, FT HAN (Hogeschool van Arnhem en Nijmegen), Open Universiteit 3 Central research question Can quality attributes (derived from NFR) and software architectures be modeled in a prototype which is based on Ampersand? 4

3 Non-functional requirements 5 Relation with research program IS&BP Modeling architectural decisions Complexity reduction if possible Non functional requirements and Quality attributes, software architecture patterns Ampersand (Relation Algebra) Rule based Model student systems in the context of education 6

4 PhD Supervisor - Reviewers Stef Joosten, promotor, onderzoek op gebied van Ampersand, Hoogleraar Open Universiteit, Heerlen, consultant Business rules bij Ordina René Bakker, Lector HAN, Networked applications Cor Baars, grondlegger van en mede-ontwikkelaar van opleiding van Master IT Architecture, DNV (voorheen CIBIT), architect/consultant bij Sogyo Gertjan van der Pijl, Hoogleraar Erasmus Universiteit, Rotterdam. Grondlegger van opleiding IT Auditing. 7 Scope Ampersand Rule based, Relation algebra/formal language, can generate text based on models in Ampersand Use Ampersand as a ADL (Architecture description language) in which to model Components, Containers, Connectors, Ports generate simple diagrams from complex models by using the hide - transformation: containers without the components (Richard C. Holt, IEEE 1998) Rules for testing the consistency of the structure and undesired dependencies, testing if patterns for Quality attributes are applied correctly Context: student projects, projects in Health care, Networked Applications (lectoraat HAN) 8

5 Methods in Software development Agile Lean development Incremental development Software development production lines 9 Methodology Triangulation MacKay: Hypothesis, develop artefact, observe, revise hypothesis Observe data: Testing real life systems in Ampersand models with Ampersand tools 7 design guidelines for research IT systems, Hevner 10

6 Triangulation 11 Onderzoeksmodel 12

7 7 Guidelines for IT Research Hevner Design as an artifact Problem relevance Design evaluation Research contributions Research rigor Design as a search process Communication of research 13 Reactions Positive reactions of Wolfram Kahn and Mark van den Brand 14

8 15 CASL Common Algebraic Specification Language 16

9 Planning/papers Jaar 1: An explorative study in which (distributed mobile) systems developed by students of Higher education in the Netherlands (HBO Informatica) will be formalized with ADL to a verifiable software architecture. Using quality requirements such as adaptability and portability. Research question: Can student systems be specified in Ampersand? Jaar 2: Follow up study: examine the possibilities of the architectures of Students systems for quality criteria. Research question: can we model how software architecture design decisions effect quality attributes in Ampersand? Jaar 3: A follow up on previous study where results are applied to real life systems (in Health care). Research question: Can results from student systems be repeated in real life contexts in Ampersand? Jaar 4: Definitive study in ICT Health care where software architectures of internet systems are described in formal rules (Health 2.0), in such a way that they are understandable to contractors and stakeholders. Research question: Are descriptions generated by Ampersand tools useful and understandable to contractors and stakeholders? 17 Example Ampersand {-1-}CONTEXT Travelmaps {-2-} {-3-}PATTERN Consistent_Components {-4-} {-5-}CONCEPT "Component" "" ": Part of a distributed software application " {-6-}CONCEPT "Interface" "" ": Interface of a distributed software application " {-7-}CONCEPT "Database" "" ": Database with related data " {-8-}CONCEPT "Container" "" ": Runnable component that dispatches calls to components and performs facilitating services to components " {-9-}CONCEPT "Application" "" ": A software application " {-10-}CONCEPT "ApplicationComponent" "" ": A real component in a software application " {-11-}CONCEPT "ConnectionType" "" ": A connection type in a software application " {-12-} {-13-} {-14-}instantiates :: ApplicationComponent -> Component {-15-} PRAGMA "ApplicationComponent " " is an actual component (instantiation) of a component type " {-16-} =[ ("GlassFish", "Container"); ("Tomcat", "Container"); ("MySQL", "DataBaseMS"); ("GraphDATA", "DBData"); ("CityDATA","DBData"); {-17-} ("SpringSource_Webapp", "Containerdep"); ("TravelMapsApp", "Containerdep"); ("IE7", "Browser") ]. {-18-} {-19-}ispartof:: ApplicationComponent * Application {-20-} PRAGMA "ApplicationComponent " " is part of the Application " {-21-} =[ ("GlassFish", "TravelMaps"); ("Tomcat", "TravelMaps"); ("MySQL", "TravelMaps"); {-22-} ("SpringSource_Webapp", "TravelMaps"); ("TravelMapsApp", "TravelMaps"); ("IE7", "TravelMaps"); {-23-} ("GraphDATA", "TravelMaps"); ("CityDATA", "TravelMaps"); ("TestApp", "TravelMaps") ]. 18