1. Systems Analysis and Design I
Session 5
Refining the Requirements Model

2. Recap Requirements Model → Analysis Model → Design Model
Requirement models: Use Case
Use Case Modelling: Section 6.6 – (pp. 154 – 159);
Prototyping: Section (pp. 73 – 76), Section (pp. 159 – 161)
Analysis class models
Aim to produce a set of classes to meet requirements of a use case
Class Diagrams: Section 7.3 (pp. 184 – 194), Section – (pp – 215), Section (pp. 198 – 201)

3. Today
Further discussion of class diagrams (Section 7.5.2, pp 198 – 201)
Software and Specification Reuse
Section 20.2 (pp. 585 – 586)
Section 8.2 (pp. 234 – 237)
Section 8.4 (pp. 246 – 247)
Section – (pp. 252 – 253)
Adding Further Structure (to Class Diagrams)
Section – (pp. 237 – 244)
Section (pp. 409 – 410)
In this lecture you will learn … 3 3

4. Class diagrams class name compartment attributes compartment
Class (and Object/Instance)
Stereotypes
Attributes (and State)
Associations (and Links)
Multiplicity
Operations
Client
companyAddress
company
companyFax
companyName
companyTelephone
class name compartment
attributes compartment
Only staff members in the role of staff contact can participate in this association
operations compartment 4

5. Class Stereotypes
Class stereotypes represent particular kinds of class that will be encountered again and again
Everyday use of “stereotype” is not so very different
They differentiate the roles objects can play:
Boundary objects model interaction between the system and actors (and other systems)
Control objects co-ordinate and control other objects
Entity objects represent information and behaviour in the application domain
Entity classes may be imported from domain model
Boundary and control classes are more likely to be unique to one application

6. <<entity>>
Stereotypes: Entity Classes
Campaign
title
campaignStartDate
campaignFinishDate
getCampaignAdverts( )
addNewAdvert( )
<<entity>>
Campaign
title
campaignStartDate
campaignFinishDate
getCampaignAdverts( )
addNewAdvert( )
Campaign
Entity objects represent persistent data and common behaviour likely to be used in more than one application system 6 6

7. Stereotypes: Boundary Classes
package
User Interface::AddAdvertUI
startInterface( )
assignStaff( )
selectClient( )
selectCampaign( )
<<boundary>>
User Interface::AddAdvertUI
startInterface( )
assignStaff( )
selectClient( )
selectCampaign( )
User Interface::AddAdvertUI
package
Boundary objects model interaction between the system and actors (and other systems), e.g., user interface
likely to be unique to the use case but inherited from a library
The main task is to manage the transfer of information across system boundaries 7 7

8. <<control>>
Stereotypes: Control Classes
Control::AddAdvert
showClientCampaigns( )
showCampaignAdverts( )
createNewAdvert( )
<<control>>
Control::AddAdvert
showClientCampaigns( )
showCampaignAdverts( )
createNewAdvert( )
AddAvert
Control classes
encapsulate unique behaviour of a use case
Specific logic kept separate from the common behaviour of entity classes 8 8

9. Boundary, control and entity together
Advert
setCompleted()
createNewAdvert()
«entity»
User Interface::AddAdvertUI
startInterface()
selectClient()
selectCampaign()
«boundary»
Campaign
title
campaignStartDate
campaignFinishDate
getCampaignAdverts()
addNewAdvert() 1
0..*
conducted by
Client
companyAddress
companyName
companyTelephone
companyFax
company
getClientCampaigns()
getClients()
places
Control::AddAdvert
showClientCampaigns()
showCampaignAdverts()
«control»

10. Recall: association
An association is a relationship of some kind between two classes.
We may prefer to represent some relationships as classes.
If an association is something we need to describe in terms of further characteristics
if it is apparent that it has attributes of its own, modelled as a class
If it only has meaning as a relationship, leave it as an association 10 10

11. direction in which name should be read (optional)
association
association role
Client
StaffMember
companyAddress
staffContact
staffName
company
staffNo
liaises with
companyFax
staffStartDate
companyName
Only staff members in the role of staff contact can participate in this association
companyTelephone
association name
direction in which name should be read (optional)
Only staff members in the role of staffContact can participate in this association 11 11

12. Association Classes
An association class is joined to the corresponding association by a dashed line 12 12

13. Aggregation and Composition
Two special types of association
Aggregation represents a whole-part relationship between classes
Composition (or Composition aggregation) is based on the concept of aggregation
Composition expresses a similar relationship but differs in showing a stronger form of ownership by the whole
Each part may belong to only one whole at a time.
When the whole is destroyed, so are all its parts. 13 13

