Week 9 Implementation

Transcription

1 Week 9 Implementation Dr. Eliane l. Bodanese What is more important From a software engineering perspective: Good Gui? does what customer wants maintainable, extensible, reusable Commented Code? how is this reflected in YOUR project? 2 Page 1

2 Agenda Implementation Purpose of Implementation Role of Implementation in the Software Life Cycle Artifacts Workers Implementation Workflow Library System Example 3 Purpose of Implementation [1] Taking the result from design as input, we now need to implement the system in terms of components (source code, scripts, binaries, executables, etc.) Most of the system s architecture was already captured during design The system is implemented as a succession of small and manageable steps During implementation the system is distributed by mapping executable components onto nodes in the deployment model primarily based on active classes found during design 4 Page 2

3 Purpose of Implementation [1] Design classes and subsystems found during design are now implemented (as file components that contain source code) The components are tested, and then integrated by compiling them and linking them together into one or more executables, before they are sent to integration and system tests Implementation is the focus during the construction iterations Implementation is also done during elaboration phase executable architectural baseline during transition to handle late defects (beta releasing the system) 5 The focus of Implementation [1] Phases Core Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis Design Implementation Test Deployment Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iterations Iter. #n+2 Iter. #m Iter. #m+1 6 Page 3

4 Workers and Artifacts Architect System Integrator responsible for responsible for Implementation Model Architecture Description Deployment Model Integration Building Plan 7 Workers and Artifacts Component Engineer responsible for Implementation Subsystem Interface Component 8 Page 4

5 Artifact: Implementation Model The implementation model describes how elements are implemented (source code files, executables) It also describes how the components are organised according to the implementation environment and the programming language how the components depend on each other The implementation model defines a hierarchy (Figure 10.3 [1]) The implementation model is represented by an implementation system that denotes the top-level subsystem of the model 9 Artifact: Implementation Model [1] 1 * * Implementation Model Implementation System Implementation Subsystem * * * * Interface Component 10 Page 5

6 Artifact: Component physical packaging of model elements, such as design classes Some standard stereotypes of components include the following: <<executable>> is a program that may be run on a node <<file>> is a file containing source code or data <<library>> is a static or dynamic library <<table>> is a database table <<document>> is a document 11 Artifact: Component these stereotypes may be modified to reflect what the components actually stand for in the specific implementation environment A component traces the design element it implements The component provides the same interface as the design element 12 Page 6

7 Artifact: Component Stubs A stub is a component with a skeletal or specialpurpose implementation that can be used to develop or test another component [1] Stubs can minimize the number of new components required in each version of the system simplifying integration problems and tests represents a component that is not yet built simple element that responds to a stimlus 13 Artifact: Component (Example) In the Interbank system, the design class Account Transfers is implemented in the AccountTransfers.java source code component This is because it is a convention and common use of Java to create one Java source code file for each class, although this is not enforced This is modelled by a trace dependency between the design and the implementation model (Figure 10.4 [1]). 14 Page 7

8 Artifact: Component (Example) In the lnterbank system, the Account Transfers design class provides a Transfers interface This interface is also provided by the AccountTransfers.java component, which implements the Account Transfers class (Figure 10.5 [1]). Design Model Implementation Model Account Transfers <<trace>> <<file>> AccountTransfers.java Transfers Transfers 15 Artifact: Implementation Subsystem Implementation subsystems may consist of components, interfaces, and other subsystems It provides interfaces (exportation of operations) It depends on the packaging mechanism of the implementation environment, such as A package in Java A project in Visual Basic A directory of files in a C++ project A subsystem in an integrated development environment such as Rational Apex A component view package in a visual modeling tool such as Rational Rose 16 Page 8

9 Artifact: Implementation Subsystem Here we discuss implementation on a generic level, applicable to most implementation environments Implementation subsystems are very strongly related to their traceable design subsystems (dependencies, interfaces, classes and/or inside subsystems) FIGURE 10.8 [1] An implementation subsystem in the implementation model tracing one-to-one to a design subsystem in the design model The subsystems in the different models provide the same interface (α) and is dependent on the same inter face (β) Components in the implementation subsystem implement classes in the design subsystem 17 Artifact: Implementation Subsystem Design Subsystem <trace> (1:1) Implementation Subsystem <<file>> <<file>> α β α β 18 Page 9

