Ch. 9 Extending to the upper layers : Information System Services

1. Ch. 9 Extending to the upper layers:Information System Services Architecture and Modelling of Information Systems (D0I71A) Prof. dr. Monique Snoeck

2. Overview of MERODE • IS Service Modelling Phase • Identification of required Information Services • For each service: • identification of information object types • identification of generated business events (input services) • construction of Service SpecificationDiagram • Identification of attributes • Identification of methods • Business ProcessModellingPhase

3. Overview of MERODE • Requirement engineering with MERODE • "Owner's view" - IS agnostic • WHAT – Identification of Business Concepts • HOW – Behavioural aspects of Business Concepts • What is left as not addressed? • "Owner's view" - (IS agnostic at levels 1&2) • HOW - BPModellinglevels 1&2 = Organisationalaspects: who does what & when ? • "IS functionality"– the way a system will interact with user • GUI: graphical interfaces, inputs & outputs format (e.g. user identification, text fields, drop down choice lists, buttons/links, charts/diagrams, tabular data…) • I/O detail level algorithms • BPModelling level 3

4. Problem space <> Solution SpaceConceptual model <> IS functionality • WHY an architect is supposed to have a good knowledge on I/O services ? • Check thecompleteness of a conceptual model in terms of • capabilityto support all business tasks • capabilityto support all information needs • Check the impact on workorganisation

5. Roadmap

6. Refining the middle layer • Information Object Types • The database willcontain more than domain object types only … • Information System Services • Output Services • Input Services • Simple versus complex services • Refining the Architecture of the IS layer • Event handling layer • Consistent Events & Transactions • Cross-cutting concerns • Case: JMermaidArchitecture

7. Overall Architecture with cross-cutting concerns Business Processes logs Input Services Output Services Single EventTransactions Multi-Event Transactions logs Busieness Analytics Authorisation (Consistent) Event Handling Layer Consistent Composed Events Consistent Atomic Business Events Inconsistent Atomic Business Events logs Business Objects Information Objects

8. Overall Architecture with cross-cutting concerns Business Processes logs Input Services Output Services Single EventTransactions Multi-Event Transactions logs Busieness Analytics Authorisation (Consistent) Event Handling Layer Consistent Composed Events Consistent Atomic Business Events Inconsistent Atomic Business Events logs Business Objects Information Objects

9. Information Object Types • Business Objects are assumed to be persistent (= stored in a database) • Additional persistent objects may be required to provide additional functionality  Information Objectse.g. • logging of executed business events • logging of executed services • presentation data • user preferences

10. Information Object Types • Example • Logging of events (transactions) on a bank account • (assumesthatmovements are events, not business objects) • User preferences Business Object Types ACCOUNT USER PREFERENCES InformationObject Types MOVEMENT

11. Information Object Types • Some information object types are ED of business OTs, some not. • Can be related to business OTs trough ‘conventional’ UML associations • May or may not have a lifecycle • E.g. ‘movement’ has an instantaneous lifecycle • May respond to IS events • E.g. “update user preferences” is not a business event. • E.g. “generated pdf report” that stays available one week • It’s an information object type • It’s created by an information system event (generate pdf report) • It’s ended by a timer event.

12. Information Object Types Example: ISP action logs when Who(User) Who (Role) What

13. Overall Architecture with cross-cutting concerns Business Processes logs Input Services Output Services Single EventTransactions Multi-Event Transactions logs Busieness Analytics Authorisation (Consistent) Event Handling Layer Consistent Composed Events Consistent Atomic Business Events Inconsistent Atomic Business Events logs Business Objects Information Objects

14. Information System Services • Deals with user input/output system • processing data into output information based on the input e.g. generating a report on account holder’s transactions for a given period, etc.

15. IS Service Modelling • Two basic principles: • Output: IS Services inspect the value of object attributes to provide the user with output facilities in the form of predefined screens or printed reports. • Input: IS Services provide input facilities to end-users by capturing data associated with events and transmitting events and data to the enterprise model.

16. Example: Financial Adminstration KULeuven • Input Services • Mainly used at operational level • Some even only by "accredited staff" (Financial Antenna) • Trained for correct input of financial transaction • Ensure the quality of the input • Output Services • Used at operational level by Financial Antenna and Budget Holder to check available budget • Used at management level for overview & reporting

17. OUTPUT IS services available to me in myrole of budget administrator

18. Output Service for budget accountnr. search

19. Overview of oneproject's budget

21. Input Service: form to enter a refundrequest

22. User interface The user interface is nothing more than “presentation”. A different user interface may offer exactly the samefunctionality E.g. KU Loket redesignreorganisespresentation

23. Template UseCase diagram (UC) for a Simple Output Service Enterprise Layer Output Service A «access» 1 * D B 1 C * * 1

24. Template textual description for a Simple Output service • Inspired on Zachman: What, How, When, Where, Who, Why • WHEN: • Timer or User invocation (howtoinvoke) • preconditionstobesatisfied • WHAT • Input: Parameters / Screen layout / message format • Output: message format / screen layout • guarantee: postconditions (minimal, whensuccesful) • HOW: SQL Query • WHY: goal • WHERE: networkaspects • WHO: • owner • Authorisedinvoker • destination of output

25. Output Service in JMermaid Produce a report that gives per customer an overview of the balance of their accounts

