How to draw Use case Diagram Sequence Diagram Class Diagram Database Diagram for software projects with symbols and examples

How to start a software project ? Pre conditions to follow. 

Sample Project Proposal: Absence Request and Vacation Schedule Management
Example Project Proposal: Online Examination and Evaluation System

·          Use case Diagram

·          Sequence Diagram

·          Class Diagram

·          Database Diagram

What is a UML Use Case Diagram?

Use case diagrams model the functionality of a system using actors and use cases. Use cases are services or functions provided by the system to its users.

YouTube https://www.youtube.com/channel/UCJojbxGV0sfU1QPWhRxx4-A
LinkedIn https://www.linkedin.com/in/ict-bit-tuition-class-software-development-colombo/
WordPress https://computerclassinsrilanka.wordpress.com
quora https://www.quora.com/profile/BIT-UCSC-UoM-Final-Year-Student-Project-Guide
Newsletter https://sites.google.com/view/the-leaning-tree/newsletter
Wix https://itclasssl.wixsite.com/icttraining
Web https://itclass-bit-ucsc-uom-php-final-project.business.site/
mystrikingly https://bit-ucsc-uom-final-year-project-ideas-help-guide-php-class.mystrikingly.com/
https://elakiri.com/threads/bit-ucsc-uom-php-mysql-project-guidance-and-individual-classes-in-colombo.1627048/
ucsc bit registration 2023 bit (ucsc syllabus) bit colombo university fees bit results bit vle bit course fee bit exam time table 2023 bit moratuwa

Basic Use Case Diagram Symbols and Notations

System

Draw your system's boundaries using a rectangle that contains use cases. Place actors outside the system's boundaries.

Use Case

Draw use cases using ovals. Label with ovals with verbs that represent the system's functions.

Actors

Actors are the users of a system. When one system is the actor of another system, label the actor system with the actor stereotype.

Relationships

Illustrate relationships between an actor and a use case with a simple line. For relationships among use cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates that one use case is needed by another in order to perform a task. An "extends" relationship indicates alternative options under a certain use case.
Learn how to draw relationships.

https://www.andrew.cmu.edu/course/90-754/umlucdfaq.html

With the help of a use case diagram, you can discuss and communicate:

• The scenarios in which your system or application interacts with people, organizations, or external systems.
• The goals that it helps those actors achieve.
• The scope of your system.

A use case diagram does not show the detail of the use cases: it only summarizes some of the relationships between use cases, actors, and systems. In particular, the diagram does not show the order in which steps are performed to achieve the goals of each use case. You can describe those details in other diagrams and documents, which you can link to each use case. For more information, see Describing Use Cases in Detail in this topic.

The descriptions you provide for use cases will use several terms related to the domain in which the system works, such as Sale, Menu, Customer, and so on. It is important to define these terms and their relationships clearly, and you can do that with the help of a UML Class Diagram. For more information, see UML Class Diagrams: Guidelines.

Use cases deal only in the functional requirements for a system. Other requirements such as business rules, quality of service requirements, and implementation constraints must be represented separately. Architecture and internal details must also be described separately. For more information about how to define user requirements, see Modeling User Requirements.

The examples used in this topic relate to a Web site on which customers can order meals from local restaurants.

• An actor (1) is a class of person, organization, device, or external software component that interacts with your system. Example actors are Customer, Restaurant,Temperature Sensor, Credit Card Authorizer.
• A use case (2) represents the actions that are performed by one or more actors in the pursuit of a particular goal. Example use cases are Order Meal, Update Menu,Process Payment.

On a use case diagram, use cases are associated (3) with the actors that perform them.

• Your system (4) is whatever you are developing. It might be a small software component, whose actors are just other software components; or it might be a complete application; or it might be a large distributed suite of applications deployed over many computers and devices. Example subsystems are Meal Ordering Website, Meal Delivery Business, Website Version 2.

A use case diagram can show which use cases are supported by your system or its subsystems.

Drawing Actors and Use Cases

The main purpose of a use case diagram is to show who interacts with your system, and the main goals they achieve with it.

