executive summar€¦ · web view2016. 10. 28. · mysql has many reasons to why it is the...

Software Architecture 3412ICT/7412ICT


mySQLSoftware Architecture Document (SAD)

Workshop No: 3

[email protected] No: 1

Students:

Jed Burr, s5034187 (Leader)Iuliana Saparkina, s2966827

Jane Nenkova, s2911947Slobodan Olujic, s2958331

Sy Le, s5017252

Monday, May 9th, 20161 of 67


Table of Contents

1. Executive Summary 2. System Introduction

2.1. History 2.2. Stakeholders 2.3. Competitive Landscape 2.4. Strengths 2.5. Weaknesses 2.6. Opportunities 2.7. Threats

3. Architecture Background 3.1. Context Information 3.2. Description of contextual information

Inputs and outputs of the context diagram, concise description:3.3. Significant Driving Requirements

4. Views 4.1. Module View

4.1.1. View Packet Overview 4.1.2. View Packets

4.1.2.1. View Packet #1: MySQL 4.1.2.1.1. Primary Presentation 4.1.2.1.2. Element Catalog

4.1.2.1.2.1. Elements 4.1.2.1.2.2. Relations

4.1.2.1.3. Context Information 4.1.2.2. View packet #2: Transaction Processor

4.1.2.2.1. Primary Presentation 4.1.2.2.2. Element Catalog


4.1.2.2.3. Context Information 4.1.2.3. View packet #3 Storage Management



4.1.2.3.3. Context Information 4.1.2.4. View packet #4 Query Manager





4.1.2.4.3. Context Information 4.1.2.5. View packet #5: Recovery Management



4.1.2.5.3. Context Informatio n 4.2. Component and Connector View

4.2.1. View Packet Overview 4.2.2. View Packets 4.2.3. View packet # 1 Server Component

4.2.3.1. Primary Presentation 4.2.3.2. Element Catalog

4.2.3.2.1. Elements 4.2.3.2.2. Relations

4.2.3.3. Context diagram 4.2.4. View packet 2: Client component

4.2.4.1. Primary presentation 4.2.4.2. Element Catalog


4.3. Allocation View 4.3.1. View Packet Overview 4.3.2. View Packets 4.3.3. View packet - Deployment View



4.3.3.3. Context Information 4.3.4. View packet - Deployment Requirements



4.3.4.3. Context Information 4.3.5. View packet - Implementation View (Connector/ODBC 5.3.6)


4.3.5.2.1. Elements



4.3.5.2.2. Relations 4.3.5.3. Context Information

4.3.6. View packet - Implementation View (My SQL Connector/C 6.1.6) 4.3.6.1. Primary Presentation 4.3.6.2. Element Catalog


4.3.6.3. Context Information 4.3.7. View packet - Implementation View (MySQL Server 5.7)



4.3.7.3. Context Information 5. Relations Among Views

5.1. General Relations Among Views 5.2. View-to-View Relations

5.2.1. Module-to-CnC View Relations 5.2.2. CnC-to-Allocation View Relations 5.2.3. Module-to-Allocation View Relations

5.3. Stakeholders Interests to Views 6. References 7. Project Management Report

7.1. Project working Load 7.2. Project Working Load Summary 7.3. Individual effort and contribution summary



1 Executive Summary

MySQL is the industry leader in database systems. MySQL comes in enterprise edition, and in community supported open source edition which will be the focus of this paper. It possesses great scalability in supporting large volumes of data and users, and embedded database applications as well. It offers speed, reliability and ease of use. Different analyses of it are conducted in this paper, including SWOT, and assorted software architecture module views.

Keywords: MySQL, database system, community edition, open source, software architecture, module views.



2 System Introduction

Renowned as the world’s second most widely used and most widely open-source client-server model relational database management system (RDBMS) – a software that enables users use of web features that can implement a database with tables, columns, indexes and can also interpret an SQL query. MySQL is a Structured Query Language; a database management system that is being used for businesses of many sizes enabling cost-effective delivery of reliable, high performance and scalable Web-based and embedded database applications.

