text:
Use case
From Wikipedia, the free encyclopedia
Jump to: navigation, search
A very simple use case diagram of a Wiki system.
Software development
Core activities
Processes
Requirements
Design
Engineering
Construction
Testing
Debugging
Deployment
Maintenance
Paradigms and models
Agile
Cleanroom
Incremental
Prototyping
Spiral
Waterfall
Methodologies and frameworks
DevOps
DSDM
FDD
IID
Kanban
Lean SD
MDD
MSF
PSP
RAD
SAFe
Scrum
SEMAT
TSP
UP
V-Model
XP
Supporting disciplines
Configuration management
Documentation
Software quality assurance (SQA)
Project management
User experience
Practices
ATDD
BDD
CCO
CI
CD
DDD
PP
Stand-up
TDD
Tools
Compiler
Debugger
Profiler
GUI designer
Modeling
IDE
Build automation
Release automation
Infrastructure as Code
Testing
Standards and BOKs
CMMI
IEEE standards
ISO 9001
ISO/IEC standards
SWEBOK
PMBOK
BABOK
v
t
e
In software and systems engineering, a use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modeling Language as an actor) and a system to achieve a goal. The actor can be a human or other external system. In systems engineering use cases are used at a higher level than within software engineering often representing missions or stakeholder goals. The detailed requirements may then be captured in the Systems Modeling Language (SysML) or as contractual statements.
Use case analysis is an important and valuable requirement analysis technique that has been widely used in modern software engineering since its formal introduction by Ivar Jacobson in 1992. Use case driven development is a key characteristic of many process models and frameworks such as ICONIX, the Unified Process (UP), the IBM Rational Unified Process (RUP), and the Oracle Unified Method (OUM). With its inherent iterative, incremental and evolutionary nature, use case also fits well for agile development.
Contents
[hide]
1 History
2 Templates
2.1 Cockburn style
2.1.1 Design scopes
2.1.2 Goal levels
2.1.3 Fully dressed
2.1.4 Casual
2.2 Fowler style
3 Actors
4 Business Use Case
5 Visual modeling
6 Examples
7 Advantages
8 Limitations
9 Misconceptions
10 Tools
11 See also
12 References
13 Further reading
14 External links
History[edit]
In 1986, Ivar Jacobson first formulated textual, structural, and visual modeling techniques for specifying use cases. In 1992 his co-authored book Object-Oriented Software Engineering - A Use Case Driven Approach[1] helped to popularize the technique for capturing functional requirements, especially in software development. Originally he had used the terms usage scenarios and usage case — the latter a direct translation of his Swedish term användningsfall — but found that neither of these terms sounded natural in English, and eventually he settled on use case.[2]
Since then, other experts have also contributed a great deal to the technique, notably Alistair Cockburn, Larry Constantine, Dean Leffingwell, Kurt Bittner and Gunnar Overgaard.
In 2011, Jacobson published an update to his work, called Use Case 2.0,[3] with the intention of incorporating many of his practical experiences of applying use cases since the original inception of the concept.[4][need quotation to verify]
Templates[edit]
There are many ways to write a use case in text, from use case brief, casual, outline, to fully dressed etc., and with varied templates. Writing use cases in templates devised by various vendors or experts is a common industry practice to get high-quality functional system requirements.
Cockburn style[edit]
The template defined by Alistair Cockburn in his popular book Writing Effective Use Cases has been one of the most widely used writing styles of use cases.[citation needed]
Design scopes[edit]
Cockburn suggests annotating each use case with a symbol to show the "Design Scope", which may be black-box (internal detail is hidden) or white-box (internal detail is shown). Five symbols are available:[5]
Scope
Icon
Organization (black-box) Filled House
Organization (white-box) Unfilled House
System (black-box) Filled Box
System (white-box) Unfilled Box
Component Screw or Bolt
Other authors sometimes call use cases at Organization level "Business use cases".[6]
Goal levels[edit]
Hierarchy of goal levels
Cockburn suggests annotating each use case with a symbol to show the "Goal Level";[7] the preferred level is "User-goal" (or colloquially "sea level"[8]:101).
Goal Level
Icon
Symbol
Very High Summary Cloud ++
Summary Flying Kite +
User Goal Waves at Sea !
Subfunction Fish -
Too Low Seabed Clam-Shell --
Sometimes in text writing, a use-case name followed by an alternative text symbol (!, +, -, etc.) is a more concise and convenient way to denote levels, e.g. place an order!, login-.
Fully dressed[edit]
Cockburn describes a more detailed structure for a use case, but permits it to be simplified when less detail is needed. His fully dressed use case template lists the following fields:[9]
Title: "an active-verb goal phrase that names the goal of the primary actor"[10]
Primary Actor
Goal in Context
Scope
Level
Stakeholders and Interests
Precondition
Minimal Guarantees
Success Guarantees
Trigger
Main Success Scenario
Extensions
Technology & Data Variations List
In addition, Cockburn suggests using two devices to indicate the nature of each use case: icons for design scope and goal level.
Cockburn's approach has influenced other authors; for example, Alexander and Beus-Dukic generalize Cockburn's "Fully dressed use case" template from software to systems of all kinds, with the following fields differing from Cockburn:[11]
Variation scenarios "(maybe branching off from and maybe returning to the main scenario)"
Exceptions "i.e. exception events and their exception-handling scenarios"
Casual[edit]
Cockburn recognizes that projects may not always need detailed "fully dressed" use cases. He describes a Casual use case with the fields:[9]
Title (goal)
Primary Actor
Scope
Level
(Story): the body of the use case is simply a paragraph or two of text, informally describing what happens.
Fowler style[edit]
Martin Fowler states "There is no standard way to write the content of a use case, and different formats work well in different cases."[8]:100 He describes "a common style to use" as follows:[8]:101
Title: "goal the use case is trying to satisfy"[8]:101
Main Success Scenario: numbered list of steps[8]:101
Step: "a simple statement of the interaction between the actor and a system"[8]:101
Extensions: separately numbered lists, one per Extension[8]:101
Extension: "a condition that results in different interactions from .. the main success scenario". An extension from main step 3 is numbered 3a, etc.[8]:101
The Fowler style can also be viewed as a simplified variant of the Cockburn template.
Actors[edit]
Main article: Actor (UML)
A use case defines the interactions between external actors and the system under consideration to accomplish a goal. Actors must be able to make decisions, but need not be human: "An actor might be a person, a company or organization, a computer program, or a computer system—hardware, software, or both."[12] Actors are always stakeholders, but not all stakeholders are actors, since they "never interact directly with the system, even though they have the right to care how the system behaves."[12] For example, "the owners of the system, the company's board of directors, and regulatory bodies such as the Internal Revenue Service and the Department of Insurance" could all be stakeholders but are unlikely to be actors.[12]
Similarly, a person using a system may be represented as different actors because he is playing different roles. For example, user "Joe" could be playing the role of a Customer when using an Automated Teller Machine to withdraw cash from his own account, or playing the role of a Bank Teller when using the system to restock the cash drawer on behalf of the bank.
Actors are often working on behalf of someone else. Cockburn writes that "These days I write 'sales rep for the customer' or 'clerk for the marketing department' to capture that the user of the system is acting for someone else." This tells the project that the "user interface and security clearances" should be designed for the sales rep and clerk, but that the customer and marketing department are the roles concerned about the results.[13]
A stakeholder may play both an active and an inactive role: for example, a Consumer is both a "mass-market purchaser" (not interacting with the system) and a User (an actor, actively interacting with the purchased product).[14] In turn, a User is both a "normal operator" (an actor using the system for its intended purpose) and a "functional beneficiary" (a stakeholder who benefits from the use of the system).[14] For example, when user "Joe" withdraws cash from his account, he is operating the Automated Teller Machine and obtaining a result on his own behalf.
Cockburn advises to look for actors among the stakeholders of a system, the primary and supporting (secondary) actors of a use case, the system under design (SuD) itself, and finally among the "internal actors", namely the components of the system under design.[12]
Business Use Case[edit]
This section needs expansion. You can help by adding to it. (July 2015)
A business Use Case Diagram depicts a model of several business use cases (goals) which represents the interactions between a restaurant (the business system) and its primary stakeholders (business actors and business workers).
Visual modeling[edit]
UML diagrams
Structural UML diagrams
Class diagram
Component diagram
Composite structure diagram
Deployment diagram
Object diagram
Package diagram
Profile diagram
Behavioral UML diagrams
Activity diagram
Communication diagram
Interaction overview diagram
Sequence diagram
State diagram
Timing diagram
Use case diagram
v
t
e
Use cases are not only texts, but also diagrams, if needed. In the Unified Modeling Language, the relationships between use cases and actors are represented in use case diagrams originally based upon Ivar Jacobson's Objectory notation. SysML uses the same notation at a system block level.
In addition, other behavioral UML diagrams such as activity diagrams, sequence diagrams, communication diagrams and state machine diagrams can also be used to visualize use cases accordingly. Specifically, a System Sequence Diagram (SSD) is a sequence diagram often used to show the interactions between the external actors and the system under design (SuD), usually for visualizing a particular scenario of a use case.
Use case analysis usually starts by drawing use case diagrams. For agile development, a requirement model of many UML diagrams depicting use cases plus some textual descriptions, notes or use case briefs would be very lightweight and just enough for small or easy project use. As good complements to use case texts, the visual diagram representations of use cases are also effective facilitating tools for the better understanding, communication and design of complex system behavioral requirements.
Examples[edit]
Below is a sample use case written with a slightly-modified version of the Cockburn-style template. Note that there are no buttons, controls, forms, or any other UI elements and operations in the basic use case description, where only user goals, subgoals or intentions are expressed in every step of the basic flow or extensions. This practice makes the requirement specification clearer, and maximizes the flexibility of the design and implementations.
Use Case: Edit an article
Primary Actor: Member (Registered User)
Scope: a Wiki system
Level: ! (User goal or sea level)
Brief: (equivalent to a user story or an epic)
The member edits any part (the entire article or just a section) of an article he/she is reading. Preview and changes comparison are allowed during the editing.
Stakeholders
...
Postconditions
Minimal Guarantees:
Success Guarantees:
The article is saved and an updated view is shown.
An edit record for the article is created by the system, so watchers of the article can be informed of the update later.
Preconditions:
The article with editing enabled is presented to the member.
Triggers:
The member invokes an edit request (for the full article or just one section) on the article.
Basic flow:
The system provides a new editor area/box filled with all the article's relevant content with an informative edit summary for the member to edit. If the member just wants to edit a section of the article, only the original content of the section is shown, with the section title automatically filled out in the edit summary.
The member modifies the article's content till satisfied.
The member fills out the edit summary, tells the system if he/she wants to watch this article, and submits the edit.
The system saves the article, logs the edit event and finishes any necessary post processing.
The system presents the updated view of the article to the member.
Extensions:
2-3.
a. Show preview:
The member selects Show preview which submits the modified content.
The system reruns step 1 with addition of the rendered updated content for preview, and informs the member that his/her edits have not been saved yet, then continues.
b. Show changes:
The member selects Show changes which submits the modified content.
The system reruns step 1 with addition of showing the results of comparing the differences between the current edits by the member and the most recent saved version of the article, then continues.
c. Cancel the edit:
The member selects Cancel.
The system discards any change the member has made, then goes to step 5.
4a. Timeout:
...
Advantages[edit]
Since the inception of the agile movement, the user story technique from Extreme Programming has been so popular that many think it is the only and best solution for agile requirements of all projects. Alistair Cockburn lists five reasons why he still writes use cases in agile development.[15]
The list of goal names provides the shortest summary of what the system will offer (even than user stories). It also provides a project planning skeleton, to be used to build initial priorities, estimates, team allocation and timing.
The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do and what it will not do. It provides the context for each specific line item requirement (e.g. fine-grained user stories), a context that is very hard to get anywhere else.
The extension conditions of each use case provide a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look ahead mechanism, so the stakeholders can spot issues that are likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule, so that the answers can be ready when the development team gets around to working on them.
The use case extension scenario fragments provide answers to the many detailed, often tricky and ignored business questions: “What are we supposed to do in this case?” It is a thinking/documentation framework that matches the if…then…else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time.
The full use case set shows that the investigators have thought through every user’s needs, every goal they have with respect to the system, and every business variant involved.
In summary, specifying system requirements in use cases has these apparent benefits comparing with traditional or other approaches:
User focused
Use cases constitute a powerful, user-centric tool for the software requirements specification process.[16] Use case modeling typically starts from identifying key stakeholder roles (actors) interacting with the system, and their goals or objectives the system must fulfill (an outside perspective). These user goals then become the ideal candidates for the names or titles of the use cases which represent the desired functional features or services provided by the system. This user-centered approach ensure that what has the real business value and the user really want is developed, not those trivial functions speculated from a developer or system (inside) perspective.
Use case authoring has been an important and valuable analysis tool in the domain of User-Centered Design (UCD) for years.
Better communication
Use cases are often written in natural languages with structured templates. This narrative textual form (legible requirement stories), understandable by almost everyone, complemented by visual UML diagrams foster better and deeper communications among all stakeholders, including customers, end-users, developers, testers and managers. Better communications result in quality requirements and thus quality systems delivered.
Quality requirements by structured exploration
One of the most powerful things about use cases reside in the formats of the use case templates, especially the main success scenario (basic flow) and the extension scenario fragments (extensions, exceptional and/or alternative flows). Analyzing a use case step by step from preconditions to postconditions, exploring and investigating every action step of the use case flows, from basic to extensions, to identify those tricky, normally hidden and ignored, seemingly trivial but realistically often costly requirements (as Cockburn mentioned above), is a structured and beneficial way to get clear, stable and quality requirements systematically.
Minimizing and optimizing the action steps of a use case to achieve the user goal also contribute to a better interaction design and user experience of the system.
Facilitate testing and user documentation
With content based upon an action or event flow structure, a model of well-written use cases also serves as an excellent groundwork and valuable guidelines for the design of test cases and user manuals of the system or product, which is an effort-worthy investment up-front. There is obvious connections between the flow paths of a use case and its test cases. Deriving functional test cases from a use case through its scenarios (running instances of a use case) is straightforward.[17]
Limitations[edit]
Limitations of use cases include:
Use cases are not well suited to capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere.
As there are no fully standard definitions of use cases, each project must form its own interpretation.
Some use case relationships, such as extends, are ambiguous in interpretation and can be difficult for stakeholders to understand as pointed out by Cockburn (Problem #6)[18][citation needed]
Use case developers often find it difficult to determine the level of user interface (UI) dependency to incorporate in a use case. While use case theory suggests that UI not be reflected in use cases, it can be awkward to abstract out this aspect of design, as it makes the use cases difficult to visualize. In software engineering, this difficulty is resolved by applying requirements traceability, for example with a traceability matrix. Another approach to associate UI elements with use cases, is to attach a UI design to each step in the use case. This is called a use case storyboard.
Use cases can be over-emphasized. Bertrand Meyer discusses issues such as driving system design too literally from use cases, and using use cases to the exclusion of other potentially valuable requirements analysis techniques.[19]
Use cases are a starting point for test design,[20] but since each test needs its own success criteria, use cases may need to be modified to provide separate post-conditions for each path.[21]
Though use cases include goals and contexts, whether these goals and motivations behind the goals (stakeholders concerns and their assessments including non-interaction) conflict or negatively/positively affect other system goals are subject of goal oriented requirement modelling techniques (such as BMM, I*, KAOS and ArchiMate ARMOR).
Misconceptions[edit]
This section needs expansion. You can help by adding to it. (July 2015)
Common misunderstandings about use cases are:
User stories are agile; use cases are not.
Agile and Scrum are neutral on requirement techniques. As the Scrum Primer[22] states,
Product Backlog items are articulated in any way that is clear and sustainable. Contrary to popular misunderstanding, the Product Backlog does not contain "user stories"; it simply contains items. Those items can be expressed as user stories, use cases, or any other requirements approach that the group finds useful. But whatever the approach, most items should focus on delivering value to customers.
Use cases are mainly diagrams.
Craig Larman stresses that "use cases are not diagrams, they are text".[23]
Use cases have too much UI-related content.
As some put it,
Use cases will often contain a level of detail (i.e. naming of labels and buttons) which make it not well suited for capturing the requirements for a new system from scratch.
Novice misunderstandings. Each step of a well-written use case should present actor goals or intentions (the essence of functional requirements), and normally it should not contain any user interface details, e.g. naming of labels and buttons, UI operations etc., which is a bad practice and will unnecessarily complicate the use case writing and limit its implementation.
As for capturing requirements for a new system from scratch, use case diagrams plus use case briefs are often used as handy and valuable tools, at least as lightweight as user stories.
Writing use cases for large systems is tedious and a waste of time.
As some put it,
The format of the use case makes it difficult to describe a large system (e.g. CRM system) in less than several hundred pages. It is time consuming and you will find yourself spending time doing an unnecessary amount of rework.
Spending much time in writing tedious use cases which add no or little value and result in a lot of rework is a bad smell indicating that the writers are not well skilled and have little knowledge of how to write quality use cases both efficiently and effectively. Use cases should be authored in an iterative, incremental and evolutionary (agile) way. Applying use case templates does not mean that all the fields of a use case template should be used and filled out comprehensively from up-front or during a special dedicated stage, i.e. the requirement phase in the traditional waterfall development model.
In fact, the use case formats formulated by those popular template styles, e.g. the RUP's and the Cockburn's (also adopted by the OUM method) etc., have been proved in practice as valuable and helpful tools for capturing, analyzing and documenting complex requirements of large systems. The quality of a good use case documentation (model) should not be judged largely or only by its size. It is possible as well that a quality and comprehensive use case model of a large system may finally evolve into hundreds of pages mainly because of the inherent complexity of the problem in hand, not because of the poor writing skills of its authors.
Tools[edit]
This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (August 2013) (Learn how and when to remove this template message)
Text editors and/or word processors with template support are often used to write use cases. For large and complex system requirements, dedicated use case tools are helpful.
Some of the well-known use case tools include:
CaseComplete
Enterprise Architect
MagicDraw
Rational Software's RequisitePro - one of the early, well-known use case and requirement management tools in the 1990s.
objectiF and objectiF RM developed by microTOOL.
Wiki software - good tools for teams to author and manage use cases collaboratively.
Most UML tools support both the text writing and visual modeling of use cases.
See also[edit]
Software Testing portal
Abuse case
Business case
Event partitioning
Feature
List of UML tools
Misuse case
Requirement
Requirements elicitation
Scenario
Storyboard
Test Case
Use Case Points
References[edit]
Jump up ^ Jacobson Ivar, Christerson Magnus, Jonsson Patrik, Övergaard Gunnar, Object-Oriented Software Engineering - A Use Case Driven Approach, Addison-Wesley, 1992.
Jump up ^ "Alistair Cockburn, "Use cases, ten years later"". Alistair.cockburn.us. 2002. Retrieved 2013-04-17.
Jump up ^ Jacobson, Ivar; Spence, Ian; Bittner, Kurt (December 2011). "Use Case 2.0: The Guide to Succeeding with Use Cases". Ivar Jacobson International. Retrieved 2014-05-05.
Jump up ^ "Business Analysis Conference Europe 2011 - 26-28 September 2011, London, UK". Irmuk.co.uk. Retrieved 2013-04-17.
Jump up ^ Cockburn, 2001. Inside front cover. Icons "Design Scope".
Jump up ^ Suzanne Robertson. Scenarios in Requirements Discovery. Chapter 3 in Alexander and Maiden, 2004. Pages 39-59.
Jump up ^ Cockburn, 2001. Inside front cover. Icons "Goal Level".
^ Jump up to: a b c d e f g h Fowler, 2004.
^ Jump up to: a b Cockburn, 2001. Page 120.
Jump up ^ Cockburn, 2001. Inside rear cover. Field "Use Case Title".
Jump up ^ Alexander and Beus-Dukic, 2009. Page 121
^ Jump up to: a b c d Cockburn, 2001. Page 53.
Jump up ^ Cockburn, 2001. Page 55.
^ Jump up to: a b Alexander and Beus-Dukic, 2009. Page 39.
Jump up ^ Cockburn, Alistair (2008-01-09). "Why I still use use cases". alistair.cockburn.us.
Jump up ^ Karl Wiegers (March 1997). "Listening to the Customer's Voice". Process Impact. Software Development.
Jump up ^ Peter Zielczynski (May 2006). "Traceability from Use Cases to Test Cases". IBM developerWorks.
Jump up ^ http://alistair.cockburn.us/Structuring+use+cases+with+goals
Jump up ^ Meyer, 2000. (page needed)
Jump up ^ Armour and Miller, 2000. (page needed)
Jump up ^ Denney, 2005. (page needed)
Jump up ^ Pete Deemer; Gabrielle Benefield; Craig Larman; Bas Vodde (2012-12-17). "The Scrum Primer: A Lightweight Guide to the Theory and Practice of Scrum (Version 2.0)". InfoQ.
Jump up ^ Larman, Craig. Applying UML and patterns. Prentice Hall. pp. 63–64. ISBN 0-13-148906-2.
Further reading[edit]
Alexander, Ian, and Beus-Dukic, Ljerka. Discovering Requirements: How to Specify Products and Services. Wiley, 2009.
Alexander, Ian, and Maiden, Neil. Scenarios, Stories, Use Cases. Wiley 2004.
Armour, Frank, and Granville Miller. Advanced Use Case Modeling: Software Systems. Addison-Wesley, 2000.
Kurt Bittner, Ian Spence, Use Case Modeling, Addison-Wesley Professional, Aug 20, 2002.
Cockburn, Alistair. Writing Effective Use Cases. Addison-Wesley, 2001.
Larry Constantine, Lucy Lockwood, Software for Use: A Practical Guide to the Essential Models and Methods of Usage-Centered Design, Addison-Wesley, 1999.
Denney, Richard. Succeeding with Use Cases: Working Smart to Deliver Quality. Addison-Wesley, 2005.
Fowler, Martin. UML Distilled (Third Edition). Addison-Wesley, 2004.
Jacobson Ivar, Christerson M., Jonsson P., Övergaard G., Object-Oriented Software Engineering - A Use Case Driven Approach, Addison-Wesley, 1992.
Jacobson Ivar, Spence I., Bittner K. Use Case 2.0: The Guide to Succeeding with Use Cases, IJI SA, 2011.
Dean Leffingwell, Don Widrig, Managing Software Requirements: A Use Case Approach, Addison-Wesley Professional. Dec 7, 2012.
Kulak, Daryl, and Eamonn Guiney. Use cases: requirements in context. Addison-Wesley, 2012.
Meyer, Bertrand. Object Oriented Software Construction. (2nd edition). Prentice Hall, 2000.
Schneider, Geri and Winters, Jason P. Applying Use Cases 2nd Edition: A Practical Guide. Addison-Wesley, 2001.
Wazlawick, Raul S. Object-Oriented Analysis and Design for Information Systems: Modeling with UML, OCL, and IFML. Morgan Kaufmann, 2014.
External links[edit]
Alistair Cockburn's use case column
Use Cases (Usability.gov)
Basic Use Case Template by Alistair Cockburn
Application of use cases for stakeholder analysis "Project Icarus: Stakeholder Scenarios for an Interstellar Exploration Program", JBIS, 64, 224-233
"An Academic Survey on the Role of Use Cases in the UML"
Search use case in IBM developerWorks
[show]
v
t
e
Unified Modeling Language
Actors
Organizations
Object Management Group
UML Partners
Persons
Grady Booch
Ivar Jacobson
James Rumbaugh
Concepts
Object oriented
Object-oriented programming
Object-oriented analysis and design
Object-oriented modeling
Structure
Actor
Attribute
Artifact
Class
Component
Interface
Object
Package
Profile diagram
Behavior
Activity
Event
Message
Method
State
Use case
Relationships
Aggregation
Association
Composition
Dependency
Generalization (or Inheritance)
Extensibility
Profile
Stereotype
Other
Multiplicity
Diagrams
Structure
Class
Component
Composite structure
Deployment
Object
Package
Behaviour
Activity
State Machine
Use case
Interaction
Communications
Sequence
Interaction overview
Timing
Derived languages
Systems Modeling Language (SysML)
UML eXchange Format (UXF)
XML Metadata Interchange (XMI)
Executable UML (xUML)
Other topics
Glossary of UML terms
Rational Unified Process
List of Unified Modeling Language tools
Object Modeling in Color
[show]
v
t
e
Software engineering
Fields
Computer programming
Requirements engineering
Software deployment
Software design
Software maintenance
Software testing
Systems analysis
Formal methods
Concepts
Data modeling
Enterprise architecture
Functional specification
Modeling language
Orthogonality
Programming paradigm
Software
Software archaeology
Software architecture
Software configuration management
Software development methodology
Software development process
Software quality
Software quality assurance
Software verification and validation
Structured analysis
Orientations
Agile
Aspect-oriented
Object orientation
Ontology
Service orientation
SDLC
Models
Developmental
Agile
EUP
Executable UML
Incremental model
Iterative model
Prototype model
RAD
UP
Scrum
Spiral model
V-Model
Waterfall model
XP
Other
SPICE
CMMI
Data model
ER model
Function model
Information model
Metamodeling
Object model
Systems model
View model
Languages
IDEF
UML
USL
SysML
Software
engineers
Victor Basili
Kent Beck
Grady Booch
Fred Brooks
Barry Boehm
Peter Chen
Danese Cooper
Ward Cunningham
Tom DeMarco
Edsger W. Dijkstra
Delores M. Etter
Martin Fowler
Adele Goldstine
Margaret Hamilton
C. A. R. Hoare
Lois Haibt
Mary Jean Harrold
Grace Hopper
Watts Humphrey
Michael A. Jackson
Ivar Jacobson
Alan Kay
Nancy Leveson
Stephen J. Mellor
Bertrand Meyer
David Parnas
Trygve Reenskaug
Winston W. Royce
James Rumbaugh
Mary Shaw
Peri Tarr
Elaine Weyuker
Niklaus Wirth
Edward Yourdon
Related fields
Computer science
Computer engineering
Project management
Risk management
Systems engineering
Category
Commons
Retrieved from "https://en.wikipedia.org/w/index.php?title=Use_case&oldid=818212369"
Categories:
Software project management
Software requirements
Unified Modeling Language
Systems Modeling Language
1986 establishments in Sweden
1986 in computer science
Swedish inventions
Agile software development
Hidden categories:
Use dmy dates from April 2011
Wikipedia articles needing factual verification from May 2014
All articles with unsourced statements
Articles with unsourced statements from March 2016
Articles to be expanded from July 2015
All articles to be expanded
Articles using small message boxes
Articles with unsourced statements from October 2013
Articles needing additional references from August 2013
All articles needing additional references
Navigation menu
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
Namespaces
Article
Talk
Variants
Views
Read
Edit
View history
More
Search
Navigation
Main page
Contents
Featured content
Current events
Random article
Donate to Wikipedia
Wikipedia store
Interaction
Help
About Wikipedia
Community portal
Recent changes
Contact page
Tools
What links here
Related changes
Upload file
Special pages
Permanent link
Page information
Wikidata item
Cite this page
Print/export
Create a book
Download as PDF
Printable version
Languages
Afrikaans
العربية
Català
Čeština
Dansk
Deutsch
Español
فارسی
Français
한국어
Italiano
עברית
Nederlands
日本語
Norsk
Polski
Português
Русский
Shqip
Slovenčina
Suomi
Svenska
Türkçe
Українська
Tiếng Việt
中文
Edit links
This page was last edited on 2 January 2018, at 07:19.
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
Privacy policy
About Wikipedia
Disclaimers
Contact Wikipedia
Developers
Cookie statement
Mobile view
Enable previews

value: mw-page-base noprint

value: mw-head-base noprint

value: firstHeading firstHeading en

value: siteSub noprint

value: jump-to-nav mw-jump

tag: th

tag: li

value:
/wiki/Software_development_methodology
mw-redirect
Software development methodology

value:
/wiki/Model-driven_development
mw-redirect
Model-driven development

value:
/wiki/Scaled_Agile_Framework
mw-redirect
Scaled Agile Framework

value:
/wiki/Continuous_Integration
mw-redirect
Continuous Integration

value:
/wiki/Continuous_Delivery
mw-redirect
Continuous Delivery

value:
/wiki/Pair_Programming
mw-redirect
Pair Programming

value: Template talk:Software development process

value: float:right;clear:right;width:22.0em;margin:0 0 1.0em 1.0em;background:#f9f9f9;border:1px solid #aaa;padding:0.2em;border-spacing:0.4em 0;text-align:center;line-height:1.4em;font-size:88%

value:
/wiki/Requirement_analysis
mw-redirect
Requirement analysis

value:
/wiki/Functional_requirements
mw-redirect
Functional requirements

value: Quotation needed from source to verify. (May 2014)

value: This claim needs references to reliable sources. (March 2016)

value:
noprint Inline-Template Template-Fact
white-space:nowrap;

attr: alt src width height data-file-width data-file-height

value: plainlinks metadata ambox mbox-small-left ambox-content

value:
/wiki/Use_Case_Diagram
mw-redirect
Use Case Diagram

value:
plainlist
padding:0 0.1em 0.4em;text-align:left

value: Timing diagram (Unified Modeling Language)

value:
/wiki/System_Sequence_Diagram
mw-redirect
System Sequence Diagram

value:
/wiki/Extreme_Programming
mw-redirect
Extreme Programming

value:
/wiki/Agile_development
mw-redirect
Agile development

value:
/wiki/Non-functional_requirements
mw-redirect
Non-functional requirements

value: This claim needs references to reliable sources. (October 2013)

value:
/wiki/Scrum_(development)
mw-redirect
Scrum (development)

value: Help:Introduction to referencing with Wiki Markup/1

value: plainlinks metadata ambox ambox-content ambox-Unreferenced

value:
/wiki/List_of_UML_tools
mw-redirect
List of UML tools

value:
/wiki/Portal:Software_Testing
mw-redirect
Portal:Software Testing

value: display:table-cell;padding:0.2em 0.2em 0.2em 0.3em;vertical-align:middle

value: margin:0.5em 0 0.5em 1em;border:solid #aaa 1px

value: Ian Spence (software engineer) (page does not exist)

value:
nofollow
http://www.irmuk.co.uk/BA2011/
external text

value: -moz-column-width: 40em; -webkit-column-width: 40em; column-width: 40em; list-style-type: decimal;

value:
nofollow
external text
http://alistair.cockburn.us/Use+cases

value:
nofollow
https://www.uleth.ca/survey/uml/
external text

value:
navbox-image
5
width:1px;padding:0px 0px 0px 2px

value: Glossary of Unified Modeling Language terms

value: nowraplinks collapsible autocollapse navbox-inner

value: nowraplinks hlist collapsible autocollapse navbox-inner

value: Category:Wikipedia articles needing factual verification from May 2014

value: Category:All articles with unsourced statements

value: Category:Articles with unsourced statements from March 2016

value: Category:Articles to be expanded from July 2015

value: Category:Articles using small message boxes

value: Category:Articles with unsourced statements from October 2013

value: Category:Articles needing additional references from August 2013

value: Category:All articles needing additional references

value: Discussion about edits from this IP address [ctrl-alt-n]

value: A list of edits made from this IP address [ctrl-alt-y]

value: You are encouraged to create an account and log in; however, it is not mandatory

value: You're encouraged to log in; however, it's not mandatory. [ctrl-alt-o]

value:
/wiki/Use_case
View the content page [ctrl-alt-c]
c

value: Discussion about the content page [ctrl-alt-t]

value:
/w/index.php?title=Use_case&action=edit
Edit this page [ctrl-alt-e]
e

value: About the project, what you can do, where to find things

value: A list of recent changes in the wiki [ctrl-alt-r]

value: portal navigation p-interaction p-interaction-label

value: List of all English Wikipedia pages containing links to this page [ctrl-alt-j]

value: Recent changes in pages linked from this page [ctrl-alt-k]

value:
/wiki/Wikipedia:File_Upload_Wizard
Upload files [ctrl-alt-u]
u

value: A list of all special pages [ctrl-alt-q]

value: Permanent link to this revision of the page

value: Link to connected data repository item [ctrl-alt-g]

value: Printable version of this page [ctrl-alt-p]

value:
uls-settings-trigger
Language settings
0
button
true

value: حالة الاستخدام (هندسة البرمجيات) – Arabic

value:
https://da.wikipedia.org/wiki/Use_case
Use case – Danish
da
da
interlanguage-link-target

value: مورد استفاده – Persian

value: 유스 케이스 – Korean

value: תרחיש שימוש – Hebrew

value:
https://nl.wikipedia.org/wiki/Use_case
Use case – Dutch
nl
nl
interlanguage-link-target

value: Сценарий использования – Russian

value:
https://sq.wikipedia.org/wiki/Use_case
Use case – Albanian
sq
sq
interlanguage-link-target

value: Сценарій використання – Ukrainian

value:
https://vi.wikipedia.org/wiki/Use_case
Use case – Vietnamese
vi
vi
interlanguage-link-target

value: mediawiki ltr sitedir-ltr mw-hide-empty-elt ns-0 ns-subject page-Use_case rootpage-Use_case skin-vector action-view


text:
Metallic bonding
From Wikipedia, the free encyclopedia
Jump to: navigation, search
Types of radii
Atomic radius
Ionic radius
Covalent radius
Metallic radius
Van der Waals radius
v
t
e
Metallic bonding is a type of chemical bonding that arises from the electrostatic attractive force between conduction electrons (in the form of an electron cloud of delocalized electrons) and positively charged metal ions. It may be described as the sharing of free electrons among a lattice of positively charged ions (cations). Metallic bonding accounts for many physical properties of metals, such as strength, ductility, thermal and electrical resistivity and conductivity, opacity, and luster.[1][2][3][4]
Metallic bonding is not the only type of chemical bonding a metal can exhibit, even as a pure substance. For example, elemental gallium consists of covalently-bound pairs of atoms in both liquid and solid state—these pairs form a crystal lattice with metallic bonding between them. Another example of a metal–metal covalent bond is mercurous ion (Hg2+
2).
Contents
[hide]
1 History
2 The nature of metallic bonding
2.1 In 2D
2.2 In 3D
2.3 Electron deficiency and mobility
3 Metallic radius
4 Strength of the bond
5 Solubility and compound formation
6 Localization and clustering: from bonding to bonds
7 Optical properties
8 See also
9 References
History[edit]
This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (October 2009) (Learn how and when to remove this template message)
As chemistry developed into a science it became clear that metals formed the large majority of the periodic table of the elements and great progress was made in the description of the salts that can be formed in reactions with acids. With the advent of electrochemistry, it became clear that metals generally go into solution as positively charged ions and the oxidation reactions of the metals became well understood in the electrochemical series. A picture emerged of metals as positive ions held together by an ocean of negative electrons.
With the advent of quantum mechanics, this picture was given more formal interpretation in the form of the free electron model and its further extension, the nearly free electron model. In both of these models, the electrons are seen as a gas traveling through the lattice of the solid with an energy that is essentially isotropic in that it depends on the square of the magnitude, not the direction of the momentum vector k. In three-dimensional k-space, the set of points of the highest filled levels (the Fermi surface) should therefore be a sphere. In the nearly free correction of the model, box-like Brillouin zones are added to k-space by the periodic potential experienced from the (ionic) lattice, thus mildly breaking the isotropy.
The advent of X-ray diffraction and thermal analysis made it possible to study the structure of crystalline solids, including metals and their alloys, and the construction of phase diagrams became accessible. Despite all this progress, the nature of intermetallic compounds and alloys largely remained a mystery and their study was often empirical. Chemists generally steered away from anything that did not seem to follow Dalton's laws of multiple proportions and the problem was considered the domain of a different science, metallurgy.
The almost-free electron model was eagerly taken up by some researchers in this field, notably Hume-Rothery, in an attempt to explain why certain intermetallic alloys with certain compositions would form and others would not. Initially his attempts were quite successful. His idea was to add electrons to inflate the spherical Fermi-balloon inside the series of Brillouin-boxes and determine when a certain box would be full. This indeed predicted a fairly large number of observed alloy compositions. Unfortunately, as soon as cyclotron resonance became available and the shape of the balloon could be determined, it was found that the assumption that the balloon was spherical did not hold at all, except perhaps in the case of caesium. This reduced many of the conclusions to examples of how a model can sometimes give a whole series of correct predictions, yet still be wrong.
The free-electron debacle showed researchers that the model assuming that the ions were in a sea of free electrons needed modification, and so a number of quantum mechanical models such as band structure calculations based on molecular orbitals or the density functional theory were developed. In these models, one either departs from the atomic orbitals of neutral atoms that share their electrons or (in the case of density functional theory) departs from the total electron density. The free-electron picture has, nevertheless, remained a dominant one in education.
The electronic band structure model became a major focus not only for the study of metals but even more so for the study of semiconductors. Together with the electronic states, the vibrational states were also shown to form bands. Rudolf Peierls showed that, in the case of a one-dimensional row of metallic atoms, say hydrogen, an instability had to arise that would lead to the breakup of such a chain into individual molecules. This sparked an interest in the general question: When is collective metallic bonding stable and when will a more localized form of bonding take its place? Much research went into the study of clustering of metal atoms.
As powerful as the concept of the band structure proved to be in the description of metallic bonding, it does have a drawback. It remains a one-electron approximation to a multitudinous many-body problem. In other words, the energy states of each electron are described as if all the other electrons simply form a homogeneous background. Researchers like Mott and Hubbard realized that this was perhaps appropriate for strongly delocalized s- and p-electrons but for d-electrons, and even more for f-electrons the interaction with electrons (and atomic displacements) in the local environment may become stronger than the delocalization that leads to broad bands. Thus, the transition from localized unpaired electrons to itinerant ones partaking in metallic bonding became more comprehensible.
The nature of metallic bonding[edit]
The combination of two phenomena gives rise to metallic bonding: delocalization of electrons and the availability of a far larger number of delocalized energy states than of delocalized electrons.[clarification needed] The latter could be called electron deficiency.
In 2D[edit]
Graphene is an example of two-dimensional metallic bonding. Its metallic bonds are similar to aromatic bonding in benzene, naphthalene, anthracene, ovalene, and so on.
In 3D[edit]
Metal aromaticity in metal clusters is another example of delocalization, this time often in three-dimensional entities. Metals take the delocalization principle to its extreme and one could say that a crystal of a metal represents a single molecule over which all conduction electrons are delocalized in all three dimensions. This means that inside the metal one can generally not distinguish molecules, so that the metallic bonding is neither intra- nor intermolecular. 'Nonmolecular' would perhaps be a better term. Metallic bonding is mostly non-polar, because even in alloys there is little difference among the electronegativities of the atoms participating in the bonding interaction (and, in pure elemental metals, none at all). Thus, metallic bonding is an extremely delocalized communal form of covalent bonding. In a sense, metallic bonding is not a 'new' type of bonding at all, therefore, and it describes the bonding only as present in a chunk of condensed matter, be it crystalline solid, liquid, or even glass. Metallic vapors by contrast are often atomic (Hg) or at times contain molecules like Na2 held together by a more conventional covalent bond. This is why it is not correct to speak of a single 'metallic bond'.[clarification needed]
The delocalization is most pronounced for s- and p-electrons. For caesium it is so strong that the electrons are virtually free from the caesium atoms to form a gas constrained only by the surface of the metal. For caesium, therefore, the picture of Cs+ ions held together by a negatively charged electron gas is not too inaccurate.[5] For other elements the electrons are less free, in that they still experience the potential of the metal atoms, sometimes quite strongly. They require a more intricate quantum mechanical treatment (e.g., tight binding) in which the atoms are viewed as neutral, much like the carbon atoms in benzene. For d- and especially f-electrons the delocalization is not strong at all and this explains why these electrons are able to continue behaving as unpaired electrons that retain their spin, adding interesting magnetic properties to these metals.
Electron deficiency and mobility[edit]
Metal atoms contain few electrons in their valence shells relative to their periods or energy levels. They are electron deficient elements and the communal sharing does not change that. There remain far more available energy states than there are shared electrons. Both requirements for conductivity are therefore fulfilled: strong delocalization and partly filled energy bands. Such electrons can therefore easily change from one energy state into a slightly different one. Thus, not only do they become delocalized, forming a sea of electrons permeating the lattice, but they are also able to migrate through the lattice when an external electrical field is imposed, leading to electrical conductivity. Without the field, there are electrons moving equally in all directions. Under the field, some will adjust their state slightly, adopting a different wave vector. As a consequence, there will be more moving one way than the other and a net current will result.
The freedom of conduction electrons to migrate also give metal atoms, or layers of them, the capacity to slide past each other. Locally, bonds can easily be broken and replaced by new ones after the deformation. This process does not affect the communal metallic bonding very much. This gives rise to metals' typical characteristic phenomena of malleability and ductility. This is particularly true for pure elements. In the presence of dissolved impurities, the defects in the lattice that function as cleavage points may get blocked and the material becomes harder. Gold, for example, is very soft in pure form (24-karat), which is why alloys of 18-karat or lower are preferred in jewelry.
Metals are typically also good conductors of heat, but the conduction electrons only contribute partly to this phenomenon. Collective (i.e., delocalized) vibrations of the atoms known as phonons that travel through the solid as a wave, contribute strongly.
However, the latter also holds for a substance like diamond. It conducts heat quite well but not electricity. The latter is not a consequence of the fact that delocalization is absent in diamond, but simply that carbon is not electron deficient. The electron deficiency is an important point in distinguishing metallic from more conventional covalent bonding. Thus, we should amend the expression given above into: Metallic bonding is an extremely delocalized communal form of electron deficient[6] covalent bonding.
Metallic radius[edit]
Metallic radius is defined as one-half of the distance between the two adjacent metal ions in the metallic lattice. This radius depends on the nature of the atom as well as its environment—specifically, on the coordination number (CN), which in turn depends on the temperature and applied pressure.
When comparing periodic trends in the size of atoms it is often desirable to apply so-called Goldschmidt correction, which converts the radii to the values the atoms would have if they were 12-coordinated. Since metallic radii are always biggest for the highest coordination number, correction for less dense coordinations involves multiplying by x, where 0 < x < 1. Specifically, for CN = 4, x = 0.88; for CN = 6, x = 0.96, and for CN = 8, x = 0.97. The correction is named after Victor Goldschmidt who obtained the numerical values quoted above.[7]
The radii follow general periodic trends: they decrease across the period due to increase in the effective nuclear charge, which is not offset by the increased number of valence electrons. The radii also increase down the group due to increase in principal quantum number. Between rows 3 and 4, the lanthanide contraction is observed – there is very little increase of the radius down the group due to the presence of poorly shielding f orbitals.
Strength of the bond[edit]
This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (September 2014) (Learn how and when to remove this template message)
The atoms in metals have a strong attractive force between them. Much energy is required to overcome it. Therefore, metals often have high boiling points, with tungsten (5828 K) being extremely high. A remarkable exception are the elements of the zinc group: Zn, Cd, and Hg. Their electron configuration ends in ...ns2 and this comes to resemble a noble gas configuration like that of helium more and more when going down in the periodic table because the energy distance to the empty np orbitals becomes larger. These metals are therefore relatively volatile, and are avoided in ultra-high vacuum systems.
Otherwise, metallic bonding can be very strong, even in molten metals, such as Gallium. Even though gallium will melt from the heat of one's hand just above room temperature, its boiling point is not far from that of copper. Molten gallium is therefore a very nonvolatile liquid thanks to its strong metallic bonding.
The strong bonding of metals in the liquid form demonstrates that the energy of a metallic bond is not a strong function of the direction of the metallic bond; this lack of bond directionality is a direct consequence of electron delocalization, and is best understood in contrast to the directional bonding of covalent bonds. The energy of a metallic bond is thus mostly a function of the number of electrons which surround the metallic atom, as exemplified by the Embedded atom model.[8] This typically results in metals assuming relatively simple, close-packed crystal structures, such as FCC, BCC, and HCP.
Given high enough cooling rates and appropriate alloy composition, metallic bonding can occur even in glasses with an amorphous structure.
Much biochemistry is mediated by the weak interaction of metal ions and biomolecules. Such interactions and their associated conformational change has been measured using dual polarisation interferometry.
Solubility and compound formation[edit]
Metals are insoluble in water or organic solvents unless they undergo a reaction with them. Typically this is an oxidation reaction that robs the metal atoms of their itinerant electrons, destroying the metallic bonding. However metals are often readily soluble in each other while retaining the metallic character of their bonding. Gold, for example, dissolves easily in mercury, even at room temperature. Even in solid metals, the solubility can be extensive. If the structures of the two metals are the same, there can even be complete solid solubility, as in the case of electrum, the alloys of silver and gold. At times, however, two metals will form alloys with different structures than either of the two parents. One could call these materials metal compounds, but, because materials with metallic bonding are typically not molecular, Dalton's law of integral proportions is not valid and often a range of stoichiometric ratios can be achieved. It is better to abandon such concepts as 'pure substance' or 'solute' is such cases and speak of phases instead. The study of such phases has traditionally been more the domain of metallurgy than of chemistry, although the two fields overlap considerably.
Localization and clustering: from bonding to bonds[edit]
The metallic bonding in complicated compounds does not necessarily involve all constituent elements equally. It is quite possible to have an element or more that do not partake at all. One could picture the conduction electrons flowing around them like a river around an island or a big rock. It is possible to observe which elements do partake, e.g., by looking at the core levels in an X-ray photoelectron spectroscopy (XPS) spectrum. If an element partakes, its peaks tend to be skewed.
Some intermetallic materials e.g. do exhibit metal clusters, reminiscent of molecules and these compounds are more a topic of chemistry than of metallurgy. The formation of the clusters could be seen as a way to 'condense out' (localize) the electron deficient bonding into bonds of a more localized nature. Hydrogen is an extreme example of this form of condensation. At high pressures it is a metal. The core of the planet Jupiter could be said to be held together by a combination of metallic bonding and high pressure induced by gravity. At lower pressures however the bonding becomes entirely localized into a regular covalent bond. The localization is so complete that the (more familiar) H2 gas results. A similar argument holds for an element like boron. Though it is electron deficient compared to carbon, it does not form a metal. Instead it has a number of complicated structures in which icosahedral B12 clusters dominate. Charge density waves are a related phenomenon.
As these phenomena involve the movement of the atoms towards or away from each other, they can be interpreted as the coupling between the electronic and the vibrational states (i.e. the phonons) of the material. A different such electron-phonon interaction is thought to cause a very different result at low temperatures, that of superconductivity. Rather than blocking the mobility of the charge carriers by forming electron pairs in localized bonds, Cooper-pairs are formed that no longer experience any resistance to their mobility.
Optical properties[edit]
The presence of an ocean of mobile charge carriers has profound effects on the optical properties of metals. They can only be understood by considering the electrons as a collective rather than considering the states of individual electrons involved in more conventional covalent bonds.
Light consists of a combination of an electrical and a magnetic field. The electrical field is usually able to excite an elastic response from the electrons involved in the metallic bonding. The result is that photons are not able to penetrate very far into the metal and are typically reflected. They bounce off, although some may also be absorbed. This holds equally for all photons of the visible spectrum, which is why metals are often silvery white or grayish with the characteristic specular reflection of metallic luster. The balance between reflection and absorption determines how white or how gray they are, although surface tarnish can obscure such observations. Silver, a very good metal with high conductivity is one of the whitest.
Notable exceptions are reddish copper and yellowish gold. The reason for their color is that there is an upper limit to the frequency of the light that metallic electrons can readily respond to, the plasmon frequency. At the plasmon frequency, the frequency-dependent dielectric function of the free electron gas goes from negative (reflecting) to positive (transmitting); higher frequency photons are not reflected at the surface, and do not contribute to the color of the metal. There are some materials like indium tin oxide (ITO) that are metallic conductors (actually degenerate semiconductors) for which this threshold is in the infrared,[9] which is why they are transparent in the visible, but good mirrors in the IR.
For silver the limiting frequency is in the far UV, but for copper and gold it is closer to the visible. This explains the colors of these two metals. At the surface of a metal resonance effects known as surface plasmons can result. They are collective oscillations of the conduction electrons like a ripple in the electronic ocean. However, even if photons have enough energy they usually do not have enough momentum to set the ripple in motion. Therefore, plasmons are hard to excite on a bulk metal. This is why gold and copper still look like lustrous metals albeit with a dash of color. However, in colloidal gold the metallic bonding is confined to a tiny metallic particle, preventing the oscillation wave of the plasmon from 'running away'. The momentum selection rule is therefore broken, and the plasmon resonance causes an extremely intense absorption in the green with a resulting beautiful purple-red color. Such colors are orders of magnitude more intense than ordinary absorptions seen in dyes and the like that involve individual electrons and their energy states.
See also[edit]
Bonding in solids
Metal aromaticity
References[edit]
Jump up ^ Metallic bonding. chemguide.co.uk
Jump up ^ Metal structures. chemguide.co.uk
Jump up ^ Chemical Bonds. chemguide.co.uk
Jump up ^ PHYSICS 133 Lecture Notes Spring, 2004 Marion Campus. physics.ohio-state.edu
Jump up ^ If the electrons were truly free, their energy would only depend on the magnitude of their wave vector k, not its direction. That is in k-space, the Fermi level should form a perfect sphere. The shape of the Fermi level can be measured by cyclotron resonance and is never a sphere, not even for caesium, see:
Okumura, K. & Templeton, I. M. (1965). "The Fermi Surface of Caesium". Proceedings of the Royal Society of London A. 287 (1408): 89–104. Bibcode:1965RSPSA.287...89O. doi:10.1098/rspa.1965.0170. JSTOR 2415064.
Jump up ^ Electron deficiency is a relative term: it means fewer than half of the electrons needed to complete the next noble gas configuration. For example, lithium is electron deficient with respect to neon, but electron-rich with respect to the previous noble gas, helium.
Jump up ^ Shriver and Atkins' Inorganic Chemistry. Oxford University Press. 2010. pp. 74–. ISBN 978-0-19-923617-6.
Jump up ^ Daw, Murray S.; Foiles, Stephen M.; Baskes, Michael I. (1993). "The embedded-atom method: a review of theory and applications". Materials Science Reports. 9 (7–8): 251–310. doi:10.1016/0920-2307(93)90001-U.
Jump up ^ Brewer, Scott H.; Franzen, Stefan (2002). "Indium Tin Oxide Plasma Frequency Dependence on Sheet Resistance and Surface Adlayers Determined by Reflectance FTIR Spectroscopy". The Journal of Physical Chemistry B. 106 (50): 12986–12992. doi:10.1021/jp026600x.
[hide]
v
t
e
Chemical bonds
Intramolecular
(strong)
Covalent
By symmetry
Sigma (σ)
Pi (π)
Delta (δ)
Phi (φ)
By multiplicity
1 (single)
2 (double)
3 (triple)
4 (quadruple)
5 (quintuple)
6 (sextuple)
Miscellaneous
Agostic
Bent
Coordinate (dipolar)
Pi backbond
Charge-shift
Hapticity
Conjugation
Hyperconjugation
Antibonding
Resonant
Electron deficiency
3c–2e
4c–2e
Hypercoordination
3c–4e
Aromaticity
möbius
super
sigma
homo
bicyclo
spiro
σ-bishomo
spherical
Y-
Metallic
Metal aromaticity
Ionic
Intermolecular
(weak)
van der Waals
forces
London dispersion
Hydrogen
Low-barrier
Resonance-assisted
Symmetric
Dihydrogen bonds
C–H···O interaction
Noncovalent
other
Mechanical
Halogen
Chalcogen
Aurophilicity
Intercalation
Stacking
Cation–pi
Anion–pi
Salt bridge
Bond cleavage
Heterolysis
Homolysis
Authority control
GND: 4169574-4
Retrieved from "https://en.wikipedia.org/w/index.php?title=Metallic_bonding&oldid=830457145"
Categories:
Chemical bonding
Metals
Hidden categories:
Use dmy dates from July 2012
Articles needing additional references from October 2009
All articles needing additional references
Wikipedia articles needing clarification from January 2014
Articles needing additional references from September 2014
Wikipedia articles with GND identifiers
Navigation menu
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
Namespaces
Article
Talk
Variants
Views
Read
Edit
View history
More
Search
Navigation
Main page
Contents
Featured content
Current events
Random article
Donate to Wikipedia
Wikipedia store
Interaction
Help
About Wikipedia
Community portal
Recent changes
Contact page
Tools
What links here
Related changes
Upload file
Special pages
Permanent link
Page information
Wikidata item
Cite this page
Print/export
Create a book
Download as PDF
Printable version
In other projects
Wikibooks
Languages
العربية
Asturianu
Bân-lâm-gú
Български
Bosanski
Català
Čeština
Deutsch
Eesti
Ελληνικά
Español
فارسی
Français
한국어
Hrvatski
Bahasa Indonesia
Italiano
עברית
Қазақша
Kiswahili
Magyar
Македонски
Bahasa Melayu
Nederlands
日本語
Norsk
Norsk nynorsk
Occitan
ਪੰਜਾਬੀ
Polski
Português
Română
Русский
Shqip
Simple English
Slovenčina
Српски / srpski
Srpskohrvatski / српскохрватски
Suomi
Svenska
தமிழ்
ไทย
Türkçe
Українська
Tiếng Việt
文言
粵語
中文
39 more
Edit links
This page was last edited on 14 March 2018, at 23:11.
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
Privacy policy
About Wikipedia
Disclaimers
Contact Wikipedia
Developers
Cookie statement
Mobile view
Enable previews

tag: div

attr: id class

value: mw-page-base noprint

key: html

type: local

value: mw-head-base noprint

tag: a

attr: id class lang

value: firstHeading firstHeading en

value: siteSub noprint

value: jump-to-nav mw-jump

value: padding:0.2em 0.4em 0.2em;font-size:145%;line-height:1.2em;border-bottom:2px solid; background:#d3d3d3

tag: tr

attr: href title

attr: href class title

value:
/wiki/Metallic_radius
mw-redirect
Metallic radius

tag: ul

tag: td

attr: class style

value:
plainlist
padding:0 0.1em 0.4em

tag: abbr

value: float:right;clear:right;width:auto;margin:0 0 1.0em 1.0em;background:#f9f9f9;border:1px solid #aaa;padding:0.2em;border-spacing:0.4em 0;text-align:center;line-height:1.4em;font-size:88%

value:
/wiki/Conduction_electrons
mw-redirect
Conduction electrons

value:
/wiki/Physical_properties
mw-redirect
Physical properties

value:
/wiki/Crystal_lattice
mw-redirect
Crystal lattice

value:
/wiki/Mercurous_ion
mw-redirect
Mercurous ion

attr: alt src width height srcset data-file-width data-file-height

value: Help:Introduction to referencing with Wiki Markup/1

value: plainlinks metadata ambox ambox-content ambox-Unreferenced

value:
/wiki/Magnitude_(vector)
mw-redirect
Magnitude (vector)

value:
/wiki/X-ray_diffraction
mw-redirect
X-ray diffraction

value: Edit section: The nature of metallic bonding

value: The text near this tag may need clarification or removal of jargon. (January 2014)

value:
noprint Inline-Template
margin-left:0.1em; white-space:nowrap;

value:
/wiki/Metal_cluster
mw-redirect
Metal cluster

value: font-family: 'Georgia Pro', Georgia, 'DejaVu Serif', Times, 'Times New Roman', serif;

value:
/wiki/Nearly-free_electron_model
mw-redirect
Nearly-free electron model

value: Edit section: Electron deficiency and mobility

value:
/wiki/Carat_(purity)
mw-redirect
Carat (purity)

value:
/wiki/Valence_electrons
mw-redirect
Valence electrons

value:
/wiki/Electron_shielding
mw-redirect
Electron shielding

value:
/wiki/Atomic_orbitals
mw-redirect
Atomic orbitals

value:
/wiki/Metallic_glass
mw-redirect
Metallic glass

value:
/wiki/Dual_polarisation_interferometry
mw-redirect
Dual polarisation interferometry

value: Edit section: Solubility and compound formation

value:
/wiki/Solid_solubility
mw-redirect
Solid solubility

value: Edit section: Localization and clustering: from bonding to bonds

value:
/wiki/Plasmon_frequency
mw-redirect
Plasmon frequency

value:
/wiki/Momentum_space
mw-redirect
Momentum space

value:
nofollow
external text
//doi.org/10.1098%2Frspa.1965.0170

value:
nofollow
external text
//www.jstor.org/stable/2415064

value:
nofollow
external text
//doi.org/10.1021%2Fjp026600x

value:
reflist mw-references-wrap
list-style-type: decimal;

value:
/wiki/Mechanical_bond
mw-redirect
Mechanical bond

value: Salt bridge (protein and supramolecular)

value: nowraplinks collapsible autocollapse navbox-inner

value:
nofollow
external text
https://d-nb.info/gnd/4169574-4

value: Category:Articles needing additional references from October 2009

value: Category:All articles needing additional references

value: Category:Wikipedia articles needing clarification from January 2014

value: Category:Articles needing additional references from September 2014

value: Category:Wikipedia articles with GND identifiers

value: Discussion about edits from this IP address [ctrl-alt-n]

value: A list of edits made from this IP address [ctrl-alt-y]

value: You are encouraged to create an account and log in; however, it is not mandatory

value: You're encouraged to log in; however, it's not mandatory. [ctrl-alt-o]

value:
/wiki/Metallic_bonding
View the content page [ctrl-alt-c]
c

value: Discussion about the content page [ctrl-alt-t]

value: p-namespaces navigation vectorTabs p-namespaces-label

value:
p-variants
navigation
vectorMenu emptyPortlet
p-variants-label

value: Past revisions of this page [ctrl-alt-h]

value: p-views navigation vectorTabs p-views-label

value:
p-cactions
navigation
vectorMenu emptyPortlet
p-cactions-label

value:
mw-wiki-logo
/wiki/Main_Page
Visit the main page

value:
/wiki/Main_Page
Visit the main page [ctrl-alt-z]
z

value: Featured content – the best of Wikipedia

value: Find background information on current events

value:
/wiki/Special:Random
Load a random article [ctrl-alt-x]
x

value: portal navigation p-navigation p-navigation-label

value: Guidance on how to use and edit Wikipedia

value: About the project, what you can do, where to find things

value: portal navigation p-wikibase-otherprojects p-wikibase-otherprojects-label

value: رابطة فلزية – Arabic

value:
interlanguage-link interwiki-ast
display: none;

value:
interlanguage-link interwiki-zh-min-nan
display: none;

value: Метална връзка – Bulgarian

value:
interlanguage-link interwiki-bg
display: none;

value:
interlanguage-link interwiki-bs
display: none;

value:
interlanguage-link interwiki-ca
display: none;

value:
interlanguage-link interwiki-cs
display: none;

value:
interlanguage-link interwiki-et
display: none;

value: Μεταλλικός δεσμός – Greek

value:
interlanguage-link interwiki-el
display: none;

value: پیوند فلزی – Persian

value:
interlanguage-link interwiki-fa
display: none;

value:
interlanguage-link interwiki-ko
display: none;

value:
interlanguage-link interwiki-hr
display: none;

value:
interlanguage-link interwiki-it
display: none;

value: קשר מתכתי – Hebrew

value:
interlanguage-link interwiki-he
display: none;

value: Металдық байланыс – Kazakh

value:
interlanguage-link interwiki-kk
display: none;

value:
interlanguage-link interwiki-sw
display: none;

value:
interlanguage-link interwiki-hu
display: none;

value: Метална врска – Macedonian

value:
interlanguage-link interwiki-mk
display: none;

value:
interlanguage-link interwiki-nl
display: none;

value:
interlanguage-link interwiki-ja
display: none;

value:
interlanguage-link interwiki-no
display: none;

value:
interlanguage-link interwiki-nn
display: none;

value:
interlanguage-link interwiki-oc
display: none;

value: ਧਾਤਵੀ ਬੰਧਨ – Punjabi

value:
interlanguage-link interwiki-pa
display: none;

value:
interlanguage-link interwiki-pl
display: none;

value:
interlanguage-link interwiki-ro
display: none;

value: Металлическая связь – Russian

value:
interlanguage-link interwiki-sq
display: none;

value:
interlanguage-link interwiki-simple
display: none;

value:
interlanguage-link interwiki-sk
display: none;

value: Метална веза – Serbian

value:
interlanguage-link interwiki-sr
display: none;

value:
interlanguage-link interwiki-sh
display: none;

value:
interlanguage-link interwiki-fi
display: none;

value:
interlanguage-link interwiki-sv
display: none;

value: மாழைப் பிணைப்பு – Tamil

value:
interlanguage-link interwiki-ta
display: none;

value: พันธะโลหะ – Thai

value:
interlanguage-link interwiki-th
display: none;

value:
interlanguage-link interwiki-tr
display: none;

value: Металічний зв'язок – Ukrainian

value:
interlanguage-link interwiki-uk
display: none;

value:
interlanguage-link interwiki-vi
display: none;

value:
interlanguage-link interwiki-zh-yue
display: none;

value: All languages (initial selection from common choices by you and others)

value: /static/images/wikimedia-button-1.5x.png 1.5x, /static/images/wikimedia-button-2x.png 2x

value: /static/images/poweredby_mediawiki_132x47.png 1.5x, /static/images/poweredby_mediawiki_176x62.png 2x

value:
suggestions
display: none; font-size: 13px;

value: mediawiki ltr sitedir-ltr mw-hide-empty-elt ns-0 ns-subject page-Metallic_bonding rootpage-Metallic_bonding skin-vector action-view


text:
Not a Love Story (2011 film)
From Wikipedia, the free encyclopedia
Jump to: navigation, search
Not A Love Story
Theatrical release poster
Directed by
Ram Gopal Varma
Produced by
Nitish sharma
Shailesh R. Singh
Kiran Kumar Koneru
Story by
Nitish sharma
Starring
Mahie Gill
Deepak Dobriyal
Nitish sharma
Ajay Gehi
Music by
Sandeep Chowta
Cinematography
Harshraj Shroff , M.Ravichandra Thevar
Edited by
Abhijit Kokate,Vinay Chauhan,Jimmy Thomas
Distributed by
Bohra Bros Prod. Pvt. Ltd.
Release date
19 August 2011 (2011-08-19)
Running time
100 minutes
Country
India
Language
Hindi
Budget
80 lacs
Not A Love Story is a 2011 Indian crime-thriller film inspired by the gruesome murder of Neeraj Grover in 2008 that led to the arrest of M.L. Jerome and Maria Susairaj. Starring Mahie Gill, Deepak Dobriyal and Ajay Gehi and directed by Ram Gopal Varma, the film was released on 19 August 2011. Ram Gopal Varma has announced that the film is not a biopic but is inspired by the case.[1][2]
The film's shooting was completed in 20 days. One of the prime locations was the building Dheeraj Solitaire where Neeraj Grover was allegedly murdered in 2008.
Contents
[hide]
1 Cast
2 Music
3 Reception
3.1 Critical response
4 See also
5 References
6 External links
Cast[edit]
Mahie Gill as Anusha Chawla
Deepak Dobriyal as Robin Fernandes
Ajay Gehi as Ashish Bhatnagar
Zakir Hussain as Inspector Mane
Neil Bhoopalam as Prem
Darshan Jariwala as Anusha's lawyer
Ganesh Yadav as Robin's lawyer
Rasika Joshi as Ashish's mother
Prabhleen Sandhu as Anju
Urmila Matondkar as Item number
Mahesh Thakur as ad-film maker Sam in a guest role
Sandesh Jadhav as Inspector Chavan
Dimple Ghosh as Richa
Rakesh Kukreti as Prashant
Abhijeet Lahiri as Ashish's father
Nandita Puri as Anusha's mother
Vandana Sajnani as Apeksha, Director
Sushma Bhagwat as Robin's mother
Ashok Awasthi as Robin's father
Shankar Sachdev as Public Prosecutor
Kamal Adip as Judge
Rajesh Barsewal as watchman
Sandeep Bose as Kishen, Producer
Music[edit]
Yayi Re Yayi Re, Hoja Rangeela Re - Tarannum Mallik
Jab Se Mai Choti Thi - Sandeep Patil , Dharmaraj Bhatt
Yayi Re Yayi Re, Hoja Rangeela Re (Sad) - Tarannum Mallik
Jab Se Mai Choti Thi (Sad) - Sandeep Patil, Dharmaraj Bhatt
Woh Ek Pal Chhina Kal - Arijit datta, Neha Kakkar
Reception[edit]
Critical response[edit]
The critics' response has been positive to mixed. Taran Adarsh of Bollywood Hungama gave 4 stars out of 5.[3] Subhash K Jha gave 3.5 out of 5.[4] Kaveree Bamzai of India Today gave 3 out of 5.[5] Zee News gave 3 out of 5.[6] Raja Sen of Rediff rated it 1.5 out of 5, saying that it is a film made in bad taste.[7] Harish of Behindwoods rated it 2 out of 5 and said "Overall in the time of stylish filmmaking of no substance movies, RGV tries to differ but with such a wafer-thin but powerful plot-line, you expect the background music, editing and camera work to push it to greatness and that is where the movie falters."[8]
Mayank Shekhar of the Hindustan Times said "it delves deeper into neither the young dream-chasers of a scary celeb industry nor chilling procedurals of an infamous police case", and rated it 2 out of 5.[9] CNN-IBN's Rajeev Masand said "Not A Love Story' is not entirely unwatchable", rating it 2 out of 5, but asserted that it is the "most senseless movie made in Bollywood for a long time."[10] Nupur Barua of fullhyd.com rated it 6/10 and said you can watch the movie if you can digest, visually, blood, gore, violent sex, and constant shaky camera movement.[11]
See also[edit]
Bollywood portal
Neeraj Grover murder case
References[edit]
Jump up ^ Sandeep Chowta and RGV join forces again. IBN Live. 2011-05-10. Retrieved on 2011-07-04.
Jump up ^ "First look of 'Not a love story'". The Indian Express. 2 July 2011. Retrieved 3 July 2011.
Jump up ^ Taran Adarsh (19 August 2011). "Not A Love Story Review". Bollywood Hungama. Retrieved 27 August 2011.
Jump up ^ Subhash K Jha Barua (20 August 2011). "Not A Love Story Review". ibosnetwork. Retrieved 27 August 2011.
Jump up ^ Kaveree Bamzai (19 August 2011). "Not A Love Story Review". India Today. Retrieved 27 August 2011.
Jump up ^ Zee News (19 August 2011). "Not A Love Story Review". Zee News. Retrieved 27 August 2011.
Jump up ^ Raja Sen (19 August 2011). "Not A Love Story Review". Rediff. Retrieved 27 August 2011.
Jump up ^ "Not A Love Story Movie Review". Behindwoods. Retrieved 27 August 2011.
Jump up ^ Mayank Shekhar (19 August 2011). "Not A Love Story Review". Hindustan Times. Retrieved 27 August 2011.
Jump up ^ Rajeev Masand (19 August 2011). "Not A Love Story Review". CNN-IBN. Retrieved 27 August 2011.
Jump up ^ Nupur Barua (19 August 2011). "Not A Love Story Review". fullhyd.com. Retrieved 27 August 2011. .
External links[edit]
Wikimedia Commons has media related to Not a Love Story (2011 film).
Not a Love Story on IMDb
[hide]
v
t
e
Ram Gopal Varma
1980s-1990s (Director)
Siva (1989)
Shiva (1990)
Kshana Kshanam (1991)
Raat (1992)
Antham (1992)
Drohi (1992)
Gaayam (1993)
Govinda Govinda (1994)
Rangeela (1995)
Deyyam (1996)
Anaganaga Oka Roju (1997)
Daud: Fun on the Run (1997)
Satya (1998)
Prema Katha (1999)
Kaun (1999)
Mast (1999)
2000s-2010s (Director)
Jungle (2000)
Company (2002)
Bhoot (2003)
Naach (2004)
Madhyanam Hathya (2004)
Sarkar (2005)
Shiva (2006)
Darna Zaroori Hai (Story 2) (2006)
Nishabd (2007)
Aag (2007)
Darling (2007)
Sarkar Raj (2008)
Contract (2008)
Phoonk (2008)
Agyaat (2009)
Rann (2010)
Rakta Charitra (2010)
Katha Screenplay Darshakatvam Appalaraju (2011)
Dongala Mutha (2011)
Not a Love Story (2011)
Department (2012)
Bhoot Returns (2012)
The Attacks of 26/11 (2013)
Satya 2 (2013)
Rowdy (2014)
Ice Cream (2014)
Ice Cream 2 (2014)
Anukshanam (2014)
365 Days (2015)
Killing Veerappan (2016)
Attack (2016)
Veerappan (2016)
Vangaveeti (2016)
Sarkar 3 (2017)
Writer and Productions
Money (1993)
Thiruda Thiruda (1993)
Money Money (1995)
Gulabi (1996)
W/o V. Vara Prasad (1998)
Dil Se.. (1998)
Shool (1999)
Pyaar Tune Kya Kiya (2001)
Love Ke Liye Kuchh Bhi Karega (2001)
Road (2002)
Darna Mana Hai (2003)
Main Madhuri Dixit Banna Chahti Hoon (2003)
Ek Hasina Thi (2004)
Ab Tak Chhappan (2004)
Gayab (2004)
Vaastu Shastra (2004)
My Wife's Murder (2005)
D (2005)
Mr Ya Miss (2005)
Shabri (2005)
Shock (2006)
Darna Zaroori Hai (2006)
Darwaaza Bandh Rakho (2006)
Go (2007)
Phoonk 2 (2010)
Gaayam 2 (2010)
Bejawada (2011)
Psycho (2013)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Not_a_Love_Story_(2011_film)&oldid=752388274"
Categories:
2011 films
Hindi-language films
Films directed by Ram Gopal Varma
Films set in Mumbai
2010s crime films
2010s thriller films
Indian crime films
Indian films
Indian erotic films
Hindi films based on actual events
Film scores by Sandeep Chowta
Hidden categories:
Use dmy dates from December 2015
Use Indian English from December 2015
All Wikipedia articles written in Indian English
Navigation menu
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
Namespaces
Article
Talk
Variants
Views
Read
Edit
View history
More
Search
Navigation
Main page
Contents
Featured content
Current events
Random article
Donate to Wikipedia
Wikipedia store
Interaction
Help
About Wikipedia
Community portal
Recent changes
Contact page
Tools
What links here
Related changes
Upload file
Special pages
Permanent link
Page information
Wikidata item
Cite this page
Print/export
Create a book
Download as PDF
Printable version
In other projects
Wikimedia Commons
Languages
Add links
This page was last edited on 1 December 2016, at 00:00.
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
Privacy policy
About Wikipedia
Disclaimers
Contact Wikipedia
Developers
Cookie statement
Mobile view
Enable previews

value: mw-page-base noprint

value: mw-head-base noprint

tag: i

value: firstHeading firstHeading en

value: siteSub noprint

value: jump-to-nav mw-jump

attr: colspan class style

tag: img

attr: alt src width height class srcset data-file-width data-file-height

attr: href class

attr: colspan style

attr: scope style

tag: br

value:
/wiki/Neeraj_Grover
mw-redirect
Neeraj Grover

value:
/wiki/Maria_Susairaj
mw-redirect
Maria Susairaj

value:
/wiki/Nandita_Puri
mw-redirect
Nandita Puri

value: display:table-cell;padding:0.2em 0.2em 0.2em 0.3em;vertical-align:middle

value: margin:0.5em 0 0.5em 1em;border:solid #aaa 1px

value: commons:Category:Not a Love Story (2011 film)

value:
nofollow
http://www.imdb.com/title/tt1999935/
external text

value:
/wiki/Love_Ke_Liye_Kuchh_Bhi_Karega
mw-redirect
Love Ke Liye Kuchh Bhi Karega

value: nowraplinks hlist collapsible autocollapse navbox-inner

value: Category:Films directed by Ram Gopal Varma

value: Category:Hindi films based on actual events

value: Category:Use dmy dates from December 2015

value: Category:Use Indian English from December 2015

value: Category:All Wikipedia articles written in Indian English

value: Discussion about edits from this IP address [ctrl-alt-n]

value: A list of edits made from this IP address [ctrl-alt-y]

value: You are encouraged to create an account and log in; however, it is not mandatory

value: You're encouraged to log in; however, it's not mandatory. [ctrl-alt-o]

value:
/wiki/Not_a_Love_Story_(2011_film)
View the content page [ctrl-alt-c]
c

value: Discussion about the content page [ctrl-alt-t]

value: p-namespaces navigation vectorTabs p-namespaces-label

value:
p-variants
navigation
vectorMenu emptyPortlet
p-variants-label

value: Past revisions of this page [ctrl-alt-h]

value: p-views navigation vectorTabs p-views-label

value:
p-cactions
navigation
vectorMenu emptyPortlet
p-cactions-label

value:
mw-wiki-logo
/wiki/Main_Page
Visit the main page

value:
/wiki/Main_Page
Visit the main page [ctrl-alt-z]
z

value: Featured content – the best of Wikipedia

value: Find background information on current events

value:
/wiki/Special:Random
Load a random article [ctrl-alt-x]
x

value: portal navigation p-navigation p-navigation-label

value: Guidance on how to use and edit Wikipedia

value: About the project, what you can do, where to find things

value: A list of recent changes in the wiki [ctrl-alt-r]

value: portal navigation p-interaction p-interaction-label

value: List of all English Wikipedia pages containing links to this page [ctrl-alt-j]

value: Recent changes in pages linked from this page [ctrl-alt-k]

value:
/wiki/Wikipedia:File_Upload_Wizard
Upload files [ctrl-alt-u]
u

value: A list of all special pages [ctrl-alt-q]

value: Permanent link to this revision of the page

value: Link to connected data repository item [ctrl-alt-g]

value: Printable version of this page [ctrl-alt-p]

value: portal navigation p-wikibase-otherprojects p-wikibase-otherprojects-label

value:
uls-settings-trigger
Language settings
0
button
true

value: mediawiki ltr sitedir-ltr mw-hide-empty-elt ns-0 ns-subject page-Not_a_Love_Story_2011_film rootpage-Not_a_Love_Story_2011_film vector-experimental-print-styles vector-nav-directionality skin-vector action-view