Implementation Diagrams

1
Implementation Diagrams Evaluation

• Outline the role of
• Component Diagrams
• Deployment Diagrams
• Package Diagrams
• Outline evaluate Rational Unified Process
• Discuss whether UML meets its goals

2
Summary

• Implementation Diagrams
• Diagrams supporting
• Model structuring
• Interaction of components
• Physical architecture and location of software
• A UML-based development process
• Rational Unified Process
• Does UML achieve its goals
• General purpose
• Supports good practice
• Simple but powerful

3
Implementation Diagrams

• Component diagrams
• structural relationships between system
  components
• UML 1.4 files executables - physical divisions
• UML 2 pluggable/replaceable modules
• Deployment diagrams
• Describe the physical architecture of the
  application.
• Nodes usually represent hardware platforms.
• Package diagrams
• Group model items into logical modules
• Show high-level relationships between packages.

4
Component Diagrams in UML 2

• components are
• Encapsulated units providing one or more
  interfaces.
• Modular building blocks plug interfaces to
  sockets
• Can have internal structure classes,
  sub-components
• Provide an architectural view
• Can sub-contract or buy components
• An AI component built from other components

interface
socket
5
Component Diagrams in UML 1.4

• Components model physical things such as
• executables, libraries, tables, files and
  documents
• Components are rectangles with two tabs
• Dependencies are dashed dependency arrows.
• Components and dependencies may be classified
• Use stereotypes such as ltltexecutablegtgt and
  ltltlinkgtgt
• A component diagram of compile-time dependencies

6
Deployment Diagrams

• The deployment diagram shows
• The physical communication links between hardware
  items (machines and other resources such as
  printers).
• The relationships between physical machines and
  processes.
• A physical system is made of nodes with links
• Nodes represent physical things and may have a
  type
• e.g. Workstation, Server, printer
• A node is represented as a box.
• Links represent physical connections
• e.g cables, LANs, phone lines etc.
• Represented by unbroken lines
• A link can be given a name and a stereotype
  defining its type

7
Example Deployment Diagram

• A deployment diagram with the software

8
Package Diagrams

• Logical organisation of model/diagram items
• Organise collections of model elements.
• Every part of a model must belong to a package.
• Elements in a package must be logically related
• common functionality or tightly-coupled
  implementation.
• The root package indirectly contains the full
  model

9
Example Package Diagram

• Package are rectangles with a tab on the top edge
• Dependencies are broken arrows.

10
UML and development

• What should a methodology provide?
• Notation
• Development Process
• Lifecycle
• Deliverables
• Heuristics
• Hints tips
• Rules of good style
• Recommendations

11
Rational Unified Process

• A process to achieve a goal which defines
• Roles
• Tasks
• Sequencing (workflow)
• Checks.
• RUP can be modified to suit the organization.

12
Practices

• Develop iteratively
• Regular releases of executables
• Model visually (UML)
• Manage requirements
• Use cases/stories are continuously discovered,
  refined, and managed during the project, and
  drive unit and systems test
• Control changes
• Change is good if it reduces the risks to success
• Continuously verify quality
• Continuously test to measure progress, using use
  cases/stories
• Use component-based architectures
• Validate the essential architecture early to
  reduce technical risks

13
Drivers

• Use Case Driven to support
• Creation and validation of the systems
  architecture
• Definition of test cases and procedures
• Planning of iterations
• Creation of user documentation
• Deployment of system
• Architecture Driven
• Design architecture early
• Structure
• High-level design
• Should be robust
• able to adapt to requirements changes

14
Iterative

• An iteration
• A sequence of activities with an established plan
  and evaluation criteria, resulting in an
  executable release
• Claimed advantages over the waterfall process
• Risks are managed earlier
• Change is more manageable
• Higher level of reuse
• The project team can learn along the way
• Better overall quality

15
Lifecycle phases

• Inception
• Define the scope of the project develop the
  business case.