2.1 HistoryFounded by the company MySQL AB, MySQL was first released in May 23rd 1995 and was written in programming languages C, C++. Over the period of 20 years, the development of MySQL grew exponentially first being released onto Windows 95 and NT in 1998, establishing a trialing beta period that ran different versions from 2000 to 2005 leading up to more advanced MySQL Server 5.5 that featured enhancements and changes, such as initializing a default storage engine known as InnoDB, which supports transactions and referential integrity constraints, improved InnoDB I/O subsystem and new options for user-defined partitioning. New features were being added as the system continued to grow, and as of now MySQL 5.7 is the latest version. Within those years, in 2008 Sun Microsystems bought MySQL for $1b who then entered into an agreement with Oracle Corporation in 2009 to purchase Sun Microsystems, then owners of MySQL copyright and trademark.

2.2 StakeholdersMySQL, founded by Company MySQL AB was developed by David Axmark, Allan Larsson and Michael “Monty” Widenius. As of now, Oracle owns the right to all trade mark and copyright of MySQL, and are investing into stakeholders who continue to contribute to the growth of the system. These stakeholders are listed as:

● Users - The people who interact with MySQL and will be utilizing it for their own personal needs. Their opinion on efficiency of MySQL helps mound what the system should be aiming for.

● Acquirers – Sun Microsystems first bought MySQL AB for $1b in 2008, and then sold it to Oracles Corporation along with the owners of MySQL’s copyright and trademark.

● Developers – After being sold to Oracles, a new development team continued working on the development of MySQL, improving and upgrading it to the latest version MySQL 5.7

● Maintainers - The people who will regulate and handle the maintenance of MySQL internally and externally. They upload new versions and adjust other attributes in the package database.



● Infrastructure support – The people who handled the design for MySQL’s architecture infrastructure

● Analyst – The people who analyzed MySQL’s development phase and made reviewed the pros and cons of the design.

● Project Manager – The person who handles a group of people and sets them tasks to complete.

2.3 Competitive LandscapeAs a relational database management system, MySQL faces the challenge of trying to outcompete against major competitors that perform the same functionality of the system and against programs that could otherwise be used as alternates instead of MySQL. These challengers include

● MariaDB● PostgreSQL ● Software SQL● Oracle Database● SQLite

Table 1: SWOT Analysis OverviewStrengths

● MySQL is free and open, rich with features and benefits that can be shared and installed on differently OS easily● Overwhelming MySQL’s community is willing to help in debugging, maintaining and upgrading the system● Extremely popular within low and middle scale companies and has the biggest part of the market compared to other open sourced database.

Weaknesses

● The most noticeable issue in MySQL is that it can’t support the large database effectively● Lack of problem solving solutions and responsibilities for the MySQL, technical issues from the official representative

Opportunities

● High profit on large Enterprise organisations

Threats

● Highly competitive market

2.3.1 StrengthsMySQL has many reasons to why it is the world’s second most widely used and most widely open-source client-server model relational database management system (RDBMS). MySQL offers scalability & flexibility, high performance, high availability, robust transactional support, web and data warehouse strengths, strong data protection, comprehensive application development, management ease, open source



freedom and 24/7 support and lowest total cost of ownership. All these reasons are factors to why MySQL is successful.

Another strength to MySQL is the success they have to the online world, being implemented in many high-profiled, large scale websites including Google, Facebook, Twitter, Flickr and YouTube. MySQL is compatible with any type of operating system, and remains one of the most used database systems in the world that it has become more or less an industry standard. Their popularity have been waning in recent years with the lack of innovation MySQL has been doing with system development but being used by leading web applications is an advantage they have over competitors.

2.3.2 WeaknessesThe weakness that MySQL holds is the company’s lack of innovation. Ever since Oracle Corporations got the rights for MySQL AB, there has been a lack of progress in the development of the relational database management system with only one major release in the past several years. This sudden halt has left the MySQL community left wondering and frustrated, as the company does not accept community-developed patches, nor has it bothered to offer users any sort of roadmap for the MySQL development. The lack of innovation could lead to the downfall of MySQL where other companies may use this opportunity to overtake them.

