Systems Analysis and Design I

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 – 6.6.2 (pp. 154 – 159); • Prototyping: Section 3.3.2 (pp. 73 – 76), Section 6.6.3 (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 7.5.5 – 7.5.10 (pp. 208 – 215), Section 7.5.2 (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 8.5.1 – 8.5.2 (pp. 252 – 253) • Adding Further Structure (to Class Diagrams) • Section 8.3.1 – 8.3.3 (pp. 237 – 244) • Section 14.4.4 (pp. 409 – 410) 3

4. Client companyAddress companyEmail companyFax companyName companyTelephone Class diagrams • Class (and Object/Instance) • Stereotypes • Attributes (and State) • Associations (and Links) • Multiplicity • Operations class name compartment attributes compartment operations compartment

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: • Boundaryobjectsmodel interaction between the system and actors (and other systems) • Controlobjectsco-ordinate and control other objects • Entity objectsrepresent 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>> Campaign Campaign title title campaignStartDate campaignStartDate campaignFinishDate campaignFinishDate Campaign getCampaignAdverts( ) getCampaignAdverts( ) addNewAdvert( ) addNewAdvert( ) Stereotypes: Entity Classes • Entity objects represent persistent data and common behaviour likely to be used in more than one application system 6

7. <<boundary>> User Interface::AddAdvertUI User Interface::AddAdvertUI startInterface( ) startInterface( ) assignStaff( ) assignStaff( ) selectClient( ) selectClient( ) selectCampaign( ) selectCampaign( ) Stereotypes: Boundary Classes package User Interface::AddAdvertUI • 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

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

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

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

11. association association role Client StaffMember companyAddress staffContact staffName companyEmail staffNo liaises with companyFax staffStartDate companyName 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

12. Association Classes An association class is joined to the corresponding association by a dashed line 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

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.

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

16. Ingredient Meal 1 1..* 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 “Owing” class 16

17. Small trick • Trick to remember the difference : • has A -- Aggregation • Own -- cOmposition

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

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

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) http://en.wikipedia.org/wiki/Universal_Serial_Bus Plug and Play 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 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

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

25. Adding Generalization Structure 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 https://en.wikipedia.org/wiki/Barbara_Liskov 26

27. ChequeAccount Account accountName accountName balance balance Restructuring to credit() satisfy LSP credit() debit() MortgageAccount MortgageAccount ChequeAccount interestRate interestRate debit() calculateInterest() calculateInterest() - debit() Liskov Substitution Principle MortgageAccount cannot be treated as if they are objects of ChequeAccount 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

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 28

29. Group project dating