UML Components : Component Interaction

1. UML Components : Component Interaction

2. UML Components Workflow Business requirements Requirements Existing assets Use Case models Business concept model Technicalconstraints Components Use Case models Specification Provisioning Assembly Applications Component specs& architectures Test Tested Applications Deployment

3. UML components focuses on “specification”. Business requirements Requirements Existing assets Business concept model Technical constraints Specification Use Case models Component Identification Component Interaction Component Specification Component specs& architectures

4. Component Interaction defines how components will work together to deliver the required functionality. This will result in interaction diagrams, refined interfaces, and refined component specs and architecture. ComponentIdentification Business Type Model Business Interfaces SystemInterfaces Component Specs& Arch (implicit) Use Case Model ComponentInteraction Discover Business Operations Refine Interfaces and Ops Refine Component Specs &Arch BusinessInterfaces SystemInterfaces Component Specs& Architecture ComponentSpecification

5. The steps in the Component Interaction workflow: • For each operation defined on each system interface • Define an interaction diagram • Identify necessary operations on the business interfaces • Identify parameters on system and business operations • Name, type, and direction • Identify constraints • Identify any necessary data types • Refine system interfaces until all interaction diagrams are complete.

6. Each interaction diagram consists of a component instance, an initial message, required business interfaces. • Things to note: • initialMessage() is part of systemInterface • subsequentMessage() is part of businessInterface • There may be more than one business interface involved • Multiple messages can be exchanged • No exchanges between business interfaces • Business interface components should not have a component type identified /systemInterface:componentType initialMessage() subsequentMessage() {constraint} /businessInterface

7. UML object syntax objectName/roleName:objectType n an object named ‘n’ n:T an object named ‘n’ of type ‘T’ n/r an object named ‘n’ playing role ‘r’ /r an object playing role ‘r’ /r:T an object playing role ‘r’ of type ‘T’ n/r:T an object named ‘n’ playing role ‘r’ of type ‘T’

8. UML Components methodology follows UML syntax but constrains the use. objectName/interfaceName:componentType General rules: The object name is typically left off. If the interface name is a system interface, the component is identified If the interface name is a business interface, the component is unidentified Remember: Design constrains the implementation /ICustomerMgt /IMakeReservation:ReservationSystem

9. When defining operation parameters, complex information may need to be passed. • <<data type>>: • Represents logically related data – it’s a container • 1 or more attributes • No operations • No associations • Attribute types must be data types (includes UML built-ins) <<datatype>> Name attributeName : TypeName • Note: • String and HotelId suggest something more complicated than a data type • At this level of abstraction, they are conceptually data types. • Remember: This is not at implementation level! <<datatype>> HotelDetails id : HotelId name : String roomTypes : String[]

10. Parameter definition needs to be done independent of target implementation technology. IMakeReservation::makeReservation( in res: ReservationDetails, in cus: CustomerDetails out resRef : String) : Integer “in” : meant to have meaningful information to be used by the method “out” : meant to be filled in by the method – enable multiple return values The ReservationSystem example often uses the formal return value as a status indicator

11. Java and “out” parameters • Java doesn’t formally support directed parameters • They are always “in” • Java can be used to implement directed parameters • Requires good design and careful implementation

12. Java : “implementing” an “out” parameter public class FileUser { private File file; public void setFile(File newFile) { file = newFile; } } public class FileUtilities { public boolean open(String fileName, FileUser user) { File openedFile = null; try { openedFile = new File(fileName); if (openedFile.exists()) { user.setFile(openedFile) return true; } } catch (Exception e) { return false; } } } In FileUtitilities::open(): fileName is “in” user is “out” This technically isn’t truly “out”. Why?

13. Java : String cannot be “implemented” as “out” • Why?

14. UML Interaction Diagrams • Show run-time interactions between objects • Two types • Sequence diagrams • Collaboration diagrams • UML Components uses collaboration diagrams

15. Example : Sequence diagram :ButtonManager modeMgr:ModeManager timeMgr:TimeManager alarmTime:Time display:Display doSetAlarm() setMode(Mode.SET_ALARM) showAlarmTime() hour:=getHour() minute := getMinute() showHour(hour) showMinute(minute) *[while desired hour is not displayed] doIncrementHour() incrementHour() incrementHour() hour:= gethour() showHour(hour) *[while desired hour is not displayed] doIncrementMinute() incrementMinute() incrementMinute() minute:=getMinute() showMinute(minute)

16. Example : Collaboration Diagram :ModeManager 1.1 setMode() 1.2.1 getHour() 1.2.2 getMinute() 2.1.1 incrementHour() 2.1.2 getHour() 3.1.1 incrementHour() 3.1.2 getHour() :TimeManager alarmTime:Time :ButtonManager 1.2 showAlarmTime() 2.1 incrementHour() 3.1 incrementMinute() 1. doSetAlarm() 2. doIncrementHour() 3. doIncrementMinute() 1.2.3 showHour() 1.2.4 showMinute() 2.1.3 showHour() 3.1.3 showMinute() :Display

17. From here, it’s a matter of creating diagrams for each identified system interface operation. /ICustomerMgt 1.1:getCustomerMatching(c, id) {result = 1} 1.2:createCustomer (c, id) 1.4:notifyCustomer(id, s) {where s includes rr etc.} 1:makeReservation(r, c, rr) /IMakeReservation:ReservationSystem 1.3:makeReservation(r, id, rr) /IHotelMgt IMakeReservation::makeReservation(in res:ReservationDetails, in cus:CustomerDetails, out resRef:String) : Integer In flushing out the interaction, operations on ICustomerMgt and IHotelMgt were discovered and defined.

18. Example: Use case and associated interface. Name Select Drink Main success scenario 1. User hits “add drink” button. 2. System presents drink list. 3. User selects from among list. 4. System shows recipe. Extensions 3. Drink not found on list. 3a. System prompts user to create a custom drink. 3b. User enters drink ingredients. 3c. System adds drink to drink list and shows recipe. 3d. Stop. <<inteface type>> ISelectDrink getDrinkList() getRecipe() queueDrink() createRecipe()

19. Current component architecture. ISaleMgt <<comp spec>> Processing System IReportWeightChange ISelectDrink ILogin IDeleteAccount ILogout ICreateAccount ITenderPayment IRunReport <<comp spec>> SaleMgr IWarehouseMgt <<comp spec>> SaleMgr ISenosrMgt IReportMgt IDrinkMgt <<comp spec>> SensorMgr IEmployeeMgt <<comp spec>> ReportMgr <<comp spec>> DrinkMgr <<comp spec>> EmployeeMgr

20. So…