Whirling CSS3 Dropdown Menu

Thank you to Admin of

I could learn new technique on how to use CSS for drop down menu, It is awesome tutorial. I studied and had my own work.


To kick a start, I code general functions for Main page by CSS







General coding for main page is done at the moment, I will come back later to complete. Now I go forward to menu navigation.










Registration Page with CSS 3 and HTML 5 version 2


Registration Page with CSS 3 and HTML 5 version 1

I searched and got a tutorial source from This is awesome article so I decide to pratice and learn for my own work.

First of all, I need to have two files called “index.php” and “css.css” respectively.

In the file “index.php” I have:


a form will be seen like this on Firefox browser:


That is a basic thing to go first, now we consider on how to decorate our page by CSS 3.

in file “css.css”, we move the form into the middle of page by elements



Next step, I style a header by CSS with HTML element h1


“Note that at this moment only webkit browsers support background-clip: text, so we will create a stripped background only for webkit here, and clip it to the text to add the stripes to the H1 title. Since the background-clip: text property currently only works in Webkit browsers, I decided to go only with the webkit prefix. That’s the reason why I split the CSS declaration into two parts, and use a webkit prefixed gradient only. Only using the –webkit- prefix is bad practice, it’s only for demo purpose, and you should never do this on real a website! That’s also where the -webkit-text-fill-color: transparent comes in handy: it enables us to only have a transparent background on the webkit browsers, all the other ones will ignore it and give us the provided text color fallback.”


A line is put up under the header


suiting up all form elements for better look, we firstly start with p, label and a



Here I styled the inputs of text box and remove outline.


as seen on browser, there is nothing changed here.

I used the :not [type=”checkbox”], to style all inputs, except the checkbox.


However, if we remove the outline, we should provide some :active and :focus states for the inputs because the outline helps user know which input is focused.


Result on Firefox browser


I nearly finish the registration page, my step now is to style the button “Sign up”, there are some steps to do

    size the button by 30%

  • transforming button from arrow to hand pointer
  • decorating button with background, padding, font-family, colour, font-size, border, margin button
  • making text shadow effect


Full styling code for submit button


Finally, we have a better look on button


I made a little change for a button when users click on,


The effect will be shown below:


Moving the button to right side of the page



styling the form with css elements

cssform hinh

Finally, my work is done. Time to enjoy a cup of hot tea !!! Yah


INM312 Systems Specification Class Diagram


INM312 Systems Specification Use Case Diagram APPLYING THE CONCEPTS

Business Process Modeling with Activity Diagrams

Based on the functional requirements identified for the Internet Sales System, Alec and his team decided that there were at least four high-level activities that needed to be addressed: Place CD Orders, Maintain CD Information, Maintain CD Marketing Information, and Fill Mail Orders. As a first step toward developing a functional model of the functional requirements, Alec decided to model the overall flow of execution of the business processes as an activity diagram. Upon close review of the Place CD Orders requirements,
the team identified a decision and two additional activities: Place InStore Hold and Place Special Order. These activities were based on the requirements laid out in point 3.5 of Figure 4-15. Furthermore, the team noticed that there seemed to be three separate concurrent paths of execution implied in the requirements. The first path dealt with orders, the second addressed the maintenance of marketing information, and the third focused on maintaining the information about the CDs. Based on these new insights, Alec and his team drew the activity diagram for the Internet Sales system shown in diagram below:

Identify the Major Use Cases

The first four steps in writing use cases deal with reviewing the activity diagram, finding the subject boundaries, listing the primary actors and their goals, and identifying and writing overviews of the major use cases based on these results. These use cases will form the basis of the use cases that are contained on the use-case diagram. We should review the requirements identified in the activity diagram before we continue

To begin with, it seems that the subject boundary should be drawn in such a manner that anything that is not part of CD Selections’ Internet Sales System, such as the vendors and customers, should be identified as primary actors. Therefore, these are considered outside of the scope of the system. The other potential actors identified could be the distribution system, electronic marketing (EM) manager, and the current CD Selections stores.

it seems that the distribution system and the current CD Selections stores should be outside the scope of the Internet Sales System. As such, they also should be identified as primary actors. It also seems that the EM manager should be considered as part of the Internet Sales System and, therefore, should not be identified
as a primary actor.

We should remember that primary actors are only those that can be viewed as being outside of the scope of the system.

