Academic - NCC SAD - Art Gallery

The Art Gallery System

Systems Analysis & Design | Victor Diacono STCD08275 1

_____________________________________________________________

Art Gallery System: Analysis & Design

Systems Analysis & Design Assignment Victor Diacono STCD08275 IAD Bach March, 2009 7,227 Words



Table Of Contents

Functional Model Page 3 Structural Model 11 Behavioural Model 20 Data Conversion 32 Input Form Prototypes 36 Relational Database 43 Security 72 Hardware & Assignment Review 78 Bibliography 80

Press CTRL and click the page number to go directly to the linked chapter



Use Case Diagram

The Use Case diagram below identifies six use cases and three actors. To a degree, the diagrams design was subject to interpretation as an accurate system representation could still be achieved with a different design. One could, for instance, have grouped the Borrow Exhibit and Return Exhibit cases into one Maintain Borrowed Exhibit use case. The representation below is however sufficiently uncluttered to justify a fully decomposed presentation.

Buy Exhibit

Display Exhibit

Store Exhibit

Return Exhibit

Borrow Exhibit

Owner

Curator

>

>

>

>

Assistant Curator

Maintain Website

>



Use Case Specifications

The following cards detail the Functional Models use case specifications. The Buy Exhibit specification illustrates not only the case of adding to the gallery-owned inventory of exhibits by purchasing a previously un-displayed item but also that of purchasing, rather than returning, a borrowed exhibit. This case could arise if the Curator decides to request the outright sale of an exhibit on loan.

The other specifications illustrated below detail the remaining five use cases and, unlike Buy Exhibit, do not have inherent alternative actions to be discussed. ___________ Buy Exhibit



______________ Borrow Exhibit



_____________ Return Exhibit



____________ Store Exhibit



______________ Display Exhibit



_______________ Maintain Website



Activity Diagram

Owner Assistant

Curator

Curator

Sell or Lend

Exhibit

Buy or Borrow

Exhibit

Store

Exhibit

Display

Exhibit

Release

Exhibit

Return

Exhibit

Accept

Return

Pay

Owner

Maintain Website

Return to Table of Contents



Class Diagram

The class diagram has been sufficiently refined that no generalisation emerges.

+storesExhibits()

-locationRef : String

-storeRef : String

-locationName : String

Location

+storeExhibit()

+displayExhibit()

+maintainWebsite()

-curatorRef : String

-curatorName : String

Assistant Curator

+hostLocation()

-storeRef : String

-storeName : String

Store

+maintainCatalogue()

-exhibitRef : String

-exhibitionRef : String

-ownerRef : String

-locationRef : String

-artistRef : String

-genreRef : String

-exhibitName : String

-inHand : Boolean

-onDisplay : Boolean

-value : Decimal = 0.00

-borrowedOn : Date = sysdate

-returnOn : Date = sysdate + 90

-\duration : Integer = returnOn - borrowedOn

-year : Integer

-exhibitHistory : String

Exhibit

+displaySelectedExhibits()

-exhibitionRef : String

-hallRef : String

-themeRef : String

-startDate : Date = sysdate

-endDate : Date = sysdate + 90

-\duration : Integer = endDate - startDate

-description : String

Exhibition

+displaysCatalogue()

-url : String

Website

+borrowExhibit()

+returnExhibit()

+buyExhibit()

+maintainCatalogue()

-curatorRef : String

-curatorName : String

Curator

+lendExhibit()

+acceptExhibitReturn()

+sellExhibit()

-ownerRef : String

-ownerName : String

Owner

-stores

0 .. 4

-stored by

1

-delivered to-delivers to

0 .. *0 .. 6

-maintained by-maintains

0 .. 6 1

-manages 1

-managed by 0 .. 6

-set up by

-sets up

1

0 .. 6

-maintained by

0 .. *

-maintains

1

-displays 0 .. *

-displayed by 1

-borrowed by

-bought by

-returned by

-lends

-sells

-takes return

0 .. * 1

-borrowed by

0 .. *

-borrows

1

-returns

1

-returned by

0 .. *

-bought by-buys

1

-displayed by

-displays

1

0 .. *

0 .. *

0 .. *



Attributes And Operations (CRC Cards)

_______ Exhibits



______ Stores



_________ Locations



__________ Exhibitions



_______ Website



_______ Curator



________________ Assistant Curators



_______ Owners




Sequence Diagram: Maintain Website

The Maintain Website sequence diagram goes into the process whereby the Curator delegates site maintenance to one of the six Assistant Curators. One scenario could be the addition of a new exhibit to the gallerys inventory necessitating the creation of a new web page displaying an image of the exhibit and a short exhibit history and artists biography.

aCurator

aWebsite : website

anAssistant Curator

DelegateSiteMaintenance( )

CreateWebPage( )



Sequence Diagram: Borrow Exhibit

The Borrow Exhibit sequence describes the dynamics of the Curator requesting a loan from an owner followed by the owners confirmation and subsequent consignment. Once the exhibit has been received by the Curator he in turn passes it on to an Assistant Curator for consignment to a store location. The curator then finalises the process by creating a new exhibit record on the database system.

aCurator

aLocation.location

anAssistantCuratoraOwner