10 Artifact: Interface A component that realises an interface must implement all operations defined by the interface in a correct manner An implementation subsystem that provides an interface must also contain components that provide the inter face or other subsystems that provide the interface Example An Implementation Subsystem Providing an Interface The Interbank system has an implementation subsystem called AccountManagement (a Java package), which provides the Transfers interface (Figure 10.10[1]) The java code for the Transfers interface is illustrate in Figure [1] 19 Artifact: Interface Transfers package AccountManagement; //provided interfaces: public interface Transfers { AccountManagement <<Implementation Subsystem public Account create(customer owner, Money balance, AccountNumber account_id); public void Deposit (Money amount, String reason); } public void Withdraw (Money amount, String reason); 20 Page 10

11 Artifact Architecture Description The architecture description contains an architectural view* of the implementation model The following artifacts in the implementation model are usually considered architecturally significant: 1. subsystems, their interfaces, and the dependencies between them this decomposition is very significant for the architecture 2. Key components, such as components that trace to architecturally significant design classes *see glossary: Appendix C [1] 21 Artifact: Integration Build Plan The software must be built incrementally in manageable steps so that each step yields small integration or test problems The result of each step is called a build, which is an executable version of the system, normally a part of the system Each build is subject to integration tests (Chapter 11) before the subsequent build is created Each build has a version control so that it is possible to go back to the previous build 22 Page 11

12 Artifact: Integration Build Plan Benefits of this incremental approach: An executable version of the system is created early and can be used to demonstrate system features to internal project members as well as external stakeholders The integration tests start early as well Defects are easier to locate during integration tests Integration tests tend to be more thorough than system wide tests because they can focus on smaller, more manageable parts 23 Artifact: Integration Build Plan In an iterative development, each iteration will result in at least one build The functionality to be implemented in a specific iteration is often too complex to be integrated in a single build a sequence of builds may be created within the iteration, each representing a small increment to the system An integration build plan describes the sequence of builds required in an iteration 24 Page 12

13 Artifact: Integration Build Plan For each build the plan describes: The functionality that is expected to be implemented in the build, listing use cases and/or scenarios or parts of them, and supplemental requirements if needed Which parts of the implementation model are affected by the build, listing the subsystems and components required to implement the functionality expected by the build 25 Worker: Architect The architect is responsible for the integrity of the implementation model and ensures that the model as a whole is correct, consistent, and readable The architect is also responsible for the architecture of the implementation model the architecturally significant parts as depicted in the architectural views of the model The architect is responsible for the mapping of executable components onto nodes architectural view of the deployment model Finally the architect is responsible for the architecture description - Implementation 26 Page 13

14 Worker: Component Engineer The component engineer defines and maintains the source code of one or more file components making sure that each component is correct, i.e., it implements the correct functionality The component engineer also maintains the integrity of one or more implementation subsystems The component engineer needs to make sure that the components of the implementation subsystems are correct, that their dependencies to other subsystems and/or interfaces are correct, and that they correctly implement the interfaces they provide 27 Worker: System Integrator The integration of the system is the responsibility of the system integrator planning the sequence of builds required in each iteration integrating each build when its parts have been implemented The planning results is an integration build plan 28 Page 14

15 System Integrator: Stubs and Drivers Chapter 15 [1] role of stubs and drivers also seen in testing represents a component that is not yet built simple element that responds to a stimlus how might these help your own work (not just SE coursework)? 29 Implementation - Workflow The architect outlines the key components in the implementation model For each iteration, the system integrator plans the system integration supplies the sequence of builds of that iteration The system integrator also describes the functionality that should be implemented in each build and which sub systems and components will be affected by it The subsystems and components are then implemented by component engineers The resulting components are unit tested and passed to the system integrator for integration The system integrator then integrates the new components into a build and passes it to integration testers for integration tests 30 Page 15

16 Architect Architectural Implementation System Integrator Integrate System Implement a Component Engineer Implement a Subsystem Class Perform Unit Test 31 Activity 1. Architectural Implementation The architect has the following activities 1.1 Identify Architecturally significant components Identify executable components from the architectural design (subsystems and interfaces) The implementation trace one-to-one design components 1.2 Map executable components onto Nodes 1.3 Maintain, refine, and update the architecture description and its architectural views of the implementation and deployment models 32 Page 16

