Tutorial 2 Walk-through to Web Application Design
The essence of system design is to structure content and system so people can find the required information quickly and easily, the process should aim at optimizing the system flow to help users achieve their goals while using the system.
System Design Overview
System design is a need-based design process to discover, describe, and address user requirements. Figure 97 shows the main system design process:
Figure 97: System Planning and Design Overview
70 planning, designing, and programming for web application
Requirement Specification – User Needs Analysis
A user needs analysis is part of the ongoing process of developing a website that will effectively meet the needs of users. This process also helps to determine the technological requirements necessary to justify these needs.
There are 2 steps to conducting the requirement specification – determine the objectives and users of the system, and match the user requirements with system requirement descriptions.
System Specification – Data & Functional Requirement
From the system requirement description, one should be able to work out the system’s data requirement and the functional require- ments.
Figure 98: Details of Requirements Specification
The data requirement is discovered via examining the “objects” in the system requirement description. These “objects” are the required data of the system, one should work from here to derive the database design for the system, so that the system would store the right infor- mation required by the user.
Figure 99: Details of System Specifica- tion
The functional requirement is developed from the system requirement description by discovering pairing of “objects” and “methods” in
the description. Each pair of “object” and “method” would form a use case of the system, which correspond to 1 functionality of the system. The use case can then be worked further to detail the work flow of completing the functionality from the perspective of the user (a narrative description), the perspective of the system (an activity diagram), and the interaction among different components within the system (a sequence diagram).
Information Architecture – User Interface Wireframing
Information architecture (IA) involves structuring and or- ganizing information on websites to enable your users to find the information they want. Having met the data requirement and the functional requirement of the system, one should have a good idea of what information should or should not exist on which page. A user interface wireframe can be developed through matching the data with the functionality of the system.
In the wireframe, structure the information on each page so that it meets the data requirement for the specific functionality, and link up each page to reflect the way a potential user is expecting the pages to flow from one to the other.
Figure 100: Details of Information Architecture
tutorial 2 walk-through to web application design 71
The remaining tutorials will be in the form of a case study on a simple TODO list system, from system planning and design all the way to the coding and deployment of the system. We start with design the TODO list system using the system design process introduced at the beginning of this tutorial, and walk you through all the steps of this process.
72 planning, designing, and programming for web application
Requirement Specification
Requirement specification is crucial in system design; because this step helps you understand how the system will function so as to fulfill the needs of different kinds of users. In a formal Information System development context, requirement specification would take up a very long time interviewing people or set up focus group, however, the focus of this tutorial is not on discovering user requirements but rather on how to translate user requirements into our system.
The “What’s” and the “Who’s”
To start with, you have to determine “What’s” and “Who’s” of your system:
What: What is the objective of the system? Who: Who will use the system?
For the TODO list system, it is easy to determine those 2: What’s and Who’s of TODO List System
What: Web-based system allowing users to create and man- age todo lists, and all the associated tasks under each todo list
Who: a Users who want to use the system to manage their todo list and tasks
b System admin who manages the system
In reality, a system may have way more types of users than the 2 we listed here. For demonstration purpose, we will keep this system simple and keep the scope of the system small.
Requirement Description
After you’ve determined the “What’s” and “Who’s” aspects
of the system, you can go on describing what each type of user in the system should or should not do. The description can be in the form of a few sentences, or in the form of a paragraph; writing this description is to help you find out the “objects” and “methods” that’s required by the system:
tutorial 2 walk-through to web application design 73
TODO List System Requirements – Object Method
1. The user can register an user account, and use the system’s
functionalities after login.
2. The user can use the system to create TODO list.
3. The user can list all TODO lists created by the user, and manage the TODO lists such as edit and delete the specific TODO list.
4. The user can view details of a specific TODO list.
5. The user can add task to a specific TODO list.
6. The user can list all tasks created by the user, and manage the tasks such as edit, delete, and complete the specific task.
7. The admin can list all user accounts in the system.
After written down the system description, you need to identify the “objects” and “methods” in each sentence of the descrip- tion and use them to form the backbone of your system. For instance, you will know what needed to be included in your database by find- ing out the objects in the description; and know what functions to include in the system by combining the “methods” and “objects” highlighted in each sentence.
∗note that there are seemingly infinite number of requirements you can come up with for a system, you should focus on the core problems first then slowly expand your scope if time permits
74 planning, designing, and programming for web application
System Specification – Data Requirement
The data requirement is satisfied through the process of database design. There are specific steps in find- ing out contents and designing the system’s database, including: find out entities, establish relationships, assigning keys, assigning attributes, and normalization. While the latter steps may not be required to carry out in a particular order, you must first discover the entities in the system. Note that the database design we do here will be translated into the model definitions in Laravel’s MVC structure, so we are following the conventions of Laravel’s model definition in this design process.
Identify Entities
The types of information that are saved in the database are called “entities”. These entities exist in four kinds: people, things, events, and locations. Everything you could want to put in a database as an entity fits into one of these categories. If the information you want to include doesn’t fit into these categories, then it is probably not an entity but a property of an entity – an attribute; or a collection of entity items.
From the requirement description, it is obvious there are 3 entities in the system – “Todolist”, “Task”, and “User”. Going back to the categories of the entities, we can see the “Todolist” and “Task” belong to “things” and “User” belong to people. Following Laravel’s model definition convention, the entity’s name should be one word of singular form. Graphically, the 3 entities we’ve just identified can be represented using ERD diagram notation as shown in figure 101.
Identifying Relationships
The next step is to determine the relationships between the entities and to determine the cardinality of each relationship. The relation- ship is the connection between the entities, just like in the real world: what does one entity do with the other, how do they relate to each other? The cardinality shows how much of one side of the relation- ship belongs to how much of the other side of the relationship. First,
Figure 101: Entities of TODO List System Database
you need to state for each relationship, how much of one side belongs to exactly 1 of the other side.
Discovering Relationships
• Todolist → Task: 1 Todolist has many Tasks
• Task → Todolist: 1 Task only belongs to 1 Todolist • User → Todolist: 1 user has many Todolists
• Todolist → User: 1 Todolist only belongs to 1 User • User → Task: 1 User has many Tasks
• Task → User: 1 Task only belongs to 1 User
Concluding the relationships between the 3 entities: • Todolist ⇔ Task: 1–to–many
• User ⇔ Todoliist: 1–to–many • User ⇔ Task: 1–to–many
Graphically, we can represent the relationship like in figure 102:
tutorial 2 walk-through to web application design 75
Figure 102: Relationships between Entities
76 planning, designing, and programming for web application
Refer to figure 102, the relationship is captured using the ERD notation, as explained in figure 103. Since a user may or may not create a Todolist at all, and a Todolist may or may not have any Task, the relationships between the 3 entities should all be optional.
Next, we need to remove redundant relationships. It is obvious the relationship between the “User” and the “Task” entity
is redundant. Since the Task belongs to 1 and only 1 Todolist, and the Todolist belongs to 1 and only 1 User, it naturally establishes a one–to–many relationship between Task and User. We can say the “Task” belongs to the “User” through the “Todolist” entity. As a result, the User ⇔ Task can be removed from the database design.
Refer to figure 104, the database is much simpler after the redun- dant relationship is removed. Now, the database features a straight- forward relationship: a “Todolist” table exists linking the “User” and “Task” table.
Identifying Attributes
The data elements that you want to save for each entity are called “attributes”. For example, a Todolist should at least have a name, a description, a category, and user.
Figure 105isasampledatabasewitharbitraryattributesforeach
Figure 104: Relationships after Remov- ing Redundancy
Figure 103: Explaining the ERD nota- tion
entity. At this stage, what will be included precisely is not of impor- tance yet; it is still only about what data you want to use in your system.
Assigning Keys
You need to assign the primary key (PK) and foreign key (FK) to the database entities:
Primary Keys
• A primary key (PK) is one or more data attributes that uniquely identify an entity. All attributes that are part of a primary key must have a value in every record and its value should be unique in the entity.
• Following Laravel’s model definition convention, we will use “id” as the primary keys for each of the entities in our TODO list system.
Foreign Keys
• The Foreign Key (FK) in an entity is the reference to the primary key of another entity. In the Entity Relationship Diagram that attribute will be indicated with “FK” in front of its name. Since the foreign key is simply reference to primary key of another entity, you should have 1 foreign key for each relationship you have with other entities. In our simple library database, the “Todolist” entity should have a foreign key “user_id”, whereas the “Task” entity should have a foreign key “todolist_id”.
Figure 106 shows an improved database with key assignments:
tutorial 2 walk-through to web application design 77
Figure 105: Preliminary Attributes
78 planning, designing, and programming for web application
Defining the Attribute’s Column Type
Next, we need to define the type of data to be stored under each attributes. The table below shows a list of common Laravel column types:
Table 1: Common Laravel Column Types
Laravel Column Types
increments boolean string
text
date time datetime integer float
Data Type Equivalent
integer boolean varchar text
date time datetime integer float
Type
Figure 106: Database with Primary Keys and Foreign Keys
Description
Figure 107 shows the database with column types defined for each attributes:
Exact numeric, primary key of auto-incrementing integer Exact numeric, 0 (false) & 1 (true)
Character string
Character string (larger maximum text data)
Date (0000-01-01 to 9999-12-31)
Time (00:00:00.0000000 to 23:59:59.9999999) Date and time
Exact numeric
Approximate numeric (number with decimal)
The “increments” type is only used on primary key columns as it will automatically set the column as primary key of a table. Also
Figure 107: Database with Column Type
notice the “user_image” column has a “N” at the end, symbolising the “user_image” column is allowed to be left empty (nullable).
Normalisation
Normalisation makes your data model flexible and reli- able. It does generate some overhead because you usually get more tables, but it enables you to do many things with your data model without having to adjust it.
To achieve normalisation, our database should confine with the following 2 properties:
Normalisation Conditions
1. No repeating elements or groups of elements
2. All non–primary key attributes fully functionally dependent
on the whole primary key
As there’s no repeating elements in the database, we only need to take care of the second requirement – all non–primary key attributes fully functionally dependent on the whole primary key.
The problem here is the “category” attribute. Although the “Todolist” need to have a category, the name of the category should not be fully dependent on the identity of the “Todolist” table. In this sense, the category should be an independent table in the database, and then the “Category” can be referenced in the “Todolist” through a one–to– many relationship. Figure 108 shows the final design of the TODO list system’s database.
tutorial 2 walk-through to web application design 79
Figure 108: Normalised Final Database Design
80 planning, designing, and programming for web application
System Specification – Functional Requirement
In this section, we discover functional requirements from the requirement description into a set of sys- tem functionalities (use cases), then fill in the details of each use case with the help of UML diagramming.
System Use Case Analysis
The purpose of use case diagram is to capture the dynamic aspect of a system. Use case diagrams are considered for high level requirement analysis of a system. So when the requirements of a system are analysed the functionalities are captured in use cases. We can say that uses cases are nothing but the system functionalities written in an organized manner. Now the second things which are relevant to the use cases are the actors. Actors can be defined as something that interacts with the system. So in a brief when we are planning to draw an use case diagram we should have the following items identified.
Essential Elements of Use Case Diagram
1. Functionalities to be represented as an use case 2. Actors
3. Relationships among the use cases and actors.
Use case diagrams are drawn to capture the functional require- ments of a system. So after identifying the above items we have to follow the following guidelines to draw an efficient use case diagram.
Guidelines in Drawing Use Case Diagram
1. The name of a use case is very important. So the name should be chosen in such a way so that it can identify the functionalities performed.
2. Give a suitable name for actors.
3. Show relationships and dependencies clearly in the dia- gram.
You can derive system functionalities from the system requirements description you have written down at the requirement specification stage. A functionality is usually derived from combining the Object and Method you’ve highlighted in the system requirements description. For example, by combining the method “create” and
the object “TODO list” you get the create TODO list functionality. Of course not all object–method combinations can be put together to form system functionalities, you need to put in a little bit of thinking and common sense when you are developing the functionalities.
After you derived all the major functionalities of the system, you can start pairing the actors (certain type of user) with the functionalities just as shown in table 2.
tutorial 2 walk-through to web application design 81
Table 2: Mapping System Functionalities with Users Users
Functionality
Registration Login
Log Out
Guest
√
Registered User
Administrator
√√ √√
Create List
View All List View List Details Edit List
Delete List
Add Task to List View All Tasks Edit Task
Delete Task Complete Task
List All Users
TODO List Functionalities
√√ √√ √√ √√ √√
Task Functionalities
√√ √√ √√ √√ √√
System Administration
√
82 planning, designing, and programming for web application
The next step is to translate the system functionalities identified in table 2 into the system use case diagram depicting the relationship between actors (system users) and use cases (functionalities). Figure 109 is the use case model of the TODO List system:
As seemingly complicated as it seems, figure 109 is only a representation of the system requirement description with added relationships between actors (users) and use cases, or among different
Figure 109: Use Case Model of TODO List System
use cases. To briefly explain the essential components of a use case diagram using figure 109, the use case diagram can be understood in this way:
Essential Components of Use Case Diagram
• System Boundary: The oval shape represents the system boundary of TODO List system. Users of the system are drawn outside of the system boundary, so they are not part of the system but merely external parties that interact with the system.
• Actor – Actor Relationship: Actors sometimes are related to each other. In the case of the TODO List system, the administrator actor can be generalized as a registered user. In this way, the administrator actor will be able to access all use cases belonging to the registered user, as well as other uses cases only accessible by the administrator. Note that the generalization is 1 directional, i.e. the registered user will not be able to access any of the administrator use cases.
• Actor – Use Case Relationship: The relationship between actor and use case are represented by drawing a solid line connecting the actor with the use case. For example, the “Login” use case is only accessible by registered user but not the unregistered user, so a solid line is draw between the registered user and the login use case to represent a relationship between them.
• Relationships between Use Cases: One use case could “include” or “extend” the functionality of another as part
of its normal processing. Generally, if a use case “include” other use cases, the “include” use cases must all be com- pleted before the base use case be executed. There’s no example of “include” use case in the TODO List system, but one real-life example can be the “Check out” use case in supermarket, where “Product Scan” and “Payment” use cases must all be done before “check out” is completed. On the other hand, the “extend” use cases represent optional use cases which may be executed by the users. For instance, the “View All List” use cases extends 4 optional use cases, which are actions the user might do when he/she views the todolists.
tutorial 2 walk-through to web application design 83
84 planning, designing, and programming for web application
Narrative Specification for Use Case
A use case narrative must be produced for each of the use cases you have identified for your system, the narrative would explain the interaction between an actor (or category of users) and the system to achieve a goal of observable value. A good use case narration helps to visualize the system in action, and is a meeting place of what the client (external user) wants to get and what the system developer think to build.
The structure of a use case narrative specification typically contain the following parts: brief description, actors involved, preconditions necessary for the use case to start, detailed description of main flow and alternative flow of events, and postcondition that define the state of the system after the use case ends. We will use the “registration” use case in table 3 to demonstrate how the use case narrative specification is done.
Table 3: Narrative Specification for use case “Registration”
Use Case
Brief description
Actors Preconditions Main flow
Registration
This use case allows a guest to register a user account to use the system’s user- only features
Guest
The guest user is currently at front page or login page of the System
1. The use case begins with the user decides to create an account by selecting the “registration” link displayed on the web page
2. The system loads the registration form on screen, and the user is required to filling the user information including: username, email address, password, user image (optional)
3. The user chooses the “register” function to submit the registration information
4. The system creates the user account using the submitted information
5. The system redirects the user to the “home” page
• The user chooses a username or email already existed in the system, the system displays an error message and requests the user to choose another username or email
If the use case was successful, the user account is recorded in the system’s database. Otherwise, the system’s state is unchanged
Alternative flows
Postconditions
Activity Diagram
In UML, an activity diagram is used to display the sequence of ac- tivities. Activity diagrams show the workflow from a start point to the finish point detailing the many decision paths that exist in the progression of events contained in the activity. They may be used to detail situations where parallel processing may occur in the execution of some activi- ties. Activity diagrams are useful for business modeling where they are used for detailing the processes involved in business activities.
For each of the use cases in your use case diagram, you can cre- ate an activity diagram based on the use case narrative specification you’ve created in the last step. For example, figure 110 describes the flow of activities from the moment the user click the “Register” link till the registration completes and being redirected to the login page,
Figure 110: Activity Diagram for Registration Use Case
tutorial 2 walk-through to web application design 85
86 planning, designing, and programming for web application
it is basically a logical translation of the main flow and alternative flow of events described in table 3. Bear in mind that an activity di- agram is drawn from the perspective of the internal system instead of the perspective of the user, so you should consider the activity state of the system when you draw the diagrams.
Figure 111 is another example of activity diagram for the TODO List system. In the login use case, the system has to authenticate the login information provided by the user, the login can only be proceeded if the user has provided correct login information.
Although only a couple activity diagrams are demonstrated here, it is expected to draw up activity diagrams for each one of the use case in the system, so that you would have a better idea of how each functionality builds up step–by–step, and what the user and the system is expected to do in order to complete a certain functionality of the system.
Figure 111: Activity Diagram for Login Use Case
Sequence Diagram
Sequence diagrams are used to display the interaction between users, screens, objects and entities within the system. It provides a sequential map of message passing between objects over time. Fre- quently these diagrams are placed under Use Cases in the model
to illustrate the use case scenario – how a user will interact with the system and what happens internally to get the work done. Sequence diagrams are good at showing which objects communicate with which other objects; and what messages trigger those communica- tions. Sequence diagrams are not intended for showing complex procedural logic. As examples, we demonstrate to you how a typical CRUD (create, retrieve, update, delete) operation can be represented using sequence diagram.
tutorial 2 walk-through to web application design 87
Figure 112 shows an example of a create operation that creates a todolist record using the “store” method. The interaction between the user, the view, the controller, and the todolist entity are carried out in sequential order, the entire sequence can be understood in this way:
Figure 112: Sequence Diagram for Create List Use Case
88
planning, designing, and programming for web application
Create List Use Case Sequence
1. User fill in list content in the web form displayed on the screen, and submits the web form
2. the user input is passed on through the “store()” method in the lists controller
3. The store method calls the “create_list()” method from the “Todolist” model to create new todolist record using the submitted information
4. After the record is created, the Todolist model returns a success feedback to the lists controller
5. The list controller then redirects to the “show(list)” method and the create list use case is completed
The “View List Details” use case as shown in figure 113 basically follows the same logic and sequence as the retrieve use case.
Figure 113: Sequence Diagram for View List Details Use Case
The “Edit List” use case involves two sets of interactions. The first set of sequence retrieves the specific todolist record from the database and put it on the edit view so that the user can make changes to
the information, then the updated information is send back to the Todolist model to update the database.
tutorial 2 walk-through to web application design 89
Figure 114: Sequence Diagram for Edit List Use Case
90 planning, designing, and programming for web application
The “Delete List” use case basically follows the same sequence as the “Create List” use case.
Figure 115: Sequence Diagram for Delete List Use Case
Information Architecture – User Interface Wireframing
You can create wireframes for each of the page in your system, and the wireframes should include enough information to reflect what needs to appear on each page for your system to function properly. Take the “Create List” view of the system as an example (figure 116), the user needs to input the list content and submit it to create the list, in that way the view should at least feature a number of input boxes and a submit button. What also should be included in the wireframe are some additional information that would guide your user to better use the system such as navigation, graphics, and so on.
Once you have an idea of what each of your page will include, start creating your wireframes based on those elements. Keep in mind that a wireframe should be brief and functional, it only need to include the functional elements that is necessary for the planned functionality; any additional information are too much for your wireframe. Please refer to the appendix regarding drawing the UI wireframe.
Figure 116: Sample Wireframe for Create List View
tutorial 2 walk-through to web application design 91
92 planning, designing, and programming for web application
Appendix – Guide to System Design Documentation
This document is developed based on the Lucidchart online diagramming tool, in which you will be provided with an account to finish your assignment, but you are not limited to use only the tool if you find a better alternative.
Log in to Your Account and Create Your First Diagram
We have already registered a user account for you to use the Lucid- chart online diagramming tool, so you can use the tool right away to create your diagrams for your assignment 2. Refer to figure 117, go to the Lucidchart homepage at http://www.lucidchart.com and select “LOG IN” at the top right corner.
On the log in page, input the username and password then hit “sign in”. Your username and password are the same as the FTP account you have received earlier.
The document page is shown after login/sign up, select “Create → New Document” to add a new diagram (see figure 119):
Figure 117: Click “Log in” at Lucidchart Homepage
tutorial 2 walk-through to web application design 93
Figure 118: Sign in using Your FTP Account Username and Password
Get Familiar with the Editor
You will be prompted to select an appropriate template after choose “Create → New Document”. Right now, you have not decided which type of diagram to draw, simply select “Start Drawing” (see figure 120) will bring up the editor with no specific shapes and other con- tents.
The editor is where the magic happens. This short tutorial explains the basic components of what you see when you open a document (see figure 121) – the canvas, menu bar, properties bar, toolbox, dock, and page controls.
1. Canvas: The canvas is the heart of the editor. Drag and drop shapes on the canvas to get started.
• Resize the canvas to accommodate large and small diagrams
Figure 120: Just Select “Start Drawing”
Figure 119: Select Create New Docu- ment to Start Up
94 planning, designing, and programming for web application
• Change the orientation and layout of each page • Hide or resize the grid
2. Menu Bar: Located at the top of the editor under the document title, the menu bar provides access to common actions.
• Organized list of options for working inside the editor
• Displays hotkey for actions within each drop down menu
3. Properties Bar: Located at the top of the editor under the page tabs, the property bar allows you to quickly change the properties of:
• Text (size, color, font, styling)
• Lines (thickness, color, line type, arrow type)
• Shapes (shape color, border color, border thickness)
4. Toolbox: The toolbox on the left contains all the shapes you need to create your diagrams.
• Load different categories of shapes with the “More Shapes” button
• Upload your own images to include in your diagrams
Figure 121: Layout of the Document Editor
• The Standard shape library stays pinned to the toolbox with a transparent text box, text block, note, and hotspot.
5. Dock: On the right of the editor, there is a dock with several essential features. Click once to open a dock panel, and once more to close it. You can drag the panels away from the dock around to set up your workspace how you like it.
• Navigation – Get around your document easily with the thumb- nail view
• Graphic – Style and color of objects and lines, fill shape with gradient or image
• Metric – View current position and size of an object with the option for custom entry
• Text – Modify indentation and spacing within lines of text
• Page settings – View and change size, margins and orientation of page. Change snap to grid preferences and the size of objects in relation to the page. Auto paginate adds a page when objects move off the existing page.
• Master pages – Create master page to duplicate design across multiple pages
• Shape options – Access specific options for ERD, UI mockup, and other shapes
• Document history – See the history of your document and revert to a previous version
• Demo controls – Create states for interaction in UI mockups
6. Page Controls: Along the top right of the application, you will find page controls where you can easily manage your pages.
• Add using the “+” button and delete by clicking the “X” on each page tab
• Scroll through pages using arrows or select specific page with drop down arrow
tutorial 2 walk-through to web application design 95
96 planning, designing, and programming for web application
Entity–Relationship Diagram (ERD)
You need to first add the “ERD” shapes to your library before making the drawings. Clicking on “More Shapes” at the bottom left corner of the editor to bring up the “Manage Library” dialogue, and select “Entity Relationship” then press “Save” (see figure 122). This will add the ERD shapes to your toolbox.
Drag and drop the 3-column entity object onto the canvas.
Figure 122: Add Entity Relationship Shapes
Figure 123: Drag and Drop the 3– column Entity Object
After letting go of the object the text field is immediately highlighted. Easily move from each text box by pressing tab on your keyboard and shift+tab to go back. Press enter or click off the object when finished and double click on the text to enter back into text edit mode. To change the size of the object, simply click and drag from one of the corners and extend to either side. The columns will auto–adjust when moving to help fit the content inside.
Click on the entity object and hover–over to the floating panel to quickly add or remove fields in the entity.
To establish a relationship between 2 entities, move the cursor on one entity until it change into “+”; then click on the entity and drag it to the other entity until the line intersects the entity with a red dot.
Select the line and, on the properties bar, change the arrow style into the appropriate ERD notation.
Figure 124: Access the Floating Panel
tutorial 2 walk-through to web application design 97
Figure 125: Establish Relationship Between Entities
Figure 126: Change to ERD Notation
98 planning, designing, and programming for web application
You can also select “Manage Fields” from the floating panel to add / remove / re–prioritize fields easily:
Figure 127: Manage Fields
System Use Case Diagram
The system use case diagram utilizes the UML shape library which currently does not exist in the toolbox yet. Again, you need to open the “Manage Library” dialogue to enable the shapes.
Out of the many UML shape libraries, only the “UML USE CASE” library will be used to create the use case diagram. The first step is to drag and drop an actor to the canvas and rename the actor.
Then select the actor and drag a line from the actor. A shape auto–prompt will appear to you, and you can select either to connect the existing actor with a new actor, or a new use case.
Figure 128: Add UML Shapes
tutorial 2 walk-through to web application design 99
Figure 129: Drag Actor to Canvas
Figure 130: Drag a Line and Add New Elements
100 planning, designing, and programming for web application
The line style will automatically change into dependencies (dotted line) when you create use cases put of an existing use case, and
you can change the line and arrow style from the property bar as well. Double click on the line allows you to add text on the line. Conversely, you can connect the use cases and actors after creating all of them, just like what you did with the ERD.
You can use a “Package” to group the related use cases. Drag and drop the “Package” shape to the canvas, resize the package and put it on top of the use cases you want to group together. Right click on the package and select “Send To Back”, now the package appears to be hosting the use cases.
Figure 131: Add Use Case
Figure 132: Add Package to Use Case Diagram and Send to Back
Rename the package and give it a different color, then select the package and all the use cases inside to group the use cases.
tutorial 2 walk-through to web application design 101
Figure 133: Group Use Cases Inside Package
102 planning, designing, and programming for web application
Wireframe
You can start wireframing the web application by create a new blank wireframe, or add the “UI Mockups” shapes to your toolbox.
You can find the “Browser Window” shape under the UI containers library. After you have the browser window on the canvas, feel free to experiment with the general layout using text, shapes, elements, area until you are satisfied with it. But bear in mind that your wireframe should be brief, showing what “Elements” should be included on each page is fine.
Need for a Master Page
Drawing the wireframe is a little bit different from creating other diagrams, it involves building and reusing a master page, and creating interac- tions through the use of links, hotspots, and demo mode. You should start by building the master page that contains the general layout of your web application.
Figure 134: Add UI Mockup Shapes
Figure 135: Add Browser Window
After you are satisfied with the general layout, you need to make this page the master page of the web application wireframe. Select “Page → Convert to Master” from the menu bar to make this layout a master page, and you can continue building the wireframe using this master page.
Try creating a new page by pressing the “+” button on the right-top corner of the menu bar. When your new page is created, select “Page → Apply Master” to use the master page you’ve just created. In this case, the master page will be displayed on the page as a background image, not editable by user on the page.
Drag and drop the elements you planned to display on the page. According to the site–map of the library system, the homepage contains links to various browse books functions, and one of them can directly lead to the “Book Details” page. Therefore, the page needs a navigation panel, and a brief description of books the directly link to the “Book Details” page. There are more than enough shapes in the UI library to help you complete this process.
Figure 136: Convert to Master
tutorial 2 walk-through to web application design 103
Figure 137: Add New Page
Figure 138: Apply Master Page
104 planning, designing, and programming for web application
After adding elements to the page, you also need to add in- teractions to the elements, so that it will redirect itself to another page when an element is selected. Developing the interactions al- lows you to understand how different pages are linked together, and thus helps you design the controller-view interaction in the web application.
You need to create a hotspot for interaction. A hotspot is like a link that redirects you to somewhere else when you click on it. If you want to add a link to a particular place or to the same place on different layers, drag and drop a hotspot from the standard shapes library and resize it to fit the particular button.
Figure 139: Sample Wireframe without Interaction
Figure 140: Drag and Drop Hotspot Element
If the whole object redirects to only 1 page, you can simply right-click on the object and select “Create Hotspot”
There are many hotspot actions, but the most straightforward one is “Link to Page”. You can create a new page directly through this hotspot. You will find a new blank page created for you right after you press “OK”.
You can also test the wireframe using the “DEMO CONTROLS”. You can find the control on the dock, your wireframe will enter presentation mode in the demo, and you can navigate through the web application by clicking on the hotspots on each page.
Figure 141: Right–Click on Element to Create Hotspot
tutorial 2 walk-through to web application design 105
Figure 142: Add Link to New Page
Figure 143: Start Demo using Demo Controls
106 planning, designing, and programming for web application
Using Templates
They are also a number of templates shared within the IMSE2016 team, joining the team enables you to make use of these templates which potentially speeds up your drawing process.
After login, you can see a pending invitation on the right–top corner of the documents section. You can find a “Templates” folder appear under the “My Documents” folder, inside are 6 templates of all the drawings in this chapter.
Click to open the templates if you want to use them. The system will automatically create a new document in the “My Documents” folder, and every changes you made to the templates will be saved to the new document, leaving the original template file unchanged.
Figure 144: Accept the Pending Invita- tion
Figure 145: New Drawing Saved Under My Documents
Figure 146: Templates Provided
Styling the drawing
• Change the shape size
1. Select the shape by single–clicking on it
2. Grab a corner of the shape and drag to resize it or 3. Change the width and height in the Metrics panel
• Change the border thickness
tutorial 2 walk-through to web application design 107
Figure 147: Steps to Change Shape Size
1. Select the shape by single–clicking on it
2. Adjust the line thicknesses in the properties bar or 3. Adjust the line thickness in the Graphic panel
Figure 148: Steps to Change Border Thickness
108 planning, designing, and programming for web application
• Change the shape color
1. Select the shape by single–clicking on it
2. Click on the Fill color box on the properties bar to open the
color picker
3. Select the color you want and it will recolor the shape
• Change the border color
Figure 149: Steps to Change Shape Color
1. Select the shape by single–clicking on it
2. Click on the line color box on the property bar to open the color
picker
3. Select the color you want and it will recolor the border
Figure 150: Steps to Change Border Color
• Apply a simple gradient
1. Select the shape by single–clicking on it
2. Click on the “Fill” box on the properties bar
3. Select the gradient circle at the bottom of the panel
4. The Graphic panel appears, fills the object with simple gradient
5. Select the angle of the gradient and its colors under “Simple Gradient” option
• Apply an advanced gradient (continued from simple gradient)
tutorial 2 walk-through to web application design 109
Figure 151: Steps to Apply Simple Gradient on Shapes
1. Select “Advanced Gradient” from the “Fill” menu
2. Add and modify colors in the gradient bar. Click anywhere along the bar to add more colors and slide markers to change the intensity
3. Choose between radial or linear gradient and change its angle
Figure 152: Steps to Apply Advanced Gradient
110 planning, designing, and programming for web application
• Change the line color
1. Select the line by single–clicking on it
2. Click on the line color box to open the color picker 3. Select the color you want and it will recolor the line
• Change the line thickness
Figure 153: Steps to Change Line Color
Figure 154: Steps to Change Line Thickness
1. Select the line by single–clicking on it
2. Click on the arrows in the properties bar to change the line
width
3. Click on the arrows in the Graphic panel to change the line width
• Change the line style
1. Select the line by single–clicking on it
2. Click on line style in the properties bar or 3. Click on line style in the Graphic panel
Figure 155: Steps to Change Line Style
• Change the line shape
tutorial 2 walk-through to web application design 111
Figure 156: Steps to Change Line Shape
1. Select the line by single–clicking on it
2. Click on one of the three angle types available (curved, elbow,
direct) in the properties bar
3. For customized line shapes, click “Edit Line Shapes” and drag the different points.
• Change the arrow type
Figure 157: Customize Line Shape
Figure 158: Steps to Change Arrow Type
1. Select the line by single–clicking on it
2. Click on one of the arrow types for each side of the line
112 planning, designing, and programming for web application
Export Drawings
Quickly download your diagram to your computer as either a PDF or high–res image.
• Download as PDF
1. Click “File” from the Menu bar and select “Download As . . .”
2. A menu will appear where you can select PDF
3. Next, choose whether to include the entire document or only the current page
4. Press “Download” and the PDF will begin downloading
• Download as image
1. Click “File” from the Menu bar and select “Download As . . .”
2. A menu will appear where you can select which image type you
want to download (PNG or JPEG).
3. Next, select whether to download the entire page or part of a current page. An additional menu will allow you to select the quality for your image.
4. Press “Download” and the image will begin downloading. If you selected to print a part of the page, you will be prompted to drag and highlight which part of the page.
Figure 159: Select Download As from the Meun
Figure 160: Select the Options to Download either PDF or Image
Appendix – Beginner’s Guide to Databases Database Fundamentals
This beginner’s guide to database introduces to you the fundamental concepts and definitions regarding databases, and the key concept of relational database model.
Definition of Database
A database is a collection of interrelated data items that are managed as a single unit. This definition of database is extremely broad, thus there are a variety of computer files that are qualified as database. For example, a text file containing student names and university numbers is already a simple database; on the other hand, if you organize these information into a spreadsheet then you will have
a better database, because now you can search and update records more efficiently.
Both text file and spreadsheet are not ideal for storing and organizing a huge amount of data for a web application, you need to use the Relational Model database to process and manage these data.
The Basics of Relational Database
The relational model is based on the notion that any preconceived path through a data structure is too restrictive a solution, especially in light of ever–increasing demands to support ad hoc requests for information.
The relational model presents data in familiar two-dimensional tables, much like a spreadsheet does. There are a few basic elements for a database: tables, columns, and rows.
Key Elements
a
b
c
Table: a database table is responsible for storing data of a certain kind in the database
Column: a column is re- sponsible for defining the type of data that goes into each cell
Row: a row contains each record in the table
114 planning, designing, and programming for web application
The concept of a relational database is better illustrated using the example in figure 161. The sample database contains 5 tables, where each of these tables are used to store only 1 kind of record. For instance, the Customer table contains only the information belonging to the customers, and the Product table only stores information related to the product itself. The concept of column and row can also be easily explained using the sample database. Take the Customer table as an example, each Column in the Customer table corresponds to 1 type of customer attribute; whereas each row stores record of 1 particular customer.
The Keys
One essential aspect that makes the relational database is the use of keys. In short, keys are attributes within a table that defines the records in the table, or establish relationship for the records across various tables. The most common keys are Primary Key and Foreign Key:
Figure 161: A Sample Relational Database
a A primary key is a column or a combination of columns that uniquely identify a row (record). Every table should have a primary, and a table cannot have more than one primary key.
b A foreign key is a column or a combination of columns in one table whose values must have matching values in the primary key of another table. A foreign key in one table is always a primary key in another table, thus a foreign key is said to reference its primary.
c Both primary key and foreign key are constraints applied on the records. For example, a primary key constraints
the value for the primary key field to be unique within the given table. On the other hand, the existence of a referenc- ing foreign key in another table prevents the editing and deleting action to be carried out to both tables.
Relationships in Relational Database
As the name implies, there is a strong emphasis on relationships in the context of relational database. For instance, each table in a relational database is a relation, and the tables are linked to each other by relationships.
Using the sample database from the last section, a portion of the sample database is shown in figure 162 where three of the five tables have been represented with sample data in selected columns. In particular, note that the Customer ID column is stored in both the Customer table and the Order table; in that sense, the Customer ID
PK & FK Examples
a primary key examples from sample database: Customer ID in Customer File, Prod- uct ID in Product File, Order ID in Order File.
b foreign key examples from sample database: Customer ID from Order File, Em- ployee ID from Order File, Product ID from Order Detail File
appendix – beginner’s guide to databases 115
Figure 162: Relational Tables Joined by Relationships
116 planning, designing, and programming for web application
is referenced as a foreign key in Order Table, and such foreign key has established the relationship between the Customer table and
the Order table. When the customer ID of a row in the Order table matches the customer ID of a row in the Customer table, you know that the order belongs to that particular customer. Similarly, the Employee ID column is stored in both the Employee and Order tables to indicate the employee who accepted each order.
The referencing of primary/foreign key pair has made the relational database extremely flexible. Once the relationships (primary/foreign key pair) are established, one can easily extract any combinations of information across different tables using these relationships.
CRUD Operations
CRUD refers to “Create-Retrieve-Update-Delete”; it is the essence of database processing and management. No matter what programming language you’re using, your CRUD operations are going to be basically the same. You should be able to abstract a common process for each CRUD operation. You’ll notice that even within these processes, certain CRUD operations are used, e.g. both UPDATE and DELETE make use of RETRIEVE.
C CREATE: initiate a new record of the object to be created, then store the new object in the database
R RETRIEVE: use the data from user’s request to retrieve the object to be updated or deleted from the database
Figure 163: Graphical Illustration of CRUD Operation
U UPDATE: use the data from user’s request to retrieve the object, change the content of the object if the object exists, the store the updated object in the database
D DELETE: use the data from user’s request to retrieve the object, if the object exists, remove it from the database
appendix – beginner’s guide to databases 117