Part 5: Model Transformations and Agile Development We go in more detail into Model-driven development, and introduce Agile development techniques.

Transcription

1 Part 5: Model Transformations and Agile Development We go in more detail into Model-driven development, and introduce Agile development techniques. Model transformations Agile development Team project (assessed). 1

2 Model Transformations Essential part of model-driven development (MDD): can map UML models to code, can migrate models from one modelling language to another, or improve model quality, etc. Many different MT languages: QVT (an OMG standard), ATL, ETL, Kermeta (Java-like), GrGen, TGG (graph-based), etc. In this course we will use UML-RSDS: a UML-based MT language which generates executable Java programs to carry out transformations. 2

3 Model Transformation Definition Meta-model A Meta-model B Conforms To Transformation Conforms To Model Transformation Execution Model A Model B Model transformation context 3

4 Models and Metamodels A class diagram at the language level is called a metamodel because its classes have instances at the (application) model level. In turn, an application model has instances at the instance model (program execution) level. Both language level and application level models can be represented using class diagram notation, and are stored in file mm.txt by the UML-RSDS tools. Instance-level models are represented as text files (in model.txt, in.txt, out.txt, etc.). 4

5 Modelling levels 5

6 Model transformation concepts A source language/metamodel (Eg., a language of Task s to be performed in development) is mapped to a target language (eg., a language of staff and task allocations to staff). Can be same language. A model transformation (MT) takes as input a source model (eg., a particular task dataset) and produces a corresponding target model (eg., a particular task allocation dataset). A transformation is usually defined by transformation rules, which map particular kinds of source model elements to corresponding target model elements. 6

7 Basic task allocation metamodels 7

8 Transformation examples Code generation/refinement: produce more implementation-specific model/code from implementation-independent representation. Eg., mapping of UML to Java, or UML to C++, etc. Migration: transform one version of a language to another/or to closely similar language. Eg., mapping Java to C#, or UML 1.4 to UML 2.3, or from one EHR (patient data) format to another, etc. Refactoring/restructuring: rewrites a model to improve structure/quality. Eg., removing redundant inheritance, introducing Template method pattern, etc. 8

9 Transformation specification in UML-RSDS Source and target metamodels drawn as class diagrams in UML-RSDS editor. Transformations defined as use cases, rules expressed as postconditions Ante Succ of use case. Minimal example: empty class diagram, one use case hello with single postcondition "Hello world!"->display() [Use options Create (General) Use case, and Edit use case, Add postcondition.] 9

10 Start screen of UML-RSDS 10

11 Constraint definition dialog 11

12 Defining constraints A constraint P Q on entity E is entered by writing E in the first text area, P in the second and Q in the third. The default options (system requirement, non-critical, update code) can be chosen for the other options in most cases. E is called the context or scope of the constraint. 12

13 Transformation specification in UML-RSDS Another example: Transformation copies each a : A instance to a b : B with b.y = a.x a.x. Single postcondition of a2b use case, operating on A: B->exists( b b.y = x*x ) This is implicitly universally quantified over A, so means for every A object, there exists a b : B such that b.y = x x. Write A in first box, true in 2nd, B->exists( b b.y = x*x ) in 3rd. 13

14 A to B transformation 14

15 Transformation specification in UML-RSDS To get an executable transformation, select Generate Design from the Synthesis menu, then Generate Java 4. Executable is GUI.java in output/ subdirectory, compile + run this. Input files in.txt describe instance models, eg: a1 : A a1.x = 3 a2 : A a2.x = -5 15

16 GUI of transformation executable 16

17 Running the transformation produces the output file out.txt: a1 : A a1.x = 3 a2 : A a2.x = -5 b1 : B b1.y = 9 b2 : B b2.y = 25 17

18 Transformations in UML-RSDS Can be any number of postconditions (rules) in transformation use case, and source/target metamodels can be as complex as required. Rule mapping from source class Sc to target class Tc typically has form Tc->exists( t t.f1 = e1 &... & t.fn = en ) where the fi are features of Tc and the ei are expressions using Sc s features. Constraint iterated over Sc. Other rules can display/print, eg: y->display( ) iterated over B in our example prints out all y values of B objects. 18

19 Simple allocator class diagram 19