14. Composition vs aggregation
In both aggregation and composition object of one class "owns" object of another class.
But there is a subtle difference.
In Composition the object of class that is owned by the object of it's owning class cannot live on it's own
Also called "death relationship".
It will always live as a part of it's owning object
In Aggregation the dependent object is standalone and can exist even if the object of the owning class is dead.
So in composition if owning object is garbage collected the owned object will also be which is not the case in aggregation.
Confused?
Composition Example : Consider example of a Car and an engine that is very specific to that car (meaning it cannot be used in any other car). This type of relation ship between Car and SpecificEngine class is called Composition. Object of Car class cannot exist without object of SpecificEngine class and object of SpecificEngine has no significance without Car class. To put in simple words Car class solely "owns" the SpecificEngine class.
Aggregation Example : Now consider class Car and class Wheel. Car needs a Wheel object to function. Meaning Car object own Wheel object but we cannot say Wheel object has no significance without Car Object. It can very well be used in a Bike, Truck or different Cars Object.
Aggregation and Composition are subsets of association meaning they are specific cases of association.

15. unfilled diamond denotes aggregation
Notation: Aggregation
A student could be in a number of modules
If a module is cancelled, students are not destroyed
Module
Student
0..*
1..*
unfilled diamond denotes aggregation
“Owing” class 15 15

16. filled diamond denotes composition
Notation: Composition
An ingredient is in only one meal at a time
If you drop your meal on the floor, you probably lose the ingredients too
Meal
Ingredient
1..* 1
filled diamond denotes composition
“Owing” class 16 16

17. Small trick Trick to remember the difference : has A -- Aggregation
Own -- cOmposition
So in composition if owning object is garbage collected the owned object will also be which is not the case in aggregation.
Confused?
Composition Example : Consider example of a Car and an engine that is very specific to that car (meaning it cannot be used in any other car). This type of relation ship between Car and SpecificEngine class is called Composition. Object of Car class cannot exist without object of SpecificEngine class and object of SpecificEngine has no significance without Car class. To put in simple words Car class solely "owns" the SpecificEngine class.
Aggregation Example : Now consider class Car and class Wheel. Car needs a Wheel object to function. Meaning Car object own Wheel object but we cannot say Wheel object has no significance without Car Object. It can very well be used in a Bike, Truck or different Cars Object.

19. Why Reuse?
We now aim to refine and add further structure to the analysis model
The arguments for reuse are
partly economic
saving time and effort in software development including software testing and quality assurance
partly concerned with quality
fewer defects
partly about business flexibility
faster time to market 19 19

20. How O-O Contributes to Reuse
Inheritance and Encapsulation
Two main forms of abstraction that O-O relies on to achieve reuse
Components
Patterns
next year, Software Engineering I and Systems Analysis and Design II ;-) 20 20

21. Reuse: Encapsulation
allows one class or component to be replaced by another with different internal details, as long as they adhere to the same external interface
thus classes or components can be used in systems for which they were not originally designed
a group of classes can be encapsulated through aggregation or composition to become a reusable subassembly (i.e., an independent module)
Universal Serial Bus (USB)
Plug and Play 21 21

22. Reuse: Generalisation and Inheritance
encourages identifying those aspects of a design or specification that has general application to a variety of situations or problems
allows the creation of new specialised classes when needed, with little effort
“Do not reinvent the wheel!”
same circular form and central shaft
To reinvent the wheel is to duplicate a basic method that has already previously been created or optimized by others 22 22

23. Reuse: Components
A software component is a package or module that provides services to other components or systems.
Reusable component is one that has been designed for use in more than one context
For example, a house (bricks, tiles, doors, windows, pipes, etc.), a home theatre (a big screen TV, a DVD player, a decoder, an amplifier, speakers, etc.), …
Traditional, software development has concentrated on inventing new solutions.
Recently, the emphasis has shifted.
Much software is now assembled from components that already exist.
So called component-based development or CBSE. 23 23

24. Adding Generalisation Structure
A generalisation structure can be added when
two classes are similar in most respects,
but differ in some details such as
behaviour (operations or methods)
data (attributes)
associations with other classes 24 24

25. Adding Generalization Structure
Figure 8.2 25 25

26. Liskov Substitution Principle
A criterion of formulating inheritance hierarchies
In object interactions, it should be possible to treat a derived object as if it were a base object without integrity problems.
If the principle is not applied, then it may be possible to violate the integrity of the derived object.
Prof. Barbara Liskov
2009 A. M. Turing Award winner 26 26

27. Liskov Substitution Principle
ChequeAccount
accountName
balance
credit()
debit()
MortgageAccount
interestRate
calculateInterest() -
Restructuring to
satisfy LSP
Account
accountName
balance
credit()
ChequeAccount
debit()
MortgageAccount
interestRate
calculateInterest()
MortgageAccount cannot be treated as if they are objects of ChequeAccount
debit() is declared private and cannot be used by any other object
debit() is declared private and cannot be used by any other object
Disinheritance of debit() means that
the left-hand hierarchy is not Liskov compliant 27 27

28. Take Home Messages Software and Specification Reuse
Why Reuse
How O-O Contributes to Reuse
Adding Further Structure (to Class Diagrams)
Generalisation/Specialisation
Liskov Substitution Principle
Aggregation and Composition
In this lecture you have learned about … 28 28

29. Group project dating