patterns and testing - university of warwick...patterns and testing lecture # 7 department of...
TRANSCRIPT
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