1. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 1 Domain Modelling and requirement specifications by Rolv Bræk NTNU

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

3. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 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, January 2007 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, January 2007 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, January 2007 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, January 2007 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, January 2007 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, January 2007 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, January 2007 10 owns : User : Card : Access Point : Access Zone may use may enter EntryControl : Door controls Access control domain,, = (+) ExitControl has … you may now use UML 2.0 composite classes az[k]: AccessZone ap[m]: AccessPoint u[n]: User c[n]: Card d[l]: Door Access Control Domain SOON model part structures As do Composite Classes in UML2.0

11. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 11 …and UML2.0 Class diagrams UML class diagrams model classes/types NOT parts! 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

12. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 12 Make domain models for a Hospital Ward (sengepost) 1.Passive objects: Patients, Nurses, Doctors, Rooms, Beds, Patient Journals,… 2.Active objects: Patients, Nurses, Doctors, Patient Journals, Terminals, … 3.Services: Log on/off Mark available/unavailable Show location Call assistance

13. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 13 UML 2.0 collaborations to model role structures related to services and interfaces to specify role properties 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

14. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 14 Collaboration diagrams Service roleA:TypeA roleC:TypeC roleB:TypeB session1: Session session2: Session session3: Session roleX roleY roleX roleY roleX roleY A collaboration with three roles and three collaboration uses: may define a service structure Session roleX:TypeX roleY:TypeY A collaboration with two roles: may define a semantic connector TypeA must be compatible with (the semantic interface) 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

15. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 15 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

16. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 16 Domain Property Models Non-functional and functional properties. Functional properties model domain behaviour, i.e.: 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

17. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 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

18. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 18 How to model the service behaviour? A service is an identified (partial) functionality, provided by a system, component, or facility, to serve a purpose (or achieve a goal) for its (usage) environment. Goal state expressions Activity diagrams Sequence diagrams Structure of inner collaboration uses Role state machines

19. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 19 Activity diagram (or sequence overview diagram) Phases (features) of the service as activities with goal expressions

20. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 20... with corresponding sequence diagram Features (phases) as referenced diagrams

21. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 21 Decomposing into collaboration uses corresponding to features (phases) note that the ordering follows from the behaviour diagrams here

22. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 22 Requirement specification Specifies Properties that must be satisfied by a system or system component. Defines: The system boundary, and the environment (what parts of the domain are provided and supported). The functional requirements: the system interfaces and services, i.e. the behaviour properties visible to the environment. The non-functional requirements: constraints on the implementation of the system.

23. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 23 Requirements and architecture Requirements are not designs – avoid overspecification Requirements need some minimal structure to be precise A-rule: Sketch system structure Sketch the system structure using SOON or similar notations. Identify the parts that are subject to requirements. Avoid to describe more than required. “… for the foreseeable future, each attempt to study telecommunication requirements will have a specific architecture as its formal framework.” Pamela Zave; Feature Disambiguation. Feature Interactions in Telecommunications and Software Systems. D.Amyot, L. Logrippo (Eds) IOS Press 2003

24. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 24 Functionality reference model A classification of objects in the environment and the system; used to structure functional requirements and design; supporting separation of concerns, reuse and flexibility. A classification of objects in the environment and the system; used to structure functional requirements and design; supporting separation of concerns, reuse and flexibility. Interface given System given Domain given Users Other systems Controlled processes Known entities Environment System Service providing Service needing

25. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 25 Functional requirements (properties) Define the context (the system boundary and environment) Identify (functional) interfaces and interface layers Identify domain given objects inside and outside the system Define interfaces and their behaviour properties Define services and their behaviour properties Define the context (the system boundary and environment) Identify (functional) interfaces and interface layers Identify domain given objects inside and outside the system Define interfaces and their behaviour properties Define services and their behaviour properties Interface given System given Domain given Human users Other systems Controlled processes Subjects Environment System Service providing Service needing

26. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 26 A-rule: Context Make a context diagram where the system is identified and the system environment is detailed. Describe communication interfaces and other relations the system shall handle.

27. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 27 Subject Access Control System The AC system: Context with domain given objects Authorizer Authenticator User Operator Door Card Access Zone Controlled process Human user Subject

28. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 28 Subject Interface given Access Control System … adding interface given objects Authorizer Authenticator User Operator Door Panel Operator Terminal Card Access Zone Controlled process Human user Subject Domain given Interface given Domain given Door Controller Interface given

29. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 29 Subject Interface given Access Control System … and possibly agents mirroring the environment Authorizer Authenticator User Operator Door Panel Operator Terminal Card Access Zone Controlled process Human user Subject Domain given Interface given Domain given Door Controller Interface given User Agent Operator Agent System given These are all very generic and stable

30. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 30 Interface behaviour A-rule: Interface Collaborations (new) Use collaborations to structure interface definitions. A-rule: Message Sequence Charts Make message sequence charts that describe the typical interaction sequences (protocols) at each layer of the interfaces. p:Panel u:User PanelInterface PanelUser Code OK Push door MSC User_accepted

31. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 31 Role behaviours and Semantic Interfaces A-rule: Role behaviour Define the interface behaviour of each role in the system and in the environment. Use the roles as basis for behaviour synthesis and validation. A-rule: Semantic Interfaces (new) Use collaborations to structure and define semantic interfaces. p:Panel u:User PanelInterface

32. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 32 Service behaviour A-rule: Service separation (new) Use layering to separate service behaviour from interface given behaviour A-rule: Service Collaborations (new) Use collaborations to structure service definitions. a:Authenticator b:Authorizer u:User d:Door User Access ua:UserAgent The system structure helps to identify service roles Services may need roles provided by additional system objects – to be determined during design

33. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 33 Panel Interface Access Control System Binding collaboration roles Authorizer Authenticator User Operator Door Panel Operator Terminal Card Access Zone Door Controller User Agent Operator Agent User Access u p u ua a b d design objects shall be compatible with the roles cf the role-play principle

34. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2007 34 Model organization Object Models Class X Service-A MSC Text Service-A Plays role of Property Models... Service-B MSC Text Service-B Plays role of r2 r3 r1 r2 r3 r1