Most Popular Party System

Published Date: 02 Nov 2017

Firstly, we would like to thank parents, who suggest us to attend this course, International Advanced Diploma in Computer Studies. Because of their help and maintenance, we can attend this course.

We would like to thank NCC for the joint program of our course.

I thank to all of my friends who give us energy to overcome the difficulties in developing my assignment. And I also thank for their lucid and useful suggestion and supports.

Introduction

This assignment will allow you to demonstrate an understanding of the object-oriented analysis and design of a computer system. You will analyse and design a system for a political party including the creation of a prototype user interface and examine data protection issues.

The Scenario

The Most Popular Party is a political party in the country of Contented land. The country is divided into five administrative regions (Northland, Eastland, Southland, Westland and Central) and each region is subdivided into ten administrative counties (numbered 1 to 10). The country holds elections every four years for the national parliament and the assembly for each region. The national and regional elections all take place on the same day except in special circumstances, such as the death of the current post holder, when a by-election is held at a suitable time. The Most Popular Party puts candidates forward for every seat in every election.

The national parliament is made up of fifty members of parliament (MPs) with each Member of Parliament being elected by popular vote in one county using a "first past the post" system as used in the United Kingdom. Each regional assembly has twenty assembly members (AMs) with each county electing two assembly members using a "first past the post" system.

The Most Popular Party funds its activities from two sources. It has around fifty thousand individual members and each member pays the same annual subscription fee to the party. It also receives donations from individuals and organizations that agree with the party’s aims and such donations can be for any amount of money.

The party pays for two full-time party workers in each county who work from one of the five regional offices it rents. It also has ten full-time national officers based in rented headquarters in the country’s capital city. The party has to fund its headquarters building and regional offices and also pay for election material including leaflets and television advertising. The party has to submit annual accounts to ensure that it is not breaking any election rules and also for taxation purposes.

At election time individual members of the party are selected as candidates to stand for election to the national parliament and to the regional assemblies. Up to six potential candidates for each post are added to a shortlist by the full-time party workers in each region. The party members in each county then attend a meeting and select their candidates for the next election. This meeting takes place approximately three months before an election is due. Each candidate may only stand for the national election or the regional election, not for both.

Party members are relied on to organize meetings and distribute leaflets for the party at election time. The paid party staff need the party members at this time and must be able to contact them to enlist their help.

The party requires a new computerized system to keep records of paid staff, party members, election candidates, members of parliament and regional assembly members. The system must also be able to record details of income, payments made and generate financial reports based upon this information.

Task 1

In task 1, we need to analyze based on object method and procedure for the Most Popular Party. We produce a functional modeling including:

Use Case Diagram

Use Case Description

Activity Diagram

Firstly we need to implement with Use case diagram. In Use case diagram, we n need to divide with five pictures. First picture is about the details of Most Popular Party System. Second picture is also about searching the party’s election candidates for a particular county. And then third picture is editing that member need to change their address and status. Third picture is about adding new member. And final picture is listing party’s MP showing where was elected.

Use Case Diagram

A use case is a pattern of behavior, the system exhibits

Each use case is a sequence of related transactions performed by an actor and the system in dialogue.

USE CASE is dialogue between an actor and the system.

It is a snapshot of one aspect of system.

They model a dialog between actor and system.

A use case typically represents a major piece of functionality that is complete from beginning to end.

Most of the use cases are generated in initial phase, but you find some more as you proceed.

A use case may be small or large. It captures a broad view of a primary functionality of the system in a manner that can be easily grasped by non technical user.

Figure: Most popular party system

Figure: Searching the party’s candidate

Figure: Editing member detalis

Figure: Adding new member

Figure: Searching MP list

Use-Case Description

Number : UC01

Name : Most popular party system

Status : Working

Actors : Party, member , enquirer , Tax office , Estate agents , Publishing House, Candidate , Staff, donator , Media company

Pre-requisites : none

Goal : To play party activities

Use-Case relationships:

Extend :

Include :

Association : Party, member , enquirer , Candidate , Staff , Publishing House , Media company, Tax office , Estate agents , donator

Generalization :

Description :

Index

Actor event

1

Party pay taxation

2

Party give application form for new member

3

Enquirer pay new member fee

4

Member select candidate

5

Candidate stand for election

6

Party receive donation

7

Staff play party activities

Alternatives :

Index

Actor event

A4/5

Invalid data

A4/5.1

Member select invalid member ID

A4/5.2

Party notifies member of invalid member ID

A4/5.3

Member confirms

A6/7

Invalid data

A6/7.1

Donator pay money

A6/7.2

Party inform invalid amount

A6/7.3

Donator confirms

Figure: Most popular party System

Number : UC02

Name : Searching for the party’s candidate

Status : Working

Actors : Party, member , Candidate

Pre-requisites : none

Goal : To search for the party’s election candidates for a particular county

Use-Case relationships:

Extend : Stand for MP , Stand for AM

Include :

Association : Party, member , Candidate

Generalization :

Description :

Index

Actor event

1

Member select and inform candidate

2

Party choose the candidates from the region

3

Party choose the candidates from the county

Alternatives :

Index

Actor event

A1/2