17 Design model Architect Component (outlined and mapped onto nodes) Deployment model Architectural Implementation [1] Architect. Description (views of the design and deployment models) Architecture Description 33 Activity 1. Architectural Implementation It is important not to identify too many components at this stage or delve into too many details An initial outline of the architecturally significant components would suffice Identifying Executable Components and Mapping Them onto Nodes Consider the active classes found during design and assign one executable component per active class, denoting a heavyweight process This mapping is very significant to the architecture of the system and should be depicted in the architectural view of the deployment model 34 Page 17

18 Activity 1. Architectural Implementation (Example) In the design model, there is an active class called Payment Request Processing In the implementation, we identify a corresponding executable component called PaymentRequestProcessing An active object of the Payment Request Processing class is allocated to the Buyer server node Since the PaymentRequestProcessing component implements the Payment request processing class, it should also be deployed onto the Buyer server node (Figure 10.19) [1] 35 Activity 1. Architectural Implementation (Example [1]) Design Model Implementation Model Payment Req. Processing <<trace>> <<executable>> PaymentRequestProcessing Node and their active objects Node and their component instances :Buyer Server :Payment Request Processing implies :Buyer Server <<executable>> :PaymentRequestProcessing 36 Page 18

19 Library Example: From Architectural Design <<Design subsystem>> Book Borrower s Management BookBorrower_UI BB_ui BookBorrower_Ctr BB_control Nodes Web Client Web/Lib Server 37 Activity 1. Architectural Implementation (Library Example) Design Model Implementation Model BB_control <<trace>> <<executable>> BB_control Node and their active objects Node and their component instances :Web Server :BB_control implies :Web/Library Server <<executable>> :BB_control 38 Page 19

20 Activity 2. Integrate System (1) Planning a build The build should add functionality to the previous build by implementing complete use cases and/or scenarios (if possible) Scenarios are paths through use cases it is easier to test complete use cases and/or scenarios than fragments of them The build should not include too many new or refined components hard to integrate and perform integration testing some components can be implemented as stubs to minimize the number of new components 39 Activity 2. Integrate System The build should expand upwards and to the sides in the layered subsystem hierarchy Initial builds should start in the lower layers (middleware and system- software layers) Subsequent builds then expand upwards to the applicationgeneral and application-specific layers It is hard to implement components in the upper layers if the lower layers are not already functioning properly 40 Page 20

21 Activity 2. Integrate System When planning a build is crucial to identify the right requirements to be implemented and to leave the rest of the requirements for future builds For each potential use case to be implemented: Consider the design of the use case by identifying its corresponding use-case realisation Identify the design subsystems and classes that participate in the use-case realisation Identify the implementation subsystems and components in the implementation model tracing to those design subsystems and classes 41 Activity 2. Integrate System For each potential use case to be implemented (cont): Consider the impact in implementing these subsystems and components on top of the current build Evaluate whether this impact is acceptable If so, plan to implement the use case in this build Otherwise, leave it for a future build The results should be captured in the integration build plan and communicated to the appropriate component engineers 42 Page 21

22 Activity 2. Integrate System Integrating a Build collect the right versions of the implementation subsystems and components, compile them, and link them into a build The resulting build passes through integration tests If it passes, the build passes through system tests (if it is the last build created within an iteration (Chapter 11)) 43 Activity 3. Implement a Subsystem The component engineer needs to make sure the subsystem implementation fulfils correctly its role in all builds Maintaining the subsystem contents: If the subsystem components were outlined by the architect, probably the component engineer needs to refine them Remember that the implementation keeps the trace one-to-one with the design components The implementation subsystem must contain component(s) or internal subsystem(s) that provide the correct interface (outlined in the design) After these considerations, the component engineer start to implement the components within the subsystem and unit test them. 44 Page 22

23 Integration Build Plan Architecture Description (view of the implement. model) Component Engineer Implementation Subsystem (implemented for a build) Implement a Subsystem Design Subsystem Interface (designed) [1] Interface (implemented for a build) 45 Activity 3. Implement a Subsystem [1] Design Subsystem <trace> (1:1) Implementation Subsystem <<file>> <<file>> Classes required by the current build α β α β 46 Page 23

