Training of master Trainers Workshop 10 – 15 November 2012

1. Training of master Trainers Workshop 10 – 15 November 2012 e-Services Design and Delivery Module VII Emilio Bugli Innocenti

2. e-Services Design & Delivery Contents of MODULE VII – “e-Services Design & Delivery” • Data Modeling: Entity Relationship Diagrams • System Modeling: Unified Modeling Language • Example/Case Study: The KIWI Project

3. e- Service Design & Delivery: the Technical Perspective DATA SET DESIGN: ENTITY-RELATIONSHIP DIAGRAM • Data modeling – a technique for organizing and documenting a system’s data. Sometimes called database modeling. • Entity relationship diagram (ERD) – a data model utilizing several notations to depict data in terms of the entities and relationships described by that data

4. e- Service Design & Delivery: the Technical Perspective • Places: sales region, building, room, branch office, campus. • Objects: book, machine, part, product, raw material, software license, software package, tool, vehicle model, vehicle. • Events: application, award, cancellation, class, flight, invoice, order, registration, renewal, requisition, reservation, sale, trip. • Persons: agency, contractor, customer, department, division, employee, instructor, student, supplier. • Concepts: account, block of time, bond, course, fund, qualification, stock. Data Modelling Concept: Entity • Entity – a class of persons, places, objects, events, or concepts about which we need to capture and store data. • Named by a singular noun

5. e- Service Design & Delivery: the Technical Perspective • Attribute – a descriptive property or characteristic of an entity. Synonyms include element, property, and field. • Just as a physical student can have attributes, such as hair color, height, etc., data entity has data attributes • Compound attribute – an attribute that consists of other attributes. Synonyms in different data modeling languages are numerous: concatenated attribute, composite attribute, and data structure. Data Modelling Concept: Attribute

6. e- Service Design & Delivery: the Technical Perspective • Key – an attribute, or a group of attributes, that assumes a unique value for each entity instance. It is sometimes called an identifier. • Concatenated key - group of attributes that uniquely identifies an instance. Synonyms: composite key, compound key. • Candidate key – one of a number of keys that may serve as the primary key. Synonym: candidate identifier. • Primary key – a candidate key used to uniquely identify a single entity instance. • Alternate key – a candidate key not selected to become the primary key. Synonym: secondary key. Data Modelling Concept: Identification

7. e- Service Design & Delivery: the Technical Perspective • Relationship – a natural business association that exists between one or more entities. • The relationship may represent an event that links the entities or merely a logical affinity that exists between the entities. Data Modelling Concept: Relationship

8. e- Service Design & Delivery: the Technical Perspective • Cardinality – the minimum and maximum number of occurrences of one entity that may be related to a single occurrence of the other entity. • Because all relationships are bidirectional, cardinality must be defined in both directions for every relationship. Data Modelling Concept: Cardinality

9. e- Service Design & Delivery: the Technical Perspective • Degree – the number of entities that participate in the relationship. • A relationship between two entities is called a binary relationship. • A relationship between three entities is called a 3-ary or ternary relationship. • A relationship between different instances of the same entity is called a recursive relationship. Data Modelling Concept: Degree

10. e- Service Design & Delivery: the Technical Perspective • Logical models remove biases that are the result of the way the system is currently implemented, or the way that any one person thinks the system might be implemented. • Logical models reduce the risk of missing business requirements because we are too preoccupied with technical results. • Logical models allow us to communicate with end-users in nontechnical or less technical languages. Logical System Models

11. e- Service Design & Delivery: the Technical Perspective • Processes on DFDs can operate in parallel (at-the-same-time) • Processes on flowcharts execute one at a time • DFDs show the flow of data through a system • Flowcharts show the flow of control (sequence and transfer of control) • Processes on a DFD can have dramatically different timing (daily, weekly, on demand) • Processes on flowcharts are part of a single program with consistent timing Difference between DFDs and Flowcharts

12. e- Service Design & Delivery: the Technical Perspective System Design: UML - Unified Modeling Language • It is a modeling language, not a process • In 1996, work on the UML was begun by Rational • UML is a robust notation that can express information gathered throughout a project’s lifecycle. • Adopting standard use of UML can improve communication between clients and developers. • UML can be used as an effective data modeling tool as well as an object modeling tool.

13. UML UML Diagrams • Class Diagrams • Use Case Diagrams • Collaboration Diagrams • Sequence Diagrams • Package Diagrams • Component Diagrams • Deployment Diagrams • Activity Diagrams • State Diagrams