·         Create Actors to represent classes of people, organizations, other systems, software or devices that interact with your system or subsystem.

o    To learn how to draw actors and other elements, see How to: Edit UML Models and Diagrams.

o    For each distinct set of goals, identify actors by their type or role, even though the physical persons or entities might be the same. For example, Restaurant and Customer are separate actors, even though a restaurant employee might sometimes be a customer.

·         Create Use Cases for each of the goals that each actor seeks to achieve with the system.

o    Name and describe the use cases in words that the actor would understand, instead of implementation terms.

·         Use Associations to link actors to use cases.

Inheritance between Actors

You can draw a Generalization link between Actors. The specialized actor, such as Club Customer in the example, inherits the use cases of the generalized actor, such as Customer. The arrowhead should point at the more general actor, such as Customer. When you create the link, point first at the more specialized actor.

The specialized actor can have its own additional use cases that are not available to the other actors.

Structuring Use Cases

You should try to describe your system's behavior with just a few major use cases. Each large use case defines a major goal that an actor achieves, such as buying a product, or, from the vendor's point of view, providing products for sale.

When you have made these goals clear, you can go into more detail about how the each goal is achieved, and about variations in the basic goals.

Avoid decomposing the use cases into too much detail. Use cases are about the users' experience of your system, instead of its internal workings. Additionally, you will generally find it more productive to create early working versions of the code, instead of spending time structuring use cases into fine detail.

You can summarize on a use case diagram the relationships between major and more detailed use cases. The following sections describe this:

 

Showing the details of a use case with Include

Use an Include relation to show that one use case describes some of the detail of another. In the illustration, Order a Meal includes Pay, Choose Menu, and Choose Menu Item. Each of the included, more detailed use cases is a step that the actor or actors might have to perform to achieve the overall goal of the including use case. The arrow should point at the more detailed, included use case.

You can share included use cases. In the example, the Order a Meal and Subscribe to Reviews use cases both include Pay.

The goal and scenarios of an included use case should make sense independently so that it can be included in use cases that are designed later.

Separating use cases into including and included parts is useful to achieve the following goals:

·         Structure your use case descriptions into different layers of detail.

·         Avoid repeating shared scenarios in different use cases.

Sharing goals with Generalization

Use a Generalization relation to show that a specialized use case is a particular way to achieve the goals expressed by another general use case. The open arrowhead should point at the more general use case.

For example, Pay generalizes Pay by Credit Card and Pay by Cash.

Separating variant cases with Extend

Use an Extend link to show that one use case may add functionality to another use case under certain circumstances. The arrow should point at the main, extended use case.

System versions

You can use different subsystem boundaries to illustrate different versions of the system. For example, the Pay use case might be included in Website Version 2 but not in Version 1.This implies that the system helps customers make their orders. However, they have to pay the restaurant directly.

Use Dependency relations to link subsystems representing different versions or variants.

Basic Use case Diagram For Hotel Management System

Sample use case diagram for Patient Management System

Use-case diagram for Library management system

What is a UML Sequence Diagram?

Sequence diagrams describe interactions among classes in terms of an exchange of messages over time.

Basic Sequence Diagram Symbols and Notations

What is a UML Sequence Diagram?

Sequence diagrams describe interactions among classes in terms of an exchange of messages over time.

Basic Sequence Diagram Symbols and Notations

Class roles

Class roles describe the way an object will behave in context. Use the UML object symbol to illustrate class roles, but don't list object attributes.
Learn how to edit text on a symbol.

Activation

Activation boxes represent the time an object needs to complete a task.

Messages

Messages are arrows that represent communication between objects. Use half-arrowed lines to represent asynchronous messages. Asynchronous messages are sent from an object that will not wait for a response from the receiver before continuing its tasks.
Learn how to draw messages.

 
Various message types for Sequence and Collaboration diagrams

Lifelines

Lifelines are vertical dashed lines that indicate the object's presence over time.
Learn how to attach activation boxes to lifelines.

Destroying Objects

Objects can be terminated early using an arrow labeled "<< destroy >>" that points to an X.

Loops

