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
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.
Model B Model A Conforms To Meta-model B Meta-model A Conforms To Transformation Model Transformation Definition Model Transformation Execution
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.).
Model transformation concepts
• A source language/metamodel (Eg., a language of Tasks 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
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.
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.]
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.
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.
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
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
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.
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 .
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"
to the data (in out.txt): a1 : Assignment a1.task = t1 a1.staff = s1 a2 : Assignment a2.task = t2 a2.staff = s2
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.
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.
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.
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.
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.
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.
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
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”).
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
www.dcs.kcl.ac.uk/staff/kcl/uml2web/) to specify the class diagram and use cases and to generate an executable system.
• 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.
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
• Task schedule for an iteration is represented by class Schedule, with attribute totalCost : Integer, and ordered list assignment of Assignment objects.
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
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.