While MySQL is equipped to handle a virtually limitless volume of data, it has been known to halt when overridden with too many operations at a given time. Poor performance scaling is the problem in MySQL and may slow the efficiency and effectiveness of the relational database management system of, giving them unnecessary stress thus proving to be a flaw in MySQL’s user interface design

2.3.3 OpportunitiesMySQL Enterprise edition gives the opportunity for enterprises to utilize comprehensive set of advanced features that are designed to benefit them. This edition exists to improve the overall environment of businesses, composing of MySQL enterprise manager, monitor, backup, encryption and many more and is cost effective meaning that it’s significantly less expensive than most other database options on the market. Overall will be beneficial to enterprises.



2.3.4 ThreatsA threat that MySQL faces is outcompeting major competitors that perform the same functionality of the system and against programs that could otherwise be used as alternates instead of MySQL, compared to software’s like MariaDB and PostgreSQL. Although SQL may be holding the title of the world’s second most widely used and most widely open-source client-server model relational database management system (RDBMS), compared against MariaDB who have third-party storage engines, various performance enhancements, extensions and new features, MySQL is lacking in fields that competitors can take advantage off. Overcoming this obstacle will require MySQL to ensure that their RDBMS matches the market expectation to overcome the flaws they lack.

3 Architecture Background

3.1 Context Information

Figure 1: Context Diagram

Client connects to the database on the servers through MySQL (relational database management system based on Structured Query Language). Client sends queries to the database (in form of MySQL) located on the server. Server replies, sending results back to MySQL, to be read by the client.



3.2 Description of contextual information

Inputs and outputs of the context diagram, concise description:

● Initially the connection is established between the client and MySQL● And between MySQL and the Server(s)● Then, Client submits a Query towards the database system (MySQL).

● Database system (MySQL) then interprets and passes it onwards to server architecture where the actual information is stored.

● The server(s) reply to MySQL, locating and sending requested data. ● MySQL again servers as a mediator between the server where the data is actually stored, and the

Client requesting access to such data● Where in turn (MySQL) responds to Client, delivering him with a desired Query Result.

3.3 Significant Driving RequirementsDriving requirements for the proper implementation of this system are:

● a proper server side physical infrastructure ● mediating database modelling and manipulating software (MySQL in this case)● adequate client side architecture used for connecting to a database● and of course a need for such system to be implemented



4 Views

4.1 Module View

The module view can be used to describe the MySQL software units called modules and how they are connected. This viewtype shows lower level submodules that are partly hidden, the functional characteristics of the submodules and provides the necessary information that is required to develop blueprints for construction. Since MySQL has multiple modules they have been separated into view packets below.

4.1.1 View Packet Overview

The module view has been divided into the following view packets for convenience of presentation:

Table 2: View Packet Overview for MySQL

Number of View Packet View Packet Name Description

1 MySQL System Represents the 4 main modules inside the system and how they interact.

2 Transaction Processor Represents the Transaction Processor module, its submodules and their interactions.

3 Storage Management Represents the Storage Management module, its submodules and their interactions.

4 Query Manager Represents the Query Manager module, its submodules and their interactions.

5 Recovery Management Represents the Recovery Management module, its submodules and their interactions.



4.1.2 View Packets

4.1.2.1 View Packet #1: MySQL

4.1.2.1.1 Primary PresentationTable 3: Primary Presentation for View Packet #1

System Segment

MySQL

Transaction Processor

Storage Management

Query Manager

Recovery Management



Figure 2 : Decomposition view of View Packet 1: MySQL



4.1.2.1.2 Element Catalog

4.1.2.1.2.1 Elements

Table 4 : Visibility of the MySQL modules

Visibility Transaction Processor is visible to the Recovery Management and the Query Manager.

Storage Management is visible to the Recovery Management, Transaction Processor, and Query Manager.

Query Manager is visisble to external systems.

Recovery Management is visible to the Transaction Processor and the Query Manager.

Table 5 : Elements of the MySQL modules

Element name Element’s responsibility

Transaction Processor

The Transaction Processor handles the transaction process and maintains concurrency in the data access. This module has relationships with the Storage Management, Query Manager and Recovery Management. There are 2 submodules that are in this module, Concurrency-Control Manager and the Transaction Manager.

