CM602: Effective Systems Development Principles of Implementation Components Component and Deployment Diagrams

Learning Outcomes This week we look at general principles of implementation and the specific tools and techniques that can be used in UML for implementation This week we look at general principles of implementation and the specific tools and techniques that can be used in UML for implementation At the end you should be able to explain: At the end you should be able to explain: what’s involved in implementation and the various implementation strategies that could be adopted. what’s involved in implementation and the various implementation strategies that could be adopted. the role of components in UML the role of components in UML the role of UML component and deployment diagrams in implementation. the role of UML component and deployment diagrams in implementation.

Outline What’s involved in implementation & the various implementation strategies that could be adopted. What’s involved in implementation & the various implementation strategies that could be adopted. The role of components in UML The role of components in UML The role of UML component and deployment diagrams in implementation. The role of UML component and deployment diagrams in implementation.

Why is implementation important? Where all the analysis and design issues and ideas come together Where all the analysis and design issues and ideas come together Integrates analysis and design in code Integrates analysis and design in code Links all aspects of system together into a live environment Links all aspects of system together into a live environment

Objectives in Implementation Obtain an operational business information system Obtain an operational business information system Meet all the agreed user requirements Meet all the agreed user requirements Gain user / client acceptance Gain user / client acceptance Acceptance = > Payment Acceptance = > Payment Provide full documentation Provide full documentation Ensure appropriate support during handover Ensure appropriate support during handover Train users Train users

UML and implementation In UML the structural and behavioural aspects are represented as they are built In UML the structural and behavioural aspects are represented as they are built Specific UML techniques Specific UML techniques component diagrams component diagrams deployment diagrams deployment diagrams Other UML aspects to consider in implementation Other UML aspects to consider in implementation Software tools Software tools Coding and documentation standards Coding and documentation standards Software testing Software testing Data conversion Data conversion User training User training Strategy for implementation (changeover) Strategy for implementation (changeover)

Strategies in implementation Possible strategies to consider Possible strategies to consider Direct Direct Parallel Parallel Phased Phased Pilot Pilot Serious consideration as to which strategy to choose Serious consideration as to which strategy to choose technical technical Organisational and Human Resources Organisational and Human Resources time constraints time constraints

Direct implementation old system discontinued and new started immediately old system discontinued and new started immediately advantage advantage cheaper than other strategies cheaper than other strategies users forced to bite the bullet users forced to bite the bullet disadvantages disadvantages much pressure on testing much pressure on testing no old system to fall back on no old system to fall back on can panic users can panic users Time Old System New System

Parallel implementation old and new operated concurrently for a period of time old and new operated concurrently for a period of time advantages advantages safe safe old system to fall back on old system to fall back on users less traumatised users less traumatised disadvantages disadvantages expensive expensive stretch personnel resources stretch personnel resources users slow to adopt new system users slow to adopt new system Time Old System New System

Phased implementation new system introduced a module at a time, usually by logical grouping new system introduced a module at a time, usually by logical grouping old system is run for all but the new module old system is run for all but the new module advantages advantages divide and conquer divide and conquer users gain confidence users gain confidence disadvantages disadvantages build interfaces between old and new modules build interfaces between old and new modules old system might not be group in modules old system might not be group in modules Time Old System New System modules, old system decreases

Pilot implementation similar to Phased similar to Phased implementation may be undertaken in one location or geographic site implementation may be undertaken in one location or geographic site Time Old System New System modules, old system decreases

Use of implementation contracts performance goals performance goals tolerances tolerances estimated information system life estimated information system life maintenance expectations maintenance expectations future changes future changes

Moving to acceptance plan maintenance and support of new system plan maintenance and support of new system plan training plan training creation of Service Level Agreement creation of Service Level Agreement ensure all documentation is complete ensure all documentation is complete produce details for disaster recovery plan produce details for disaster recovery plan agree what isn’t to be fixed agree what isn’t to be fixed final acceptance meeting final acceptance meeting

Review – The System Cost/benefit analysis Cost/benefit analysis Has it delivered? Has it delivered? Tangible, intangible Tangible, intangible Are functional & non-functional requirements met? Are functional & non-functional requirements met? Are users satisfied with the system? Are users satisfied with the system? Problems, software and other Problems, software and other Change/enhancement requests & plans Change/enhancement requests & plans

Review - The Project / Process Lessons learned Lessons learned Were targets met? Were targets met? Were estimates accurate? Were estimates accurate? Metrics – record actual experience to help future estimating Metrics – record actual experience to help future estimating

Activity 1: Problems? What can go wrong during implementation? What can go wrong during implementation? When would you plan a post- implementation review, and why? Give some examples to support your answer. When would you plan a post- implementation review, and why? Give some examples to support your answer.

What can go wrong during implementation? databases become unreliable databases become unreliable programs go live with operational errors programs go live with operational errors user resistance user resistance avoidance avoidance hostility hostility sabotage sabotage users find system too complex users find system too complex all user requirements not met all user requirements not met hardware doesn’t perform as specified hardware doesn’t perform as specified user training is insufficient user training is insufficient

When would you plan a post- implementation review? Start planning early! Certainly before implementation. Start planning early! Certainly before implementation. You may need to collect comparative data. You may need to collect comparative data. You will need to secure involvement of users etc. You will need to secure involvement of users etc. For example, For example, Time savings – how long did it take before? Time savings – how long did it take before? Costs – do you have accurate costs for comparison? Costs – do you have accurate costs for comparison? Response improvements – what was response time before? Response improvements – what was response time before?