24 Activity 3. Implement a Subsystem (Example [1]) A Subsystem Providing an Interface The subsystem Buyer s Invoice Management needs to provide the Invoice interface in the current build The component engineer responsible for the subsystem decides to let the Invoice Processing component realise that interface (Figure 10.24) [1] Buyer s Invoice Management Invoice Invoice Processing 47 Activity 3. Implement a Subsystem (Library Example) Printer s Management Print_return_date Print LM s Management ILM_control Member_ID 48 Page 24

25 Activity 4. Implement a Class 4.1 Outlining the File Component The source code that implements a design class resides in a file component You also need to consider the scope of the file component You can code several classes in one file, if the programming environment allows you to do that (java does not -.java ->.class) Design workflow may have used syntax of programming language source code maybe be easily generated However, only the signatures of operations are generated, the operations must still be implemented 49 [1] Design Class Component Engineer (designed) Component Implement a (implemented) Interface Class (provided by the design class) 50 Page 25

26 Activity 4. Implement a Class 4.2 Implementing operations Each operation of the design class needs to be implemented, unless they are virtual (or abstract) and then they are implemented by the descendants (remember the example in chapter 9 the trade design object page 258 [1]) The term methods denotes the implementation of the operations The implementation of the operation is the coding of the algorithm that realises the operation and the data structures involved 4.3 Making the component provide the right interfaces The component must provide the same interface(s) that its correspondent design component 51 1public class Account 2{ 3 //In this example the Account has a balance only 4 private Money balance = new Money (0); 5 public Money withdraw (Money amount) 6 { 7 // First we must ensure that the balance is at least as big as 8 // the amount to withdraw 9 if balance >= amount 10 // Then we check that we will not withdraw negative amount 11 then 12 { if amount >= 0 design by contract 13 then{ 14 try{ 15 balance = balance amount; 16 return amount 17 } 18 catch (Exception exc) {} 19 //Deal with failures reducing the balance...to be defined 20 } 21 else {return 0} 22 } 23 else {return 0} 24 } 25} (Example [1]) 52 Page 26

27 Activity 5. Performing Unit Test The component engineer tests the implemented components as individual units (Figure [1]) Two types of unit testing are performed: 5.1 Specification testing, or black-box testing verifies the component s behaviour without considering how that behaviour is implemented within the component what output the component will return when given certain input and when starting in a particular state 53 Black Box Testing cont. To consider all possible inputs, starting states, and outputs is impractical Instead, the ranges of inputs, outputs, and states are divided into equivalence classes An equivalence class is a set of input, state, or output values for which an object is supposed to behave similarly [1] By testing a component for each combination of the equivalent classes, it is possible to achieve almost the same test coverage as when testing all individual value combinations This dramatically reduces time and effort 54 Page 27

28 [1] Component (implemented) Component Engineer Interface Perform Unit Test Component (unit tested) 55 Activity 5. Performing Unit Test 5.2 Structure testing, or white-box testing verifies that a component works internally as intended the component engineer should test all code (every statement has to be executed at least once) the component engineer should also test the most interesting paths, most critical paths, the least known paths, and the high risk paths through the code 56 Page 28

29 Activity 5. Specification Testing (Example [1]) Equivalence Classes The state of an account has three equivalence classes: empty, negative balance (perhaps overdrawn), and positive balance. The input arguments can be divided into two equivalence classes: zero and positive numbers. The output arguments fall into two equivalence classes: positive amount withdrawn and nothing withdrawn. The component engineer should choose values for the tests based on heuristics: Normal values in the allowed range for each equivalence class, such as withdrawing 4, 3.14, or 5,923, from an account. Values that are on the boundary of the equivalence classes, such as withdrawing 0, the smallest possible positive number (e.g., ) and the largest possible number. Values outside the eligible equivalence classes, such as withdrawing a value greater or smaller than the possible range. Illegal values, such as withdrawing -14, and A. 57 Activity 5. Specification Testing (Example [1]) When choosing the tests, the component engineer should try to cover all the combinations of input, state, and output equivalence classes, such as withdrawing $14 from An account with $ , resulting in nothing being withdrawn. An account with $0, resulting in nothing being withdrawn. An account with $13.125, resulting in nothing being withdrawn. An account with $15, resulting in $14 being withdrawn. The net result of these four test cases is that all eligible combinations of equivalence classes for state (positive balance and negative balance) and output (positive amount withdrawn and nothing withdrawn) are tested for one value in one equivalence class 58 Page 29

30 Activity 5. Specification Testing (Example [1]) The component engineer should then choose to test cases with similar state (perhaps $ , 0, 3, and 15) and output values ($0 and 14), but with another value from the same input equivalence class, such as Then the component engineer prepares similar ranges of test cases for other equivalence classes of input values, such as trying to withdraw $0, 4, 3.14, 5,923, , 37,000,000,000,000,000,000,000 (If that is the largest possible number), 37,000,000,000,000,000,000,001,-14, and A. 59 Activity 5. Structure Testing (Example [1]) Performing structure test in the code example for Account (Figure [1], reproduced in slide 45) we must ensure that all if-statements evaluate to both true and false, and that all code is executed For example, we may test the following: Withdrawing $50 from an Account with a balance of $100, where the system will execute rows Withdrawing $-50 from an Account with a balance of $10, where the system will execute row 23. Withdrawing $50 from an Account with a balance of $10, where the system will execute row 21. Triggering an exception when the system executes the statement balance = balance - amount, where the system will execute rows Page 30

31 Library System Case Study Now we give a simplified example of the java code implementation for the use case Identify Library Member A dummy class that tests the use case A simplified implementation of the ILM_control and ILM_UI classes An example of the creation and use of an interface (Member_ID). 61 import javax.swing.joptionpane; // JOptionPane - a predefined dialog box // that allows the user to input a value (input dialog) and print a // message (message dialog) public class Identify_LM_test { public static void main (String args[]) { boolean result; ILM_control lmc = new ILM_control(); result = lmc.checklmid(); if (result == true) JOptionPane.showMessageDialog(null, "Your library number was accepted","result", JOptionPane.PLAIN_MESSAGE); else JOptionPane.showMessageDialog(null, "Your library number was refused", "Result", JOptionPane.PLAIN_MESSAGE); } (Library Example for Identify LM) System.exit(0); // Terminates the program } 62 Page 31

32 public class ILM_control extends Object implements Member_ID { private int lm_db[]; //declares the array as private public ILM_control () // public constructor for ILM_control { lm_db = new int [200]; //Allocates memory to the array that will simulate the data base for LM numbers //Emulates a data base, initialising the data base with some Library Numbers for (int i = 0; i < lm_db.length; i++) lm_db[i] = i; } public boolean checklmid() { int lmnumber; boolean result; ILM_UI ilmui = new ILM_UI(); // create an instance of ILM_UI // send request to LM_UI to ask for the Library number of the user lmnumber = ilmui.get_lm_number(); result = false; for (int i = 0; i < lm_db.length; i++) { if ( lmnumber == lm_db[i]) { result = true; break; } (Library Example for Identify LM) } return result; } } 63 (Library Example for Identify LM) // file Member_ID.java public interface Member_ID { // Add method to return the outcome of the LM's ID check // true = okay, false = refuse } public boolean checklmid(); 64 Page 32

33 // JOptionPane - a predefined dialog box that allows the user to input a //value (input dialog) and print a message (message dialog) import javax.swing.joptionpane; public class ILM_UI extends Object{ private String LM_id; //declares the string to contain the LM number private int number; } // public constructor for ILM_UI public ILM_UI () { // read from the keyboard the number entered by the library user LM_id = JOptionPane.showInputDialog ("Enter your Library Number"); } //converts the entered id from type String to type int number = Integer.parseInt(LM_id); public int get_lm_number() { return number; } (Library Example for Identify LM) 65 References [1] Jacobson I., Booch G., Rumbaugh J., The Unified Software Development Process, Chapter 10, Addison- Wesley, Stevens P., Pooley R. Using UML Software Engineering with Objects and Components. Addison- Wesley, Fowler M., Scott K., UML Distilled A Brief Guide to the Standard Object Modelling Language, Addison-Wesley, Further Reading: [1] Chapter 15, Construction Phase 66 Page 33