20 Simple task allocator Use case allocatetasks with one postcondition, on context class Task: st : Staff & assignment.size = 0 & st.assigned.size = 0 => Assignment->exists( a a.task = self & a.staff = st ) This is transformation rule that maps Task and Staff to Assignment: for each unassigned task self : Task, it picks some unassigned staff member st and creates an assignment that assigns st to work on self. 20

21 Simple task allocator For example, this could map the task and staff data (in in.txt): t1 : Task t1.taskid = "t1" t1.duration = 10 t2 : Task t2.taskid = "t2" t2.duration = 5 t1 : t2.dependson s1 : Staff s1.staffid = "Mike" s2 : Staff s2.staffid = "Amy" 21

22 to the data (in out.txt): a1 : Assignment a1.task = t1 a1.staff = s1 a2 : Assignment a2.task = t2 a2.staff = s2 If there were 3 tasks and 2 staff, one task would remain unallocated. 22

23 Simple task allocator Problems with this transformation: No account is taken of dependson or duration: a task should only be allocated if all its preceding tasks have already been allocated: dependson forall(d d.assignment.size > 0) We might want to assign long-duration tasks first. No account is taken of staff skills or cost. These improvements are for you to do in the team project. 23

24 Model Transformations: Summary Transformations can automate many software engineering tasks, such as implementation, migration, etc. Many MT approaches, languages, etc. UML-RSDS approach uses standard UML/OCL notations to define transformations, compiles specifications to code. 24

25 Agile Development Traditional software development processes are plan-based: focussed on prescriptive activities and fixed sequence of stages (eg., Analysis, Design, Coding, Testing in Waterfall process). Agile processes in contrast attempt to be as lightweight as possible in terms of process: primary goal is to deliver a system to customer that meets their needs, in the shortest possible time. 25

26 Agile development concepts Traditional development approaches have become too slow to handle rapid change in markets and technology: by the time code is delivered it is out-of-date. Agile development addresses problem by delivering parts of system as working code as soon as possible. Delivery cycles are short, so developers can adapt system to deliver what customer requires. 26

27 Agile development principles Responding to change is more important than following a plan. Producing working software is more important than comprehensive documentation. Individuals and interactions are emphasised over processes and tools. Customer collaboration is emphasised over contract negotiation. Development cycles are iterative, and build small parts of systems, with continuous testing and integration. 27

28 Agile development principles Self-selecting teams the best architectures, requirements, designs emerge from such teams. Agile methodologies suitable for smaller organisations and projects. Extreme programming (XP) suitable for single projects developed and maintained by single person/small team. 28

29 Agile versus plan-based development Agile development Plan-based development Small/medium-scale Large scale (10+ people) In-house project, co-located team Distributed/outsourced team Experienced/self-directed Varied experience levels developers Requirements/environment volatile Requirements fixed in advance Close interaction with customer Distant customer/ stakeholders Rapid value, high-responsiveness High reliability/correctness required required 29

30 Agile development techniques Sprints: development work which implements specific user requirements, in short time frame to produce new release. Deliver working software frequently. Scrum methodology. Refactoring: Regularly restructure code to improve it, remove redundancy, etc. (ref: Fowler, Refactoring: improving the design of existing software ). 30

31 Scrum process 31

32 Agile development: Sprints Sprints are regular re-occuring iterations in which project work is completed. Produce deliverables that contribute to overall project. Each iteration of system involves set of use cases/work items ( stories in Scrum) to be implemented. Use cases can be classified by business value to customer (high, medium, low), and by risk/effort by developer. High priority and high risk uc s should be dealt with first. Project velocity: amount of developer-time available per iteration. Taking these into account, can define release plan: which uc s will be delivered by which iteration and by which developers. 32

33 Defining a release plan Release consists of set of iterations (eg., sprints) and produces a deliverable to client If use case uc1 depends on uc2 via extend, include or inheritance arrow from uc1 to uc2, then uc1 must be in same or later iteration to uc2 Iterations also depend on availability of developers with required skills for development of uc s in iteration. Some use cases may be prioritised over others. 33

34 Release plan example 34