A repetition or loop within a sequence diagram is depicted as a rectangle. Place the condition for exiting the loop at the bottom left corner in square brackets [ ].
Learn how to arrange objects on a page.

The diagram below shows how objects interact in the "rent item" collaboration when the item is not available during the requested period.

http://www.tracemodeler.com/articles/a_quick_introduction_to_uml_sequence_diagrams/

Objects as well as classes can be targets on a sequence diagram, which means that messages can be sent to them. A target is displayed as a rectangle with some text in it. Below the target, its lifeline extends for as long as the target exists. The lifeline is displayed as a vertical dashed line.

Object

The basic notation for an object is

Where 'name' is the name of the object in the context of the diagram and 'Type' indicates the type of which the object is an instance. Note that the object doesn't have to be a direct instance of Type, a type of which it is an indirect instance is possible too. So 'Type' can be an abstract type as well.

Both name and type are optional, but at least one of them should be present. Some example :

As with any UML-element, you can add a stereotype to a target. Some often used stereotypes for objects are «actor», «boundary», «control», «entity» and «database». They can be displayed with icons as well :

An object should be named only if at least one of the following applies

·        You want to refer to it during the interaction as a message parameter or return value

·        You don't mention its type

·        There are other anonymous objects of the same type and giving them names is the only way to differentiate them

Try to avoid long but non-descriptive names when you're also specifying the type of the object (e.g. don't use 'aStudent' for an instance of type Student). A shorter name carries the same amount of information and doesn't clutter the diagram (e.g. use 's' instead).

MultiObject

When you want to show how a client interacts with the elements of a collection, you can use a multiobject. Its basic notation is

Again, a name and/or type can be specified. Note however that the 'Type' part designates the type of the elements and not the type of the collection itself.

Class

The basic notation for a class is

Only class messages (e.g. shared or static methods in some programming languages) can be sent to a class. Note that the text of a class is not underlined, which is how you can distinguish it from an object.

When a message is prefixed with an asterisk (the '*'-symbol), it means that the message is sent repeatedly. A guard indicates the condition that determines whether or not the message should be sent (again). As long as the condition holds, the message is repeated.

The above interaction of repeatedly sending the same message to the same object is not very useful, unless you need to document some kind of polling scenario.

A more common use of repetition is sending the same message to different elements in a collection. In such a scenario, the receiver of the repeated message is a multiobject and the guard indicates the condition that controls the repetition.

This corresponds to an iteration over the elements in the collection, where each element receives the message. For each element, the condition is evaluated before the message is sent. Usually though, the condition is used as a filter that selects elements from the collection (e.g. 'all', 'adults', 'new customers' as filters for a collection of Person objects). Only elements selected by the filter will receive the message.

If you want to show that multiple messages are sent in the same iteration, a 'loop' combined fragment can be used. The operator of the combined fragment is 'loop' and the guard represents the condition to control the repetition.

Again, if the receiver of a repeated message is a collection, the condition is generally used to specify a filter for the elements.

For example, to show that the bounds of a drawing are based on those of its visible figures we could draw the following sequence diagram :

Several things are worth noting in this example

·        a local variable 'r' was introduced to clarify that it is the result of getBounds that is added.

·        naming the resulting Rectangle 'bounds' avoids the introduction of an extra local variable.

·        the loop condition is used as a filter on the elements of the figures collection.

What is a UML Class Diagram?

What is a UML Class Diagram?

Class diagrams are the backbone of almost every object-oriented method including UML. They describe the static structure of a system.

Basic Class Diagram Symbols and Notations

Classes represent an abstraction of entities with common characteristics. Associations represent the relationships between classes.

Illustrate classes with rectangles divided into compartments. Place the name of the class in the first partition (centered, bolded, and capitalized), list the attributes in the second partition, and write operations into the third.
Learn how to create this symbol.

Active Class

Active classes initiate and control the flow of activity, while passive classes store data and serve other classes. Illustrate active classes with a thicker border.

Visibility

Use visibility markers to signify who can access the information contained within a class. Private visibility hides information from anything outside the class partition. Public visibility allows all other classes to view the marked information. Protected visibility allows child classes to access information they inherited from a parent class. Learn how to edit text.

