1. Requirements Analysis Instructor: Roozbeh Mehrabadi Based on notes by P.J. Davies Object Oriented Analysis: 1.Object Identification (physical) 2.Object Interactions (Behaviours) 3.Collaboration (Seq./Comm) Diagrams Class Diagrams 1.Class Identification 2.Class Relationships

2. Transactions occur whenever one or more objects interact or collaborate e.g. when one object sends a message to another. The result of such a collaboration of objects is sometimes another object, i.e. a transaction object, encapsulating the results of that collaboration. Transaction objects frequently only exist for the duration of the collaboration, i.e. they are like arguments passed between functions in C/C++, they are created purely for the purpose of passing data between objects and then they cease, but the information that hold means that we should create a class to represent that object Object Classification: Identify Transaction Objects 2

3. Object1Object2InteractionTransaction Object & Details Button Elevator controllerRequest Transport Floor Request Object - Floor Number - Request type (up/down) - Source (inside or outside) SensorData SystemGenerate SampleTemperature Sample Object - Temperature reading - Date and time WomanManMarriageMarriage Details Object - Wedding date - Name and occupation of bride and grooms parents - Wedding location - Prenuptial agreement - Witnesses - etc (fill in your own details) StudentInstructorAssessmentAssessment Result Object - Student ID - Mark - Pass/Fail Status CustomerGas PumpGas requestPurchase - Credit card details - Quantity of fuel - Value in $'s Sample Object Collaboration and Resultant Transaction Objects 3

4. Object Classification: Identify Physical Objects Real-time systems sensors and actuators: A/D converters: sample data from sensors Digital I/O ports: control single bit (switches, relays) Push Buttons Relays They could be modeled with SW objects Other objects can use these to interact with the physical devices (the objects act as device drivers). 4 Application Interface Object Initialise() Calibrate() GetSample() Application Software Objects Real World Sensor A/D Converter Real World Physical Objects

5. From Structural Modeling to Object and Class diagrams Structural Models entail: 1.The objects from which our system will be composed 2.The role and responsibilities that each objects assumes 3.The collaborations between objects, i.e. which objects communicate with other to implement a use-case. 4.The relationships between objects 5.The classes that implement the objects 6.The number of objects involved in the relationship (multiplicities) The first 3 are captured on an object interaction diagram The 2 nd set are captured on a class diagram. 5

6. 6 Gas Station Simulation Question: How does it work? Could you explain how a customer obtains their gas? What objects are involved in this process? All these questions are answered with an object interaction diagram

7. UML: Object Interaction Diagrams Object collaboration through message passing is captured on: Sequence Diagrams Communication Diagrams We need at least one type to document object interactions for each use-case. Complex use-cases may require a hierarchy of diagrams (each showing more details as we descend it) Interaction diagrams, capture the implementation of a use-case as a set of objects, collaborating through a process of message passing. 7

8. 8 Gas Station Simulation communication diagram (minus messages). It shows the objects involved and which objects collaborate using messaging. Communication Diagrams Document message passing (without the timing constraints) Object layout, makes identifying object relationships easier Note: in the architecture diagram, objects and their interactions are shown, what is missing?

9. Sequence Diagrams Document message passing between objects which are plotted as a function of time. The collaborating objects are laid out on a horizontal line (difficult to observe object collaboration) We can identify the components, but the structure and relationship between the objects is hard to identify. They contain: At least one actor representing the user initiating the use- case. A set of objects which were identified using various techniques A set of messages propagating between those objects which might also include message arguments and returned data. 9

10. Interaction Diagrams: Analysis vs. Design stage Analysis: capture the essence of the users interactions with the system (use- cases and scenarios) Actual people Business processes and logic Useful to the customer and meaningful for the domain experts Design: model the implementation of the SW replace form T4A with a GUI Librarian Database and a barcode scanner 10

11. Actors initiates 1 st message Object sending message to self Object lifeline showing Objects involved in Interaction and their life duration Message 6 sent from one object to another in response to message 4 User sending message to Object Time Message 4 may lead to 5 & 6 Simple Analysis Model sequence diagram describing the Driving of a Car Comment s 'Bar' shows the duration for which a thread executes within the object (advanced modelling technique) Note: ALL messages contains verbs in their name as they ask an object to do something

12. Object Class Identification and Message Arguments Objects may include their class name if this is known Messages may have arguments and a return type 12 Object name = Shiftys Class name = BMWGarage Message Parameter Name = theCar Message Parameter Type = BMWGarage Message return data = theCar whose type is BMW

13. Example: Analysis Model Draw an analysis model sequence diagram to show how a customer Borrows a book from a library –Real world objects and messages. Now refine the diagram to show design aspects. 13

