patterns and testing - university of warwick...patterns and testing lecture # 7 department of...

Patterns and TestingLecture # 7

Department of Computer Science and TechnologyUniversity of Bedfordshire

Written by David Goodwin,based on the lectures of Marc Conrad and Dayou Li

and on the book Applying UML and Patterns (3rd ed.)by C. Larman (2005).

Modelling and Simulation, 2012

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Outline

PatternsIntoductionResponsibilities

Knowing/DoingGood/bad design

GRASPCreatorExpertLow CouplingControllerHigh Cohesion

CRC cards

TestingpurposeStratagiesUnit TestingIntegration TestingSystem TestingTesting ProcedureLarge SoftwareManagement

Package Diagrams

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Patterns

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Introduction

I An object-oriented system is composed of objectssending messages to other objects.

I The quality of the overall design depends on whichobject is doing what.

I That is, the quality depends on how we assignresponsibilities to the objects.

I Problem: Define “good quality”.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

There are two types ofResponsibilities.

I KnowingI about private

encapsulated dataI about related objectsI about things it can

derive or calculate

I DoingI doing something itselfI initiating action in

other objectsI controlling and

coordinating activitiesin other objects

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Example: the Recycling machine -Knowing and Doing

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Example: the Recycling machine -Knowing and Doing

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Example: the Recycling machine -Knowing and Doing

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Example: the Recycling machine -Knowing and Doing

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Example: the Recycling machine -Knowing and Doing

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Example: the Recycling machine -Knowing and Doing

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Example: the Recycling machine -Knowing and Doing

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Good design/Bad design

I Consider the following alternative design of therecycling machine.

I A class responsible for printing and holding the data ofbottle and crate.

I The can class is also responsible for customer input andcomputing the sum.

I One more class doing all the rest of the tasks.

I Is this a good design?

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Good design/Bad design

I Our feeling says that the previous example is not a gooddesign.

I Is it possible to give this “feeling” a more solid, moreobjective, more traceable, and more comprehensiblefoundation?

I Answer: Yes, by using patterns.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns

I GRASP stands for General Responsibility AssignmentSoftware Patterns.

I GRASP can be used when designing interaction(sequence) diagrams and class diagrams.

I GRASP try to formalize “common sense” in objectoriented design.

I They do not usually contain “new” ideas. They try tocodify existing knowledge and principles.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

The GRASP patterns

I Creator

I Expert

I Low Coupling

I Controller

I High Cohesion

I Polymorphism

I Pure Fabrication

I Indirection

I Protected Variations

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesCREATOR: Problem

I Who should be responsible for creating a new instanceof some classes?

I The creation of objects is one of the most commonactivities in OO systems.

I It is useful to have a general principle for theassignment of responsibilities.

I Assigned well, the design can support low coupling,increased clarity, encapsulation, and resusability.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesCREATOR: Solution

I Assign class B the responisbility to creat an instance ofclass A if one of these is true:

I B aggregates A.I B contains A.I B records instances of A objects.I B closely uses A objects.I B has the initializing data that will be passed to A when

it is created.

I B is a creator of A objects

I if more than one option applied, usually chose“aggregates or contains”

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesCREATOR: Discussion

I The creation of objects is one of the most commonactivities in an object-oriented system.

I This pattern is useful to find out who should beresponsible for creating objects.

I The last point (B has initializing data of A) is actuallyan example of the Expert pattern (B is an expert withrespect to creating A).

I In an Aggregation the lifetime of the part is usually thesame as the lifetime of the whole. So the idea that thewhole creates the part is straightforward.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesCREATOR: Example

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesEXPERT: Problem

I What is a general principle of assigning responsibilitiesto objects?

I When interactions between objects are defined, wechose assignment of responsibilities to software classes.

I Chosen well, systems tend to be easier to understand,maintain and extend.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesEXPERT: Solution

I Assign a responsibility to the information expert - theclass that has the information necessary to fulfill theresponsibility.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesEXPERT: Discussion

I Expert is the basic guiding principle in object-orienteddesign.

I Expert leads to designs where a software object doesthose operations which are normally done to thereal-world thing it represents (“Do it Myself”)

I Real-world example:I When going for medical treatment - which person would

you ask for an appointment? The cleaner, thereceptionist, or the doctor?

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesEXPERT: Example

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesLOW COUPLING: Problem

I How to support low dependency, low change impact,and increased reuse?

I Coupling:I measurement of how strongly one element is connected

to, has knowledge of, or relies on another.I A class with high coupling relies on many other classes,

and may suffer from the following:

I forced local changes because of changes in relatedclasses

I harder to understand in isolationI harder to reuse because its use requires the additional

presence of the classes on which it is dependent.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesLOW COUPLING: Solution

I Assign a responsibility so that coupling remains low.Use this principle to evaluate alternatives.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesLOW COUPLING: Discussion

I Low Coupling is an evaluative pattern which a designerapplies while evaluating all design decisions.

I Coupling happens in the same forms as visibility: local,global, as a parameter, as an attribute.

I A subclass is strongly coupled to its superclass, sosubclassing needs to be considered with care!

I Low Coupling supports reuseability, so classes which areinherently very generic in nature should have especiallylow coupling.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesLOW COUPLING: Example

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesCONTROLLER: Problem

I What first object beyond the UI layer receives andcoordinates (“controls”) a system operation?

I System operations are the major input events upon oursystem.

I A controller is the first object beyond the UI layer thatis responsible for receiving or handling a systemoperation message.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesCONTROLLER: Solution

I Assign the reponsibility to a class representing one ofthe following:

I Represents the overall “system”, a “root object”, adevice that the software is running within, or a majorsubsystem

I Represents a Use Case scenario within which the systemevent occurs.