26. Template UseCase diagram (UC) for a Simple Input Service Noticethatthe event is sent tothe EL package as a whole, nottospecific classes in that EL package. Enterprise Layer «access Input Service * A 1 «send» * event D B 1 C * 1

27. Template textualdescriptionfor a Simple input service • Inspired on Zachman: What, How, When, Where, Who, Why • WHEN: • howtoinvoke or timer • preconditionstobesatisfied • WHAT • Input: Parameters / Screen layout / message format • Output: message format / screen layout • guarantee: postconditions (minimal, whensuccesful) • HOW • SQL Query • Triggered events, sequence of event triggering & Business Object Querying • WHY: goal • WHERE: networkaspects • WHO: • owner + Authorisedinvoker + destination of output

28. Trivial Services • Trivial output services: • one output service per business object type to view the list of all objects in that class, • one output service per business object type to search for a specific objects in that class, using search criteria, • one output service per business object type to select and view the details of one object in that class. • Trivial input services: • one input service per business event in the domain model.

29. Complex Services • by means of the «include» and «extend» relationships between Use Cases. • For example • list of all objects in a class (trivial output service) • invoke the input service for create an object • service that allows to view the details of one object • invoke the modifying and ending events for that object. • input service for triggering a creating event • invoke the trivial output services to search and select the master objects for the to-be-created dependent object.

30. Complex Services • Complex IS service modellingcanalsobedonewithUse Case diagrams (UML) • Detailedmodelling ? • Requires high level of interactionwith end-users •  agile development is more efficientandeffective • List services  implement  feedback  list RFC  implement  …

31. Important modelling constructs of a use case diagram

32. Model for a car rentalcompany «BOT» «BOT» CAR CUSTOMER 1 1 «BOT» RENTAL * * 1 * «IOT» REMINDERS

33. Trivial Services

34. Sample non-trivial services • "Rentals Overview“ • On request, produce a list of all persons, indicating per person, the number of cars in rent at this moment. • "Search Customer and Register Rental“ • Register the rental of a car by a customer that has already been registered before. • "Congratulation Letter" • Automatically produce a letter to congratulate a person who rents his/her fifth car.

35. Sample non-trivial Services «BOT» «BOT» RentalsOverview CAR CUSTOMER Enterprise Layer 1 1 «access «BOT» RENTAL * * 1 SearchCustomer «access» * «include» «IOT» Customer Service Desk REMINDERS Search Customer &Register Rental SearchCar «include» «access» «access» «include» Register Rental «send» rent «extend» Customer «access» CongratulationsLetter

36. Q. Check: Realised IS Services & Use Cases • Completeness • Every actor should have at least one Use Case or I/OService to interact with the system. • Every event should appear in at least one Input Service/UC • It should be possible to inspect every class (= Output service that gives list of objects) • It should be possible to inspect every object (= Output service that gives details of an objects) • Grouping • Increase user friendliness by offering grouped services

37. Overall Architecture with cross-cutting concerns Business Processes logs Input Services Output Services Single EventTransactions Multi-Event Transactions logs Busieness Analytics Authorisation (Consistent) Event Handling Layer Consistent Composed Events Consistent Atomic Business Events Inconsistent Atomic Business Events logs Business Objects Information Objects

38. Event Handling Layer Input Services trigger events Assumesthere is a mechanismtodispatch events to right objects = Event Handling Layer in between Input Services and Business ObjectsLayer

39. General Architecture Information System Services Layer Input Information System Services Business Event Handling Layer Enterprise Layer Output Information System Services Information Objects Business Objects

40. Event Handling Layer • Grouping of events can happen fortworeasons • Workorganisation invoke a serie of events ratherthanone • Example: delete an order andallits order lines • Consistency Management • Example: manage “mandatory” associations •  Assign employee immediatelytodepartment

41. Event triggering: consistency management • BUSINESS EVENTS • atomic • not always consistent • ==> Definition of CONSISTENT EVENTS • consistent atomic events • consistent composed events

42. Grouping for consistency & work org. = GroupingforConsistency Management = GroupingforWorkOrganisation

43. Overall Architecture with cross-cutting concerns Business Processes logs Input Services Output Services Single EventTransactions Multi-Event Transactions logs Busieness Analytics Authorisation (Consistent) Event Handling Layer Consistent Composed Events Consistent Atomic Business Events Inconsistent Atomic Business Events logs Business Objects Information Objects

44. JMermaidCase • Domain model  meta-model • E.g. object types, dependencies, event types, states, transitions, … • Information object types  e.g. to keep information about visualisation (presentation data) • E.g. location on the screen, border color, fill color,

45. Information Object Types Example: Jmermaid presentation data Meta-model = Model of a modellingmethod GUI-model = Information object types to keep track of presentationaspects

46. Information Object types ExampleJmermaid: presentation data

47. Information Object Types Example: JMermaid action logs

48. Overall Application Architecture of JMermaid User Interface Input Services Output Services Complex Command CombinedCommand GUI Command MetaCommands Meta-Model Objects Graphical Model Objects

49. RefresherfromChapter 2 ...

50. Architecture versus project management • Iteration between domain modellingand IS modellingallowsgraduallyexpanding • Adding/modifying IS services is howevereasierthanexpanding/modifyingthe domain layer • Keep focus on domain layer first! (as much as possible)