RequestExhibit(exhibitName)

ConfirmLoan()

ConsignExhibit()

aStore.store

ConsignExhibit(location.locnRef)

GetExhibit(location.locnRef)

exhib

its.e

xhib

itRef

CreateRecord(exhibits.exhibitRef)



Sequence Diagram: Buy Exhibit

The Buy Exhibit sequence consists of the curator requesting a quotation, the owner submitting same and the Curators acceptance. Once the Curator has accepted the quoted price it is then a question of the consignment process seen in Borrow Exhibit being repeated.

aCurator

aLocation : location

anAssistantCuratoranOwner

RequestQuotation(exhibitName)

SubmitQuotation( )

ConsignExhibit( )

aStore : store

StoreExhibit(location.locnRef)

LocatedAt(store.locnRef)

exh

ibits

.exh

ibitR

ef

CreateRecord(exhibits.exhibitRef)

AcceptQuotation( )



Sequence Diagram: Return Exhibit

This sequence diagram describes the process of the Curator requesting consignment of an exhibit due for return from stores and the Assistant Curators retrieval followed by consignment by the Curator to the owner. The Curator then finalises the process by recording the return on the gallerys system.

aCurator

aLocation.location

anAssistantCuratoraOwner

getExhibit(exhibits.exhibitRef)

aStore.store

getLocation(store.locationRef)

exh

ibits

.exh

ibitR

ef

ModifyRecord(exhibits.exhibitRef)

ConsignExhibit( )

requestExhibit( )

retrieveExhibit(exhibits.exhibitRef)

ReturnExhibit( )



Sequence Diagram: Store Exhibit

This diagram illustrates the process of the Curator delegating an exhibits consignment to store to an Assistant Curator. This activity could be the result of an exhibition coming to an end and the displayed items being thus returned to storage.

aLocation : location

anAssistant Curator

ConsignExhibit( )

aStore : store

ConsignExhibit( )

GetLocation( )



Sequence Diagram: Display Exhibit

The Display Exhibit diagram illustrates the process of the Curator advising an Assistant Curator which exhibits to put on display for a new exhibition. The process ends with the Assistant Curator fetching the exhibit and consigning it to the display hall.

aCurator

anExhibition : exhibition

anAssCurator

AdviseDisplayOfExhibit( )

TransferExhibitToHall( )

aStore : store

getExhibit( )



State Chart: Exhibits

This state chart illustrates an exhibits life cycle from loan or purchase of an exhibit through to storage, display and eventual return if it has been borrowed.

Exhibit ObtainedOwner Lends or Sells Exhibit

Curator Consigns Exhibit to Ass.Curator

Curator Adds Item To Exhibition List

Exhibit Stored

Exhibit Displayed

Exhibit Returned To Store

[duration = 3 months]

Borrowed Exhibit Returned To Owner

Owned Exhibit Consigned To Location



State Chart: Exhibitions

The Exhibtions state chart describes the process of setting up an exhibition starting with the Curator defining an exhibition theme, assigning a hall to it and setting its duration. The process ends with Assistant Curators setting up the exhibition proper by transferring exhibits to the designated hall.

Exhibition Defined

Exhibition Established

Exhibition Open

Curator Defines Theme, Hall & Duration

Curator Gives List of Exhibits to Ass.Curator

Ass.Curator Transfers Exhibits To Hall

[duration = 3 months]



State Chart: Website

This final state chart illustrates the short process of updating the website with the contents of a new exhibit.

site not updated

Curator borrows or buys exhibit

site updated

Curator updates site



Communication Diagram: Buy or Borrow Exhibit

an

Ass.C

ura

tor

aC

ura

tor

an

Ow

ne

r

2:

Le

nd

OrS

ellI

tem

( )

1:

Re

qu

estI

tem

( )

3:

Co

nsig

nE

xh

ibit(

)

4: Ma

intain

Catal

ogue

( )

an

Exh

ibit :

exh

ibit

5:

Co

nsig

nT

oL

ocn

( )

aS

tore

: s

tore

6: C

reate

WebP

age( )

aW

eb

site

: w

eb

site



Communication Diagram: Exhibition

an

Ass.C

ura

tor

aC

ura

tor

1:

De

fin

eT

he

me

& E

xh

ibitsL

ist(

)

2: G

iveE

xhibits

List( )

aE

xh

ibitio

n : e

xh

ibitio

n

3:

Co

llectF

rom

Lo

cn

( )

aS

tore

: s

tore

aH

all

: h

all

4:

Dis

pla

yE

xh

ibits(

)



Communication Diagram: Return Exhibit

anA

ss.C

ura

tor

aC

ura

tor

1: R

em

oveE

xhib

it(

) aS

tore

: s

tore

2: C

onsig

nT

oC

ura

tor

3: C

onsig

nT

oO

wner

anO

wner




Conversion Of Paper-Based Records To Digital Format

