Implementation Yaodong Bi

Introduction to Implementation Purposes of Implementation – Plan the system integrations required in each iteration – Distribute the system by mapping executable components onto nodes in the deployment model – Implement the design classes and subsystems found during design as file components – Unit test the components, then integrate then by compiling them linking them together into one or more executables.

Artifacts of Implement. - Overview Implementation model Components Implementation subsystems Interfaces Architecture description Integration build plan

Artifacts – Implementation Model Implementation model – Describe how elements in the design model are implemented in terms of components such as source code files, executables, and so on. – Describe how the components are organized according to the structuring and modularization mechanisms available in the implementation environment and programming languages

Artifacts – Components Components – A component is the physical packaging of model elements, such as design classes in the design model – Standard stereotypes of components: > is a program that may run on a node > is a file containing source code or data > is a static or dynamic library > is a database table > is a document

Artifacts – Components Components – Components have trace relationships to the model element they implement such as design classes – It is common for a component to implement several elements. (p. 270, Fig 10.4) – Components provide the same interfaces as the model elements they implement (p 271, Fig 10.5) – There can be compilation dependencies between components (p. 271, Fig 10.6)

Artifacts – Components Stubs – A stub is a component with a skeletal or special- purpose implementation that can be used to develop and test other components – Stubs can be used to minimize the number of new components required in each new (intermediate) version of the system.

Artifacts – Implement. Subsystems Implementation subsystems – Provide a means of organizing the artifacts of the implementation model into more manageable pieces – A subsystem may consists of components, interfaces, and other subsystems – An implementation subsystem is manifested by an actual “packaging mechanism” in the implementation environment such as a package in Java, a project in VB, etc.

Artifacts – Implement. Subsystems – An implementation system should be traced one- to-one to a corresponding design subsystem – The implementation subsystem should define analog dependencies toward other implementation subsystems – The implementation subsystem should provide the same interface – The implementation subsystem should define which contained components provide each of the interfaces (p273 Fig 10.8)

Artifacts – Interfaces Interfaces – Specify the operations implemented by components and implementation subsystems – A component that realizes an interface must implement all operations defined by the interface – An implementation subsystem that provides an interface must also contain components that provide the interface (p.275, Fig 10.10)

Artifacts – Architecture (Implem.) Architecture description (view of the implementation model) – Subsystems, their interfaces, and dependencies between them. They have a one-to-one mapping to design subsystems – Key components mapping to significant design classes, executable components, general components

Artifacts – Integration Build Plan Integration build plan – Build: an executable version of the system – Built incrementally in manageable steps – Integration build plan: the sequence of builds in an iteration. It describes: The functionality to be implemented, as a list of use-cases Which parts of the implementation model are affected by the build, as a list of subsystems and components

Activities of Implement. - Overview Architectural Implementation – Outline the implementation model and its architecture. Integrate system – Create an integration plan and integrate each build Implement subsystems – Ensure each subsystem fulfill its role in each build

Activities of Implement. - Overview Implement classes – Implement each design class in a file component Perform unit test – Test the implemented components as individual units

Architectural Implementation Identify and implement architecturally significant components, such as executable components – Consider each active class as an executable component (p. 282, Fig 10.18) Mapping components to nodes in the deployment model – Map each component to the node its corresponding design active class assigned to. (p. 282, Fig )

Integrate System Create an integration build plan describing each build and its requirements – Each build should add functionality to the previous build by implementing complete use-cases – Each build should include too many new or refined component. Stubs may be used for components Integrate each build before it is subject to integration test. – Collect the right versions of subsystems and components, compiling them, and linking them into a build

Implement Subsystems Maintain the subsystem contents – A subsystem should fulfill its purpose for the current build by components – Each class (and subsystem) required for the current build should be implemented by components (and implementation subsystem) of the implementation subsystem (p. 286, Fig 10.22) – Each interface required by the build must be implemented by components (p Fig 10.23, Fig 10.24)

Implement Classes Outline the file components for source code – The source code for each class resides in a file component – The chosen file components should support the compilation, installation, and maintenance of the system Generating code from a design class – Many details of a design class are described during design – Code for association and aggregation depends the language Associations  reference attribute in the referring object The name of the attribute is the role name of the association at the opposite end Multiplicity determines the type of the reference: a simple pointer or a collection of pointers

Implement Classes Implementing operations – Methods: implementations of an operation – Methods may be described in natural language in design – Choose a suitable algorithm and data structures for each operation – The states of the design class may impact on the implementation Making the component provide the right interface – The resulting component should provide the same interfaces as the design class(es) it implements

Perform Unit Test Specification testing or black-box testing – Verify the unit’s externally observable behavior – The range of inputs, outputs, and states are divided into equivalence classes – An equivalence class: a set of inputs, outputs, or states for which an object is supposed to behavior similarly – Test components for each combination of the equivalence classes. (p290, example)

Perform Unit Test Structure testing or white-box testing – Verify the unit’s internal implementation – Every statement is executed at least once. – Test the most interesting paths through the code Most commonly followed paths Most critical paths The least-known paths High risk paths. (p292, Fig 10.27)

Summary of Implementation Implement subsystems including their contents, interfaces, and their dependencies Implement components: file and executable components, and their dependencies on each other Unit test components Define the architectural view of the implementation model. Implementation model is the primary input to subsequent testing activities