14. Use Case Example: 14 Use-Case: Borrow Book The member identifies himself or herself to the librarian using their membership card. The member presents one or more books to the Librarian. The Librarian checks the books to make sure they can be loaned. The Librarian checks the membership card to make sure it is valid. The Librarian looks up the members records in his/her card indexing system and checks that the number of loaned books will be less than 6, (the maximum that can be loaned at any time to a library member). If acceptable, each book is then stamped with the appropriate return date (2 weeks from today). Each book has its identifying card removed from the inside cover. The Librarian updates the members loan details by placing the identifying cards into that members record maintained by the library. End

15. Decisions and Iterations on a Sequence Diagram First Notice: SD is not a replacement for a flowchart. On occasions where modeling loops and decisions is useful, use the following: –Text or Pseudo code annotated onto the diagram (usually in the left hand field) –Placing stick-it notes over the diagram to point out key decisions or repetition –Enclosing sequences into a frame and showing the specific circumstances under which they will be executed. 15

16. Using Stick-it notes plus anchors to the messages 16

17. Using Frames

18. Q1: Which frame operator is used in UML to show mutual exclusive logic? A.Opt (Optional) B.Alt (Alternative) C.Loop D.Region (Critical Region) 18

19. UML: Some Common Frame Operator Meaning 19 OptOptional fragment that executes if (Condition) is true. (see example in last sheet) AltAlternative fragment for mutually exclusive logic based on if-else type decision. (see example in last sheet) LoopLoop fragment: A sequence of messages that repeats while some Condition is true. (Note: Can also be written as loop(n) to indicate looping n times) ParTwo or more sequences that execute in parallel. RegionCritical region. A sequence of statements that can only be executed by one thread at a time, the implication is that the designer will have to implement some form of mutual exclusion (i.e. a mutex with wait and signal) to protect the code.

20. UML Message Types, returned values and Object Life Different Message Types Note arrow type. Right click in VP to set the type of message Synchronous message 'GetValue' sent by Object A to Object B. Synchronous message means that Object A MUST wait for Object B to process the message (i.e. complete) and return the answer. In this case the returned answer is assigned to the variable x within Object A, but see also theexplicit return notation later 20

21. UML Message Types, returned values and Object Life Different Message Types Message sent to oneself. That is, ObjectA sends the message 'ResultValid' to itself. Ultimately this means that some function running in ObjectA will invoke a second function within ObjectA to implement the message 'ResultValid'. Note that in this particular case it is a synchronous message 21

22. UML Message Types, returned values and Object Life Different Message Types Note arrow type. Right click in VP to set the type of message Asynchronous message 'Calculate_Y' sent by Object A to Object B. Semantics of an asynchronous message mean that Object A does NOT have to wait for Object B to complete the Operation. Implies that Object B isactive (e.g. has its own thread) so that Object A and B can continue to execute in parallel. 22

23. UML Message Types, returned values and Object Life Different Message Types Note arrow type. Right click in VP to set the type of message Create Message. Used to model the Dynamic creation of objects at run time (implemented using operatornew in C++) 23

24. UML Message Types, returned values and Object Life Different Message Types Destroy Message. Used to Dynamically destroy objects at run time (implemented using operator delete in C++) 'X' on timeline shows end of objects life, i.e. point where object ceases to exist. 24

25. When a message is sent from one object to another there is an implied relationship between those objects. The objects who send and receive messages tells us about their multiplicities. From the diagram below we see that there is a 1:1 relationship between a Car and an Engine object, because, as a car, we only send messages to one single engine and as an engine we receive messages from only the one single car (i.e. there are no other engine or car objects shown). Implied Relationship between Car and Gearbox and between Car and Engine Multiplicity is 1:1 No Relationship between Engine and Handbrake since neither sends messages to each other Identifying Object Relationships and Multiplicities 25

26. Class Diagrams Class Structure From Sequence Diagrams to Class Diagrams Class Relationships Association Aggregation and Composition Generalisation (Inheritance) From Class Diagrams to Code 26

27. Identifying Class Structure 1.The Classes from which our objects (on the sequence diagram) will be constructed. 2.The Member Functions of those classes (mapped from the messages sent to the objects in the sequence diagram). 3.The Member Variables/items of data that the objects will need in their classes. 4.The Relationships between objects so that message passing can be implemented. 27

28. Class Diagram In UML Gives an overview of: Header and Source files Member functions UML Class diagram: 28 Class Name is CPU Class CPU has 4 member variables Class CPU has 8 member functions Accessibility Indicator:+ means public- means private # means protected Type of variable is string Return type of function SetManufacturer() is void Function SetModel() takes 1 parameter of type string Member Functions (display optional) Member Variables (display optional) Right mouse click on a class to add attributes or functions (i.e. member variables/functions) in V.Paradigm 28