The decision on whether the EM manager, the current CD Selections stores, or the distribution system is inside or outside of the system is somewhat arbitrary. From a customer’s perspective, the distribution system, and the current CD Selections stores could be seen as being inside of the overall system, and it could be argued
that the EM manager is a primary user of the Internet Sales System. At this point in the process, it is important to make a decision and to move on. During the process of writing use cases, there are ample opportunities to revisit this decision to determine whether the set of use cases identified are necessary and sufficient to describe the requirements of the Internet Sales System for CD Selections. As we can see, based on
the preceding, finding the systems boundaries and listing the primary actors are heavily

Based on the functional requirements and the activity diagram, Alec and his team identified four overview major use cases: Maintain CD Information, Maintain CD Marketing Information, Place Order, and Fill Order. We might have considered adding new CDs to the database, deleting old ones, and changing information about CDs as three separate use cases.

In addition to these three, we also need to have use cases for finding CD information and printing reports about CDs. However, our goal at this point is to develop a small set of essential use cases for the Internet Sales System. The same pattern should be evident for the marketing materials.

We have the same processes for recording new marketing material for a CD, creating it, reading it, updating it, deleting it, and printing it. These activities are usually required any time that we have information to be stored in a database.

The project team at CD Selections identified these same four major use cases. At this
point in the process, the project team began writing the overview use cases for these four.
Remember that an overview use case only has five pieces of information:

  1. Use case name
  2. ID number
  3. Primary actor
  4. Type
  5. A brief description.

At this point in time, we have already identified the primary actors and have associated them with the four use cases. Furthermore, because we are just beginning the development process, all four use cases will be
overview and essential types. Because the ID numbers are simply used for identification purposes (i.e., they act as a key in a database), their values can be assigned in a sequential manner. This leaves us with only two pieces of information for each use case to write. The use-case name should be an action verb–noun phrase combination (e.g.,Make Appointment).

In the CD Selections Internet Sales situation, Maintain CD Information, Maintain CD Marketing Information, Place Order, and Fill Order seem to capture the essence of each of the use cases. Finally, a brief description is written to describe the purpose of the use case or the goal of the primary actor using the use case. This description can range from a sentence to a short essay. The idea is to capture the primary issues in the use case and make them explicit.

The fifth step is to carefully review the current set of use cases. Take a moment to review the use cases and make sure we understand them. Based on the descriptions of all four use cases, there seems to be an obvious missing use case: Maintain Order. Because the project team did not include language in the brief description of the Place Order use case, it seems that the project team believes that maintaining an order is sufficiently different from placing an order that it should have its own use case to describe it. Furthermore, it does not seem
reasonable that a customer would see placing an order and maintaining an order as the same use case. This type of interactive and incremental process goes on until the project team feels that they have identified the major use cases for the Internet Sales System.

The sixth step is to choose one of the major use cases to expand. To help the project team to make this choice, they identified the trigger and the stakeholders and their interests for each of the major use cases.

The first use case, Maintain CD Information, was triggered by the Distribution System distributing new information for use in the CD database. Besides the Distribution System, another stakeholder was identified: EM Manager.

The second use case,Maintain CD Marketing Information, has a similar structure. The receipt of marketing materials from vendors triggers it.Again, it seemed to the project team that the EM Manager was an interested stakeholder.

The third use case, Place Order, is more interesting. The trigger is the action of a Customer. Again, the EM Manager is an interested stakeholder. This use case has many more inputs.

The fourth use case, Fill Order, is based on the decision logic identified in the activity diagram. However, upon further reflection, the team decided to replace this use case with three separate use cases, one for each approach to filling an order: Place Special Order, Place In-Store Hold, and Fill Mail Order. The first two are controlled by actions of the Customer.

However, the Fill Mail Order use case has a temporal trigger: every hour the Internet Sales System downloads orders into the Distribution System. The final use case, Maintain Order, is triggered by the action of a Customer.However, on close review, it seems that it also has much in common with the other maintenance-related use cases: Maintain CD Information and Maintain CD Marketing Information. And like all of the other use cases, the EM Manager has an interest. Based on their review of the major use cases, the project team decided that the Place Order use case was the most interesting.

The next step, step 7, is to start filling in the details of the chosen use case. At this point in time, the project team had the information to fill in the stakeholders and interests, the trigger, and the association relationship. (Note: Remember that the association relationship is simply the communication link between the primary actor and the use case.) In this use case, the association relationship is with the Customer. The project team then needed to gather and organize the information needed to define the Place Order use case in more detail. Specifically, they needed to begin writing the normal flow of events; that is, they should perform the eighth step for writing effective use cases.

