OHT 11.1 © Marketing Insights Limited 2004 Chapter 9 Analysis and Design EC Security.

OHT 11.1

© Marketing Insights Limited 2004

Chapter 9Analysis and Design

EC Security

OHT 11.2


Workflow management

Workflow is ‘the automation of a business process, in whole or part during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.’

Examples:• Booking a holiday• Handling a customer complaint• Receiving a customer order

OHT 11.3


Process modelling

• Often use a hierarchical method of establishing– the processes and their constituent sub-

processes– the dependencies between processes– the inputs (resources) needed by the

processes and the outputs

• Complete activity 11.2 using Figure 11.2 and Table 11.2 for how to improve processes

OHT 11.4


Symbols used for flow process charts

Figure 11.2 Symbols used for flow process charts

OHT 11.5


Flow process chart showing the main operations performed by

users when working using workflow software

Figure 11.3 Flow process chart showing the main operations performed by users when working using workflow software

OHT 11.6


Data modelling

• Uses well established techniques used for relational database design

• Stages:1. Identify entities

2. Identify attributes of entities

3. Identify relationships

OHT 11.7


1. Identify entities

• Entities define the broad groupings of information such as information about different people, transactions or products. Examples include customer, employee, sales orders, purchase orders. When the design is implemented each design will form a database table.

• Entity A grouping of related data, example customer entity. Implementation as table.

• Database table Each database comprises several tables.

OHT 11.8


2 Identify attributes

• Entities have different properties known as attributes that describe the characteristics of any single instance of an entity. For example, the customer entity has attributes such as name, phone number and e-mail address. When the design is implemented each attribute will form a field, and the collection of fields for one instance of the entity such as a particular customer will form a record.

• Attribute A property or characteristic of an entity, implementation as field.

• K Field Attributes of products, example date of birth.• L Record A collection of fields for one instance of an

entity, example Customer Smith.

OHT 11.9


3 Identify relationships

• The relationships between entities requires identification of which fields are used to link the tables. For example, for each order a customer places we need to know which customer has placed the order and which product they have ordered. As is evident from Figure 11.5, the fields customer id and product id are used to relate the order information between the three tables. The fields that are used to relate tables are referred to as key fields. A primary is used to uniquely identify each instance of an entity and a secondary key is used to link to a primary key in another table.

• Relationship Describes how different tables are linked.• Primary key The field that uniquely identifies each record in a

table.• Secondary key A field that is used to link tables, by linking to a

primary key in another table.

OHT 11.10


Generic B2C ER diagram

Figure 11.5 Generic B2C ER diagram

OHT 11.11


Client / server architecture – separation of functions

• Data storage. Predominantly on server. Client storage is ideally limited to cookies for identification of users and session tracking. Cookie identifiers for each system user are then related to the data for the user which is stored on a database server.

• Query processing. Predominntly on the server, although some validation can be performed on the client.

• Display. This is largely a client function.• Application logic. Traditionally, in early PC applications

this has been a client function, but for e-business systems the design aim is to maximize the application logic processing including the business rules on the server.

OHT 11.12


Three-tier client server in an e-business environment

Figure 11.6 Three-tier client server in an e-business environment

OHT 11.13


E-business architecture for the B2C company

Figure 11.7 E-business architecture for The B2C Company

OHT 11.14


User centred design

‘Unless a web site meets the needs of the intended users it will not meet the needs of the organization providing the web site.

Web site development should be user-centred, evaluating the evolving design against user requirements.’

(Bevan, 1999a)

OHT 11.15


Analysis considerations (Bevan)

• Who are the important users?• What is their purpose for accessing the site?• How frequently will they visit the site?• What experience and expertise do they have?• What nationality are they? Can they read English?• What type of information are they looking for?• How will they want to use the information: read it on

the screen, print it or download it?• What type of browsers will they use? How fast will

their communication links be?• How large a screen/window will they use, with how

many colours?

OHT 11.16


Use-case analysis

• The use-case method of process analysis and modelling was developed in the early 1990s as part of the development of object-oriented techniques. It is part of a methodology known as Unified Modelling Language (UML) that attempts to unify the approaches that preceded it such as the Booch, OMT and Objectory notations.

• Use-case modelling A user-centred approach to modelling system requirements.

• Unified Modelling Language (UML) A language used to specify, visualize and document the artefacts of an object-oriented system.

OHT 11.17


Schneider and Winters (1998) stages in Use Case

• Identify actors. Actors are typically application users such as customers and employers also other systems.

• Identify use-cases. The sequence of transactions between an actor and a system that support the activities of the actor.

• Relate actors to use-cases. See Figure 11.8.

• Develop use-case scenarios. See Figure 11.9 for a detailed scenario.

OHT 11.18


Relationship between actors and use-cases for the B2C Company,

sell-side e-commerce site

Figure 11.8 Relationship between actors and use-cases for The B2C Company, sell-side e-commerce site

OHT 11.19


Parties involved in secure transactions

• Purchasers. These are the consumers buying the goods.

• Merchants. These are the retailers.• Certification Authority (CA). This is a body that

issues digital certificates that confirm the identity of purchasers and merchants.

• Banks. These are traditional banks.• Electronic token issuer. A virtual bank that

issues digital currency.

OHT 11.20


Main security risks

• (a) Transaction or credit card details stolen in transit.

• (b) Customer’s credit card details stolen from merchant’s server.

• (c) Merchant or customer is not who they claim to be.

OHT 11.21


Security requirements for e-commerce

• Authentication – are parties to the transaction who they claim to be?

• Privacy and confidentiality – is transaction data protected? The consumer may want to make an anonymous purchase. Are all non-essential traces of a transaction removed from the public network and all intermediary records eliminated?

• Integrity – checks that the message sent is complete i.e. that it isn’t corrupted.

• Non-repudiability – ensures sender cannot deny sending message.

• Availability – how can threats to the continuity and performance of the system be eliminated?

OHT 11.22


Public-key or asymmetric encryption

Figure 11.18 Public-key or asymmetric encryption

OHT 11.23


SET

Figure 11.19 An example of the Secure Electronic Transaction (SET) standard

OHT 11.24


The Open Buying on the Internet model for business-to-business e-commerce

Figure 11.20 The Open Buying on the Internet model for business-to-business e-commerce transactions

OHT 11.1 © Marketing Insights Limited 2004 Chapter 9 Analysis and Design EC Security.

Documents

Transcript of OHT 11.1 © Marketing Insights Limited 2004 Chapter 9 Analysis and Design EC Security.