Invalid data

A1/2.1

Member select invalid candidate ID

A1/2.2

Party know member of invalid data

A1/2.3

Member confirms

Figure: Searching the party’s election candidate

Number : UC03

Name : Editing member details

Status : Working

Actors : Party, member

Pre-requisites : none

Goal : To update party’s member details

Use-Case relationships:

Extend : Change address , Change status

Include : Check valid member ID

Association :Party , member

Generalization :

Description :

Index

Actor event

1

Party request update information

Figure: Editing the member details

Number : UC04

Name : Adding a new member

Status : Working

Actors : Party, member , enquirer

Pre-requisites : none

Goal : To add new member

Use-Case relationships:

Extend :

Include :

Association : Party , member , enquirer

Generalization :

Description :

Index

Actor event

1

Party give application form for new member

2

Enquirer pay new member fee

3

Member receive member card

Figure: Adding new member

Number : UC05

Name : Listing the party’s MP

Status : Working

Actors : Party, Candidate

Pre-requisites : none

Goal : To list the party’s MPs showing where each was selected

Use-Case relationships:

Extend : Select to stand for MP , Select to stand for AM

Include :

Association : Party , candidate

Generalization :

Description :

Index

Actor event

1

Party select candidate

2

Party play election

3

Party select MP

Figure: Listing the party’s MP

Activity Diagram

It is a special kind of state diagram and is worked out at use case level.

These are mainly targeted towards representing internal behavior of a a use case.

These may be thought as a kind of flowchart.

Flowcharts are normally limited to sequential process; activity diagrams can handle parallel process.

Activity diagrams are recommended in the following situations:

Analyzing use case

Dealing with multithreaded application

Understanding workflow across many use cases.

Figure: Activity diagram for most popular party

Figure: Activity diagram for searching for party’s candidate

Figure: Activity diagram for updating the member details

Figure: Activity diagram for adding new member

Figure: Activity diagram for listing the party’s MP

Task 2

A class diagram shows the existence of classes and their relationships in the logical view of a system. UML modeling elements in class diagrams are:

Classes their structure and behavior

Relationships components among the classes like association, aggregation, composition, dependency and inheritance.

Multiplicity and navigation indicators

Roles names or labels

In task 2 , we need to implement Most Popular Party System with class diagram including attributes and operation. We divide ten class for this system. They are:

Member

Candidate

MP

AM

Staff

Election

Office

Report

Expense

Income

Figure: Class diagram for Most Popular Party System

Task 3

Communication diagram

Sequence diagram

Figure: Updating the member datails

Figure: Adding new member

Figure: Searching candidate

Figure: Searching MP

State machines

UML state machine diagrams depict the dynamic behaviorof an entity based on its response to events, showing how theentity reacts to various events based on its current state. Createa UML state machine diagram to

explore the complex behavior of a class, actor, subsystem,or component;

Model real-time systems.

Figure: Member for state machine

Figure: Office for state machine

Figure: Election for state machine

Task 4

Protection of data are practiced mainly in two ways such as

Physical Access Control

Logical Access Control

Physical Access Controls are designed to prevent intruders getting near to the computer equipment. It includes keeping computer rooms under lock and key, assigning guards for the computer rooms, only allowing the authorized users to enter the computer room and allow to use the computers and making back-up of data file storing in safe places.

Logical Access Controls are also designed to prevent from the unauthorized data users who are using the computers. It includes protecting the data files by password, assigning the certain computer users only for particular computer application project and using the DBMS which allows the different levels of privilege for data access such as read only, write only etc.

a)

Our country is developing country, so we need to plan new law concerning with data protection. Nowadays we show this protection law and regulation for my country is:

fairly and lawfully processed

processed for limited, stated purposes

adequate, relevant and not excessive

accurate and up-to-date

kept no longer than necessary

processed in accordance with the individual’s rights

secure

not transferred to a country outside the European Economic Areaunless that country has adequate data protection itself.

b)

National legislation

This is relating to data protection, confidentiality and privacy, provides the main framework for the operations of CSO.

Data Confidentiality and privacy of data providers

Confidentiality of returns and penalty for improper disclosure are spelled out explicitly in the Act.

Data Collection, Storage and transmission

The electronic data collection method is used in the case of foreign trade statistics.With regard to data storage and transmission, paper documents and files are kept under lock and key in the various sections of the CSO. As for electronic data storage, data files are saved on hard disks, diskettes and CD. These data files can be accessed through the valid password.

 Data protection considerations

Only the designated staff has access to data files and programs through the use of user ID and password.

Measures taken to protect against computer viruses

Anti-virus software is installed in Local Area Networks for computer virus protection. Up-to-date versions of this software are being loaded on to the workstations in order to have the most up-to-date virus detection.

General awareness about data security issues

The computer rooms are kept under lock and key outside working hours. Each IT officer is responsible for the computer which is being assigned.

Measures taken to prevent unintentional data loss

To prevent from the unintentional data loss, a backup copy of the data and program files are made on diskette, CD-ROM and even on the hard disk of a separate microcomputer and they are kept in safe different places. On file servers a hard disk copy is kept as well as on client workstation.

c)

Best methods for data protection in new system:

Data Communication among the regional offices

Data Sharing in the Intranet

Electronic Data Interchange

On-line data services

Implementation of  regional databases using user-friendly Relational Database

Management Systems

Internet Home Page creation

Task 5

Figure: Searching the party’s candidate for a particular county

Figure: Adding new member

Figure: Editing member details

Figure: Listing party’s MP

Task 6

Data normalization

Gathering data for member

First Normal

Form

Second Normal Form

Third Normal

Form

Optimization

Name

Entity: Member

Entity: Member

Entity: Member

Entity: Member

NRC.no

PK: MemberID

PK: MemberID

PK: MemberID

PK: MemberID

Sex

Name

Name

Name

Name

Date of birth

NRC.no

NRC.no

NRC.no

NRC.no

Status

Sex

Sex

Sex

Sex

County

Date of birth

Date of birth

Date of birth

Date of birth

Region

Status

Status

Status

Status

Address

County

County

County

County

Region

Region

Region

Region

Address

Address

Address

Address

Gathering data for candidate

First Normal

Form

Second Normal Form

Third Normal

Form

Optimization

Name

Entity: Candidate

Entity: Candidate

Entity: Candidate

Entity: Candidate

NRC.no

PK: CandidateID

PK: CandidateID

PK: CandidateID

PK: CandidateID

Sex

FK: MemberID*

FK: MemberID*

FK: MemberID*

FK: MemberID*

Date of birth

Time

Time

Time

Time

Status

Year

Year

Year

Year

County

Region

Address

Gathering data for AM

First Normal

Form

Second Normal Form

Third Normal

Form

Optimization

Name

Entity: AM

Entity: AM

Entity: AM

Entity: AM

NRC.no

PK: AMID

PK: AMID

PK: AMID

PK: AMID

Sex

FK: CandidateID*

FK: CandidateID*

FK: CandidateID*

FK: CandidateID*

Date of birth

Status

County

Region

Address

Time

Year

Gathering data for MP

First Normal

Form

Second Normal Form

Third Normal

Form

Optimization

Name

Entity: MP

Entity: MP

Entity: MP

Entity: MP

NRC.no

PK: MPID

PK: MPID

PK: MPID

PK: MPID

Sex

FK: CandidateID*

FK: CandidateID*

FK: CandidateID*

FK: CandidateID*

Status

County

Region

Address

Time

Year

Gathering data for Staff

First Normal

Form

Second Normal Form

Third Normal

Form

Optimization

Name

Entity : Staff

Entity : Staff

Entity : Staff

Entity : Staff

NRC.no

PK: StaffID

PK: StaffID

PK: StaffID

PK: StaffID

Sex

Name

Name

Name

Name

Date of birth

NRC.no

NRC.no

NRC.no

NRC.no

Salary

Sex

Sex

Sex

Sex

County

Date of birth

Date of birth

Date of birth

Date of birth

Region

Salary

Salary

Salary

Salary

Address

County

County

County

County

Office type

Region

Region

Region

Region

Address

Address

Address

Address

Office type

Office type

Office type

Office type

Gathering data for income

First Normal

Form

Second Normal Form

Third Normal

Form

Optimization

Received from(Name)

Entity : Income

Entity : Income

Entity : Income

Entity : Income

Received by (Staff)

PK: IncomeID

PK: IncomeID

PK: IncomeID

PK: IncomeID

Received date

FK: StaffID*

FK: StaffID*

FK: StaffID*

FK: StaffID*

Annual fee

Received from(Name)

Received from(Name)

Received from(Name)

Received from(Name)

New member fee

Received by (Staff)

Received by (Staff)

Received by (Staff)

Received by (Staff)

Total income

Annual fee

Annual fee

Annual fee

Annual fee

New member fee

New member fee

New member fee

New member fee

Total income

Total income

Total income

Gathering data for expense

First Normal

Form

Second Normal Form

Third Normal

Form

Optimization

Channel date(Start)

Entity : Expense

Entity : Expense

Entity : Expense

Entity : Expense

Channel date(End)

PK: ExpenseID

PK: ExpenseID

PK: ExpenseID

PK: ExpenseID

Channel time

FK: StaffID*

FK: StaffID*

FK: StaffID*

FK: StaffID*

Charges per minute

Authorized by

Authorized by

Authorized by

Authorized by

Total amount

Description

Description

Description

Description

Time

Order date

Order quantity

Order description

Order amount

Unit price

Total price

Expense name

Authorized by

Expense description

Rent cost (Building)

Duration

Pay salary

Gathering data for election

First Normal

Form

Second Normal Form

Third Normal

Form

Optimization

Time

Entity : Election

Entity : Election

Entity : Election

Entity : Election

Place

PK: ElectionID

PK: ElectionID

PK: ElectionID

PK: ElectionID

Date

FK: StaffID

FK: StaffID

FK: StaffID

FK: StaffID

Organizer

Description

Description

Description

Description

Gathering data for Office

First Normal

Form

Second Normal Form

Third Normal

Form

Optimization

Name

Entity: Office

Entity: Office

Entity: Office

Entity: Office

Type

PK: OfficeID

PK: OfficeID

PK: OfficeID