The goal at this point is to describe how the chosen use-case operates: Place Order. Alec and the team decided to visualize placing a CD order over the Web and to think about how other electronic commerce Web sites work—that is, to role-play. As they role-played the Place Order use case, they realized that after the customer connected to the Web site, he or she probably began searching—perhaps for a specific CD, perhaps for a category of music—but in any event, they entered some information for their search. The Web site then should present a list of CDs matching their request along with some basic information about the CDs (e.g., artist, title, and price).

If one of the CDs is of interest to them, they might seek more information about it, such as the list of songs, liner notes, reviews, etc.

Once they found a CD they liked, they would add it to their order and perhaps continue looking for more CDs. Once they were done—perhaps immediately—they would check out by presenting their order with information on the CDs they want and giving additional information such as mailing address, credit card, etc.



INM312 Systems Specification Use Case Diagram



Identify the Major Use Cases

1. Review the activity diagram.
2. Find the subject’s boundaries.
3. Identify the primary actors and their goals.
4. Identify and write the overviews of the major use cases for the above.
5. Carefully review the current use cases. Revise as needed.

Expand the Major Use Cases

6. Choose one of the use cases to expand.
7. Start filling in the details of the chosen use case.
8. Write the normal flow of events of the use case.
9. If the normal flow of events is too complex or long, decompose into subflows.
10. List the possible alternate or exceptional flows.
11. For each alternate or exceptional flow, list how the actor and/or system should react.

Confirm the Major Use Cases

12. Carefully review the current set of use cases. Revise as needed.
13. Start at the top again.

Create the Use-Case Diagram

1. Draw the subject boundary.
2. Place the use cases on the diagram.
3. Place the actors on the diagram.
4. Draw the associations.

Identifying the Major Use Cases

The first step is to review the activity diagram. This helps the analyst to get a complete overview of the underlying business process being modeled.

The second step is to identify the subject’s boundaries. This helps the analyst to identify the scope of the system.

The third step is to identify the primary actors and their goals. The primary actors involved with the system will come from a list of stakeholders and users. However, recall that an actor is a role that a stakeholder or user plays, not a specific user (e.g., doctor, not Dr. Jones). The goals represent the functionality that the system must provide the actor for the system to be a success. Identifying what the tasks are that each actor must perform can
facilitate this. For example, does the actor need to create, read, update, or delete any information currently in the system, are there any external changes of which an actor must inform the system, or is there any information that the system should give the actor?
Steps 2 and 3 are intertwined. As actors are identified and their goals are uncovered, the boundary of the system will change.

The fourth step is to identify and write the major use cases, with basic information about each, rather than jumping into one use case and describing it completely (i.e., only an overview use case). Recall from the previous description of the elements of a use case that overview use cases contain only the use case name, ID number, type, primary actor, importance level, and brief description. Creating only overview use cases at this time prevents
the users and analysts from forgetting key use cases and helps the users explain the overall set of business processes for which they are responsible. It also helps them understand how to describe the use cases and reduces the chance of overlap between use cases.

It is important at this point to understand and define acronyms and jargon so that the project team and others from outside the user group can clearly understand the use cases. Again, the activity diagram is a very useful beginning point for this step.

The fifth step is to carefully review the current set of use cases. It may be necessary to split some of them into multiple use cases or merge some of them into a single use case. Also, based on the current set, a new use case may be identified. You should remember that identifying use cases is an iterative process, with users often changing their minds about what a use case is and what it includes. It is very easy to get trapped in the details at this
point, so you need to remember that the goal at this step is to identify the major use cases and that you are creating only overview use cases. For example, in the doctors’ office example in Figure 5-10, we defined one use case as Make Appointment. This use case included the cases for both new patients and existing patients, as well as for when a patient changes or cancels an appointment. We could have defined each of these activities (makes an
appointment, changes an appointment, or cancels an appointment) as separate use cases, but this would have created a huge set of small use cases.

The trick is to select the right size so that you end up with three to nine use cases in each
system. If the project team discovers many more than eight use cases, this suggests that the
use cases are too small or that the system boundary is too big. If more than nine use cases
exist, the use cases should be grouped together into packages (i.e., logical groups of use cases)
to make the diagrams easier to read and keep the models at a reasonable level of complexity.
It is simple at that point to sort the use cases and group together these small use cases
into larger use cases that include several small ones or to change the system boundaries.

Expanding the Major Use Cases

The sixth step is to choose one of the major use cases to expand. Using the importance level of the use case can help do this. For example, the Make Appointment use case


It has an importance level of high. As such, it should be one of the earlier use cases to be

The seventh step is to start filling in the details on the use-case template. For example, list all of the identified stakeholders and their interests in the use case, the level of importance of the use case, a brief description of the use case, the trigger information for the use case, and the relationships in which the use case participates.