35 Agile development: Refactoring Small changes to rationalise/generalise or improve the structure of existing system Eg: if discover that there are common attributes in all subclasses of a class: move common attributes up to superclass. Refactoring should not change existing functionality: run tests to check this Do regular refactoring whenever you identify the need. These are just refactoring transformations on systems. 35

36 Pull-up attribute refactoring 36

37 Agile methods: extreme Programming (XP) Aim of XP is to combine best practices in development projects and to focus on agility and code production. Based on short development cycles, uses: pair programming; code reviews; frequent integration and testing; close collaboration with customers; daily review meetings. Emphasis on coding as key development activity, and as means of communicating ideas between developers and demonstrating ideas to customers. Unit testing used to check correct implementation of individual features, acceptance testing to check implementation meets customer expectations. Integration testing checks that separately developed features operate correctly together. 37

38 Agile methods: extreme Programming (XP) Has five phases: Exploration: determine feasibility, understand requirements, develop exploratory prototypes Planning: agree date and uc s for 1st release Iterations: implement/test uc s in series of iterations Productionizing: prepare documentation, training, etc and deploy system Maintenance: fix and enhance deployed system. XP recommends that iterations are one to two weeks long. 38

39 Agile methods: Scrum Has four phases: Planning: establish the vision, set expectations, develop exploratory prototypes Staging: prioritise and plan for 1st iteration, develop exploratory prototypes Development: implement uc s in series of sprints, and refine iteration plan. Daily Scrum meetings to check progress. Release: prepare documentation, training, etc and deploy system. Scrum recommends that iterations (sprints) are 1 week to 1 month long. 39

40 Agile methods: Scrum Key events: Sprint Planning: performed by Scrum team before sprint, team agrees uc s to be worked on in sprint Daily Scrum: organises activities of team, review sprint progress + deal with issues. Time limited (eg., 15 mins). Key questions for developers: (i) what did I achieve yesterday? (ii) what will I achieve today? (iii) is there anything blocking me from achieving my work? Sprint Review: at end of sprint Sprint Retrospective: after sprint review, before next sprint planning. Analyse achievements of sprint, ideas for improvement of process. 40

41 Agile methods: Scrum Story: a generalised task (ie., use case). Can consist of set of subtasks Product Backlog: ordered (in terms of priority) list of stories relevant to project Sprint Backlog: ordered list of stories to be completed in a sprint. Team uses Scrum Board showing tasks to do, in progress and completed. Burndown Chart shows graph of remaining work against time. 41

42 Scrum board 42

43 Agile methods: Scrum Scrum defines three key roles for members of a software development team: Product owner: customer representative in team, this role is responsible for liaising between technical staff and stakeholders. The product owner identifies required work items, identifies their priority, and adds these to product backlog. Development team: workers who perform the technical work. Team should have all needed skills and be self-organising. Typically between 3 to 9 members in this role. Scrum master: the Scrum master facilitates Scrum process and events, and self-organisation of the team. Not a project manager role, does not have personnel management responsibilities. 43

44 Scrum process 44

45 Agile MDD Combines Agile development and MDD. System specification is expressed in an executable model (a PIM or PSM), which can be delivered as a running system, and demonstrated to customers. Incremental development of the system now uses executable models, rather than code. The models serve as documentation, also. 45

46 Agile MDD approaches Executable UML (Mellor and Balcer; Mellor and Wolfe). UML-RSDS (Lano and Kolahdouz-Rahimi). Both use principle that The model is the code. By automating code generation, can ensure correctness even for agile development. 46

47 Executable UML (xuml) Uses UML class diagrams, state machines, action language to define explicit platform-independent specification. Classes have state machines and objects interact by sending signals to each other. Concurrent execution model: objects synchronise by communication, otherwise execute independently. Aims to translate to wide range of platforms, including C, VHDL, etc. Commercial product. 47

48 UML-RSDS Uses UML class diagrams, OCL, use cases and activity language pseudocode to define explicit PIM specifications. Individual systems are sequential, can interact via RPCs in distributed implementation. Translations to Java, C #, C++: oriented to this family of languages. Open source. 48

49 UML-RSDS process 49

50 UML-RSDS application architecture 50

