WS205/206 8.09.205 SWPLE General remarks The practical part of the lecture on SWPLE consists of 6 dates. Each date is mandatory. The lab sessions will be done in groups of 2 students. We will look at different topics in the field of software product lines. You will find out how hard it is to identify and to extract variability from daily life objects or how to use known modeling techniques enhanced with variability. In the last sessions there will be a little programming task. In the end you will hopefully have a better understanding about the importance of variability in software product lines and also in normal projects. It is supposed that you have good knowledge about software engineering, project management and UML models. Preparation In general you should try to solve the exercise with your partner before the lab date. In the course there will be time to complete your results and to discuss the results with other groups. So you are prepared for the discussion in the whole group. Tools Tools for managing product lines are rather complex and very expensive. Furthermore it is the objective of the course to understand the principles of product lines and not to teach the usage of some specific tool. For that reason we do not use any special tool but only normal text editors, drawing tools or compilers. You can use either the PC in the lab or your private computer.
WS205/206 8.09.205 Exercise : Analysis of a Case Study In this exercise you analyze a report on the successful adoption of a product line approach of the company HomeAway. Preparation: Read the report from the 2 th international Software Product Line Conference HomeAway s Transition to Software Product Line Practice: Engineering and Business Results in 60 Days which is available for download at http://www.biglever.com/papers/krueger_homeaway.pdf Write down your answers to the questions below as preparation. Exercise: Discuss your results in the course in groups of 2 persons. Make sure you are done after one hour since the remaining time will be used for discussion in the whole group. General What does HomeAway offer? Who are their customers? What is the market of HomeAway? What is the market position? What Software is developed? Describe the foundation of HomeAway in a few words Before the change How did HomeAway develop its software? How many software products did they have? What variability occurred and how was it resolved? What was the first step in order to get a common solution? What did they use? Write down the definition of a product line. Compare HomeAway s mode of working to the definition of a product line. What aspect was not fulfilled? Draw a diagram that shows the development principle before the change (displaying products vs. time) 2
WS205/206 8.09.205 The Change What parts of the development cycle crashed? What features pushed the current development approach to the edge? Who recognized that there is need for a change? What did they do in the first 30 days of the transition? What did they do in the second 30 days? What role did BigLever/Gears play? After the change How does HomeAway develop its software now? How many software products do they have? What effect did the change have on HomeAway s testing results? What effect did the change have on HomeAway s code maintenance? What about modeling, software architecture or documentation? Why was it possible to adopt a product line approach in 60 days at HomeAway? Think about the kind of software they have to provide. Imagine the following scenario: A customer is renting a house which is offered on several web sites. How is the booking stored and displayed? 3
WS205/206 8.09.205 Exercise 2: Variability In this exercise you analyze a real life example for variability. You have to identify variation points and variants. Preparation Make yourself familiar with the train tickets below and think about the differences. Exercise a) At your train station you can go to the service desk and buy various tickets. They usually offer One way tickets for trips from A to B for a single person Return tickets for trips from A to B and from B to A for a single person Seat reservations as a kind of add-on to ordinary tickets Student tickets are valid for half a year for a certain region and local trains. In the train the student has to identify himself by a passport. Happy weekend tickets that allow up to 5 people to take local trains on the weekend Commuter tickets are valid for weeks or months for a certain region and local trains. In the train the commuter has to identify himself by a passport. Compare the tickets to each other and use the following 3 questions to narrow the variability down What does vary? Why does it vary? How does it vary? Write down your results (the What and How) in a table. Variation Points One Way Return Ticket Ticket Reservation only Student Ticket Happy weekend Commuter ticket 4
WS205/206 8.09.205 b) It is planned to introduce new "E-tickets" that work as follows: You identify ( check-in ) yourself at a special terminal at the train station A (where you intend to enter a train). At train station B (where you are leaving your train) you will be registered and a check-out happens automatically. Later on you will be charged for your trip from A to B (your bank account is known). What variability or variant do you have to add to cover that kind of ticket? Think about what the train conductor will check in the train. c) What is the commonality that all these tickets share? Try to find a definition that also includes the new e-tickets. Discuss your result in the group. d) Imagine you have to implement the software that is used at the service desk. You are supposed to implement a kind of question-answer HMI for all the conventional tickets (no E-Ticket). Draw the questions and answers as a selection graph (not necessarily a tree) with variation points (questions) as nodes, variants (choices) as edges and tickets as leaves. Try to build a graph with minimal depth. Hint: Chose the questions from your table that separate the available choices into balanced groups (e.g. 50:50). There may be more than two choices at a node. 5
WS205/206 8.09.205 Exercise 3: Textual Requirements and Variability In this exercise you analyze extracts from three user manuals explaining the use of similar car radios. You have to identify the variability points, variants and common parts. The result is written down as a common textual description a core asset. Preparation Make yourself familiar with the use case template below and try to solve a) and b). Exercise a) Read the user manuals which are shown on the next page. Analyze the text with respect to use cases contained. Draw a use case diagram that contains the use cases for all the 3 manuals at once (Please do not look for something too complicated it s rather simple). b) Fill in the use case description template for each use case (template see below). Feel free to modify the text but the functionality described in the manuals has to be preserved. Highlight variation points by enclosing it in < >. Use Case Name Primary Actor Further Actors -- Precondition Stakeh & Inter Success Guar. Minimal Guar. Trigger Basic Course (Main Success Scenario) Radio Listener Marketing usability Station tuned in none. 2. Alternative Course a: a: a2: c) Draw a variability diagram containing all variation points and variants encountered. Finally add a variation point <Radio> with the variants Bremen, Paris and London and connect the radios to their specific variants i.e. represent the radios as Packaged Variants. d) The following questions will be discussed by the whole group There are a lot of restrictions within the use cases (e.g. AF and PTY must be switched off for functionality ). What do you think about these? In the middle of Paris you find the following section << Down in short intervals (for FM only; AF must be switched off) Do you understand what is meant? How could this be expressed more obviously? 6
WS205/206 8.09.205 7
WS205/206 8.09.205 Exercise 4: Design and Variability In this exercise you analyze the class diagrams for two similar car radios. You have to identify the variability points, variants and common parts. The result is documented as a variability model and as an improved class diagram. Preparation Make yourself familiar with class diagrams in general and try to solve a) and b). Exercise a) Analyze the class diagram of the car radio CD Radio supporting CD and radio. What two common tricks did the architect use to handle well-known variability? (Please do not look for something too complicated it s rather simple). class CD Radio RadioGUI CD_GUI AmplifierGUI AudioSource..* AudioManager + register(audiosource*) + unregister(audiosource*) RadioControl CD_Control TunerDriv er CD_Driv er Tuner-RDS-3 CD-Driv e ST47 8
WS205/206 8.09.205 b) Analyze the class diagram of the MP3-CD-Radio supporting CD, MP3 and radio. Compare it to the previous diagram and identify common parts and varying parts Highlight with different colors the product specific parts and parts that are (reasonable) core assets. Think carefully whether classes with same names are really the same! What about the drivers? Are they product specific or common? class MP3-CD Radio RadioGUI MP3_GUI CD_GUI AmplifierGUI AudioSource..* AudioManager + register(audiosource*) + unregister(audiosource*) RadioControl MP3_Control CD_Control TunerDriv er CD_Driv e_coordinator CD_Driv er Coordinates access to the "stupid" driver (which manages only one client). Dispatches events to more than one client. Tuner-RDS-3 CD-Driv e TR085 c) How could you model the drivers differently to get better core assets? d) Draw a variability diagram containing all variation points and variants encountered. Link the model to the classes of the diagrams. Make sure that the following information is covered: MP3 and CD support are optional, radio is mandatory CD drive ST47 does not support MP3 The CD_Drive_Coordinator is only needed if the same CD-drive is used for MP3 and CD The User Interface is always different (both radios have different designs) 9
WS205/206 8.09.205 Exercise 5: Implementing Variability I In this exercise you implement simple mechanisms that support variability in C++. Preparation Make sure that you have a C++-Compiler on your computer and that you still know how to use it. Exercise Assume the following scenario. You are developing a product line for driver information systems. All such systems need an algorithm for the route calculation. There are three different algorithms that calculate a route: Passenger car, Small Truck and Big Truck. Depending on the kind of car that has to be supported you have to choose one out of the three algorithms. So you have the following variability model VP RouteCalc Algorithms V V V Passenger a) Implement a C++ Class CRouteCalc that provides an operation void CRouteCalc::calculate(void). Depending on the desired variant the function calculate() is supposed to display 0, or 2 times the string Passenger or Small Truck or Big Truck. Use the C++-Precompiler Commands to select the appropriate code: #define ABC 23 #ifdef ABC "Hello world!\n" #endif Write a separate file that contains your main()-function. Main() creates an instance of the class and calls calculate. Implement the variation point in such a way that the selection can be made without touching the code of the class CRouteCalc. Consider your code and answer the following questions. Small Truck Big Truck What parts of the code would be core assets? What parts are product specific? If you need the C++-Compiler only for this exercise have a look at Codeblocks. This is a small C++-package that comes with compiler and debugger. 0
WS205/206 8.09.205 Imagine there were real algorithms instead of the simple loops returning the strings. Such algorithms will definitely contain common code. What would you have to do to avoid fragments of identical code at different locations in the code? Imagine you make a mistake when selecting the desired variant i.e. you chose two variants at once or none at all. What will happen? Imagine you need a 4th variant. How would you add it? Do you have to touch the core assets? What does this mean e.g. to testing? b) Implement the same variability by using a strategy pattern: DriverInfoSystem RouteStrategy* myrs DriverInfoSystem(RouteStrategy*) void newroute() RouteStrategy virtual void calculate() PassengerRouteStrategy void calculate() SmallTruckRouteStrategy void calculate() BigTruckRouteStrategy void calculate() Implement an abstract C++ Class RouteStrategy that provides an operation virtual void calculate(). Implement a C++ Class DriverInfoSystem that provides an operation void newroute() and a constructor DriverInformationSystem(RouteStrategy*) that gets the desired strategy (object) as parameter. newroute() calls the operation calculate() of the RouteStrategy-Object that comes with the constructor. Furthermore DriverInfoSystem needs an attribute RouteStrategy* myrs to realize the assoziation to the RouteStrategy. Implement the 3 different classes that are derived from RouteStrategy and implement the different calculate() operations. Depending on the RouteStrategy the function calculate() is supposed to return 0 times the string Passenger or Small Truck or Big Truck. Write a separate file that contains your main()-function. main() creates an object of DriverInformationSystem using the constructor with a specific strategy object as parameter (created by new). Then newroute() is called. Create a DriverInformationSystem object for each strategy. Hint: When compiling all strategies at once the header of the base class will be included multiply. To avoid the resulting errors wrap the content of the header file in read only once directives (#ifndef xxx #define xxx #endif). Consider your code and answer the following questions. What parts of the code would be core assets? What parts are product specific? Imagine there were real algorithms instead of the simple loop returning the strings. Such algorithms will definitely contain common code. What would you have to do to avoid fragments of identical code at different locations in the code. Can you make a mistake when selecting the desired variant i.e. chose two variants at once or none at all? What will happen? Do you have to touch the code of the class DriverInformationSystem to change the strategy that is used? Where are changes needed? Imagine you need a 4 th variant. How would you add it? Do you have to touch the core assets? What does this mean e.g. to testing?
WS205/206 8.09.205 Exercise 6: Implementing Variability II In this exercise you apply the mechanism to support variability on an example from daily life. Please choose the mechanisms that are appropriate but as simple as possible. Warning: This exercise looks rather simple. But doing it in the expected way is not easy. Preparation Write the code for an English-only system. Exercise Assume the following scenario. You are developing the user interface for a product line of automated teller machines (ATMs). You are selling the ATM to different countries. In Germany the ATM is delivered with German as the default language. But the ATM also has to support English 2. In France the ATM is delivered with French as the default language. But the ATM also has to support German 3. In Great Britain the ATM is delivered with English as the default language. But the ATM also has to support German. In a menu you can change the language at runtime. In the beginning there is a short greeting sentence. a) For the exercise you have to implement a user interface that works like this: Setup-Info (debug comments in English) Greeting, choice and invalid choice in selected language Selection key in the selected language 2 Of course there would be more languages in real life. But 3 languages are sufficient to understand the mechanisms. 3 If you are not familiar with French or German feel free to choose other languages. 2
WS205/206 8.09.205 Requirements: There are two out of 3 available languages included in the system (chosen from German, English and French). The code for the third language is NOT included 4. Additional languages can be inserted easily i.e. without touching the existing code. (This should work with adding some files and making a simple change in the mainfile.) The selection of the supported languages is supposed to be as simple as possible. In the main-file there is only primitive code, i.e. a few includes, settings and a constructor for a class displaying the user interface. Try to implement a good design following the usual design guidelines (e.g. separation of concerns). Consider your code and answer the following questions. What mechanisms did you use for the realization? Why? Describe how the languages are selected in your solution Can you make a mistake when selecting the desired variants i.e. chose three languages or only one? What will happen? What has to be done to add a new language that has to be supported? What does this mean e.g. to testing? Did you use a switch/case statement for the menu? Why (not)? What about a one fits all solution? Why is it not suitable even if there is sufficient file space for storing all language data? Think about the report from exercise. Imagine you are looking for a tool for your product line. What features would you expect? 4 Including the header-file is ok. Since the linker only includes binary files that are really used. 3