PK: OfficeID

Address

Name

Name

Name

Name

Type

Type

Type

Type

Address

Address

Address

Address

Gathering data for Staff’s office

First Normal

Form

Second Normal Form

Third Normal

Form

Optimization

Salary

Entity:StaffOffice

Entity:StaffOffice

Entity:StaffOffice

Region

CK: StaffID

CK: StaffID

CK: StaffID

County

OffficeID

OffficeID

OffficeID

Salary

Salary

Salary

Region

Region

Region

County

County

County

Gathering data for Election member

First Normal

Form

Second Normal Form

Third Normal

Form

Optimization

Name

Entity: ElectionMember

Entity: ElectionMember

Entity: ElectionMember

Entity: ElectionMember

NRC.no

PK: ElectionID

PK: ElectionID

PK: ElectionID

PK: ElectionID

Sex

FK: MemberID*

FK: MemberID*

FK: MemberID*

FK: MemberID*

Date of birth

Status

County

Region

Address

Gathering data for report

First Normal

Form

Second Normal Form

Third Normal

Form

Optimization

Income

Entity: Report

Entity: Report

Entity: Report

Entity: Report

Expense

PK: ReportID

PK: ReportID

PK: ReportID

PK: ReportID

Total income

Date

Date

Date

Date

Total expense

Description

Description

Description

Description

Report description

Report ID

Report date

Gathering data for join report

First Normal

Form

Second Normal Form

Third Normal

Form

Optimization

Income

Entity: JoinReport

Entity: JoinReport

Entity: JoinReport

Entity: JoinReport

Expense

CK: IncomeID

CK: IncomeID

CK: IncomeID

CK: IncomeID

Total income

ExpenseID

ExpenseID

ExpenseID

ExpenseID

Total expense

ReprtID

ReprtID

ReprtID

ReprtID

Report description

Report ID

Report date

Data Dictionary

Element

Data Dictionary

Title

System

Document

Name

Sheet

 

Most popular system

 

 

 

Type

 

Name

 

 

Element

MemberID

Alias

 

 

 

 

Definition

 

 

 

 

MemberID

Occurrence

 

 

 

 

1 value per one member

Picture

 

 

 

 

Notes

 

 

 

 

Author

Date

LMT

 

 

 

 

 

Data Dictionary

Title

System

Document

Name

Sheet

 

Most popular system

 

 

 

Type

 

Name

 

 

Element

CandidateID

Alias

 

 

 

 

Definition

 

 

 

 

CandidateID

Occurrence

 

 

 

 

1 value per one candidate

Picture

 

 

 

 

Notes

 

 

 

 

Author

Date

LMT

 

 

 

 

 

Data Dictionary

Title

System

Document

Name

Sheet

 

Most popular system

 

 

 

Type

 

Name

 

 

Element

MPID

Alias

 

 

 

 

Definition

 

 

 

 

Member of parliament

Occurrence

 

 

 

 

1 value per one member of perliment

Picture

 

 

 

 

Notes

 

 

 

 

Author

Date

LMT

 

 

 

 

 

Data Dictionary

Title

System

Document

Name

Sheet

 

Most popular system

 

 

 

Type

 

Name

 

 

Element

AMID

Alias

 

 

 

 

Definition

 

 

 

 

assembly member

Occurrence

 

 

 

 

1 value per one assembly member

Picture

 

 

 

 

Notes

 

 

 

 

Author

Date

LMT

 

 

 

 

 

Data Dictionary

Title

System

Document

Name

Sheet

 

Most popular system

 

 

 

Type

 

Name

 

 

Element

StaffID

Alias

 

 

 

 

Party

Definition

 

 

 

 

StaffID

Occurrence

 

 

 

 

1 value per one staff

Picture

 

 

 

 

Notes

 

 

 

 

Author

Date

LMT

 

 

 

 

 

Store

Data Dictionary

Title

System

Document

Name

Sheet

 

Most popular system

 

 

 

Type

 

Name

 

 

Store

Member file

Alias

 

 

 

 

Definition

 

 

 

 

To store member information

Occurrence

 

 

 

 

50000 records to be held

Picture

 

 

 

 

Record lengths= 200 bytes

 

Flie size=10000000 bytes

Notes

 

 

 

 

Flow in =Add new member

Author

Date

Flow out=Change update information

LMT

 

 

Pay annual member fee

 

Data Dictionary

Title

System

Document

Name

Sheet

 

Most popular system

 

 

 

Type

 

Name

 

 

Store

Candidate file

Alias

 

 

 

 

Definition

 

 

 

 

To store candidate information

Occurrence

 

 

 

 

900 records to be held per year

Picture

 

 

 

 

Record length= 200 bytes

 

File size=180000 bytes

Notes

 

 

 

 

Flow in = Stand for Election

Author

Date

Flow out=Select for MP

LMT

 

 

Select for AM

 

Data Dictionary

Title

System

Document

Name

Sheet

 

Most popular system

 

 

 

Type

 

Name

 

 

Store

MP File

Alias

 

 

 

 

Definition

 

 

 

 

To store MP information

Occurrence

 

 

 

 

50 records to be held per year

Picture

 

 

 

 