Outline What’s involved in implementation & the various implementation strategies that could be adopted. What’s involved in implementation & the various implementation strategies that could be adopted. The role of components in UML The role of components in UML The role of UML component and deployment diagrams in implementation. The role of UML component and deployment diagrams in implementation.

Components In general, a piece of software with defined interfaces. In general, a piece of software with defined interfaces. Internals are hidden Internals are hidden Components are (potentially) reusable and replaceable Components are (potentially) reusable and replaceable Growing market in component software Growing market in component software Component-driven development increasingly popular Component-driven development increasingly popular

Components in UML In UML1, components were strictly physical – units of implementation. In UML1, components were strictly physical – units of implementation. In UML 2, they represent a logical unit, and the concept of an artifact now represents physical units such as packages of code. In UML 2, they represent a logical unit, and the concept of an artifact now represents physical units such as packages of code. In most non-UML contexts, the physical view predominates. In most non-UML contexts, the physical view predominates.

Component – a UML 2 definition. “A modular part of a system design that hides its implementation behind a set of external interfaces. Within a system, components satisfying the same interfaces may be substituted freely.” “A modular part of a system design that hides its implementation behind a set of external interfaces. Within a system, components satisfying the same interfaces may be substituted freely.” Rumbaugh et al. (2005)

Outline What’s involved in implementation & the various implementation strategies that could be adopted. What’s involved in implementation & the various implementation strategies that could be adopted. The role of components in UML The role of components in UML The role of UML component and deployment diagrams in implementation. The role of UML component and deployment diagrams in implementation.

Implementation and UML Component diagrams Component diagrams show dependencies between software components in system show dependencies between software components in system can make use of stereotypes to show dependencies that are specific to particular languages can make use of stereotypes to show dependencies that are specific to particular languages can show internal structure of components can show internal structure of components Deployment diagrams Deployment diagrams used to show the configuration of run-time processing elements and the software artifacts that are located on them used to show the configuration of run-time processing elements and the software artifacts that are located on them

Component Diagram Required interfaceProvided interface

Notation of Component Diagrams Component with ports Component with ports Indicates that the component delegates responsibility for the behaviour of that interface to a subcomponent Indicates that the component delegates responsibility for the behaviour of that interface to a subcomponent Spooler PrinterDriver Spooling Spooler PrinterDriver Spooling © Bennett, McRobb and Farmer 2005

Component with ports Component with ports Shows delegated responsibility Shows delegated responsibility Notation of Component Diagrams Spooler :PrintManager :File PrinterDriver Spooling Print Spooling Printing «delegate» Spooler :PrintManager :File PrinterDriver Spooling Print Spooling Printing «delegate» © Bennett, McRobb and Farmer 2005

Notation of Deployment Diagrams Nodes Nodes rectangular prisms rectangular prisms represent processors, devices or other resources represent processors, devices or other resources Communication Associations Communication Associations lines between nodes lines between nodes represent communication between nodes represent communication between nodes can be stereotyped can be stereotyped Artifacts Artifacts

Notation of Deployment Diagrams swift:PCaardvark:DECAlpha «TCP/IP» © Bennett, McRobb and Farmer 2005

Artifacts Actual real world elements of the system Actual real world elements of the system Software, databases, files, web pages… Software, databases, files, web pages… Represented with «artifact» or Represented with «artifact» or Can manifest components Can manifest components HR.jar «manifest» Human Resources

Deployment Diagram PC Client « RMI » Server AgateServer.jarAgateClient.jar « RMI » © Bennett, McRobb and Farmer 2005

Notation of Deployment Diagrams Nodes can be stereotyped Nodes can be stereotyped Execution environments represent application containers Execution environments represent application containers Deployment specifications describe the configuration of artefacts Deployment specifications describe the configuration of artefacts © Bennett, McRobb and Farmer 2005 «device» :AppServer «executionenv» :J2EEContainer AgateServer.war «deploymentspec» serverconfig.xml «device» :AppServer «executionenv» :J2EEContainer AgateServer.war «deploymentspec» serverconfig.xml

Activity 2 A Human Resource System uses artifacts as shown. Draw a deployment diagram. A Human Resource System uses artifacts as shown. Draw a deployment diagram. Communication with the database is via JDBC, so HR.jar needs to use jdbc.jar – show a dependency. Communication with the database is via JDBC, so HR.jar needs to use jdbc.jar – show a dependency. PC Client DB server HR.jar JDBC.jar HR database

Activity 2 © Bennett, McRobb and Farmer 2005 PC Client Database Server HR.jar « JDBC » jdbc.jar HRDB

Summary Strategies for implementation Strategies for implementation Implementation considerations & tasks Implementation considerations & tasks Review Review UML support for implementation UML support for implementation Component Diagrams Component Diagrams Deployment Diagrams Deployment Diagrams

Reading Bennett et al. (2005), Chapter 19. Bennett et al. (2005), Chapter 19. (Or 2002 edn. for UML 1.4.) (Or 2002 edn. for UML 1.4.) Covers implementation tasks, strategies, diagrams Covers implementation tasks, strategies, diagrams

References Bennett, S., McRobb, S. & Farmer, R. (2005), Object-Oriented Systems Analysis and Design using UML, 3 rd edn., McGraw- Hill. Bennett, S., McRobb, S. & Farmer, R. (2005), Object-Oriented Systems Analysis and Design using UML, 3 rd edn., McGraw- Hill. Rumbaugh, J., Jacobson, I. & Booch, G. (2005), The Unified Modelling Language Reference Manual, 2 nd edn., Addison- Wesley. Rumbaugh, J., Jacobson, I. & Booch, G. (2005), The Unified Modelling Language Reference Manual, 2 nd edn., Addison- Wesley.