Storage Management

The Storage Management module is in charge of reading data from physical devices and writing information to various files. To do this, it interacts with the Recovery Management, the Query Manager, and the Transaction Processor. There are 3 submodules that are in this module, Storage Manager, Buffer Manager and Resource Manager.

Query Manager The Query Manager is a critical component that talks to the other components and deals with incoming queries by parsing and optimising them. It utilises Structured Query Language (SQL) for inputs. There are 7 submodules that are in this module, Query Preprocessor, Query Parser, Query Optimiser, Embedded DML Precompiler, DDL Compiler, Security & Integration Manager, and Execution Engine.

Recovery Management

Recovery Management is in charge of dealing with keeping backup copies of data in case of software or hardware failure and logging data editing events or commands. It interacts with the Query Manager, the



Transaction Processor and the Storage Manager. There are 2 submodules in this module, the Log Manager and the Recovery Manager.

4.1.2.1.2.2 Relations

The View Packet 1 uses the is-part-of type of relations. There are no exceptions or additions to the relations shown in the primary presentation.

4.1.2.1.3 Context Information



Figure 3 : Context Diagram of MySQL

4.1.2.2 View packet #2: Transaction Processor

4.1.2.2.1 Primary Presentation

Table 6 : Primary Presentation for View Packet 2



System Segment

Transaction Processor Concurrency-Control Manager

Transaction Manager

Figure 4 : Decomposition view of View Packet #2: Transaction Processor





Table 7 : Visibility of the Transaction Processor submodules

Visibility Concurrency-Control Manager is visible to the Transaction Processor and the Query Manager module (important for the Execution Engine submodule in the Query Manager)

Transaction Manager is visible to the Query Manager module (important for the Execution Engine submodule in the Query Manager)

Table 8 : Elements of the Transaction Processor submodules


Concurrency-Control Manager This submodule executes separate & independant transactions by utilising data locks.

Transaction Manager This submodule manages the transaction process and resolves any stoppages within the database. The submodule also issues SQL commands to confirm or undo transactions.


The View Packet 2 uses the is-part-of type of relations. The Transaction Processor could not function without one or both of the submodules above.




Figure 5 : Context diagram for the Transaction Manager module



4.1.2.3 View packet #3 Storage Management


Table 9 : Properties of Storage Management module

System Segment

Storage Management Storage Manager

Buffer Manager

Resource Manager

Figure 6 : Decomposition view of View Packet #3: Storage Management





Table 10 : Visibiliy of the Storage Management submodules

Visibility Storage Manager is visible to the Recovery Management (specifically bv the Recovery Manager and the Log Manager), the Query Manager module (specifically for the Execution engine submodule), and the Transaction Processor module and its submodules.

Buffer Manager is visible to the Resource Manager submodule only.

Storage Manager is visible to the Buffer Manager submodule only.

Table 11 : Elements of the Storage Management module

Element name Element’s responsibilities

Storage Manager This submodule handles requests between any physical storage and the Buffer Manager to extract the required data.

Buffer Manager This submodule manages the buffer by deciding how much memory each request needs to provide or manipulate data provided for the Resource Manager.

Resource Manager

This submodule is responsible for dealing with requests for data from higher level submodules and modules. It also deals with obtaining any necessary data from the Buffer Manager.


The View Packet 3 uses the is-part-of type of relations. The Storage Manager could not function without one of the submodules above.




Figure 7 : Context diagram for the Storage Management module



4.1.2.4 View packet #4 Query Manager


Table 12 : Primary Presentation for View Packet #4: Query Manager

System Segment

Query Manager

Query Preprocessor

Query Parser

Query Optimiser

Embedded DML Precompiler

DDL Compiler

Security & Integration Manager

Execution Engine

Figure 8 : Decomposition view of View Packet #4: Query Manager module





Table 13 : Visibility of the Query Manager submodules

Visibility Query Preprocessor

Query Parser

Query Optimiser

Embedded DML Precompiler

DDL Compiler

Security & Integration Manager

Execution Engine



Table 14 : Elements of the Query Manager submodules

Element name Element’s responsibilities