Record length= 200 bytes

Flie size=10000 bytes

Notes

 

 

 

 

Author

Date

LMT

 

 

 

 

 

Data Dictionary

Title

System

Document

Name

Sheet

 

Most popular system

 

 

 

Type

 

Name

 

 

Store

AM File

Alias

 

 

 

 

Definition

 

 

 

 

To store AM information

Occurrence

 

 

 

 

100 records to be held per year

Picture

 

 

 

 

Record length=200 bytes

 

File size=20000 bytes

Notes

 

 

 

 

Author

Date

LMT

 

 

 

 

 

Data Dictionary

Title

System

Document

Name

Sheet

 

Most popular system

 

 

 

Type

 

Name

 

 

Store

Staff File

Alias

 

 

 

 

Definition

 

 

 

 

To store staff information

Occurrence

 

 

 

 

110 records to be held

Picture

 

 

 

 

Record length= 200 bytes

File size=22000 bytes

Notes

 

 

 

 

Flow in = List member

Author

Date

Flow out=Update information

LMT

 

 

 

 

 

Structure

Data Dictionary

Title

System

Document

Name

Sheet

 

Most popular system

 

 

 

Type

 

Name

 

 

Structure

Member file

Alias

 

 

 

 

Definition

 

 

 

 

Member = MemberID+Name+DOB+NRC.no+Sex+Address+Status

Occurrence

 

 

 

 

50000 records to be held

Picture

 

 

 

 

Notes

 

 

 

 

primary key= MemberID

Author

Date

LMT

 

 

 

 

 

Data Dictionary

Title

System

Document

Name

Sheet

 

Most popular system

 

 

 

Type

 

Name

 

 

Structure

Candidate File

Alias

 

 

 

 

Definition

 

 

 

 

Candidate=CandidateID+Name+DOB+NRC.no+Sex+Address+Stauts

Occurrence

 

 

 

 

900 records to be held

Picture

 

 

 

 

Notes

 

 

 

 

Primary key=CandidateID

Author

Date

LMT

 

 

 

 

 

Data Dictionary

Title

System

Document

Name

Sheet

 

Most popular system

 

 

 

Type

 

Name

 

 

Structure

MP file

Alias

 

 

 

 

Definition

 

 

 

 

MP= PMID+Name+DOB+NRC.no+Sex+Address+Status+Time

Occurrence

 

 

 

 

50 records to be held per year

Picture

 

 

 

 

Notes

 

 

 

 

Primary key=MPID

Author

Date

LMT

 

 

 

 

 

Data Dictionary

Title

System

Document

Name

Sheet

 

Most popular system

 

 

 

Type

 

Name

 

 

Structure

AM file

Alias

 

 

 

 

Definition

 

 

 

 

AM= AMID+Name+DOB+NRC.no+Sex+Address+Status+Time

Occurrence

 

 

 

 

100 records to be held per year

Picture

 

 

 

 

Notes

 

 

 

 

Primary key=AMID

Author

Date

LMT

 

 

 

 

 

Data Dictionary

Title

System

Document

Name

Sheet

 

Most popular system

 

 

 

Type

 

Name

 

 

Structure

Staff file

Alias

 

 

 

 

Party

Definition

 

 

 

 

Staff= StaffID+Name+DOB+NRC.no+Sex+Address+Status+Office type

Occurrence

 

 

 

 

110 records to be held

Picture

 

 

 

 

Notes

 

 

 

 

Primary key- StaffID

Author

Date

LMT

 

 

 

 

 

Task 7

Advantages of Object-Oriented approach

Object-oriented approach makes the promise of reduced maintenance, code reusability, real world modeling, and improved reliability and flexibility.  However, these are just promises and in the real world some users find that the object-oriented benefits are not as compelling as they originally believed.  Code reusability is a subjective thing, and depends heavily on how the system is defined.  The object-oriented approach does give the ability to reduce some of the major expenses associated with systems, such as maintenance and development of programming code.  Here are some of the benefits of the object-oriented approach:    

Promotes better understanding of user requirements

Leads cleaner design

Design flexibility'

Decomposition of the system is consistent

Facilitates data abstraction & information hiding

Software reuse

Easy maintenance

Reduce Maintenance

Real world modeling

Improved reliability and flexibility

High code reusability

Increased speed

Improved efficiency

Wider perspective

Stable form

Captures business processes

Enhance communication and ensures the right communication

Capability to capture the logical software architecture independent of the implementation language

Manages the complexity

Enables reuse of design

Disadvantages of Object-Oriented approach

Decreased system / software performance: Problems with dynamic memory allocation means that either more memory is used-up on garbage, or that the system run-time speed is compromised by the need for garbage collection

Increased initial development time

Less than anticipated levels of reuse: With class libraries based on inheritance, the code of a component is not collected together in one place, but rather it is spread over the class hierarchy. The re-user must examine a number of classes to establish whether a component can be re-used. As more and more classes are added to a class hierarchy, it becomes increasingly difficult to manage.

SSADM techniques

Logical Data Modeling– The data requirements of the system being designed are identified, modeled and documented. This data is separated into entities and relationships between these entities identified.

