Systems Analysis and Design I Session 5 Refining the Requirements Model

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)

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) In this lecture you will learn … 3 3

Class diagrams class name compartment attributes compartment Class (and Object/Instance) Stereotypes Attributes (and State) Associations (and Links) Multiplicity Operations Client companyAddress companyEmail 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

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

<<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

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

<<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

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 companyEmail getClientCampaigns() getClients() places Control::AddAdvert showClientCampaigns() showCampaignAdverts() «control»

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

direction in which name should be read (optional) association association role Client StaffMember companyAddress staffContact staffName companyEmail 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

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

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

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.

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

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

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.

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

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

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 21

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

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

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

Adding Generalization Structure Figure 8.2 25 25

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. https://en.wikipedia.org/wiki/Barbara_Liskov Prof. Barbara Liskov 2009 A. M. Turing Award winner https://en.wikipedia.org/wiki/Barbara_Liskov 26 26

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

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

Group project dating