The eighth step is to fill in the steps of the normal flow of events required to describe each use case. The steps focus on what the business process does to complete the use case, as opposed to what actions the users or other external entities do. In general, the steps should be listed in the order in which they are performed, from first to last. Remember to write the steps in an SVDPI form whenever possible. In writing the use case, remember the
seven guidelines described earlier. The goal at this point is to describe how the chosen use case operates. One of the best ways to begin to understand how an actor works through a use case is to visualize performing the steps in the use case—that is, role-play. The techniques of visualizing how to interact with the system and of thinking about how other systems work (informal benchmarking) are important techniques that help analysts and users understand how systems work and how to write a use case. Both techniques (visualization and informal benchmarking) are common in practice. It is important to remember that at this point in the development of a use case, we are interested only in the typical successful execution of the use case. If we try to think of all of the possible combinations of activities that could go on, we will never get anything written down. At this point, we are looking
only for the three to seven major steps. As such, focus only on performing the typical process that the use case represents.

The ninth step is to ensure that the steps listed in the normal flow of events are not too complex or too long. Each step should be about the same size as the others. For example, if we were writing steps for preparing a meal, steps such as take fork out of drawer and put fork on table are much smaller than prepare cake using mix. If we end up with more than seven steps or steps that vary greatly in size, we should go back and review each step carefully and possibly rewrite the steps.

One good approach to produce the steps for a use case is to have the users visualize themselves actually performing the use case and to have them write down the steps as if they were writing a recipe for a cookbook. In most cases the users will be able to quickly define what they do in the as-is model. Defining the steps for to-be use cases may take a bit more coaching. In our experience, the descriptions of the steps change greatly as users work through a use case. Our advice is to use a blackboard or whiteboard (or paper with pencil) that can be easily erased to develop the list of steps, and then write the list on the use-case form. It should be written on the use-case form only after the set of steps is fairly well defined.

The tenth step focuses on identifying the alternate or exceptional flows. Alternate or exceptional flows are those flows of success that represent optional or exceptional behavior. They tend to occur infrequently or as a result of a normal flow failing. They should be labeled so that there is no doubt as to which normal flow of events it is related.

The eleventh step is simply to write the description of any alternate or exceptional flows. In other words, if an alternate or exceptional flow is to be executed, describe the response that the actor or system should produce. Like the normal flows and subflows, alternate or exceptional flows should be written in the SVDPI form whenever possible.

Confirming the Major Use Cases

The twelfth step is to carefully review the current set of use cases and to confirm that the use case is correct as written, which means reviewing the use case with the users to make sure each step is correct. The review should look for opportunities to simplify a use case by decomposing it into a set of smaller use cases, merging it with others, looking for common aspects in both the semantics and syntax of the use cases, and identifying new use cases.

This is also the time to look into adding the include, extend, or generalization relationships between use cases. The most powerful way to confirm a use case is to ask the user to roleplay, or execute the process using the written steps in the use case. The analyst will hand the user pieces of paper labeled as the major inputs to the use case and will have the user follow the written steps like a recipe to make sure that those steps really can produce the outputs
defined for the use case using its inputs.

The thirteenth and final step is to iterate over the entire set of steps again. Users will often change their minds about what is a use case and what it includes. It is very easy to get trapped in the details at this point, so remember that the goal is to just address the major use cases. Therefore, the analyst should continue to iterate over these steps until he or she and the users believe that a sufficient number of use cases has been documented to begin identifying candidate classes for the structural model (see Chapter 6). As candidate classes are identified, it is likely that additional use cases will be uncovered. Remember, object-oriented systems development is both iterative and incremental. As such, do not worry about identifying each and every possible use case at this point in the development of the system.

Creating a Use-Case Diagram

Basically, drawing the use-case diagram is very straightforward once use cases have been detailed. The actual use-case diagram encourages the use of information hiding. The only parts drawn on the use-case diagram are the system boundary, the use-cases themselves, the actors, and the various associations between these components. The major strength of the use-case diagram is that it provides the user with an overview of the detailed use cases.
However, remember that anytime a use case changes, it could impact the use case diagram. There are four major steps in drawing a use-case diagram. First, the use-case diagram starts with the subject boundary. This forms the border of the subject, separating use cases (i.e., the subject’s functionality) from actors (i.e., the roles of the external users).

Second, the use cases are drawn on the diagram. These are taken directly from the detailed use-case descriptions. Special use-case associations (include, extend, or generalization) are also added to the model at this point. Be careful in laying out the diagram. There is no formal order to the use cases, so they can be placed in whatever fashion needed to make the diagram easy to read and to minimize the number of lines that cross. It often is necessary to redraw the diagram several times with use cases in different places to make the diagram easy to read. Also, for understandability purposes, there should be no more than three to nine use cases on the model so the diagram is as simple as possible. These includes those use cases that have been factored out and now are associated with another use case through the include, extend, or generalization relationships.