Data Flow Modeling– Concerned with how the data moves around the information system.

Examines processes, data stores, external entities and data flows.

Entity Behavior Modeling– The identifying, modeling and document events with respect

to the entities in the system and the order in which these events take place.

Objectives of SSADM

SSADM was developed with the following objectives

Ensure that projects can successfully continue should a loss of staff occur without damaging effect on the project

Develop overall better quality systems

Improve the way in which projects are controlled and managed

Allow more effective use of experienced and inexperienced staff and their development

Make it possible for projects to be supported by computer based tools

Improve communication between participants in a project so an effective framework is in place

OOAD

SSADM

Function : Use case diagram, Use case specification and activity diagram

Function : Mini- specification and Data flow diagram

Data : Class diagram

Data : Entity relationship diagram

Event : Communication diagram, Sequence diagram and State machine

Event : Entity life history

Benefits of SSADM

Timelines: SSADM make one to plan, manage and control a project well. SSADM’s points are essential to deliver the product on time.

Usability: SSADM emphasis is put on the analysis of user needs. The systems model is developed and a comprehensive demand analysis is carried out.

Respond to changes in the business environment: In SSADM documentation of the project’s progress is taken very seriously. It offers the possibility to tailor the planning of the project to the actual requirements of the business.

Effective use of skills: SSADM does not require very special skills and then can easily be taught to the staff.

Better quality: SSADM reduces the error rate of IS in the beginning and constantly checking the system.

Improvement of productivity: By encouraging on-time delivery, meeting business requirements, ensuring better quality, using human resources effectively.

Cuts costs: SSADM separates that the logical and the physical systems design. Therefore the system does not have to be implemented again with new hard -or software.

Disadvantages of SSADM

SSADM puts main emphasis on the analysis of the system and documentation. This causes the danger of over-analyzing, which can be very time and cost consuming. Due to various types of description methods, checks of consistence cannot be carried out. So, the danger of spending too much money on analysis can be compensated by the reuse of the developed systems and experience gained.

Task 8

Professional Standard Report for Most Popular Party System

I hope you can see that OOA/D offers a number of potential benefits in an OO based development environment. These include:

better modeling of the problem domain (equals happier users)

better overall software design with a strong focus on class structure more flexible and maintainable systems through better class partitioning

good documentation (the notations) - and a single central overall design notation (the Object Model)

a flexible approach to project phasing

assistance in tie-ing down requirements, and

less work (in the long run)

The goal is for UML to become a common language for creating models of object oriented computer software. The UML notation is rich and full bodied. It is comprised of two major subdivisions. There is a notation for modeling the static elements of a design such as classes, attributes, and relationships. There is also a notation for modeling the dynamic elements of a design such as objects, messages, and finite state machines.

The Unified Modelling Language (UML) is a diagramming language or notation to specify, visualise and document models of Object Orientated software systems. UML is not a development method that means it does not tell you what to do first and what to do next or how to design your system, but it helps you to visualise your design and communicate with others. UML is controlled by the Object Management Group (OMG) and is the industry standard for graphically describing software.

UML is designed for Object Orientated software design and has limited use for other programming paradigms. UML is composed of many model elements that represent the different parts of a software system. The UML elements are used to create diagrams, which represent a certain part, or a point of view of the system. The following types of diagrams are supported by UML Modeller:

Use Case Diagrams show actors and their relationships

Class Diagrams show classes and the relationships between them

Sequence Diagrams show objects and a sequence of method calls they make to other objects.

Collaboration Diagrams show objects and their relationship, putting emphasis on the objects that participate in the message exchange

State Diagrams show states, state changes and events in an object or a part of the system

Activity Diagrams show activities and the changes from one activity to another with the events occurring in some part of the system

Component Diagrams show the high level programming components

Deployment Diagrams show the instances of the components and their relationships.

Use case diagram

A Use Case shows from the point of view of the actors that a group of activities in a system that produces a concrete, tangible result.

Use Cases are descriptions of the typical interactions between the users and the system. It represents the external interface of the system and specify a form of requirements of what the system has to do.

This is the important rules:

Any Use Case is related to at least one actor

Any Use Case has an initiator

Any Use Case leads to a relevant result.

Use Cases can also have relationships with others. The three most typical types of relationships between Use Cases are:

<<include>> that specifies that a Use Case takes place inside another Use Case

<<Extends>> that specifies that in certain situations, or at some point (called an extension point) a Use Case will be extended by another.

Generalisation specifies that a Use Case inherits the characteristics of the "Super"-Use Case.

Actor

An actor is an external entity in the system. Actors must be in real world life people other computer systems or external events. The actors do not represent the physical people or systems, but their role.

System Boundaries

By definition, use cases capture the functionality of a particular subject. Anything not realized by the subject is considered outside the system boundaries and should be modeled as an actor. This technique is very useful in determining the scope and assignment of responsibilities when designing a system, subsystem, or component. You represent system boundaries in a generic sense using a simple rectangle, with the name of the system at the top

Use Case Description

Use Case Descriptions are textual narrators. They usually take the form of a note or a document and explanation of the processes or activities that take place in the Use Case.

Use-Case Description Template

Use Case

Perspective

Type

Brief Description

