Flying Cucumber

- Usage

In software project management, software testing, and software engineering, Verification and Validation (V&V) is the process of checking that a software system meets specifications and that it fulfils its intended purpose. It is normally part of the software testing process of a project.

- Definitions

Also known as software quality control.

Validation checks that the product design satisfies or fits the intended usage (high-level checking) — i.e., you built the right product. This is done through dynamic testing and other forms of review.

According to the Capability Maturity Model (CMMI-SW v1.1),

• Verification: The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD-610].
• Validation: The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. [IEEE-STD-610]

In other words, validation ensures that the product actually meets the user’s needs, and that the specifications were correct in the first place, while verification is ensuring that the product has been built according to the requirements and design specifications. Validation ensures that ‘you built the right thing’. Verification ensures that ‘you built it right’. Validation confirms that the product, as provided, will fulfil its intended use.

Within the modeling and simulation community, the definitions of validation, verification and accreditation are similar:

• Validation is the process of determining the degree to which a model, simulation, or federation of models and simulations, and their associated data are accurate representations of the real world from the perspective of the intended use(s).
• Accreditation is the formal certification that a model or simulation is acceptable to be used for a specific purpose.
• Verification is the process of determining that a computer model, simulation, or federation of models and simulations implementations and their associated data accurately represents the developer’s conceptual description and specifications.

It is very difficult period since August to now, preparing my VISA, my IELTS, ready for the life in America, seems that everything mass together. And Luck,  finally, I arrive in La Crosse.

Everything is amazing in america, the air is clean, the people is nice. life in america is colorful and wonderful. But I have to alway remember concentrating on my mind and study hard. Remember my expectations and motivation of coming here.

#author: dwet (骁尧)

# After done the function requirement, the next step is GUI requirement. But, because of this project  is only the small assignment for me to practice myself, so there is no special requirment for the GUI. I decide to skip  it.

These days I though a lot about How to continual my project more engineering and more constrution~~~ what is the next step when I finish the requirement collection. How to begin the design phase. After drawing the Use Case Diagram, then is the Class diagram or Activity diagram? What should I identify class in the Class diagram? what kind of categories will be more efficiency…. All of these questions seem I need to go back to the book.

And I would also like to create a document to monitor the entire developing process. That document will record what I changed, added, deleted in previous document, and also review schedule and deadline all the time.

#  author: dwet(骁尧)

# This article is brief summary of the <Object Oriented Software Development> course.

Use Case Model

• describes what the user expects the system to do
            —-functional requirements
• generally described using an activity diagram (to be discussed later)
• example:

Activity Diagram

• an activity diagram can be used to
     — describe a use case
     — describe a method in a collaboration diagram
     — describe an action associated with a transition in a state diagram, or the entry action or the exit action of a state diagram
• every activity diagram must have only one initial state and one or more final states
• a merger is also represented by a diamond
     — two or three incoming transitions and one outgoing transition
     — the outgoing transition will be fired only when both the incoming transitions are fired
• example:

Class and Object Diagram

• How to find classes?
   - nouns in requirements document or use case descriptions do not provide adequate solutions
   - each class should contain a distinct set of operations relevant to the system under consideration
   - do not include implementation-oriented classes in the analysis model
        * may be introduced later during design and/or implementation
        * examples: array, tree, list
• every association is expected to be labeled, direction of an association, cardinality, role name are all optional
      — UML does not require a name for an association
• representations of cardinality
    — 0, 1, * (zero or more), n..m (values in the range between n and m both inclusive)
• example:

• a piece of information that belongs to both classes in an association is put into a separate class called “association class”
    — association class is a dependent class that depends on the other two classes in the association
    — cannot exist independently
    — object of an association class must refer to objects of the other two classes in the association
    — Example: A “Transaction” object depends on a “User” object and on an “Account” object.

State Diagrams

• one state diagram per class in the class diagram
• one logical state diagram may be spread out into one or more physical diagrams for space considerations

• every state may have
    – an entry action – executed as soon as the state is entered
    – an exit action – executed just before leaving the state
    – a “do” action – executed while the object is in this state; may be ongoing until the object leaves the state

#author: dwet (骁尧)

#This document describes the functional requirement for developer, which include Use Case Diagram and some brief instruction.

1. Use Case Diagram

2. Functional Discretion

Each functional requirement is given in the following format:
Index:
Name:
Purpose:
Input parameters:
Action:
Output parameters:
Exceptions:
Remarks:
Cross-references:

Index refers to a unique index assigned to this functional requirement. It will be used for cross-referencing this requirement from other requirements and also from other documents such as the design document.

Name is a descriptive name given to this functional requirement. This name does not need to be unique.

Purpose is a short description (in a line or two) of the function. It is used to quickly understand the functionality and is also used to search the required function when all the functionalities are browsed through.

Input parameters refer to a set of parameters that the given function accepts as input. These parameters are required in order to design and implement the current function. No type information will be included for parameters in this document.

Output parameters refer to a set of parameters that are output/exhibit by the current function, when implemented. No type information will be included for parameters in this document.