Third, the actors are placed on the diagram. The actors are taken directly from the primary actor element on the detailed use-case description. Like use-case placement, to minimize the number of lines that will cross on the diagram, the actors should be placed near the use cases with which they are associated.

The fourth and last step is to draw lines connecting the actors to the use cases with which they interact.No order is implied by the diagram, and the items added along the way do not have to be placed in a particular order; therefore, it may help to rearrange the symbols a bit to minimize the number of lines that cross, making the diagram less confusing


INM312: Systems Specification Examination 16th January 2012

Scenario (This scenario is used in all questions. Read it carefully.)

Picnics R Us (PRU) is a small catering firm with five employees. During a typical summer weekend, PRU caters for fifteen picnics with twenty to fifty people each. The business has grown rapidly over the past year and the owner wants to provide the customers with an on-line ordering system.

PRU already has a web presence that will now also include the new on-line ordering system. PRU has a set of ten standard menus. When a potential customer wants to book a picnic, (s)he can choose from one of the standard menus, identifying how many people are to be served. The system then displays to the customer the total costs for the food, excluding delivery. A potential customer may also choose to check for available slots first by providing the system with information about the picnic (e.g., place, date, and time). Once both sets of information have been entered, the customer may choose to move forward with the transaction and have the total cost for the picnic (food and delivery) calculated and displayed.

If the customer decides to book the picnic (s)he must agree to PRU’s terms and conditions and then enter his/her information (e.g., name, email address, phone number, etc.). The customer then is prompted to pay a deposit of 50%, which can be paid by debit card, credit card, or using PayPal. Once the deposit payment is completed, information about the picnic and the customer is stored in the system, the customer is sent an email with the details of the contract agreed, a message is displayed on the customer’s screen informing of successful completion and summarizing the picnic details, and PRU’s owner is sent an email with the details of the picnic (date, time, place, menu choice and number of people). This concludes the ordering of picnics.
Four days prior to the picnic the system sends an email to the customer reminding him/her of the details booked. If the customer has a problem with it then (s)he must contact PRU in 24 hours to resolve the issues.
The rest of PRU’s business will remain the same, with food orders being purchased two days prior to the picnics, then prepared in house, and delivered with plates, napkins, cutlery and cups/glasses according to the agreement. When a picnic is being delivered the remaining money is collected. One day later the customer is sent an email giving the option of providing feedback (on a form on-line), and the details of the picnic (excluding payment details) are stored in the system for future use, supporting trend analysis as well as for marketing purposes.

Question 1. (This question is about activity diagrams and use cases)
a) Create an activity diagram for describing the on-line booking of picnics with PRU as described in the scenario.[40 marks]

b) What are the different types of control nodes in activity diagrams? Explain what each of them means. Provide examples of two of those types from your answer to question 1a) above.[20 marks]
c) List the set of use cases relevant to the PRU scenario above with their corresponding primary actors. We expect to see around ten use cases. Draw the relevant use case diagram. Ensure that actors and use cases are labeled clearly and meaningfully. If appropriate, make use of inclusion use cases, extension use cases and generalisation.[40 marks]

Question 2. (This question is about class diagrams and sequence diagrams)

a) Create an analysis class diagram for describing a system for the PRU scenario above.[40 marks]


b) What are the differences between abstract and concrete classes? Make use of an example to illustrate your answer.[10 marks]


c) Create a sequence diagram that reflects a customer booking a picnic with PRU on-line as described in the scenario.[40 marks]


d) Describe what the main purpose of sequence diagrams is. Explain how that is achieved on your answer to question 2c) above.[10 marks]

Question 3. (This question is about state diagrams and verification & validation)

a) Draw a state machine for a picnic within a computing system to support the on-line ordering business of PRU, from the moment a customer starts considering ordering the picnic on-line until its information is stored for future use.[40 marks]
b) PRU now would like to allow its customers to cancel a requested picnic up to four days in advance, giving them a partial refund of their deposit. Describe how that would impact your model provided for question 3a) above. What would be the changes needed and why?[20 marks]
c) Describe the types of events that can be represented on a state machine and illustrate each one with an example (feel free to draw from your answer to question 3a) above).[20 marks]
d) Explain what is the role of the actors elements in verification and validation across models. Illustrate your answer with an example.[20 marks]


Nhãn: , , ,