I Use the same controller class for all system events inthe same Use Case scenario

I Informally, a session is an instance of a conversationwith and Actor. Sessions can be of any length but areoften organised in terms of Use Cases.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesHIGH COHESION: Problem

I How to keep objects focused, understandable, andmanageable, and as a side effect, support low coupling?

I Cohesion is a measure of how strongly related andfocused the reponsibilities are.

I An element with highly related responsibilities that doesnot do much work is of high cohesion.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesHIGH COHESION: Solution

I Assign a responsibility so that cohesion remains high.Use this to evaluate alternatives.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesHIGH COHESION: Discussion

I Benefits:I Clarity and ease of comprehension of the design is

increased.I Maintenance and enhancements are simplified.I Low coupling is often supported.

I Rule of thumb:I A class with high cohesion has a relatively small number

of methods, with highly related functionality, and doesnot too much work.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesHIGH COHESION: Example

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

GRASP - patterns for responsibilitiesPolymorphism, Pure Fabrication,Indirection, Protected Variations

I PolymorphismI How to handle alternatives based on type?

I Pure FabricationI Who, when you are desperate?

I IndirectionI How to de-couple objects?

I Protected VariationsI To whom should messages be sent?

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

CRC cards & role playing

I Not part of the UML design process but useful indetecting responsibilities of objects are CRC cards(developed by Kent Beck and Ward Cunningham).

I CRC stands for Class-Responsibility-Collaborator. Theylook like:

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

CRC cards & role playing

I CRC cards are index cards, one for each class, uponwhich the responsibilities and collaborators of a classare written.

I They are developed in a small group session wherepeople role play being the various classes.

I Each person holds onto the CRC cards for the classesthat they are playing the role of.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Testing

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Purpose of Testing

I Purpose of testingI Finding differences between the expected behaviour

specified by models and the observed one of theimplemented system

I The differences reflect failures of a piece of softwareI Verification: Are you build the product right? (Does it

work properly?)I Validation: Are we build the right product (Does it

satisfy user’s requirement?)

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Purpose of Testing

I Causes of a failureI Failures are caused by faults, also known as bugsI An error is a human action that results in a program

containing faultsI Errors can take place at any stage of a software life cycleI Finding an error is a diagnostic progress contain

mapping from differences detected in testing to errors

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Test Stratagies

I White Box (structural) testI Every independent execution path through the code is

tested and all conditional statements are tested for trueand false statements

I Black Box (specification) testI The ‘behaviour’ of object/class is tested and test case

design should be based upon domain knowledge.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

OBJECT ORIENTED TESTING

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Unit Testing

I Aim of Unit testing

I to test objects/classes, blocks and service packagesI more complicated than unit testing in traditional

program testing, as an object contains both attributesand operation and because of inheritance andpolymorphism.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Unit Testing

I Specification testingI black box testingI equivalence partitioning: partitioning possible inputs

into several categories and set one test case for eachcategory

I State based testingI tests are performed based on the encapsulated state and

the interaction of the operations of an object

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Unit Testing

I Structural testingI white box test, also known as path testing

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Unit Testing

I Polymorphism testingI all possible bindings should be identified and tested

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Integration Testing

I Integration testingI earlier than traditional cases because objects and classes

communicate with one another.I Integration testing is any type of software testing that

seeks to verify the interfaces between componentsagainst a software design. Normally integrated in aniterative way, allows interface issues to be localised morequickly and fixed.

I Integration testing works to expose defects in theinterfaces and interaction between integratedcomponents. Progressively larger groups of testedsoftware components corresponding to elements of thearchitectural design are integrated and tested until thesoftware works as a system.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

System Testing

I System testing of software or hardware is testingconducted on a complete, integrated system to evaluatethe system’s compliance with its specified requirements.

I System testing falls within the scope of black boxtesting, and as such, should require no knowledge of theinner design of the code or logic

I Each use case is initially tested separately based onrequirement model.

I The entire system is tested as a whole after all use caseare tested.

I Testing several use case in parallel.

I Testing several use case at the same time.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Testing Procedure

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Large Software Management

I Functional decomposition - in function-orientedprogramming, a function is broken down intosub-functions and further into sub-sub-functions andsmall pieces of programs are developed to implementthese sub-sub-functions. (Note: operations and data areseparate.)

I It looks like that we can use this idea to break down ause case into sub- or even sub-sub-cases. However, theseparation of operation and data does not satisfyOOP’s theme.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Large Software Management

I Package - grouping classes together into higher-levelunits called wok package, assignment or task. (Note:operations and data are not separate in a work packageas it is a group of classes and, therefore, package iswidely used in OOP.)

I Self-contained - a work package is self-contained, thatis, the development of a work package follows the entireprocedure of waterfall model.

I Smaller work package is more manageable.

I Work packages are assigned to individuals or teams forcompletion.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Large Software Management

I Work package example

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Package Diagrams

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Package Diagrams

I A package diagram show packages and the dependencybetween packages.

I Package:

I Dependency:

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Package Diagrams

I Dependency - if changes to definition of a class in apackage A causes the changes in classes in anotherpackage B, we say that B has dependencies with A.

I On class sends message to another (return value from amethod).

I One class mentions another as a parameter (parameterof a method).

I One class has another as a part of its data (definingreference variable)

I Dependency is not transitive.

Patterns andTesting

Patterns

Intoduction

Responsibilities

Knowing/Doing

Good/bad design

GRASP

Creator

Expert

Low Coupling

Controller

High Cohesion

CRC cards

Testing

purpose

Stratagies

Unit Testing

IntegrationTesting

System Testing

Testing Procedure

Management

PackageDiagrams

Package Diagrams

I Package diagram example