Query Preprocessor This submodule deals with checking SQL syntax and verifies the validity of the query.

Query Parser This submodule creates a parsing tree structure for the next submodule to further process the SQL query.

Query Optimiser This submodule optimises the SQL query using various optimisation techniques and indexes where possible.

Embedded DML Precompiler This submodule converts DML statements that have been embedded in an application into SQL queries that can be read by the other submodules.

DDL Compiler This submodule turns DDL commands into SQL statements which could be sent from administrative tools for MySQL to run.

Security & Integration Manager This submodule checks the client’s privileges against an access control list to determine whether to allow or deny access to the database or certain parts of the database.

Execution Engine This submodule executes the SQL statement after the other submodules in the Query Manager module have finished. It accesses the database through the Storage Management module and also interacts with the Recovery Management module.


The View Packet 4 uses the is-part-of type of relations. The Query Manager could not function without one of the submodules above.




Figure 9 : Context diagram for the Query Manager module



4.1.2.5 View packet #5: Recovery Management


Table 15 : Primary Presentation for View Packet 5

System Segment

Recovery Management Log Manager

Recovery Manager

Figure 10 : Decomposition view of View Packet #2: Transaction Processor





Table 16: Visibility of the Recovery Management submodules

Visibility Log Manager can be seen by the Transaction Management module (specifically for the Transaction Manager submodule) and the Query Manager module (specifically for the Execution Engine submodule).

Recovery Manager can be seen by the Query Processor module (specifically for the Execution Engine submodule).

Table 17 : Elements of the Recovery Management submodules


Log Manager This submodule logs every SQL command that is executed. It is a part of the recovery mechanism for the database and helps find what broke the database.

Recovery Manager This submodule restores the database to the last stable backup by using statements provided by the log.


The View Packet 5 uses the is-part-of type of relations. The Recovery Management module could not function without one of the submodules above.




Figure 11 : Context diagram for the Query Manager module



4.2 Component and Connector View


Table 18: View packets for C&C



4.2.2 View Packets

4.2.2.1 View packet # 1 Server Component

The server component in architecture of MySQL is responsible for all communications within the database system.

4.2.2.2 Primary Presentation



Figure 12: Primary Presentation of MySQL Server

4.2.2.3 Element Catalog

4.2.2.3.1 Elements

Table 19: Elements for MySQL Server

Name Type Description

Connection Process The connection will perform the following:-Authentication;-Thread handling;-Check memory;-Connection limits;

Interface Process handler This interface process handle all requests for retrieving, storing, manipulating, deleting, modifying, updating data in the database. It is also responsible for modifying data structures and views.

Parser Process Receives the command and breaks it down, checks to see if syntax in correct, attributes referenced exist and are correct and therefore passing it on to the optimizer.

