Package design and the Iterative process model

1
Package design and the Iterative process model
2
What is a package?

• Classes are not sufficient to group code
• Some classes collaborate, implying dependencies
• Some don't know each other
• A package is a group of classes
• Classes in a package are often compiled together
  into a library, but unit of compilation is mostly
  individualclass
• A package is a unit for testing
• A package can be a releasable component

3
Package dependencies

• GUI depends on AbsUI
• Associations exist between classesin GUI and
  AbsUI
• ServerStuff realises AbsUI,it is a concrete
  package
• An inheritance relationship existsbetween
  classes in AbsUI and ServerStuff

4
Package Design Principles

• Reuse-Release Equivalency Principle (REP)
• Common Closure Principle (CCP)
• Common Reuse Principle (CRP)

5
Reuse-Release Equivalency Principle (REP)

• The unit of reuse is the unit of release
• It is about reusing software
• Reusable software is external software you use
  it but somebody else maintains it.
• There is no difference between commercial and
  non-commercial external software for reuse.

6
REP Expectations on external software

• Documentation
• complete, accurate, up-to-date
• Maintenance
• bugs will be fixed, enhancements will be
  considered
• Reliability
• no major bugs
• no sudden changes
• can stay with proven versions (for a while)

7
Release Control Requirements for reusable
software

• Put reusable components into a package
• Track versions of the package
• Assign release numbers to stable releases
• Stable releases need release notes
• Allow users to use older releases for a while

8
REP Summary

• Group components (classes) for re-users
• Single classes are usually not reusable
• Several collaborating classes make up a package
• Classes in a package should form a reusable and
  releasable module
• Module provides coherent functionality
• Dependencies on other packages controlled
• Requirements on other packages specified
• Reduces work for the re-user

9
Common Closure Principle(CCP)

• Classes which change together belong together
• Minimise the impact of change for the programmer.
• When a change is needed, it is good for the
  programmer if the change affects as few packages
  as possible, because of compile and link time and
  revalidation.
• Classes should be open for extension, but closed
  for modification (This is an ideal)
• Classes will be designed for likely kinds of
  changes

10
Cohesion of closure for packages

• Classes in a package should be closed to thesame
  kinds of changes
• Change should be confined to a few packages
• Reduces frequency of release of packages
• Package closed for anticipated changes
• Confines changes to a few packages.
• Reduces package release frequency.
• Reduces work for the programmer.

11
Common Reuse Principle (CRP)

• Classes in packages should be reused together
• Packages should be focused, users should use all
  classes from a package
• Use of a package brings in all its dependencies
• When a user is only interested in a few classes
  of a package the user code still depends on all
  dependencies of the package.
• user code must be recompiled/relinked and
  retested after a new release of the package, even
  if the used classes didn't change.

12
CRP Summary

• Group classes according to common reuse
• avoid unnecessary dependencies for users
• Following the CRP often leads to
  splittingpackages
• Get more, smaller and more focused
  packagesReduces work for the re-user

13
The Iterative Software Process Model
Define Increments to Address the Highest Risks
first
Plan and Develop the Increment
Initial Risks, Initial Project Scope
Assess the Increment
Revise Project Plan
Risk Mitigation Plan Initiated and Implemented
Revise Risk Assessment and Mitigation Plans
14
UML

• UML is the Unified Modelling Language
• Note it is a language or notation NOT A
  METHODOLOGY OR PROCESS MODEL!
• The purpose of modelling is to
• Assist the project team to visualise the system
  as it is / is intended to be.
• Assist in specifying the systems structure or
  behaviour
• Provide a template which guides in constructing
  the system.
• Document the decisions that the project
  development team has made.

15
UML and 41 view

• This involves 5 different views
• The Use case view
• The Logical view
• The Implementation view
• The Process view and
• The Deployment view.

16
Use case view

• Describes the functionality the system should
  deliver as perceived by the external actors and
  the requirements of the system.
• Intended for
• Analysts, designers, developers and testers.
• Drives the development of other views.
• Technology neutral
• Focusses on the what, not the how.

17
Logical View

• Describes how the system functionality is
  provided
• Intended for
• Designers and developers
• Looks inside the system
• Describes the static structure
• Classes, objects, relationships
• Describes dynamic collaborations that occur when
  objects send messages in response to an event.

18
Implementation View

• Describes implementation modules and their
  dependencies.
• Modules can provide for crosschecks back to other
  deliverables.
• Ensure that requirements are actualised into
  code.
• Intended for developers.

19
Process View

• Also called the concurrency view.
• Describes the division of the system into
  processes and processors.
• This allows for efficient resource usage,
  parallel execution and the handling of
  asynchronous events.
• Intended for developers and integrators.
• Consists of dynamic diagrams state, sequence,
  collaboration, activity, component and deployment
  diagrams.

20
Deployment view

• Describes the physical deployment of the system
  via the component and deployment diagrams.
• Intended for developers, integrators and testers