Associations

Associations represent static relationships between classes. Place association names above, on, or below the association line. Use a filled arrow to indicate the direction of the relationship. Place roles near the end of an association. Roles represent the way the two classes see each other.
Note: It's uncommon to name both the association and the class roles.
Learn how to edit text.

Multiplicity (Cardinality)

Place multiplicity notations near the ends of an association. These symbols indicate the number of instances of one class linked to one instance of the other class. For example, one company will have one or more employees, but each employee works for one company only.

Constraint

Place constraints inside curly braces {}.

 Simple Constraint

Composition and Aggregation

Composition is a special type of aggregation that denotes a strong ownership between Class A, the whole, and Class B, its part. Illustrate composition with a filled diamond. Use a hollow diamond to represent a simple aggregation relationship, in which the "whole" class plays a more important role than the "part" class, but the two classes are not dependent on each other. The diamond end in both a composition and aggregation relationship points toward the "whole" class or the aggregate.

Generalization

Generalization is another name for inheritance or an "is a" relationship. It refers to a relationship between two classes where one class is a specialized version of another. For example, Honda is a type of car. So the class Honda would have a generalization relationship with the class car.

In real life coding examples, the difference between inheritance and aggregation can be confusing. If you have an aggregation relationship, the aggregate (the whole) can access only the PUBLIC functions of the part class. On the other hand, inheritance allows the inheriting class to access both the PUBLIC and PROTECTED functions of the superclass.

In real life coding examples, the difference between inheritance and aggregation can be confusing. If you have an aggregation relationship, the aggregate (the whole) can access only the PUBLIC functions of the part class. On the other hand, inheritance allows the inheriting class to access both the PUBLIC and PROTECTED functions of the superclass.
Learn how to draw a generalization relationship.

http://www.smartdraw.com/resources/tutorials/uml-use-case-diagram/#/resources/tutorials

UML Class Diagram Relationships, Aggregation, Composition

There are five key relationships between classes in a UML class diagram : dependency, aggregation, composition, inheritance and realization. These five relationships are depicted in the following diagram:

UML Class Relationships

The above relationships are read as follows:

• Dependency : class A uses class B
• Aggregation : class A has a class B
• Composition : class A owns a class B
• Inheritance : class B is a Class A  (or class A is extended by class B)
• Realization : class B realizes Class A (or class A is realized by class B)

What I hope to show here is how these relationships would manifest themselves in Java so we can better understand what these relationships mean and how/when to use each one.

Dependency is represented when a reference to one class is passed in as a method parameter to another class. For example, an instance of class B is passed in to a method of class A:  

?

1 2 3