14. UML Class Diagrams • Are the most fundamental UML Diagram. • Describe the classes in the system, and the static relationships between classes. • Class diagrams are used during Analysis, Design and Development

15. UML Customer Customer 1 Rental Invoice 1..* Rental Item 1 0..1 1 Checkout Screen Checkout Screen Video Game DVD Movie VHS Movie Video Game Class Diagrams

16. UML Multiplicity Customer Simple Aggregation 1 Class Abstract Class Rental Invoice 1..* Rental Item {abstract} 1 0..1 Composition (Dependency) Simple Association Generalization Checkout Screen DVD Movie VHS Movie Video Game Class Diagrams

17. UML MyClassName +SomePublicAttribute : SomeType -SomePrivateAttribute : SomeType #SomeProtectedAttribute : SomeType +ClassMethodOne() +ClassMethodTwo() Responsibilities -- can optionally be described here. • Classes can have four parts • Name • Attributes • Operations • Responsibilities • Classes can show visibility and types. • All parts but the Name are optional. Parts of a Class

18. UML ThisOne : MyClassName +SomePublicAttribute : SomeType -SomePrivateAttribute : SomeType #SomeProtectedAttribute : SomeType +ClassMethodOne() +ClassMethodTwo() • An Object is an instance of a class. • Object names are underlined. • Object diagrams are similar to class diagrams. Many of the same notations are used. • Object diagrams capture instances of classes, and allow the dynamic relationships to be shown. Object Diagrams

19. UML Class Name Association Name Customer Rental Item Rents +id:integer +name:string Class Diagram Attributes Object Name Joe: Customer Casablanca: Movie +id:1667 +id:22340 +name:Joe Smith +released:1942 Object Diagram Class and Object Diagram

20. UML Use Cases • Describe interactions between users and computer systems (both called actors) . • Capture user-visible functions. • Achieve discrete measurable goals. • Are typically used during Analysis and Design.

21. UML Use Case Actor Identify Movie Open Account Customer Clerk Return Movie Review In-Store Telephone Account Status Customer Customer Use Cases

22. UML • Brief description • Precondition • Flow of events • Main flow • Subflows • Alternate flows • Postcondition • Special Requirements • Enclosures • Diagrams • Pictures of the UI • The Use Case Report provides documentation for the Use Case. • A Use Case is not complete without the report. • The elements of the Use Case Report are shown on the right. Use Case Report

23. UML Collaboration Diagrams • Collaboration diagrams describe interactions and links • Focus on exchange of messages between objects • Appears during Analysis phase • Enhanced during Design phase

24. UML :Rented Items Object 5: add(customer, movies) 1: enter_customer() 8: generateRentalTotal() 3: enter_movies() 2: IsValidCust(CustId) 7: print invoice() :Check-out Manager :Customer :Clerk 4:GetMovieByBarcode() :Inventory Message Collaboration Diagrams – Rent a movie

25. UML Sequence Diagrams • Can be “morphed” from Collaboration Diagrams. • Describe interactions between objects arranged in time sequence • Focus on objects and classes involved in the scenario and the sequence of messages exchanged • Associated with use cases • Used heavily during Analysis phase and are enhanced and refined during Design phase

26. UML :CheckoutMgr Cust:Customer :Inventory :RentedItems :Employee 1: find customer() 2: search (string) Object 3: enter movie() 4: search (string) Activation Message 5: rent (movie) 6: add(Cust, item) Lifeline 7: printInvoice() 8: generateRentalTotal() Sequence Diagrams – Rent a Movie

27. UML Class Package Package Diagrams

28. UML Component Interface Dependency Note Component Diagram

29. UML Node Communication Association Deployment Diagram

30. UML Start State Identify Caller Action State Decision Obtain Name & Address Open Account? Current Customer? [no] [no] [yes] End State [yes] Create Account Activity Diagram

31. UML Customer Manager Walking Clerk Identify Movie Fork Point Place Order Place Order Fill Order Pay Collect Money Pickup Movie Deliver Movie Join Point Swimlanes and Fork/Join Points

32. UML Guard Event Transition Action Activity State State Diagram

33. UML UML Diagrams Usage

34. UML CASE STUDY – The KIWI Project - Use Cases for Milan Prefecture Main Actors

35. UML CASE STUDY – The KIWI Project - Use Cases for Milan Prefecture External Actors

36. UML CASE STUDY – The KIWI Project - Use Cases for Milan Prefecture Workflow on the fly

37. UML CASE STUDY – The KIWI Project – Activity Diagram Back End Process

38. UML CASE STUDY – The KIWI Project – Sequence Diagram Workflow on the fly