Business Goals and Benefits

Actors

Primary Actors

Secondary Actors

Off-Stage Stakeholders

Rules of Precedence

Triggers

Preconditions

Post conditions

Post conditions on Success

Post conditions on Failure

Any condition listed here is guaranteed to be true when the use case fails.

Extension Points

Activity diagram

Activity Diagrams shows the sequence of activities in a system. Activity Diagrams are a special form of State Diagrams. Activity Diagrams are always connected with a Class, an Operation or a Use Case.

Activity Diagrams support sequential and parallel Activities. Parallel execution is represented Fork/Wait icons, and for the Activities running in parallel, it is not important the order in which they are carried out.

Activity

An Activity is a single step in a process and one Activity is one state in the system with internal activity one outgoing transition. Activities must also have more than one outgoing transition if they have different conditions.

Activities can form hierarchies which an Activity can be composed of several detail Activities that is the incoming and outgoing transitions should match the incoming and outgoing transitions of the detail diagram.

Activity diagrams may include the following elements:

Initial node: Indicates where the workflow begins.

Control flow: An arrow showing the direction of the workflow.

Activity: Indicates a step in the process.

Decision: A diamond symbol, indicating a choice. Workflow will proceed along one of a number of possible paths, according to the guard conditions.

Merge: Use this symbol if you wish to follow best practices when a number of flows lead to the same activity and your intention is that any of the flows would lead to the activity.

Guard condition: A condition attached to a control flow. Guard conditions are usually attached to control flows that come out of a decision symbol. A guard is shown within square brackets.

Event: A trigger attached to a control flow. An event must occur for the flow to move along the control flow. An event is indicated without the use of square brackets.

Fork and join: Bars used to document parallel activities. As fork indicates the point after which a number of activities may begin in any order. A join indicates that workflow may commence only once the parallel activities that flow into it have all been completed.

Final node: Indicates the end of the process.

Class Diagram

Class Diagrams are showing the different classes that make up a system and how they relate to each other. Class Diagrams are said to be static diagrams because they show the classes with their methods and attributes as well as the static relationships but do not show the method calls between them.

Attributes

In UML, Attributes are shown with their name, and their type, initial value and other properties. Attributes can also be displayed with their visibility:

+ public attributes

# protected attributes

- private attributes

Operations

Operations or methods are also displayed with at least their name, and their parameters and return types. Operations can, just as Attributes, display their visibility:

+ public operations

# protected operations

- private operations

Templates

Classes can have templates that are used for an unspecified class or type. The template type is specified when a class is initiated.

Class Associations

Classes must relate to each other in different ways:

Generalisation

The inheritance is one of the basic concepts of Object Orientated programming. In UML, a Generalisation association between two classes puts them in a hierarchy. In UML, Generalisations are represented by a line connecting the two classes, with an arrow on the side of the base class.

Associations

An association shows a relationship between classes and gives the common semantics and structure for many types of connections between objects. Associations are the mechanism which allows objects to communicate to each other. This describes the connection between different classes. Associations may have a role that specifies the purpose of the association. Each end of the association may also have a multiplicity value, which dictates how many objects on this side of the association can relate to one object on the other side.

Associations are represented as lines connecting the classes participating in the relationship, and can also show the role and the multiplicity of each of the participants in UML. Multiplicity is showed as a range of non-negative values, with a star on the maximum side representing infinite.

Aggregation

Aggregations are one type of associations that the two participating classes don't have an equal status, but make a whole-part relationship. An Aggregation shows how the class that takes the role of the whole, is composed of other classes, which take the role of the parts. The class acting as the whole always has a multiplicity of one for Aggregations. Aggregations are represented by an association that shows a rhomb on the side of the whole in UML.

Composition

Compositions are associations which display very strong aggregations. Compositions form whole-part relationships but the relationship is so strong that the parts cannot exist on its own and exist only inside the whole. If the whole is destroyed the parts die too. Compositions are showed by a solid rhomb on the side of the whole in UML.

State machines diagram

A state machine diagram is a picture that describes the different statuses (states) of an object and the events and conditions that cause an object to pass from one state to another. The diagram describes the life of a single object over a period of time, one that may span several system use cases.

Initial state: This is shown as a "dot" on the diagram. This is the "start" point for the object. It doesn’t represent actual states of the object.

Final state: This appears as a bulls-eye. It represents the final state of the object. The final state may be named, and there may be more than one final state for an object.

Rounded rectangle state: This state is shown that the object isn’t doing anything important; it is simply waiting for an event to happen or a condition to become true. (OR) the object is performing some ongoing process and stays in this state until some event interrupts the process. (OR) the object is performing some work that has a definite end. Once the work is over, the object passes out of the state.

A state machine is a behavior that specifies the sequences of states an object goes through during its lifetime in response to events, together with its responses to those events. A state is a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for events. An event is the specification of a significant occurrence that has a location in time and space. A transition is a relationship between two states indicating that an object in the first state will perform certain actions and enter the second state when a specified event occurs and specified conditions are satisfied. An activity is ongoing nonatomic execution within a state machine. An action is an executable computation that results in a change in state of the model or the return of a value.

Transitions

