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 individual class A package is a unit for testing A package can be a releasable component

3. Package dependencies GUI depends on AbsUI Associations exist between classes in GUI and AbsUI ServerStuff realises AbsUI, it is a concrete package An inheritance relationship exists between 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 the same 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 splitting packages Get more, smaller and more focused packages Reduces work for the re-user

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

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 system’s 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 4+1 view This involves 5 different views: –The Use case view –The Logical view –The Implementation view –The Process view and –The Deployment view. Logical View Implementation View Deployment View Process View Use Case 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