The gallerys current paper-based system has fortunately been maintained by neat, printed and easily-read characters. One standardised form records each exhibits name, storage or display location, owner, value, date received, return-by date and owners details. The list of original paper-based exhibit attributes has however been further expanded in the system design illustrated earlier in this report. This creates a difficulty in that the recommended method of data conversion from hand-written to manual shall not be a complete solution as the database at system startup shall have a number of unassigned values (the new attributes) for each record. Furthermore, the flat-file nature of past record-keeping, if kept in this nature at conversion, would not enjoy the benefits of the relationships established with new attributes such as genreRef and artistRef. The gallery management has to opt for one of the following solutions to this problem:

o Keeping full records from startup but utilising past records in their converted flat-file format. This approach is not recommended as the result is an inconsistent and incomplete framework for reporting and subsequent decision-making..

o Modifying each past record, after conversion, by keying in the unrecorded attributes. This would clearly be a laborious and time-consuming task but is still the recommended approach. Much input time is already going to be saved with the automated conversion of existing record attributes and it is a one-off task that enables full exploitation of system benefits.

_________________ Conversion Options Irrespective of which of the above solutions to opt for, there is another unrelated decision to be made over which is the most-suited conversion technology to adopt. The four technologies listed below are being proposed for managements consideration and recommendations appear at the end of this part of the submission. These recommendations solely take into account which option the author of this report considers to be the most technologically adapt solution for the problem under review. The brief did not go into cost-efficiency and possible trade-offs between cost and adaptability.

o Optical Character Recognition (OCR)

o On-line Character Recognition (OLCR)

o Magnetic Ink Character Recognition (MICR) o Optical Mark Recognition (OMR)



__________________________ Optical Character Recognition