• Milestone Vision
• Elaboration
• Plan project, specify features, define the basic
  architecture
• Milestone Baseline Architecture
• Construction
• Build the product
• Milestone Initial Capability
• Transition
• Transition the product to its users
• Milestone Product Release

16
Workflow

• A sequence of activities producing a valuable
  result.
• Six core "engineering" workflows
• Business modelling workflow
• Requirements workflow
• Analysis Design workflow
• Implementation workflow
• Test workflow
• Deployment workflow
• 3 core "supporting" workflows
• Project Management workflow
• Configuration and Change Management workflow
• Environment workflow

17
Effort in core workflows over time

• Testing fluctuates with iterations.

18
1. Inception

• Activities
• Delimit the project scope.
• Identify all relevant external entities (actors)
• Identify all use cases and describe significant
  ones.
• Make the business case
• Success criteria (revenue estimates, market
  recognition)
• Risk assessment,
• Estimated resources
• Phase plan of major milestones

19
1. Inception Outcomes

• Vision document
• Core requirements
• Key features,
• Main constraints.
• Initial use-case model (10-20 complete).
• Initial project glossary
• Business case
• Prototypes.

20
1. Inception Evaluation criteria

• Stakeholder agreement
• Scope
• Cost/schedule estimates.
• Understanding of requirements
• primary use cases
• Credibility of the business case.
• Viability of any architectural prototype
• Actual expenditures against planned

21
2. Elaboration

• Activities
• Analyse the problem domain
• Establish a sound architecture
• Develop the project plan
• Eliminate the highest risk elements of the
  project.
• Find functional non-functional requirements
• performance, etc.
• Build an executable architecture prototype
  addressing
• Critical use cases
• Key technical risks.

22
2. Elaboration Outcomes

• Use-case model
• Identify all use cases and actors
• Describe most use-cases.
• Requirements.
• Software architecture description / Prototype
• Revised documents
• Risk list
• Business case
• Development case specifying the process to be
  used
• Development plan
• iterations and evaluation criteria.
• Preliminary user manual.

23
2. Elaboration Evaluation Criteria

• Are vision and architecture stable and
  achievable?
• Have major risk elements been credibly resolved?
• Is the plan sufficiently
• Detailed
• Accurate
• Credible?
• Is actual against planned expenditure acceptable?

24
3. Construction

• Activities
• Develop remaining components and features
• Test
• Manage resources to optimise costs, and quality.
• Outcomes
• The software product integrated on the adequate
  platforms.
• The user manuals.
• A description of the current release.

25
3. Construction Evaluation criteria

• Is this release stable and useful enough to be
  deployed?
• Are all stakeholders ready for the deployment?
• Are the actual versus planned expenditures still
  acceptable?
• Has a useful subset been finished to an
  acceptable quality level?
• Is appropriate user support available?

26
4. Transition

• Activities
• Support the users
• Correct problems
• Finish postponed features
• Respond to user feedback and small suggestions
• "Beta testing" to check the system against user
  expectations
• Operate in parallel with the old system
• Convert operational databases
• Train users and maintainers
• Release the product to the marketing,
  distribution, sales
• Decide if the objectives met, or need another
  development cycle.
• Evaluation criteria
• Is the user satisfied?
• Are the actual against planned expenditures
  acceptable?

27
Does UML achieve its goals

• UML is a general-purpose modelling language
• Non-proprietary
• Based on common agreement by computing community
• Support good practice
• Encapsulation, modularity, reusability
• Management of model as well as product
• Lifecycle support
• Current development issues
• large-scale distributed systems, concurrency,
  team development

28
Does UML achieve its goals?

• Not a complete development method
• No step-by-step development process
• UML and the process for using UML are separate
• Intended to support most existing development
  methods
• A simple but powerful notation
• Expressive enough to handle all the concepts that
  arise in a modern system
• Must be a universal language - therefore not
  small
• More complicated because more comprehensive