29. Class Identification Identify each object in your sequence diagram For each type of object, create a new class For member functions, look at the messages sent to objects: Each message member function within the class which implements that object. The parameters of the message (data sent as part of the message) the parameters in the member function implementing that message. Any results/data returned by the messages in the sequence diagram map directly to the return type of the member function 29

30. UML Class Relationships The UML provides three important types of class relationships: Association. Encapsulation in the form of Aggregation. Composition. Generalization. 30

31. Association Relationships An association relationship exists where one classmakes use of or calls upon the services of another in some way. Think of the two classes having a working relationship. –A Brake pedal has an association (working relationship) with the brake lights and servo. –A CPU has an association (working relationship) with the motherboard. Look for objects which send messages to others 31 Bi - directional association. Objects of Class1 are able to send messages to Objects of Class2 and vice-versa. Note no arrows on the association. Uni - directional association. Objects of Class3 are able to send messages to Objects of Class4 but not the other way around

32. Mapping of Collaborating Objects to a Class Diagram 32 Section from a Sequence Diagram Maps to this Class Diagram Object3 (represented by Class 3) sends a variety of messages to Object4 (Class 4) but not the other way around, implying a uni-directional association on the class diagram. Result: Uni-directional Association Note mapping of message to Fns

33. Coding an Association Association implies one class can send a message to the other Hence, should have a pointer to address it 33 For example, from the previous class diagram, the implementation of ClassStudent might look like this: class Student { Course *theCourse ; // each Student object will have a pointer to a Course Object... // it needs initialisation at run time and can be used to send messages } ; While Class Course, would look like this (due to the bi-directional relationship between instances of these two classes). class Course { Student *theStudent ; // each Course object will have a pointer to a Student Object... // it needs initialisation at run time and can be used to send messages } ;

34. class Student { Course *theCourse ; AddCourse( Course *aCourse) { theCourse = aCourse ; theCourse -> theStudent = this ; } } ; main() { Student Fred(…..) ; Course EECE314(…) ; Fred.AddCourse(&EECE3 14)... } class Course { Student *theStudent ; AddStudent( Student *aStudent) { theStudent = aStudent ; theStudent -> theCourse = this ; } } ; Course *theCourse ; Object Fred (Instance of a Student) Student *theStudent ; Object EECE314 (instance of a Course) Fred's course pointer points to EECE314 EECE314's student pointer Points to Fred Fred can now send messages to EECE314 and EECE314 can send messages to Fred 34

35. This brings us to the more general topic of association multiplicity. At design time (when we are drawing our class diagrams) we cannot always predict how many courses a student might enrol on or how many students enrol on each particular course, the number will vary at run-time and hence the number of objects that may exist at the end of an association could vary. We refer to the number of objects at the end of a class association as itsmultiplicity and it is defined for both ends of the association. UML class diagrams can capture a variety of different multiplicities as summarised in the table below. 0..1Could be 0 or 1 objects (caution: could be 0). 0..*Could be 0 or more objects (caution: could be 0). *Unknown many (caution: could be 0). 1Guaranteed always to be exactly 1 object. nGuaranteed always to be exactly n objects (e.g. 5). 1..*Unknown many but at least 1 and maybe more objects. Association: Multiplicity 35

36. Capturing Multiplicity on a class Diagram * indicates that a Student may be associated with many Courses * indicates that a Course may be associated with many Students * * To set multiplicity in V.Paradigm, 'right-mouse-click' on one end of the association and select 'Multiplicity' 36

37. Aggregation Relationships When one object owns (has a) relationship with other The ownership does not affect the message passing (either can send a message to the other) 37

38. What does aggregation mean from a code perspective? Aggregation actually implies the same code as an association, i.e. a pointer in the owner class pointing to the part that it owns. For example class Car { Engine *MyEngine ; // pointers to point to the part Gearbox *MyGearbox;... Engine *GetEngine() { return MyEngine ; } // allows for retrieval of the engine void AddEngine(Engine *theNewEngine ) {// permits ownership of a engine MyEngine = theNewEngine ; // point to new engine } Engine *ExchangeEngine(Engine *theNewEngine ) { // swap an engine for a new one Engine *temp = MyEngine ; // save pointer to current engine MyEngine = theNewEngine; // point car to its new engine return temp; // return pointer to old engine for } // re-use or destruction later }; In this respect aggregation has been described as a modelling placebo that is,Using it makes you feel good but doesnt alter the fact that aggregation is still implemented in code exactly like an association, nothing different. The Car destructor would be altered so that it does not delete the Engine and Gearbox objects. Similarly, GetEngine() and GetGearbox() functions would be created to detach the owned objects and return them back to the caller. 38

39. Composition Composition is a stronger form of aggregation where the life times of the owner and parts are the same, implying that the owner is responsible for the creation and destruction of its parts. 39 Composition Diamond

40. What Composition Mean? Parts cannot be detached from the owner. Their lives are the same (one is part of the other); once owner destroyed, the parts are also destroyed. Parts cannot be shared amongst owners (i.e. the multiplicity at the owner end is always 1). 40

41. Composition in Code Perspective 41 Owner responsible for creation of parts Owner responsible for destruction of parts Access to Parts is via the Owner (Car) only class Car { private: Engine *MyEngine ;// Parts created by owner when owner is created Gearbox *MyGearbox;// and destroyed when owner is destroyed public: Car(…..) { // constructor takes optional args to initialise Eng/Gearbox MyEngine = new Engine(…..) ; MyGearbox = new Gearbox(…..) ; } ~Car() { delete MyEngine ; delete MyGearbox ; } // no functions to permit the returning of a pointer to the engine or gearbox allowed // no function to add or swap the engine or gearbox allowed as this implies sharing of the part // all functions to manipulate Engine and Gearbox from outside the Car class // and must go through the car class e.g. void ChangeGear( int newGear) { MyGearbox->ChangeGear( newGear); } void StartEngine() { MyEngine -> Start(); } void StopEngine() { MyEngine->Stop(); } } ;

42. Generalisation In UML, this is how we create Kind-of relationships which implies two things: Inheritance Substitutability. Inheritance derived or child classes get it from base/parent Substitutability child or derived class could substitute base/parent 42

43. Generalisation (inheritance). This means that Intel CPU is a kind- of CPU. It also means that Intel CPU is a substitute for a CPU Generalisation (inheritance). This means that AMD CPU is a kind- of CPU. It also means that AMD CPU is a substitute for a CPU Mobile Athlon 64 is a kind-of AMD CPU. It also means that Mobile Athlon 64 is a substitute for an AMD CPU (but not an Intel CPU) and is also a substitute for a CPU Through the process of inheritance, all classes lower in the hierarchy inherit the member functions and variables of all classes higher up, and can add or redefine operations thus an Athlon 64FX can perform Reset(), Run() and Interrupt() or could redefine those operations to work in different ways to the base class CPU Core 2 Duo is a kind-of Intel CPU. It also means that Core 2 Duo is a substitute for an Intel CPU (but not an AMD CPU) and is also a substitute for a CPU Through the process of inheritance, all classes lower in the hierarchy inherit the member functions and variables of all classes higher up, and can add or redefine operations thus a Core 2 can perform Reset(), Run() and Interrupt() or could redefine those operations to work in different ways to the base class CPU

44. What does inheritance means in terms of Code class IntelCPU : public CPU{ public: IntelCPU(…..) : CPU(….) { /* constructor calls base class constructor */ } // new or overridden member functions and/or variables } ; class AMDCPU : public CPU{ public: AMDCPU(…..) : CPU(….) { /* constructor calls base class constructor */ } // new or overridden member functions and/or variables } ; class IntelCoreDuo : public IntelCPU{ public: IntelCoreDuo(…..) : IntelCPU(….) { /* constructor calls base class constructor */ } // new or overridden member functions and/or variables } ; C++ code stating that IntelCPU is derived from CPU, the public means that the interfaces of the base class CPU are available to the user of an IntelCPU Derived class constructor calls base class constructor to initialise base class member variables 44

45. Now we can create code like this int main() { CPU *theCPU = new IntelCoreDuo(…) ; theCPU ->reset() ; theCPU ->run() ; } ; Exercise : Identify as many components as you can to make up a desktop PC and identify the relationships between them and where relevant their multiplicities, dont forget to include things like different kinds of CPU, cases, disk drives motherboards etc. Now draw a class diagram to represent them and show how those relationships would be mapped to code (ignore member variables and functions – just capture the code to represent the relationships. Base class pointer can point to a derived class object because the derived class object is a valid substitute for the base class 45

46. What Is Next? Best practices for software development projects http://www.ibm.com/developerworks/websphere/library/t echarticles/0306_perks/perks2.html http://www.ibm.com/developerworks/websphere/library/t echarticles/0306_perks/perks2.html Data and Analysis Center for Software: http://www.thedacs.com/ Agile Development, Scrum, RUP. http://www.thedacs.com/ Michael Cook PhD student at Imperial College http://www.gamesbyangelina.org/Michael Cook http://www.gamesbyangelina.org/ Dr Sid Fels, http://hct.ece.ubc.ca/http://hct.ece.ubc.ca/ 46