A transition is a relationship between two states indicating that an object in the first state will perform certain actions and enter the second state when a specified event occurs and specified conditions are satisfied. On such a change of state, the transition is said to fire. Until the transition fires, the object is said to be in the source state; after it fires, it is said to be in the target state

A transition has 5 types:

Source state

The state affected by the transition; if an object is in the source state, an outgoing transition may fire when the object receives the trigger event of the transition and if the guard condition, if any, is satisfied

Event trigger

The event whose recognition by the object in the source state makes the transition eligible to fire, providing its guard condition is satisfied

Guard condition

A Boolean expression that is evaluated when the transition is triggered by the reception of the event trigger; if the expression evaluates true, the transition is eligible to fire; if the expression evaluates false, the transition does not fire, and if there is no other transition that could be triggered by that same event, the event is lost

Effect

An executable behavior, such as an action, that may act on the object that owns the state machine and indirectly on other objects that are visible to the object

Target state

The state that is active after the completion of the transition

Sequence diagram

The sequence diagram is used to show the interactions between the objects in the sequential order that those interactions occur. Developers typically think sequence diagrams were meant exclusively for them and sequence diagrams useful to communicate how the business currently works by showing how various business objects interact. During the requirements phase of a project, analysts can take use cases to the next level by providing a more formal level of refinement.

An organization's staff can find sequence diagrams useful in documenting how a future system should behave. During the design phase, architects and developers can use the diagram to force out the interactions overall system design.

One of the primary uses of sequence diagrams is in the transition from requirements expressed as use cases to the next and more formal level of refinement. Use cases are often refined into one or more sequence diagrams. In addition to their use in designing new systems, sequence diagrams can be used to document how objects in an existing system currently interact.

The basics

The main aim of a sequence diagram is to define event sequences which result in some desired outcome. The focus of the sequence diagram is less on messages themselves and more on the order in which messages occur, most sequence diagrams will communicate what messages are sent between a system's objects. The diagram conveys information along the horizontal and vertical dimensions: the vertical dimension describes top down, the time sequence of messages as they occur, and the horizontal dimension describes left to right, the object instances that the messages are sent to.

Lifelines

When implementing a sequence diagram, lifelines are placed across the top of the diagram. Lifelines represent either roles or object instances that participate in the sequence being modeled. Lifelines are shown as a box with a dashed line descending from the center of the bottom edge. The lifeline's name is placed in the box.

Object Name : Class Name

Messages

The first message in a sequence diagram starts at the top and is typically located on the left side of the diagram. Subsequent messages are added to sequence diagram slightly lower than previous message.

To show an object sending a message to another object, you draw a line to the receiving object with a solid arrowhead. The method name is placed above the arrowed line in the sequence diagram. The message is being sent to the receiving object represents a method which the receiving object's class implements.

Communication diagram

The communication diagram is categorized in the UML as an interaction diagram. Both diagrams are able to show the sequencing of operations for a scenario and indicate which object does which operation. However, each highlights a different aspect of the collaboration: The communication diagram highlights structure—the ways in which objects are linked to each other—while the sequence diagram highlight timing—the order in which messages are sent between objects. In a communication diagram, objects are connected by solid lines (links). The messages are indicated as labeled arrows above the links. Each message is numbered to indicate sequencing. The communication diagram illustrates the same scenario shown in the previous sequence diagram

Data normalization

Normalization is carried out in the following steps:

Collect the data-set – the set of data-items

Choosing the primary key

Transform the unnormalised data-set into tables in first normal form

Transform first normal form tables to second normal form

Transform second normal form tables to third normal form

Transform to optimization

UNNORMALISED DATA-SET TO FIRST NORMAL FORM

A relation is in first normal form if and only if every non-key attribute is functionally dependent upon the primary key

FIRST NORMAL FORM TO SECOND NORMAL FORM

To move from first normal form to second normal form we remove part-key dependencies. A relation is in second normal form if and only if it is in first normal form and every non-key attribute is fully functionally dependent on the primary key

SECOND NORMAL FORM TO THIRD NORMAL FORM

To move from second normal form to third normal form we remove inter-data dependencies. To do this we examine every table and ask of each pair of non-key data-items: is the value of data-item .A relation is in third normal form if and only if it is in second normal form and every non-key attribute is non-transitively dependent on the primary key

THIRD NORMAL FORM TO OPTIMIZATION

This is completed normalization.

Data dictionary

A data dictionary is a file that contains the details of the data; it contains the rules for the use of the database files. The information in a data dictionary in different DBMSs, but it generally contains the following type of information:

The data available.

Where data is located.

Descriptions of data

Ownership of the data

Access to data

How the data is used

Relationships between data items

Limitations(security and privacy)

The data dictionary is in constant use as a reference tool. When data is requested, the DBMS refers to the data dictionary to find the details of where data is stored, whether the user has authority and so on.

Hardware Requirement

We recommend that you use a computer that is not your primary workstation tothe practice exercises because you will make changes to the operating system and application configuration.

Pentium 4 or above.

CPU is 1.8 GHz or above.

Random Access Memory (RAM)is 512Mmb.

Hard Disk space is 2GB for my system and 9GB for operation system.