1 Modeldrevet softwareudvikling – 7. september 2004 Design Methods for Reactive Systems, R.J. Wieringa Part II: Function Notations Jens Bæk Jørgensen, Aarhus Universitet

2 Introduction – basic concepts and terminology zFunction: Ability to create desired effect in environment yResponsibility: Contribution to environment goal yService: Useful interaction triggered by event yTransaction: Atomic interaction

3 Introduction – software development design levels

4 Mission statement – basics zHighest level software specification zTo find software mission yAnalyze business goals yFind desired emergent properties E of composite system zJustify purpose and responsibilities by system engineering argument zUpdate mission statement during project

5 Mission statement – training information system zName: Training Information System zPurpose: To support management of monthly introductory training courses zResponsibilities yTo support course preparation, including allocation of participants to groups and printing badges yTo support course handling (unexpected, absentees) yTo support course wrap-up z Exclusions yData of unexpected participants is not checked yNo support for allocation of speakers to groups yNo support for allocation of groups to rooms

6 Mission statement – goal tree of training department

7 Mission statement – juice heating controller zName: Juice heating controller zPurpose: To control the heating process of juices in a heating tank zResponsibilities yTo initialize itself with batch data and heat the batch according to recipe yTo report on the heating process yTo maintain safe conditions in a tank zExclusions yNo support for filling storage tanks with juice yNo support for transferring pasteurized juice to canning line

8 Mission statement – goal tree of juice pasteurization plant

9 Mission statement – in general zPurpose: Role of SuD in business solution zResponsibilities; organise according to yThe business goals they contribute to yThe business process in which they are used yThe external entities that are needed to exercise the responsibilities yThe kind of added value they deliver to the environment zComposition: Description of SuD in context zExclusions: Use for expectation management

10 Function refinement tree – basics zMakes responsibilities more specific zBounds functionality of SuD yJustifies presence of services yPrevents presence of unnecessary services zThe most implementation-independent description of SuD yNot a system structure ySubjective organization yMeans of communication with customer

11 Function refinement tree – training information system

12 Function refinement tree – Guidelines for construction zDistinguish product properties from process properties zDistinguish product properties from product constraints zDistinguish between external and internal product properties zDistinguish services from quality attributes zDistinguish primary services from features zIdentify and categorise primary services zCheck that services have triggers and deliver something valuable zOrganise functions in a tree and relate them to responsibilities

13 Function refinement tree – juice heating controller exercise zP0: Initialize with batch data zP1: Heat a batch according to recipe zP2: Monitor temperature in tank zP3: Maintain a log of each heating process zP4: Watch for critical conditions zP5: Stop the system upon request from operator zP6: System should run in any plant of factory zP7: System should run on NT and Linux zP8: System should be delivered within two months zP9: System development method should be M1 zP10: Development budget is 60,000 $ zP11: Mean time between failures should be a year

14 Function refinement tree – juice heating controller

15 Service description – basics zContents of service description yTriggering event yDelivered service (of value for the environment) yAssumptions about environment (optional) zPurpose of service description yShare understanding of desired service among all stakeholders ySpecify service in an implementation-independent way yBound functionality of SuD yProduce system engineering argument

16 Service description – training information system; download joiners zTriggering event: Coordinator requests to download list of joiners from personnel information system zDelivered service: Download the list of people from personnel information system who have joined the company since previous training zAssumptions: Data in personnel information system reflects situation accurately with a time lag of not more than one working day

17 Service description – training information system; upload participant record zTriggering event: Coordinator requests to upload list of joiners to personnel information system zDelivered service: Upload the list of people who participated in the training to personnel information system zAssumptions: Personnel information systems is able to deal with data about unexpected participants, including any remaining errors in that data

18 Service description – juice heating controller; heat batch according to recipe zTriggering event: Operator command ”start heating batch b according to recipe” zDelivered service: Upon reception of this command, the controller ensures that a heating process takes place, in the heating tanks in which b is stored, according to the recipe of b zAssumptions: There is a batch in the heating tank

19 Service description – guidelines for construction zDo not be too detailed; ask yIs this an interaction that a customer is willing to pay for? yIs this an interaction after which the user feel they can go away and have a break? zDo not give details about system behaviour, nor about communication channels with SuD zJust describe valuable effect of system in environment zDescribe a service as you would explain it to the customer

20 Service descriptions – comparison with UML-style use cases zJacobson, 1987: ”A use case is a special sequence of transactions, performed by a user and a system in a dialogue” zUML, 1999: ”A use case is a description of a set of sequences of actions, including variants, that a system performs to yield an observable result to an actor” zRobertsons (Volere), 1999: ”Use cases are a unit of work that the user finds useful” zCockburn, 2001: ”The use case describes the system’s behavior under various conditions as the system responds to a request from one of the stakeholders (…) an interaction with the system to accomplish some goal” zWieringa, 2003: ”Services are similar to use cases”

21 Service descriptions – Literature on UML-style use cases zCockburn: Writing Effective Use Cases, Addison- Wesley, 2001 zBooch, Rumbaugh, Jacobson: The Unified Modeling Language User Guide, Addison-Wesley, 1999 zKruchten: The Rational Unified Process – an Introduction, Addison-Wesley, 1999 zBittner, Spence: Use Case Modeling, Addison- Wesley, 2003 zJacobson: Use Cases – Yesterday, Today, and Tomorrow, Journal on Software and Systems Modeling, July 2004

22 Summary zMission statements zGoal trees zFunction refinement trees zService descriptions