51 xuml compared with UML-RSDS UML-RSDS can be more abstract (tending to CIM level): use cases specified purely as pre/post predicates, pseudocode is synthesised automatically from these. UML-RSDS is more restrictive at PSM level: only Java-family of languages supported, code is similar in structure to specification. Executable UML requires more work in modelling execution platform. UML-RSDS provides verification capabilities via B AMN and Z3. In this course we will use UML-RSDS as it is simpler and aligned to Java. 51

52 Agile MDD in practice Build baseline class diagram, refine use cases Developers choose required use cases (from current sprint) to work on, and write unit tests for these. All share same system model. Developers work on their tasks: can only enhance/extend the CD, not delete/modify if rationalisations need to be performed, get agreement of team for refactorings Do regular full builds/integration Deliver when all tests passed. Good communication within team needed. Source code should be readable, but never directly changed. 52

53 Agile MDD in practice Alternatively, developers could have responsibility for specific modules: Each module has one developer, who works on its use cases Developers must agree interfaces of modules, and shared data. Developer of one module should never need to see code of another module. 53

54 Other development techniques Test driven development (TDD): write unit tests first, then successively extend and refine code until it passes all tests. Pair programming: two developers work at same terminal, observer has the role to improve programmers code. TDD appropriate if no clear understanding of how to solve problem. Pair programming can improve quality, and reduce time, whilst increasing cost. 54

55 Pair programming 55

56 Summary Model transformations are essential part of MDD Agile development is alternative to traditional plan-based development: agile processes increase flexibility to cope with uncertain requirements/new requirements during development Agile MDD uses agile techniques to develop system via models. 56

57 OSD team project Deadline: 4pm, Friday 11th December (Submission on Keats). Teams are listed on Keats. Your team has task to develop a scheduling system for agile development. This takes as input descriptions of development tasks, and details of skills and costs of available developers, and generates schedule assigning developers to tasks. You should write the software using UML-RSDS (tool and manual are available at: to specify the class diagram and use cases and to generate an executable system. 57

58 Organise teams to have a leader responsible for overall planning/coordination; different roles/responsibilities some team members can do research, testing, report writing, others write solution in UML-RSDS. At tutorials you will have access to technical advisors experienced in UML-RSDS. Use tutorials to sketch out class diagrams and discuss possible solutions with team. Deliverable of project: stand-alone Java program which can read files of staff and task data, and produce correct schedules. Report: include final class diagram and operation specifications. Describe development and management approach taken, project process (who did what, why), results of testing, and evaluation of outcome. 58

59 Coursework Problem: Resource Scheduling The system is intended to do release planning for an agile development process. Work items are Story objects, have a storyid : String unique key. Each story has ordered list subtasks of Task objects, which define particular work tasks. Tasks have a unique taskid : String key, and an Integer duration. A task may depend on other tasks (which must be completed before it). A task has a set, needs, of Skill objects which represent skills needed to carry out the task. Skill has a unique skillid : String. Entity type Staff represents staff, has unique staffid : String, and an Integer costday. A set, has, of skills is associated to each staff object. 59

60 Task schedule for an iteration is represented by class Schedule, with attribute totalcost : Integer, and ordered list assignment of Assignment objects. Each Assignment has associated staff and task objects. 60

61 Required system operations are: allocatestaff: for each unallocated task t, all of whose dependson tasks have already been allocated, find an available (unallocated) staff member who has all the skills required by t, and assign t to the cheapest such staff member, s. Create a new assignment for t and s, and add this to the schedule. calculatecost: add up the products s.costday t.duration for the assignments of the schedule and add this to totalcost of the schedule. displayschedule: print the list of assignments, with information of the staffid, costday, taskid, duration for each assignment. Evaluate your solution on several test cases of planning problems (the files in.txt, in1.txt, in2.txt on Keats). Does your approach always find the schedule with lowest total cost? Identify ways to improve your solution. 61

62 Add a duration : Integer attribute to Schedule, and compute this as part of the calculatecost operation. [hint: define a recursive operation totalduration() : Integer of Task which calculates the duration of the task together with those it depends on] The system only calculates a schedule for a single iteration: the iteration is complete when all possible allocations to available staff have been made. Define a use case nextiteration to schedule a further iteration. No new classes or attributes are needed, and use case itself has a single, very simple, constraint on Schedule or on Assignment. 62