1. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 1 Systems and Service Engineering Domain Modelling (textbook ch 3 ++) Rolv Bræk NTNU Department of Telematics

2. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 2 The full systems engineering cycle/spiral Domain System descriptions Develop Install System Manufacture Domain descriptions Model has needs quality = satisfaction of needs

3. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 3 Why make domain models? 1.to understand the (problem) domain 2.to understand the needs and opportunities 3.to improve communication with users, owners and developers 4.to plan better products 5.to facilitate reuse 1.to understand the (problem) domain 2.to understand the needs and opportunities 3.to improve communication with users, owners and developers 4.to plan better products 5.to facilitate reuse A common “language” for all departments: Product planning and marketing Development Engineering, production, sales Customer organizations A common “language” for all departments: Product planning and marketing Development Engineering, production, sales Customer organizations

4. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 4 What are domain models? Object models Property models Dictionary Statement Domain descriptions They model a part of reality that systems may serve. They are not specific to a system, but rather to a market segment. They identify stable domain concepts and processes that need to be supported irrespective of particular system solutions. They model a part of reality that systems may serve. They are not specific to a system, but rather to a market segment. They identify stable domain concepts and processes that need to be supported irrespective of particular system solutions.

5. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 5 How to make domain models Consider the enterprise - to find the real needs (why) and thereby identify the best system opportunities. Object models Property models Dictionary Statement Domain descriptions 1.Make domain statement; identify: owners, users, subjects, helpers, services, workflows and procedures. 2.Make dictionary (Taxonomy of terms, Ontology). 3.Make object models: passive objects and active objects. 4.Make property models: define the services, workflows, procedures. 1.Make domain statement; identify: owners, users, subjects, helpers, services, workflows and procedures. 2.Make dictionary (Taxonomy of terms, Ontology). 3.Make object models: passive objects and active objects. 4.Make property models: define the services, workflows, procedures.

6. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 6 A-rule: Problem Statement Make a statement that explains the problem domain. Focus on the purpose, the essential concepts, the procedures and the rules. e.g.: The main problem of the domain is to control the access of users to access zones. Only a user with known identity and correct access right shall be allowed to enter into an access zone. Other users shall be denied access. The authentication of a user shall be established by means of a magnetic strip card holding a card code, and a secret Personal Identification Number, PIN, known by the user. The authorization is performed on the basis of the user identity, and access rights associated with the user. When a user is authenticated and authorized the access zone may be entered through a door....

7. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 7 A-rule: Dictionary Make or obtain a dictionary for the problem domain. The dictionary should be kept updated throughout the development. e.g.: Access PointA point of access in one direction through a door. Access ZoneA physical zone where users are present, accessible through doors. AuthenticationTo establish the identity of a user. AuthorizationTo establish the right of a user to enter an access zone CardA personal identification means. CardcodeA unique identification of a card stored in machine readable form on the card. DoorA controlled passage from one access zone to another...

8. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 8 Make static object models (concept models) of the problem domain using UML diagrams, SOON or similar. A-rule: Domain Object Models zone door Passive objects (subjects) group legal user member of has access to consist of 1..* 1 Authenticator Authorizer User Card Operator Door Active objects

9. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 9 - and emphasizes passive objects (subjects) The textbook uses SOON owns : User : Card : Access Point : Access Zone may use may enter EntryControl : Door controls Access control domain,, = (+) ExitControl has

10. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 10 Use UML2.0 Class diagrams in stead SOON models part structures UML class diagrams model classes/types owns : User : Card : Access Point : Access Zone may use may enter EntryControl : Door controls Access control domain,, = (+) ExitControl has AccessZone AccessPoint Door Card User * * 0..2 may use 0..1 0..1 owns * 1 1 controls has 1..* 1 1 EntryControl 1 ExitControl may enter

11. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 11 owns : User : Card : Access Point : Access Zone may use may enter EntryControl : Door controls Access control domain,, = (+) ExitControl has... and UML 2.0 composite classes Composite Classes in UML2.0 model part structures similar to SOON (and SDL) az[k]: AccessZone ap[m]: AccessPoint u[n]: User c[n]: Card d[l]: Door Access Control Domain

12. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 12 Make domain object model for a Hospital Passive objects

13. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 13 Domain Property Models Non-functional and functional properties. Functional properties: services; workflows; procedures UML 2.0 Collaborations are well suited: Role structures – for properties of active objects. Collaboration behaviour – for services, workflows and procedures. Authenticator Authorizer User Door User Access

14. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 14 Using UML 2.0 collaborations to model active objects as role structures to specify behaviour properties using sequence diagrams, activity diagrams and/or state machines to define Use Cases in a useful way to define interfaces behaviour and semantic interfaces a:Authenticator b:Authorizer u:User d:Door User Access Classifier Role: specify properties of compatible classes

15. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 15 Collaboration diagrams Session roleX:TypeX roleY:TypeY Service roleA:TypeA roleC:TypeC roleB:TypeB session1: Session session2: Session session3: Session roleX roleY roleX roleY roleX roleY A collaboration with two roles A collaboration with three roles and three collaboration uses This illustrates collaboration (re-)use and composition Note that TypeA must be compatible with TypeX Compatibility means that the role behaviours must be contained in the total behaviour of the actor – how is a semantic variation point in UML2

16. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 16 Behaviour can be in three places: The collaboration itself The roles The context (scope) of the collaboration: Service roleA:typeA roleC:typeC roleB:typeB session1: Session session2: Session session3: Session roleXroleY roleX roleY roleX roleY sd 1 3 2 1 3 2

17. Science and Technology Norwegian University of NTNU Rolv Bræk, March 2006 17 Service User Access UserAccess example User Access: –A user enters his personal code, PIN –The authenticator checks the card id and the PIN –The authorizer checks the access right of the user –If OK the door is opened –If NOK no action MSC UserAccess_Granted User AuthorizerAuthenticator Door Card id Enter PIN Givepin [PIN] Authorize[userid] Open_Lock Enter Authenticator Authorizer User Door User Access