Training of master Trainers Workshop e-Services Design and Delivery

Slides:



Advertisements
Similar presentations
Database development (MIS 533) MBS in Management Information Systems and Managerial Accounting Systems (2007 / 2008) Fergal Carton Business Information.
Advertisements

Developing ER-Diagram
Alternative Approach to Systems Analysis Structured analysis
Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS6th Edition.
Data & Process Modeling
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 9 Slide 1 Appendix 3 Object-Oriented Analysis and Design.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall A.1.
1 Review Visual System Modeling Tools Todd Bacastow Penn State University Geospatial System Analysis & Design.
Introduction to UML Todd Bacastow Penn State University Geography 583 Geospatial System Analysis & Design.
System Analysis - Data Modeling
Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS6th Edition.
Agenda for Week 1/31 & 2/2 Learn about database design
Data Modeling Entity - Relationship Models. Models Used to represent unstructured problems A model is a representation of reality Logical models  show.
Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition.
C++ Training Datascope Lawrence D’Antonio Lecture 11 UML.
© Copyright Eliyahu Brutman Programming Techniques Course.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix.
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
Lesson-19 Data Modeling and Analysis
Lesson-21Process Modeling Define systems modeling and differentiate between logical and physical system models. Define process modeling and explain its.
Unified Modeling Language
BIS310: Week 7 BIS310: Structured Analysis and Design Data Modeling and Database Design.
Chapter 3 Object-Oriented Analysis of Library Management System(LMS)
UML Sequence Diagrams Michael L. Collard, Ph.D. Department of Computer Science Kent State University.
Introduction to Entity-Relationship Diagrams, Data Flow Diagrams, and UML Todd Bacastow Penn State University Geography 583 Geospatial System Analysis.
UML Overview. UML Diagrams to be Covered Class Diagrams Use Case Diagrams Collaboration Diagrams Sequence Diagrams Package Diagrams Component Diagrams.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
CMIS 470 Structured Systems Design
Object-oriented methodology object models use case modeling unified modeling language the data dictionary the cornucopia case portfolio project Systems.
Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition.
Sample Entity Relationship Diagram (ERD)
Systems Analysis and Design in a Changing World, Fifth Edition
Business Process Modeling
CIT UPES | Sept 2013 | Unified Modeling Language - UML.
1 CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design) Lecture 05: Data Modeling and Analysis.
BIS 360 – Lecture Six (Part 2) Conceptual Data Modeling (Chapter 10 and partial Chapter 12)
Prepared by Afra`a Sayah. Introduction. Weekly Tasks. Plane Phase. Analysis Phase. Design Phase. Report Rules. Conclusion. 2.
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix A Object-Oriented.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Chapter 5 Models and UML Notation for The Object-Oriented Approach.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
Fall 2010 CS4310 Requirements Engineering A Brief Review of UML & OO Dr. Guoqiang Hu Department of Computer Science UTEP 1.
Lecture 4 Conceptual Data Modeling. Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship,
IFS310: Module 6 3/1/2007 Data Modeling and Entity-Relationship Diagrams.
1/26 On-demand Learning Series Software Engineering of Web Application - Object-Oriented Development & UML Hunan University, Software School.
Introduction to UML CS A470. What is UML? Unified Modeling Language –OMG Standard, Object Management Group –Based on work from Booch, Rumbaugh, Jacobson.
Domain Classes – Part 1.  Analyze Requirements as per Use Case Model  Domain Model (Conceptual Class Diagram)  Interaction (Sequence) Diagrams  System.
Databases : Database Building Procedures 2007, Fall Pusan National University Ki-Joune Li.
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
Introduction to UML Todd Bacastow Rational Unified Process A process for the effective implementation of key “Best Practices” Control Changes Manage.
Chapter 3: Introducing the UML
EntityRelationshipDiagrams. Entity Relationship Models The E-R (entity-relationship) data model views the real world as a set of basic objects (entities)
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Appendix A Object-Oriented Analysis and Design A.1.
Technical Module C Object Modeling Objects Object – a valuable resource: Money (Account Receivable) Material (Product) Machines (Delivery Truck) Personnel.
1 More About UML Todd Bacastow Penn State University Geospatial System Analysis & Design.
1 Documenting Solutions Todd Bacastow Penn State University Geog 468 GIS Analysis & Design.
Inf 43: Introduction to Software Engineering May 7, 2016.
Appendix 3 Object-Oriented Analysis and Design
Introduction to UML Todd Bacastow Penn State University Geography 583 Geospatial System Analysis & Design.
UML Diagrams By Daniel Damaris Novarianto S..
The Movement To Objects
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Object-Oriented Analysis and Design
Unified Modeling Language
UML Diagrams Jung Woo.
Lecture on Data Modeling and Analysis
Object-Oriented Design of Spatial Entities Todd Bacastow
Unified Modeling Language
Analysis models and design models
Entity Relationship Model
Presentation transcript:

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

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 10 slide design tips for producing powerful and effective presentations 13Comments more + By Guest Contributor September 19, 2006, 7:00am PDT This article is also available as a PDF download. By Garr Reynolds #1: Keep it simple PowerPoint uses slides with a horizontal, or Landscape,orientation. The software was designed as a convenient way to display graphicalinformation that would support the speaker and supplement the presentation. Theslides themselves were never meant to be the star of the show. (The star, ofcourse, is your audience.) People came to hear you and be moved or informed (orboth) by you and your message. Don't let your message and your ability to tella story get derailed by slides that are unnecessarily complicated, busy, orfull of what Edward Tufte calls "chartjunk." Nothing in your slide should be superfluous, ever. Your slides should have plenty of white space, or negativespace. Do not feel compelled to fill empty areas on your slide with your logoor other unnecessary graphics or text boxes that do not contribute to betterunderstanding. The less clutter you have on your slide, the more powerful yourvisual message will become. #2 Limit bullet points and text Your presentationis for the benefit of the audience. But boring an audience with bullet pointafter bullet point is of little benefit to them. Which brings us to the issueof text. The best slides may have no text at all. This may sound insane giventhe dependency of text slides today, but the best PowerPoint slides will bevirtually meaningless without the narration (that is you). Remember, the slidesare meant to support the narration of the speaker, not make the speakersuperfluous. Many people oftensay something like this: "Sorry I missed your presentation. I hear it wasgreat. Can you just send me your PowerPoint slides?" But if they are goodslides, they will be of little use without you. Instead of a copy of yourPowerPoint slides, it is far better to prepare a written document thathighlights your content from the presentation and expands on that content.Audiences are much better served receiving a detailed, written handout as atakeaway from the presentation, rather than a mere copy of your PowerPointslides. If you have a detailed handout or publication for the audience to bepassed out after your talk, you need not feel compelled to fill yourPowerPoint slides with a great deal of text. We'll talk moreabout this in the delivery section below, but as long as we are talking abouttext, please remember to never, ever turn your back on the audience and readtext from the slide word for word.   This slide is not unusual, but it is not a visual aid, it is more like an eye chart.  Try to avoid text-heavy (and sleep inducing) slides like this one.  Aim for something like this simple slide above.  And this is even better.#3: Limit transitions and builds (animation) Use object builds and slide transitions judiciously. Objectbuilds (also called animations), such as bullet points, should not be animatedon every slide. Some animation is a good thing, but stick to the most subtleand professional (similar to what you might see on the evening TV news broadcast).A simple Wipe Left-to-Right (from the Animations menu) is good fora bullet point, but a Move or Fly, for example, is too tedious and slow (andyet, is used in many presentations today). Listeners will get bored quickly ifthey are asked to endure slide after slide of animation. For transitionsbetween slides, use no more than two or three types of transition effects anddo not place transition effects between all slides. #4: Use high quality graphics Use high qualitygraphics, including photographs. You can take your own high quality photographswith your digital camera, purchase professional stock photography, or use theplethora of high quality images available online. (But be cautious of copyrightissues.) Never simply stretch a small, low-resolution photo to make it fit yourlayout--doing so will degrade the resolution even further. Avoid usingPowerPoint Clip Art or other cartoonish line art.Again, if it is included in the software, your audience has seen it a milliontimes before. It may have been interesting in 1993, but today the inclusion ofsuch clip art often undermines the professionalism of the presenter. There areexceptions, of course, and not all PowerPoint art is dreadful, but use itcarefully and judiciously. I often use imagesof people in my slides, as photography of people tends to help the audienceconnect with the slide on a more emotional level. If the photographic image issecondary in importance, then I decrease the opacity and add a Gaussian Blur ormotion filter in Photoshop. If the photographic image is the primary area Iwant the audience to notice (such as a picture of a product), then the imagecan be more pronounced and little (or no) text is needed. Try to avoid cheesy clip art like this.  This edited stock photograph is more effective and professional.  In this title slide, the image is primary.  In this slide from the same presentation, the image is secondary and pushedto the back by editing it first in Photoshop.#5: Have a visual theme but avoid using PowerPoint templates You clearly need a consistent visual theme throughout yourpresentation, but most templates included in PowerPoint have been seen by youraudience countless times (and besides, the templates are not all that great tobegin with). Your audience expects a unique presentation with new (at least tothem) content; otherwise, why would they be attending your talk? No audiencewill be excited about a cookie-cutter presentation, and we must therefore shyaway from any supporting visuals, such as the ubiquitous PowerPoint DesignTemplate, that suggests your presentation is formulaic or prepackaged. You can make your own background templates, which will bemore tailored to your needs. You can then save the PowerPoint file as a DesignTemplate (.pot) and the new template will appear among your standard Microsofttemplates for your future use. You can also purchase professional templates online. #6: Use appropriate charts Always be asking yourself, "How much detail do Ineed?" Presenters are usually guilty of including too much data in theironscreen charts. There are several ways to display your data in graphic form;here are a few things to keep in mind: Pie charts. Usedto show percentages. Limit the slices to 4-6 and contrast the most importantslice either with color or by exploding the slice.  Vertical bar charts.Used to show changes in quantity over time. Best if you limit the bars to 4-8.  Horizontal bar charts.Used to compare quantities. For example, comparing sales figures among the fourregions of the company.  Line charts. Usedto demonstrate trends. For example, here is a simple line chart showing thatour sales have gone up every year. The trend is good. The arrow comes in laterto underscore the point: Our future looks good!  In general, tables are well suited for side-by-sidecomparisons of quantitative data.  However, tables can lack impact on a visceral level. If youwant to show how your contributions are significantly higher than two otherparties, for example, it would be best to show that in the form of a bar chart(below). But if you're trying to downplaythe fact that your contributions are lower than others, a table will displaythat information in a less dramatic or emotional way.  #7: Use color well Color evokes feelings. Color is emotional. The right colorcan help persuade and motivate. Studies show that color usage can increaseinterest and improve learning comprehension and retention. Youdo not need to be an expert in color theory, but it's good for businessprofessionals to know at least a bit on the subject. Colors can be divided intotwo general categories: cool (such as blue and green) and warm (such as orangeand red). Cool colors work best for backgrounds, as they appear to recede awayfrom us into the background. Warm colors generally work best for objects in theforeground (such as text) because they appear to be coming at us. It is nosurprise, then, that the most ubiquitous PowerPoint slide color scheme includesa blue background with yellow text. You do not need to feel compelled to usethis color scheme, although you may choose to use a variation of those colors. If you will be presenting in a dark room(such as a large hall), a dark background (dark blue, gray, etc.) with white orlight text will work fine. But if you plan to keep most of the lights on (whichis highly advisable), a white background with black or dark text works muchbetter. In rooms with a good deal of ambient light, a screen image with a darkbackground and light text tends to washout, but dark text on a light backgroundwill maintain its visual intensity a bit better. Learn more: PresentationPro.com has some great Flash tutorials, including oneon color. Dummies.com has a good short article on how to usethe Color Schemes in PowerPoint.

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

e- Service Design & Delivery: the Technical Perspective 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 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.

e- Service Design & Delivery: the Technical Perspective Data Modelling Concept: Attribute 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.

e- Service Design & Delivery: the Technical Perspective Data Modelling Concept: Identification 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.

e- Service Design & Delivery: the Technical Perspective Data Modelling Concept: Relationship 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.

e- Service Design & Delivery: the Technical Perspective Data Modelling Concept: Cardinality 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.

e- Service Design & Delivery: the Technical Perspective Data Modelling Concept: Degree 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.

e- Service Design & Delivery: the Technical Perspective Logical System Models 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.

e- Service Design & Delivery: the Technical Perspective Difference between DFDs and Flowcharts 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

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.

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

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

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

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

-- can optionally be described here. UML Parts of a Class 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.

UML Object Diagrams 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. ThisOne : MyClassName +SomePublicAttribute : SomeType -SomePrivateAttribute : SomeType #SomeProtectedAttribute : SomeType +ClassMethodOne() +ClassMethodTwo()

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

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.

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

UML Use Case Report 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. Brief description Precondition Flow of events Main flow Subflows Alternate flows Postcondition Special Requirements Enclosures Diagrams Pictures of the UI

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

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

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

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

UML Package Diagrams Class Package

UML Component Diagram Component Interface Dependency Note

UML Deployment Diagram Node Communication Association

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

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

UML Guard State Diagram Event Transition Action Activity State

UML UML Diagrams Usage

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

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

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

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

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