Action refers to a set of tasks or activities that must be performed in order to satisfy this requirement. These tasks/activities are listed in no particular order. The design will take care of sequencing the tasks.

Exceptions refer to a set of conditions, each of which indicates a situation in which the function will stop. Notice that this column only lists a set of exceptions that might

Occur but does not suggest any action that must be taken when the exceptions occur. These actions will be included in the design document.

Remarks include a set of comments that explain more about the functionality. It also describes hints to the designer and implementer that are suggested by the requirements analyst.

Cross-references refer to a set of other functional requirements that are related to the current function.

2.1 Functional Requirements for Borrower

Index: SLMS-B.1
Name: SearchItems
Purpose: To search the item in the library.
Input parameters: The ID of item or title or publisher or key word or subject or author.
Action: Ensure that all the information were accurate equal to the ID of item or title or publisher or key word or subject or author.
Output parameters: The item’s information list.
Exceptions: The inputting information does not exist in the library database.
The inputting information was not equal to the ID of item or title or publisher or key word or subject or author.
Remarks: The system does not support the illegal search so that the inputting information must be accurate.
Can not search the item by different type of parameters at the same time.
Cross-references: None.

……. (ignore the rest function)

#author: dwet (骁尧)

#some glossaries are showing in the end of this documents.

1. Product Overview

( Ignore in here, you can see in <A Simple School Library Management System— project plan>)

2. Assumption and Additional Requirements

• The system is basic on the B/S structure.
• The borrower can search the items by name, publisher, key words, author or subject.
• Administrator provide user a default password to they who are forgot their password. Then, they can reset their password.
• The system can only provide accurately search function.
• Items only have three status: ON-SHELF, BORROWED, RESERVED.
• Items for reserver: you must sure that the item is  ON-SHELF. Once the reserver apply submit it can not be canceled.
• Items for renew: Item only can be renewed once.
• Items for borrow: you must sure that this item had been reserver by you, then you can go to the front desk to ask the Clerk to borrow.
• Items for return: you must go to the front desk to return a book and pay your fines.
• If you have a pass due day item in your account or haven’t pay the fines yet, you will not allow to borrow items.

3. System Requirements

No specific system was required.

4. User Characteristics

The user must be able to use the Browser to access to Internet. No additional knowledge is required.

5. Glossary

ON-SHELF: means items can be borrowed and reserver.

BORROWED: means items have been borrowed, but you can reserver it.

RESERVED: means items have been reserved, you can not reserver again.

front desk: mean the clerk who work in the front desk help you to borrow and return an item. This object will not exsit in the system.

#author: dwet (骁尧)

#This project is for nothing just use to practice and strengthen my CS knowledge and English. So please comment me if you found something interest or have any opinion.

A Simple Library Management System —- Project Plan

1. Problem Description

The goal of this project is to create a simple library management system which can support the esay-use GUI and functions for a small library to mange items and users.

There are three type of users who will user this system.

1. Borrower: who is also called User in the system. They can search their personal information, reserver a book, renew a book and view the fines if there is any. They can also modify their personal info and the password. The borrower was divided into four levels:

1.1 Common borrower: They can only borrow totally no more than 4 items for 1 months.

1.2 Membership borrower: They can borrow totally 8 items for 1 months.

2. Librarian: who manage items in the library. They can add new items, search items and delete items.

3. Administrator: who manage users in the library. They can add new users, search users, and set the user’s level.

4. Clerk: who is on the front desk in the library. They help user to borrow items, return items and clean the user’s fines in the system.

2. Basic Requirement

The following minimal set of functionalities must be implemented:

• Provision search, reserver, renew, modify personal info and change password functions for Borrower.
• Provision add, search, delete and modify item functions for Librarian.
• Provision add, search, delete and set Borrower level functions for Administrator.
• The system should be able to generate the return date and billing information if past due date.
• The borrower should be able to pay the fines if there is any.

A graphical user interface must be developed for this software. The interface must consist of multiple screeens for different tasks. The hole system must be the web-base.

All the functionalities mentioned above must be implemented. And a database should be using in this project.

3. Planned Activities

( Ignore in here…)

Organization constraints:

External resources planned to be used:              MYSQL 5.0

Platform:                                                       NetBeans 6.5.1

Language:                                                      JAVA

Example for servlet XML mapping:

How the Container handles a request？

Welcome to my blog~~

2年前，我还记得自己第一写 “Hello World” 时候的兴奋。也是这个 “Hello World” 它开启了我无边无涯的计算机学习之旅。2年后的今天当在ubuntu的blog里写下第一篇日志时，希望也能让它陪我度过一段丰富的旅程～～恩!! “Hello world~I’m coming~~”

I still remember the feeling when I was first coding the “Hello world” program by myself two years ago. How exciting I was. Also by this “Hello world”, from that time, I was began my endless journey of computer science learning~~

2 years late, at today, when I write down my first blog in ubuntu.org, I hope this blog can bring other wonderful life~~

ex!! “Hello world ~ I’m coming ~ ~”