public class A {     public void doSomething(B b) {

Now, if class A stored the reference to class B for later use we would have a different relationship called Aggregation. A more common and more obvious example of Aggregation would be via setter injection:

?

1 2 3 4 5

public class A {     private B _b;     public void setB(B b) { _b = b; }

Aggregation is the weaker form of object containment (one object contains other objects). The stronger form is calledComposition. In Composition the containing object is responsible for the creation and life cycle of the contained object (either directly or indirectly). Following are a few examples of Composition. First, via member initialization:

?

1 2 3

public class A {     private B _b = new B();

Second, via constructor initialization:

?

1 2 3 4 5 6 7

public class A {     private B _b;     public A() {         _b = new B();     } // default constructor

Third, via lazy init (example revised 02 Mar 2014 to completely hide reference to B):

?

1 2 3 4 5 6 7 8 9 10

public class A {     private B _b;     public void doSomethingUniqueToB() {         if (null == _b) {             _b = new B();         }         return _b.doSomething();     } // doSomethingUniqueToB()

Inheritance is a fairly straightforward relationship to depict in Java:

?

1 2 3 4 5 6 7 8 9 10 11

public class A {     ... } // class A public class B extends A {     .... } // class B

Realization is also straighforward in Java and deals with implementing an interface:

?

1 2 3 4 5 6 7 8 9 10 11

public interface A {     ... } // interface A public class B implements A {     ... } // class B Ref http://usna86-techbits.blogspot.com/2012/11/uml-class-diagram-relationships.html

Library Management system Sequence diagram

Online Shopping cart Sequence diagram

What is a Database Diagram?

Entity Relationship Diagram Symbols and Meaning ERD Symbols

T ConceptDraw PRO Discover the World of Visual Communication© Design elements Crow’s Foot notation ConceptDraw gives the ability to describe visually a database using the Crow’s Foot notation icons for drawing ER diagrams - ERD. Entity-Relationship model making possibility to describe a database in which in the tables data can be the point to data in other tables - for instance, your entry in the database could point to several entries.                 The symbols below are used at the most granular level of ERDs: physical data models, although some elements are also used for logical data models. Tables are another way of representing entities. Fields represent attributes of the entity. Keys are one way to categorize attributes. A primary key is an attribute or combination of attributes that uniquely identifies one and only one instance of an entity. The primary key becomes a foreign key in any entity type to which it's related through a one-to-one or one-to-many relationship. Types may refer to the type of data associated with the corresponding field in a table. Types can also refer to entity types, which describe the structure of an entity; e.g., a book's entity types are author, title, and published date.

Visual Database diagram Creation with MySQL Workbench

Edexcel gcse ICT Unit 2 The Digital Economy Divide Notes Samples images practical classes marked by your teacher website investigation database evaluation

• Unit 2— The Digital Economy

In a world dominated by the global e-marketplace websites are the interface between customers and organisations, allowing them to do business with one another anytime, anywhere. Enhanced connectivity underpins the growth of the digital economy. The increase in internet-enabled computers in the home and the use of credit cards to pay for goods are major factors in its evolution.

Consumers exercise greater autonomy and have more choice than is available to them offline in their own locality. They expect to receive a personalised service and an instant response.

In this unit, you will investigate how organisations are responding to the pressures of the e-marketplace by using transactional websites to:

• present their products and services
• gather information
• provide a personalised service.

As an informed ICT user, you need to be aware of the methods used by organisations to persuade their customers to reveal personal information about themselves and what it is used for.

Security and privacy are two key concerns for organisations and individuals operating in the digital economy. You will assess potential threats to customer data and evaluate the effectiveness of current legislation and measures taken by organisations to protect data.

Databases are key to managing the large amount of data that organisations collect. You will learn how to use database software to analyse data and identify trends and patterns.

Your work for this unit will be an in-depth investigation into the design of a commercial transactional website and the back-office processes involved in handling an online purchase.

This is a user-focused unit. The knowledge and skills developed in this unit are particularly relevant to those who use ICT on a daily basis at work or at school/college for personal, social and work-related purposes.

What is Digital divide ?

Digital divide is a term that refers to the gap between demographics and regions that have access to modern information and communications technology, and those that don't or have restricted access. This technology can include the telephone, television, personal computers and the Internet.

Well before the late 20th century, digital divide referred chiefly to the division between those with and without telephone access; after the late 1990s the term began to be used mainly to describe the split between those with and without Internet access, particularlybroadband.

The digital divide typically exists between those in cities and those in rural areas; between the educated and the uneducated; between socioeconomic groups; and, globally, between the more and less industrially developed nations. Even among populations with some access to technology, the digital divide can be evident in the form of lower-performance computers, lower-speed wireless connections, lower-priced connections such as dial-up, and limited access to subscription-based content.

The reality of a separate-access marketplace is problematic because of the rise of services such as video on demand, video conferencing and virtual classrooms, which require access to high-speed, high-quality connections that those on the less-served side of the digital divide cannot access and/or afford. And while adoption of smartphones is growing, even among lower-income and minority groups, the rising costs of data plans and the difficulty of performing tasks and transactions on smartphones continue to inhibit the closing of the gap.

contents

• » website investigation
• » the database
• » evaluation

introduction...

Paperless transactions are hallmarks of the digital economy. In the global e-marketplace transactional websites are the interface between e-enabled customers and organisations, allowing them to do business with one another anytime, anywhere. Enhanced connectivity underpins the growth of the digital economy. The proliferation of internet-enabled computers in the home and the use of credit cards to pay for goods are major factors in its evolution.

E-consumers exercise greater autonomy and have more choice than is available to them offline in their own locality. They expect to receive a personalised service and an instant response.

In this unit, I will investigate how organisations are responding to the pressures of the e-marketplace by using transactional websites to:

• present their products and services
• gather information
• provide a personalised service.   ........

website investigation

introduction

The website that I have chosen to investigate is Ebuyer.com. Founded in 1999, it is now one of the largest global Internet resellers of brand name computer technology and consumer electronics products.

At the time of writing, the company's global headquarters is in Sheffield, UK with its US operation based out of Chandler, Arizona. Altogether they have 300 employees servicing 1.5 million registered customers.

According to their website, their business philosophy is simple:

"Give customers and businesses what they want, when they want it."

My investigation of their 'operation' will hopefully put this statement to the test! I will be sub-dividing the investigation of their website into three sections:

Website design

In this sub-division I will be describing, assessing and evaluating the design of the website. I will do this by describing its main features with a board analysis of the site's overall effectiveness and the 'customer experience' it provides. I will also be suggesting any areas for improvement supported by examples.

Back-end processes

This part of my investigation will focus entirely on the back office procedures. I will attempt to portray an accurate and complete picture of the company's operations by showing the chain of events, leading up to and triggered by an online purchase and the associated flow of information.

Potential threats to data

The last section of my investigation will consist of a description of threats to customer data collected by organisations via their websites and of the measures taken to protect, including legislation, with a clear and balanced assessment of their effectiveness. .......

Database

introduction

I have been provided with a data set which contains over five thousand records of CD Sales by an unknown company. This data set is a flat-file database. The data is split up into 15 columns separated by commas (,) and quotation marks ("). A screen dump of the data set in Notepad is shown below:

Before I design the structure I must study the data set's characteristics carefully so I will be able to create a fully customised database in Microsoft Access. To uphold the integrity of any data added in the future I will also include some data validation.

I will then create a special dummy data set and use it to carry out extensive testing to ensure that the database functions correctly and efficiently. The dummy data set will be designed to test all aspects of the database and data ranges within it, this will fully ensure its reliability.

I will then import the data and then check it carefully to make sure that it is correct. After these verification checks I will then extract some meaningful information from the database and interprete it accurately. I will attempt to identify some significant trends and then make some well informed recommendations to the company.

valuation

website investigation

website design

I am very pleased with this section of my investigation. I feel that it demonstrates that I am a savvy e-consumer. I also think that I have looked beyond the obvious features of the web site's design and come to an understanding of what eBuyer's web development team is trying to achieve. I would suggest that they focus and concentrate on enabling their customers to make fast streamlined purchases in the least amount of clicks possible. Humorously, they sort of remind me of a squeaky-clean fast food outlet - maybe it's just my quirky brain!

I also think that I have used well-chosen illustrations from many different elements of the site to support what I consider to be balanced in-depth descriptions and evaluations. I have highlighted both the sites weaknesses and strengths and have also commented on the 'customer experience' provided by the company. I also made several good suggestions for improvements.

back-end processes

This section of my investigation has been very enlightening. I did attempt to investigate eBuyer's operation in a more technical manner so to be more accurate in my descriptions. I do feel that I have produced a reasonably comprehensive set of diagrams that together give a complete picture of all the back-office processes. I have used a variety of different types of diagrams, including: Flow charts, basic information flow diagrams and DFD's. I have also annotated each of the diagrams even though I believe all of them to be relatively easy to understand so to make their contents slightly more vivid.

However, I do think that I could improve this section. If I had more time, I would have attempted to get in contact with eBuyer's web development team; maybe by email. The reason I would do this is because I believe it would help me to gain an even more accurate insight into how the company's back-office processes work. Information from insiders also provides an interesting insight into the ICT industry.

potential threats to data

I do feel that I have produced a clear and rounded assessment of all the potential threats to customer data held by eBuyer. I did this by trying to weigh-up the potential threats on the one hand against the measures and the relevant legislation on the other and come to a sensible conclusion. I also attempted to accurately examine the effectiveness of the security measures eBuyer has in place.

the database

database structure

In the end, I am certain that I chose the right option: 'the two table theory' (viz. database design). Thankfully, I did take into account what the majority of my colleagues were saying at this vital stage in the development of the database. If I never did this I would of had a multitude of problems when relating the entities together and applying some of the data validation rules. I also believe that if I had used the 'three table theory' it would have hindered a lot of my testing procedures.

comments on attribute properties

I am confident that all my field property choices where appropriate and I do believe that they actually helped the database function correctly and efficiently. I think that careful examination of the data set in its flat-file form is necessary to determine reasonable field sizes and data types.

comments on data entry error prevention

All of the input masks/validation rules that I applied to the fields have performed very well. The dummy data test stretched them to the limit and they still arose victorious (viz. dummy data set).

Strictly, I didn't actually make use of any "validation rules"; I only used input masks! I just couldn't find one characteristic in the data set that would require a "validation rule". If I had more time I would spend more time seeking out a field were I could make reasonable use of one.

what others thought about the database

My fellow colleague Ismail was genuinely impressed with my database but he found it rather difficult to navigate. He suggested that I create forms for the tables and queries to give users easier access. He had implemented this well into his own database and I am thankful for his recommendation for it highlighted a definite improvement that I could make. It is easy to imagine the benefits that a well worked-out forms system would bring to the database.

my own opinion of the database as a whole

I personally consider the database a success. I was able to interrogate the data set with precision and accuracy. I believe that I was only able to get a large amount of output from the database because of the basic structure and relationship I designed. I feel that the database runs correctly and effectively as it stands but I do think that Ismail's recommendation would definitely improve its usability. Overall I am happy that I was able to use the facilities of MS Access effectively enough to extract valid and meaningful information and identify some significant trends.

my performance

what others thought of my performance

Near the end of completing this ePortfolio I caught the flu. I was bed stricken for a couple of days and was unable to work as productively as normal for a few weeks. I was getting worried that I wouldn't meet the deadline. My parents were impressed with my maturity in deciding not to do any work until I was recognizably on the road to recovery. Because earlier in my website investigation I was using my mother's eBuyer account I had to explain to her what I was up to. She also spoke to me about her own personal experience of eBuyer's operation and I found this to be very valuable (viz. the overall experience). Due to her involvement in my investigation and because I live in the same house as her she was able to comment on my performance. She told me: "Considering all the circumstances, you've done exceptionally well!"

my own assessment of it

And I agree with her to a certain extent! I do actually think that my work is improving. I've been especially encouraged by my writing, I think it's gradually getting better. One thing that definitely still needs improvement is my planning. I need to work directly into my planning some contingency time - just incase I catch the flu or some other unforeseen event happens.

This concludes my Unit 2 ePortfolio.

2.1	Information Needs of Organisations
		Data Capture
		Data Processing
		Presentation of Information
		Exchange of Information
		Conducting Transactions
		Marketing Goods and Services
		Distribution of Goods
		Managing Customer Relations
		'Just In Time' Purchasing
2.2	From 'brick' to 'click'
		Transactional websites
2.3	Transactional Website Study
		The website	Assessment evidence  (a)
		Capture of customer information
		Techniques used to entice customers
2.4	Back-office processes
		Virtual shopping basket
		Identification and authentication
		Real-time tracking of customers' actions
		Payment processing
		Stock control
		Despatch and delivery
		Flowcharts and Data Flow diagrams	Assessment evidence  (b)
2.5	E-customers
		Purchase histories and Sales information
		Loyalty schemes
		Surveys
		Competitions
		Cookies
		Spyware
		Use of e-Customer profiles
2.6	E-consumer awareness
		What information is held?
		Identity Theft and Fraud
		Data Protection Act
		Distance selling
2.7	Security
		Risk assessment
		Physical security
		User names and Passwords
		Software security and Encryption
		Secure Electronic Transactions
2.8	The database
		Data types
		Validation
		Relationships
		Importing data
		Sorts
		Searches
		Reports

References

http://remza.co.uk/

http://bryntegict.co.uk/resources/computing/theteacher/ict/ictedexcel2.htm

http://whatis.techtarget.com/definition/digital-divide