This technology, first patented 80 years ago, has evolved to such an advanced stage that focus is now mostly on implementation of proven OCR technologies. This in turn affords a final choice of product from a wide range of commercial software packages. That, however, is once more an area which this report was not requested to go into and can be seen and implemented at a later stage of the project. Optical Character Recognition technology is widely credited with 98%+ accuracy rates (as stated in http://www.odl.ox.ac.uk/papers/OCRFeasibility_final.pdf) although accuracy measurement varies considerably if one were to consider misspelled hand-printed words, checked against an on-line dictionary, as an inaccuracy. Misspelling at data entry stage, though undesirable, is not a major concern for the system except when it appears on the website too. And it is in any case a concern beyond the systems control. Irrespective of measurement subjectivity and the condition of the source documents, an accuracy rate of a minimum 80% to 90% (as stated in http://en.wikipedia.org /wiki/Optical_character_recognition) can still be expected with neatly hand-printed characters. The condition of the source documents becomes a consideration too as unclean paper can lead to misreading. The application under review is however at the lower rungs of the complexity scale as an exhibit transfer form would not have much writing to a page (unlike a normal document) and this would translate into less characters to recognise consequently resulting in less reported errors. Furthermore, under such a scenario it would be relatively non-laborious to physically check document with physical record, after conversion has been done, for purposes of locating and modifying erroneous scanning. OCR also affords the benefits of close approximation to scanned images and other non-textual components such as tabular columns. However this (and other benefits accruing from the very advanced stage at which OCR technology has arrived) offer the required solution no added value as there are no recorded images of exhibits that have to be scanned into the new system. These benefits are only mentioned to emphasise the tried-and-tested nature of this technology as the problem in hand is solely that of converting stylised hand-writing into a digital format. Nevertheless, if there is an area of OCR on which technological research is still ongoing, it is that of hand printing and especially handwriting. So in spite of the stability generally associated with OCR, the downside to this option is that recognition of hand printing (i.e. stylised writing) is the least fully-developed of the spheres it addresses. Having said that, being the least fully-developed OCR sphere does not necessarily make it unsuitable for our hand-print recognition needs.



__________________________ Online Character Recognition Online Character Recognition can be viewed as an extension on OCR technology in that it converts data entry recorded by writing instruments but it is mostly directed towards hand-held devices such as personal digital assistants. It is a complex technology of extracting an individual writers writing patterns and matching them against structure models held on the software packages database. Like Optical Character Recognition, it is reputed to enjoy a high 98%+ recognition rate (as stated in http://portal.acm. org/ citation.cfm?id=1079048 ) but, once again, units of measurement may vary and may indeed even be subjective. The advantage of OLCR over OCR lies in that the former recognises fixed statically-shaped characters whereas the latter attempts to recognise dynamic individual handwriting motion to the extent of whether marks were drawn from left to right or vice-versa. At face value, OLCR benefits appear to have the edge over OCR in that they would address our hand-printed original sources stylised writing easily while still recognising the occasional individualised character. On the other hand, the user would have to be re-trained in the use of specific character shapes only. Since this is completely irrelevant to the problem in hand, namely that of a source which has already been compiled, OLCR has to be put aside as an option.

_______________________________ Magnetic Ink Character Recognition

Magnetic Ink Character Recognition (MICR) is being mentioned more as a case of definitively ruling out a technology which is unclearly un-adaptable to the problem under review.

MICR technology pertains almost exclusively, if not altogether, to banking applications. It operates by recognizing numeric data printed with magnetically charged ink and has long been widely adopted in the banking industry to read account numbers on cheques, deposit slips and other related banking documentation.

Even if it were to be initially considered as an option, it would have to be discarded because of the series of conditions, inherent almost exclusively to the banking industry, which it would require for accurate operation. Among other restrictions, it recognises only numbers and a restrictive set of symbols, any imprint has to have specific starting and ending symbols and character placement on the document is a critical consideration.



______________________ Optical Mark Recognition

Some Optical Mark Recognition devices use specially produced forms to measure the amount of light passing through the forms thereby recognising the shape of marks which are preventing light from getting through. And another genre of OMR applications involves the filling in of pre-produced forms carefully designed to eliminate ambiguity at the scanning stage. Both these technologies are clearly un-adaptable to the gallerys needs as we cannot enjoy the luxury of pre-produced source forms forms are already in existence and filled-in. In its most easily-recognisable source format, OMR recognises and interprets simple, special markings such as squares and circles. Nevertheless, it also offers the most reliable and error-free option for the type of standard paper forms which make up our source documentation. Particularly because our source text consists only of the minimal text required to record exhibits. While OMR does in fact have limitations with the recognition and gathering of large chunks of text, it is a sufficiently reliable option for the minimal text content appearing on our source forms. OMR enjoys other advantages over the other technologies discussed. For one thing, it does not require a recognition database thus simplifying the process and rendering it significantly faster. Furthermore, hand-printed characters stand a lesser chance of being misread although it does require high image contrast and easily recognisable character shapes. These two conditions are however unlikely to return too many errors as stylised hand-printing is already present on the source forms. ________________ Recommendations Following review of the four scanning technologies discussed, the authors recommendation is that an Optical Mark Recognition system be introduced. While no technology is going to be foolproof or perfect, it is safe to state that the characteristics possessed by OMR are by far the most adaptable for the application under review. OMR is the technology that most approaches one hundred percent accuracy and it is also the fastest not least because of its simplicity of operation. Suffice to say that speed on simple markings has been measured at rates as low as .005 seconds per marking (as stated in http://en.wikipedia.org/wiki/Optical_mark_recognition). In the application under review speeds will be lower because of textual source as against simple markings but it is still bound to be the highest recognition rate of the four technologies. In conclusion, Optical Mark Recognition will offer ease of use coupled with the lowest error rate and lowest costs.




Prototype User Interface

The prototype user interface has been developed with Visual Studio 2005. This Integrated Development Environment carries several advantages over MS Access which was employed to test the database model in an earlier task. To start with, it provides a faster development throughput and the product, with the tools it puts at the developers disposal, is significantly more attractive. It is also a more developer-friendly environment and, more importantly, helps produce a more ergonomically inclined user interface. Furthermore, the prototype would be re-usable at the development stage of the systems life cycle if coding is to be implemented with one of the programming languages hosted by Visual Studio. The user interface screens appear on the following pages.



Prototype UI: Adding A New Item

The Create Exhibit Details screen is the principal means of maintenance as new exhibits are recorded here. The user enters values for all the attributes in the Exhibits file bar one, Loan Duration, as it is a derived value. It represents the number of days an exhibit has been borrowed for and this value is computed by subtraction of the exhibits.borrowedOn date from exhibits.returnBy. The labels to the right of the four foreign keys display the name attribute in the foreign keys original file genreName, artistName etc. The user finally clicks the Import Image button to display a dialog box where he or she can enter the gif file name. The image is loaded over that of the gallerys faade. Clicking Save commits the record to storage.



Prototype UI: Editing An Items Details

This screen performs the function of modifying records created through the Create Exhibit Details window. The fields in this window are in fact an exact duplicate.

The need catered for by this window is almost exclusively that of correcting erroneous input in Create Exhibit Details. The only fields that may require modification as a result of natural change are Value (upon re-evaluation of an exhibit) and Return By (should the loan be extended).

In Hand, On Display and Location Ref may also require natural change but these would have been modified from the Transfer Exhibit screen illustrated further down, before the modified record would need to be viewed here. The record would therefore be displayed here in an already modified state. The Boolean On Display value would have been deduced according to whether the To radio button selected in Transfer Exhibit was Store or Hall. If it is Hall, the On Display value is No and vice-versa. These three fields would ideally be disabled and greyed out in this screen. Clicking Save commits the modified record to storage.



Prototype UI: Searching For The Location Of An Item

The Find Exhibit screen addresses the need for a search function. The user can search by either Exhibit Ref or part of the Exhibit Name. The location where the exhibit is to be found, being either a store location or an exhibition hall, is displayed in the label at the bottom of the pane. Upon clicking the Search button, the exhibit name box is populated with the value of exhibits.exhibitName if the user entered a search value next to Exhibit Ref. Conversely, Exhibit Ref is populated with the value exhibits.exhibitRef if a search value is entered for Exhibit Name. The exhibits image file listed in exhibits.exhibitGif is loaded over the gallery faade image in the right pane and a full transactions history for this item is superimposed over the image. A sufficient degree of opacity is applied to the loaded image to render the overlying text clearly legible.



Prototype UI: Transferring Items Between Locations

The Transfer Exhibit window performs the function of recording exhibit movements between store locations or between locations and halls. This window looks deceptively simple but is possibly the most complex, coding-wise, of the six submitted in this report.

The user keys in the relevant Exhibit Ref and the label to the right is populated with the exhibit name and the exhibit image populates the image pane. An audit trail number is automatically generated by the system and displayed in the Transfer Ref text box above.

The user then ticks the relevant radio button in the From group box. If his or her choice were Hall the greyed-out text box next to it is enabled, the user inputs the hall reference code and the hall name is displayed in the label to the right. Alternatively, if the choice were Store, the first greyed-out text box is enabled to accept storeRef input and the adjacent text box to accept locationRef. This composite key then displays the relevant store location name in the label. The To group box operates in an identical manner.

The Transfer On date is automatically read from the computers system date and the user keys in the reference code of the Assistant Curator involved.



Prototype UI: Listing Items Due For Return

The Return Exhibits Report is the simplest screen form submitted in this report. The user keys in a range of dates and, upon clicking the Print button, the system issues a report of exhibits due for return to owners within that date range.

The intended functionality is that listing of exhibits due for return, if any, is over-printed onto the gallery image in the right-hand side pane immediately the To date is entered. The displayed attribute values would be those shown in the header labels. The user then clicks the Print button to send the report to a printer. This functionality allows for visual confirmation of the report before producing hardcopy or the user may indeed choose to view only. A degree of opacity is applied to the image.

The brief requested a listing of items due for return to their owners by a selected date. This implies one date variable only but it was felt that a range of dates adds functionality. The user can always input the same date twice in the eventuality that a single-day range is required.

Validation that the range does not start with a From date smaller than the To date will be implemented in the coding.



Prototype UI: Creating A New Exhibition

Create Exhibition Details is the screen wherein exhibitions are maintained. A three-character exhibition reference code is to create and a theme and hall reference is assigned to the exhibition. Start and end-dates are keyed in together with an overview on the exhibition and Exhibition Duration, an integer value derived from the dates, is computed. Save commits the exhibition record to storage.




Relational Database Design

This chapter presents a set of fully normalised tables for the proposed database entities. The tables are being listed below in their different forms of normalisation preceded by short notes on each form. The normalised tables are followed by a diagrammatic representation of the entities, together with their relationships, produced with Microsoft Access 2003. Access was employed to test the model.

____________ Normalisation First Normalised Form has been extracted from details in the Scenario and is effectively a flat database file without consideration for separate relationships. Second Normalised Form has divided the flat-file into two, albeit as yet unrelated, tables (Exhibits and Exhibitions) and added a key identifier to each. In Third Normalised Form a proper relational database structure falls in place. Dependencies between non-key items are explored and new entities tied by separate relationships have been created where necessary. The following entities have been added to the database as a result of previously non-key items being promoted to a new relationship:

Stores

Locations

Owners

Halls

Themes

Genres

Artists

In the Optimisation process the final tweaking has been applied. A couple of redundant attributes have been removed, new ones introduced and others re-distributed among the entities created in 3NF. The most significant change at optimisation is the store attribute being removed from the Exhibits file. Store was redundant here as a storeRef primary key in the Stores entity is related to a newly created storeRef foreign key in the Locations entity. So relating Exhibits to Locations also constitutes a link to Stores. Another redundant attribute was exhibitRef in Exhibitions. This attribute was a logically incorrect inclusion as the relationship between exhibits and exhibitions is clearly not one-to-one; it is one-to-many. However, to the level submitted for this assignment, the design does not go into the historical exhibition records which the one-to-many relationship would enable. Such a historical record could however be extracted from a transaction file of exhibit transfers between stores and halls if said file were to hold transferDate, exhibitRef and



hallRef as attributes. These three parameters would be enough to establish which exhibits were in a particular hall for a particular range of dates. Newly-added attributes consist both of key and non-key items. One such non-key attribute is onDisplay, a Boolean flag which is modified whenever an exhibit moves between stores and exhibition halls. And a storeRef foreign key has been added to the Locations file for reasons discussed earlier. Another addition is two derived duration attributes in the Exhibits and Exhibitions files. These two attributes hold the loan duration and exhibition duration (both in days) respectively. Finally, a number of non-key attributes have been added as they are required for descriptive reasons:

exhibits.exhibitName

exhibits.exhibitYear

exhibits.exhibitHistory

exhibitions.description

genre.genreHistory

artist.artistHistory The normalisation tables, from First Normalised Form through to Optimisation, appear below. Key attributes appear underscored.

____________________ First Normalised Form



______________________ Second Normalised Form

____________________ Third Normalised Form



______________ Optimised Form



_____________________ Entities & Relationships This diagram is being re-produced solely for the purpose of providing a holistic picture of the normalised tables illustrated on the previous pages. However, the diagram also brings out what appears to be a deficiency in the design, namely that the Curators and AssCurators tables stand unrelated to the rest of the database. These two tables would in fact become related to the others once the enhancement, discussed further on, concerning the inclusion of an audit file to record exhibit movements is implemented. That implementation would relate the curators.curatorRef and assCurators.assCuratorRef keys to similarly-named attributes within the audit file which would in turn be linked to other entities in the database.



______________ Data Dictionary A Data Dictionary for all the database items, grouped by entity name, appears on the following pages. Discrete data elements cannot be fully documented because of their discontinuous nature and one of the most obvious instances is owners.ownerDetails. _______ Owners



______ Artists



_______ Genres



_______ Exhibits



__________ Exhibitions



_________ Locations



_____ Halls



_______ Themes



______ Stores



________ Curators



___________ AssCurators




Security

This section of the report deals with the security issues concerning both the website and the system as a whole. Security cannot consist of a random set of isolated techniques if it is to be effective but has to be the product of a coherent and comprehensive security policy. The most critical issue a security policy has to address in clear terms is who is allowed to do what and who can authorise users (NCC Education Ltd 2004, Developing a Website: p138)

______________________ Potential Security Threats Possible threats to the proposed systems security are several and they are both external and internal. Although the former are more in number, the internal threats would by their very nature be easier to instigate thus requiring proper thought and planning for prevention. ______________ Internal Threats Internal threats can be both of an intentional or an accidental nature. Internal accidental threats such as destruction of the computer hardware by flooding can be dealt with by thoughtful planning of the office space the system is to occupy. Simple logic would suffice to ensure that the server room is not located below street level and that the room does not have water or drain pipes running through it. While these might seem obvious considerations it is often that owners or non-I.T. members of management fall into the trap of consigning what the paying public will not be viewing to the least commercially-exploitable location of the building, even if that happens to be a damp basement room. The most critical items to protect would always be the servers not only in terms of purchase cost but also of the data stored on them. Threats to data are of a critical nature and precautions extend far beyond the simple logic of choosing adequate housing for the hardware although quite often even this has to be an environmentally-controlled location. Data can be damaged or destroyed through excessively hot or humid conditions or even hardware malfunction and regular backups are a must although not a hundred percent foolproof. Backups are not fully foolproof as corruption of data can be detected after say a week on a system that is reusing the backup media every five days. Under such a scenario, every backup copy would be in a corrupted state and, if said data is beyond patching, the costly option of complete re-entry of all transactions from start of operations would become necessary. This would have to be done off hardcopy source documents and a regular transaction history printout, held in a secure location, is a must. A secure backup strategy is beyond the terms of reference in this brief and gallery management can go into it, before the system goes live, at a later date.



Human error is always a major consideration when planning against threats to security but intentional misuse of the system has to be catered for too. Intentional misuse can be motivated simply by malice or for reasons of fraud. Malicious misuse could consist of, in the system under review, the entry of incorrect data for the system not to be in a position to output correct or meaningful information. The motivation might not be that of causing malicious damage per se but of keeping systems of control non-functional or under-utilised thus removing or hampering the accountability of staff in their everyday work routine. Such malicious misuse can also be motivated by fraudulent intentions. An example which easily comes to mind on this system is that of changing the value attribute of exhibits thereby reducing asset values. Under such a scenario, assets could then be fraudulently disposed of at prices below current market values. Or, even worse, removed from inventory altogether which is why precautions for such eventualities have been built into the proposed design by having a rigid transaction trail in place and exhibit movements under the control of, or directly delegated by, the Curator. Having said that, security considerations cannot stop with the Assistant Curators as the Curator has to be accountable to the gallery owners too and possibly more so, given that control mechanisms rest completely with him. Towards this end, policies have to be put in place whereby a regular paper-trail of exhibit movements and data modification is to be printed and held in a secure location. Copies of this (and the system data backups too) would ideally also be kept off-site as a precaution against the risk, mentioned earlier, of flooding or fire. ______________ External Threats External threats come in the form of hacking through an internet connection and the motives can be several. One of the most serious external threats is that of viruses which cause the system to malfunction or system data to get corrupted altogether. One of the easiest means of entry of viruses is through e-mail attachments and policies on email usage, and all internet traffic in particular, have to be put in place. Damage could be in the form of necessitating the complete re-entry of transactions as mentioned earlier in one of the internal security threats. Although one must add that very often even this laborious task is not enough to restore a system to its original unaltered and fully-functional state. Another threat is that termed as Denial of Service whereby the website would be brought down thus cutting the link between the on-line exhibitions and the general public. This is often the work of pranksters or misfits among the general public who find joy in disrupting the work and achievements of others and assume that their exploits are a sign of their under-rated capabilities. Denial of Service does not inflict much tangible harm but damage is still incurred in terms of work disruption and loss of image. Hacking can also come in the shape of political campaigning whereby socially unacceptable beliefs are propagated by means of banners or short articles hoisted onto the website. This threat never comes from the mainstream political ideologies but from



obscure groups with beliefs which the general public often finds abhorrent. Damage from loss of image and bad publicity is thus a real and big threat. Hacking for fraud is another threat and, by its nature and that of the reviewed system, could imply internal collaboration. The internal threat of fraudulent modification of data has been discussed already and such modification does not necessarily have to be directly off one of the systems workstations. The website could serve as a convenient backdoor disguising the identity of an internal perpetrator as eventual modifications would not be traced back to any particular user of the system. This envisaged threat could even present itself in the form of a new user account being created for the purpose.

_____________ Repercussions Repercussions emanating from the above potential threats can be numerous. Disruption of operations, mostly administration-wise but also concerning website downtime and possibly the running of exhibitions too, is just one. The cost of such disruption has already been touched upon earlier and can be measured in terms of both lost income from paying visitors as well as disruption to the everyday office routine, possibly even extending into long periods of concurrent re-instatement and limited everyday usage of the system. Embarrassment resulting from security breaches on the website, and consequent loss of reputation or image, are another costly repercussion though in this case not one measured in an immediately tangible way. This can come about from several types of breach and can, for instance, be the result of offence caused to the browsing public from anti-social messages being attached to the site in the form of text or banners. Such offence could also extend to the possibility of legal liability and this concern is particularly real in another form of attack whereby a site is used by hackers to launch anonymous activity from. In this type of security breach hackers often set themselves up as a bona fide user of the targeted system thereby rendering themselves anonymous and the targeted site the culpable party. Even if the targeted party can prove being victim of a breach there is still the risk, depending on legislation, of being liable for monetary damages. Damage in terms of reputation and image would have been inflicted already and is not necessarily restricted to the general public but can also extend to the loss of potential sponsors or to the collaboration of the affiliated galleries or private owners who loan out exhibits to the gallery. Motivation for this type of attack can even extend to fraudulent activity on the general public by eliciting credit card or bank account details and, with the gallery system, could conceivably take the form of requesting payment for the purchase of prints of exhibited items. And once the website visitor has been tricked into submitting card or bank account details the perpetrated fraud is not necessarily limited to the value the defrauded party has been tricked into parting with. This sort of scam abounds by the hundreds, if not thousands, on an on-going basis on the Internet.



Another issue is the threat of email interception which in our case can be a cause of the physical security risk of robbery aided through the identification of dates when borrowed exhibits of particular value are to be in transit from or to their owners. This physical risk is not only addressed by securing email communications through methods such as data encryption but also by securing the database system against ascertaining of exhibit values held in the exhibit.exhibitValue attribute. Prevention techniques have not been included in the briefs terms so it will suffice to say that they are varied and it is often a security policy bringing together several of these considerations that can provide peace of mind in the most effective (though never foolproof) manner possible.

_____________________ Restricting Permissions The method of ensuring that only the Curator and Assistant Curators enjoy write, edit and delete permissions is not a complex one and is taken care of by the system. The only way of upsetting that policy would be through a user with similar privileges being created surreptitiously as described earlier. The database can be configured to allow different privileges to different users effectively withholding users from executing instructions beyond the responsibilities assigned to them in gallery policies and practices. The brief requests that read, write and delete permissions are assigned to the Curator and Assistant Curators only but this can still be amended in future, if policy modifications so require, to have delete privileges assigned to the Curator only. In fact, privileges can always be revised and modified as required. Said privileges are allocated to the individual user by being assigned to that users account on the system. The account is given a name at time of creation and is protected by a password which the user is free to change so final responsibility of all transactions executed under his name will always rest with him. It is then the users responsibility that his password remains known to him only and is not communicated to others intentionally or through carelessness. More restrictive accounts can be created for clerical staff and others should the need arise. As discussed earlier, read-only accounts will be created for website visitors too, granting access to the dataset created for the purpose.

_________________________ Read-only access for website There is a small variety of options for ensuring that only read-only access is allowed by the website. The best solution might indeed be a mix of more than one technique. One technique is that of extracting a dataset displaying only non-critical attributes from the principal database. A dataset is

an in-memory cache of data structured like a relational database with tables and relationships



(Microsoft Press 2006, Microsoft .NET Framework 2.0 Windows Based Client Development: p742).

Dataset benefits consist in the tables being only a copy of the original data thus rendering the risk of any tampering with them limited to the display of compromised information on the website. This risk is still not to be taken lightly, as explained in the discussion on the possible repercussions of hacking, but is at least being contained therein and the much more critical nature of the principal database is being protected. With this technique, protection of the principal data against threats from the website being illegally accessed is guaranteed as it is being kept physically isolated from the site itself. The dataset is kept current by software technology which keeps it in a state of automated update with the principal database. Added, modified or deleted records on the parent database are transferred onto the dataset too. This technique works by replacing a target (website copy) dataset record with the source record from the main database every time two records with the same primary key are found to be no longer similar. Of course, this technique of rendering the principal database un-accessible can be a guarantee in itself but the purpose is still defeated if potential hackers are allowed to access the main database server via shortcomings elsewhere on the website. In other words, it is pointless to deny direct access to the database if, for instance, the possibility of creating a surrogate user on the system is still available. The old adage that every chain is only as strong as its weakest link is very much to be kept in mind when addressing computer security threats. One method of addressing this second concern is that of configuring the website as an additional user in itself and denying this new user rights beyond read-only privileges. This would effectively deny the hacker the possibility of creating a surrogate user as it would restrict his operations within a ring-fence of read-only activity of material intended for public consumption anyway. Another precautionary measure is to not leave the site accessible to uncontrolled browsing by an un-authenticated audience. While the widest dissemination of the gallerys exhibits and of other related information is the principal aims behind the sites very existence, users have to be authenticated. Countless sites of whatever nature on the Internet employ such precautionary methods. The visitor is required to submit a request for viewing rights which are allowed only after the request has been authenticated and a user name and password created. This method limits browsing to an authenticated audience whose online traffic between it and the site can be monitored by specialised software. Finally, it is of utmost importance that the site is professionally set up to avoid configuration deficiencies that can produce security holes. Since it is unlikely that the gallery, with its line of operation and relatively small staff complement, shall be enjoying the benefits of a suitably qualified employee in this area, it is highly recommended that an established provider of such services is contracted when the site goes operational. The provider will be aware of advantages and disadvantage inherent in different on-line technologies such as the security deficiencies generally associated with Telnet and ftp.



The provider will also be aware of the techniques employed by hackers to deduce small pieces of critical information from different and seemingly meaningless sources such as the website scripts very often accessible with a simple right-click of the mouse.




Hardware

The hardware requirements for the proposed system take into account the actors listed in the brief and website requirements. The list below does not include workstations for clerical staff should any be engaged in future as future one-off requirements are a minor consideration and expense which can be taken care of as it appears. And it has been assumed that a webmaster, once engaged, can operate directly at the server unit. The hardware list recommended for start-off is the following:

o Server unit for the database hosting the gallery system. o Server unit for the website.

A dedicated server unit is being recommended for the website not least for the security concerns addressed in this report. Both servers are to be equipped with an additional hard-disk storage unit for implementation of RAID-1 mirroring for backup purposes.

o Workstations for Curator and Assistant Curators (7 units).

o Printer/Scanner unit with sheet feeder. Apart from printing needs, this unit will also be required for sheet-feeding of the hand-printed source documents for data conversion purposes.

o Uninterruptible Power Supply (2 units, one for each server).

o CCTV equipment for 24/7 footage of the gallerys entry and exit points.



Appendix: Review of Submission

The Art Gallery design has gone into a number of assumptions on, among other issues, the actors responsibilities and job descriptions. Since the brief states that the Curator is ultimately responsible for the management of all exhibits held, it has been assumed that all actions by the Assistant Curators have been directly delegated by the Curator. These actions, apart from others which might arise as a result of future expansion of the system, effectively consist of the following duties:

o Transferring exhibits between store locations and halls.

o Consigning newly-borrowed or purchased items to store locations. o Consigning to the Curator items due for return.

o Maintaining the website.

o Logging exhibit movements into the system.

To perform his control function effectively, it is being recommended that the Curator be the official with direct control over the Exhibits file which performs the function of the gallerys inventory control. And for the control function to operate effectively a rigid form of exhibit movement has to be established. Hence, a rule has been designed into the system whereby all Exhibit movement has to go through Stores. Although it has not been covered by this report, a transactions file shall eventually have to be developed to hold an audit trail of Exhibit movement. This file will hold individual movement records for control purposes and will be maintained from the Transfer Exhibit screen discussed earlier. This function and other security issues have been covered in detail in the security-related notes. Another assumption inherent in the proposed design is that all exhibit traffic is from or to store locations rather than between the stores themselves. After all, locations have been assigned to stores and a relationship has in fact been created between locations.storeRef and stores.storeRef. The brief implies that exhibition themes are to be associated to the exhibition rooms. However, for the sake of precision it has to be stated that an exhibition room might be required to hold two concurrent exhibitions and the need might also arise to move an exhibition from one hall to another. For these reasons, Themes have been associated with Exhibitions (not with exhibition rooms) in the design as it was felt that this would be a more stable and logical relationship. It provides the system with added functionality and is more logical from a relational database model's perspective.

The normalised tables requested in Task 6 have been presented in the four forms from First Normalised Form through to Optimisation as requested in the assignments Scenario. This is being stated since there were entities already in 2NF upon creation. In such cases, said entities have been decomposed into 1NF for the sole purpose of respecting task requirements.

All use case specifications bar one have not had additional comment attached to them as, from their textual nature, they are self-explanatory.




Bibliography

NCC Education Ltd (2004) Developing a Website, 3rd edition. Manchester. NCC Education Ltd (2007) Business Systems Analysis, 2nd edition. Manchester. NCC Education Ltd (2007) Systems Design, 2nd edition. Manchester. Stoecker, M. Stein, S. and Northrup T. (2006) Microsoft .NET Framework 2.0 Windows-Based Client Development. Microsoft Press, Redmond, Washington. Tanner, S. (2004) Deciding whether Optical Character Recognition is feasible. Kings Digital Consultancy Services. http://www.odl.ox.ac.uik/papers/OCRFFeasibility_final.pdf [accessed on 7/2/2009] Troy Group, Inc 2007: What is MICR? http://www.whatismicr.com/ [accessed on 7/2/2009] Wikipedia 2008: Optical character recognition. http://en.wikipedia.org/wiki/Optical_character_recognition [accessed on 7/2/2009] Portal 2005: Online Character Recognition http://portal.acm.org/citation.cfm?id=1079048 [accessed on 7/2/2009] Wikipedia 2007: Optical Mark Recognition http://en.wikipedia.org/wiki/Optical_mark_recognition [accessed on 7/2/2009] Note: Wikipedia sources have been used with caution given that they are editable articles un-attributable to an author. Material obtained therefrom has been used when it could be collaborated by the authors experience or with knowledge gained from other sources.

Date post:	09-Jan-2016
Category:	Documents
Upload:	victor-diacono
View:	9 times
Download:	0 times

Academic - NCC SAD - Art Gallery

Documents