Query cache Process The query cache stores text and the results from selected statements, which were sent to the client. If at a later stage an identical statement is received, the server obtains the result from the query cache. When tables are modified, queries in the query cache are cleared (http://dev.mysql.com/doc/refman/5.7/en/ ).

Optimizer Process The optimizer in MySQL uses indexes to process queries



faster (http://dev.mysql.com/doc/refman/5.7/en/ ).

Storage Data storage There are various storage engines for MySQL, some of them:

-MyISAM;

-InnoDB;

-IBMDB21.

4.2.2.3.2 Relations

First connection component checks an authentication. After, it threads handling and quality of its thread, also, check the availability of system and existing of limit connections. After this checking the interface takes all inputs in quire, such as modifying data, deleting data, adding data and any data manipulations. Once data is received by interface, it passed to the parser of quire cache. After that it sent to optimizer. Inally the optimizer after checking the most efficient executes the query and this query is moved to storage (http://dev.mysql.com/doc/refman/5.7/en/tutorial.html).

4.2.2.3.3 Context diagram



Figure 13: Context diagram of the MySQL Server

4.2.3.1 View packet 2: Client component

This component is responsible for sending all the requests to the server component, where this request is executed and result is sent back to the client.



4.2.3.1.1 Primary presentation

Figure 14: Primary Presentation of the MySQL Server





Table 20: Elements for MySQL Server

Name Type Description

Local Client Client This client resides on the local system, which is server

Remote Client Client This client is connected to MySQL server

Application Interface Application provides connection between user and the system

Scripting language Interpreter This is programming language, which executes a task by the user.

Connector Event Connector makes possible to change the application in terms of language its written and connect MySQL to database server




The client might be either local or remote. The difference is that, the local client resides on the server, while remote one in the remote system. After, the application (which might vary, for example, it might be web browser) provides with interconnection between user and the system. The scripting language from the user executes the task. Also, scripting language allows programmer to change the language, which is supported by MySQL. After that, connector connects MySQL server with data (it might be ODBC-Open Database Connectivity or JDBC-Java Database Connectivity Technology) (http://dev.mysql.com/doc/refman/5.7/en/tutorial.html).



4.2.3.1.3 Context diagram



Figure 15: Primary Presentation of the MySQL Server



4.3 Allocation View


An allocation view type relates a software unit to a non-software unit and describes how the software elements assigned within the hardware environment. There are 3 types of the allocation view: an implementation view can show how the modules are packaged and connected in the library; a work assignment view shows how the modules are assigned to the staff who are responsible for their development; and deployment view relates a module to some hardware component on which it runs, such as a hardware processor or a communication device.

This view has been divided into the following view packets for convenience of presentation:

Table 21: Allocation View Packets



4.3.2 View Packets

4.3.2.1 View packet - Deployment View


Figure 16: Decomposition view MySQL Deployement View





Table 22: Elements of the MySQL Hardware (Environment)

Table 23: Elements of the MySQL Software




This diagram was placed in order to show the allocation of the MySQL application’s software and environment elements. There are no exceptions or limitations that need to be applied in this diagram.




4.3.2.2 View packet - Deployment Requirements


Table 24: MySQL Deployment Requirement for the system



Hardware elements of the computer:

Processor



A processor is the logic circuitry that responds to the basic instructions and processes those instructions in order to drive a computer.

Random Access Memory (RAM)

A type of computer memory that is used to store numbers of computers’ operation instructions. RAM is the most common type of memory found in computers. They use memory (RAM) to store actively running programs on the computer, including the operating system.

Operating system (OS)

Is the program that, after being initially loaded into the computer by a boot program, manages all the other programs and processes in the computer.

Hard disk space

Disk space refers to how much space you have available on your hard disk for storing files. When you save a document or install a new program, it gets stored on your hard disk. The more files you download, install or save on your hard disk, the less space you have got for further usage.Software elements of the computer:

Microsoft .NET 4.0 Framework

The .NET Framework is an application development platform that provides services for building, deploying and running different kinds of applications and web services. It includes common language runtime (CLR), which provides memory management and other system services. Moreover it has an extensive class library, which includes codes for main development applications.

Microsoft Visual C++ 2013 Redistributable Package (MSVC2013)

When companies write software using Microsoft Visual C++, they make use of standard libraries. Those are collections of pre-written software provided by Visual C++ for programmers to use. They install run-time components that are required libraries, such as: C Runtime (CRT), Standard C++, ATL, MFC, C++ AMP, and OpenMP.



4.3.2.2.2.2 RelationsThis diagram shows the minimum requirements for the system that is compulsory for MySQL installation and operation on the user (client) computer, with an example of the additional software pre requires for Microsoft Windows (7 and above) OS. The recommended requirements are optional and can provide more stable, better and faster work experience with MySQL.


4.3.2.3 View packet - Implementation View (Connector/ODBC 5.3.6)


Figure 17: Decomposition view of Implementation View MySQL





Connector/ODBC 5.3.6 is the software element of the MySQL driver that provide access to a MySQL database.

Other elements are files which represents the environment for the MySQL Connector/ODBC proper operation.


The diagram shows the packet’s data needed to support the MySQL Connector/ODBC functionality, including stored procedures and transactions between it an MySQL Server.


4.3.2.4 View packet - Implementation View (Connector/C++ 1.1.7)




Figure 18: Decomposition view of Implementation View MySQL (vol.2)



Connector/C++ is a MySQL database connector for C++. It lets you develop C++ applications that connect to the MySQL Server.


The diagram was shown the distribution of the binary and source formats data needed for the proper work of the Connector/C++ module.




4.3.2.5 View packet - Implementation View (MySQL Workbench 6.3.6)




4.3.2.5.2.1 ElementsMySQL Workbench is a graphical tool for working with MySQL Servers and databases. MySQL Workbench functionality enables: to create and manage connections to database servers; to create models of your database schema graphically; to administer MySQL server instances by administering users; and to migrate from Microsoft SQL Server, objects and data to MySQL.



4.3.2.5.2.2 RelationsEnvironment elements (folders with files) displayed to show the mapping of the MySQL Workbench 6.3.6.


4.3.2.6 View packet - Implementation View (My SQL Connector/C 6.1.6)






4.3.2.6.2.1 ElementsConnector/C is a client library that implements the C API for client/server communication.

4.3.2.6.2.2 RelationsShows the allocation of the drivers and files inside the MySQL Connector/C 6.1.6 folder.


4.3.2.7 View packet - Implementation View (MySQL Server 5.7)






4.3.2.7.2.1 ElementsMySQL Server is intended for mission-critical, heavy-load production systems as well as for embedding into mass-deployed software. It is based on the web interface usage and allow to create, edit and manage databases and tables in MySQL application.

4.3.2.7.2.2 RelationsThe diagram shows the tree-type structure of main hardware elements within the MySQL Server folder.4.3.2.7.3 Context Information



5 Relations Among Views

5.1 General Relations Among Views

The Module View, CnC View and Allocation View were acknowledged in previous sections. The reason for this is that 3 view are important in the implementation of the vision of MySQL. The first one is Module view shows how the key elements of the software are mapped to modules and subsystems, which identifying the major elements of the MySQL. They are used as participants in the next view - Component and Connector (CnC) and indicate the main processes in MySQL. The final Allocation view uses framework from both previous view as an input to implement and deploy the requests’ production.

Figure 22: Relations between Views

As it shown in the diagram, connections between 3 views can look simple. However, they can be complex (with multiple connections within modules) it in total represents the whole MySQL system and every relations are dependant. In order to reduce the issues with the vision of the system, every element of the views mentioned before, need to be examined carefully. Otherwise, even a small change can affect the rest 2 views dramatically. Analysis of those 3 views can give a clear idea and understanding of the decision making process and effort estimation while working with MySQL databases.



5.2 View-to-View Relations

Various simple allocations between Module View’s elements, CnC View’s processes and Allocation View’s procedures are shown in the next tables. This can give an easy schemes of the connectors’ relations in MySQL.

5.2.1 Module-to-CnC View Relations

Table 25: Relations between Views elements



5.2.2 CnC-to-Allocation View Relations

Table 26: Relations between Views elements (vol.2)



5.2.3 Module-to-Allocation View Relations

Table 27: Relations between Views elements (vol.3)



5.3 Stakeholders Interests to Views

Figure 23: Stakeholders interests in Views

Table 28: Stakeholders detailed interests in Views



6 References

Clements, Paul, et al. "Documenting software architectures: views and beyond." ICSE. Vol. 3. 2003.

Converse, Tim, Joyce Park, and Clark Morgan. PHP5 and MySQL bible. Vol. 147. John Wiley & Sons, 2004.

Larry Wen, 2016, 7412ICT Software Architecture lectures notes.

Mack, J. (n.d.). Five Advantages & Disadvantages Of MySQL. https://www.datarealm.com/blog/five-advantages-disadvantages-of-mysql/

MySQL Introduction. (n.d.). Retrieved May 09, 2016, from http://www.tutorialspoint.com/mysql/mysql-introduction.htm

"MySQL 5.7 Release Notes". Oracle. Retrieved 13 March 2014.http://dev.mysql.com/doc/relnotes/mysql/5.7/en/

“MySQL 5.7 Reference Manual”. Oracle. Retrieved 05 June 2016.http://dev.mysql.com/doc/refman/5.7/en/

"Oracle Completes Acquisition of Sun" (Press release). Oracle. 27 January 2010. Retrieved 1 February 2012.http://www.oracle.com/us/corporate/press/044428

Schwartz, Baron, Peter Zaitsev, and Vadim Tkachenko. High performance MySQL: Optimization, backups, and replication. " O'Reilly Media, Inc.", 2012.

Taylor, Richard N., Nenad Medvidovic, and Eric M. Dashofy. Software architecture: foundations, theory, and practice. Wiley Publishing, 2009

Valade, Janet. PHP and MySQL for Dummies. John Wiley & Sons, 2007.

Ven, Kris, Jan Verelst, and Herwig Mannaert. "Should you adopt open source software?." Software, IEEE 25.3 (2008): 54-59.

Williams, Hugh E., and David Lane. Web database applications with PHP and MySQL. " O'Reilly Media, Inc.", 2004.



What is the overall structure of a database?. (2011). Punarvasi.com. Retrieved 8 May 2016, from http://punarvasi.com/what-is-the-overall-structure-of-a-database/



7 Project Management Report

7.1 Project working Load

Task Plan Actual# Task Name Student Planned

TimeCumulativeTime

Finished Date

Time Cumulative Time

Finished Date

1 Searching Project

Jed 3 Hours 3 Hours 24/04/16 2.5 2.5 1/05/16

Jane 3 Hours 3 Hours 24/04/16 3 3 1/05/16Julie 3 Hours 3 Hours 24/04/16 3.5 3.5 1/05/16Sy 3 Hours 3 Hours 24/04/16 3.5 3.5 1/05/16Slobodan 3 Hours 3 Hours 24/04/16 3 3Task Total

15 Hours 15 Hours 15.5 15.5

2 Meeting Jed 3 Hours 6 Hours 28/04/16 9.5 12 9/05/16Jane 3 Hours 6 Hours 28/04/16 6.5 11.5 9/05/16Julie 3 Hours 6 Hours 28/04/16 6.5 10 9/05/16Sy 3 Hours 6 Hours 28/04/16 10 13.5 9/05/16Slobodan 3 Hours 6 Hours 28/04/16 6 9Task Total

15 Hours 30 Hours 39.5 55

3 Introduction Sy 10 Hours 16 Hours 30/04/16 20 31.5 9/05/16Task Total

10 Hours 40 Hours 20 75

4 Executive Summary

Slobodan 3 Hours 9 Hours 1/05/16 3 9 9/05/16

Task Total


5 Architecture Background

Slobodan 4 Hours 13 Hours 1/05/16 3 12 9/05/16

Task Total


6 Module View Jed 8 Hours 14 Hours 1/05/16 7.5 17.5 8/05/16Task Total

8 Hours 55 Hours 7.5 88.5

7 CnC View Jane 5 Hours 11 Hours 1/05/16 5 12.5 9/05/16



Task Total

5 Hours 60 Hours 5 93.5

8 Allocation View

Julie 8 Hours 14 Hours 1/05/16 13 21 9/05/16

Task Total


9 Relations Among Views

Julie 12 Hours 16 Hours 2/05/16 6 27 9/05/16

Task Total


10 Merging Work

Jed 1 Hour 15 Hours 2/05/16 2 18.5 9/05/16

Task Total

1 Hour 81 Hours 2 114.5

11 Project Management

Jed 2 Hours 17 Hours 2/05/16 2 20.5 9/05/16

Task Total


7.2 Project Working Load Summary

Plan (hours) Actual (hours)Total time 83 116.5Average time per person

16.6 23.3

Jed 17 20.5Julie 16 27Jane 11 14.5Sy 16 31Slobodan 13 12.5

7.3 Individual effort and contribution summary

Student Effort Level*(Rating from

Contribution Level*(Rating from 0 – 5, the

JustificationIf a student received level rating of 3 or less,



0 – 5, the information is filled by the

group)

information is filled by the group)

your group need to give explanation for the low level rating

Jed 5 5Julie 5 5Jane 5 5Sy 5 5Slobodan 4 4

● *Level ratings, 5 = excellent, 4 = good, 3 = reasonable, 2 = poor, 1 = unacceptable, 0 = none


executive summar€¦ · web view2016. 10. 28. · mysql has many reasons to why it is the...

Documents