The agile manifesto is a set of 12 principles for developing software in an agile manner, somewhat similar to eXtreme Programming.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Shame their website is so ugly.

Related posts:

1. A Brief Overview of eXtreme Programming
2. The Mechanics of Interaction
3. User-Centered Interaction Design

eXtreme Programming (XP) is an agile development methodology developed by Kent Beck et al. It emphasises the human aspect of software development and how issues such as respect, trust and communication are key issues along with purely technical aspects of software development.

It is agile in the sense that Beck is strongly against giant requirement documents and the waterfall model of software development in general, preferring to build the simplest system that solves the current customers problems, and iterating from there with rapid (weekly/monthly) feedback loops.

The core ideology of XP is explained in a series of complementary values, principles and practices.

Core Values of eXtreme Programming

Values are the abstract issues and ideas that XP practitioners feel are important for a project to be a success, they guide the principles and practices.

• Communication – communication is important for creating a sense of team and effective communication. Most often when you encounter a problem, someone else on the team already knows the solution.
• Simplicity – develop the simplest system that could possibly work.
• Feedback – change in a project is inevitable, so rapid feedback is required to adapt the project to changing requirements.
• Courage – effective action in the face of fear. Knowing there is a problem and having the courage to fix it.
• Respect – the contributions of each person on the team need to be respected.
• Others – there may be other values that are particularly important to certain types of projects, such as safety and security.

Core Principles of eXtreme Programming

Values are too abstract to directly guide behaviour. Specific principles are needed to guide the practices of software development.

• Humanity – people develop software, therefore software development must meet basic human needs such as: safety, accomplishment, belonging and growth.
• Economics – the project must have business value, meet business goals and serve business needs.
• Mutual Benefit – every activity should benefit all involved. A practice should benefit you now, you in the future and your customer.
• Self-Similarity – try copying the structure of one solution into a new context.
• Improvement – get an activity started right away but refine the results over time (iterative development).
• Diversity – teams need a variety of skills, attitudes and perspectives to see problems and pitfalls.
• Reflection – good teams don’t hide their mistakes, they expose them and learn from them.
• Flow – deliver a steady flow of valuable software by engaging in all the activities of development simultaneously.
• Opportunity – problems need to turn into opportunities for learning and improvement, not just survival.
• Redundancy – the critical, difficult problems in software development should be solved in several different ways.
• Failure – if you’re having trouble succeeding, fail. Risking failure can sometimes be the shortest road to success.
• Quality – sacrificing quality is not effective as a means of control.
• Baby Steps – baby steps acknowledge that the overhead of small steps is much less than when a team wastefully aborts big changes.
• Accepted Responsibility – the above practices reflect accepted responsibility by, for example, suggesting that whoever signs up to do work also estimates it.

Primary Practices of eXtreme Programming

The practices are the things XP teams do day-to-day. The primary practices are the key practices that need to be fully adopted before the secondary practices can be adopted.

• Sit Together – having a big, open space, where people can sit together encourages communication, collaboration and co-operation. Privacy needs can be meet by secluded workstations around the edge of the area.
• Whole Team – include on the team people with all the skills and perspectives necessary for the project to succeed.
• Informative Workspace – make the workspace about the work. It should be informative: stories on one wall, tasks on another, etc.
• Energised Work – work only as many hours as you can be productive and only as many hours as you can sustain.
• Pair Programming – write all the production code with two people sitting at one machine.
• Stories – plan using units of customer-visible functionality. As soon as a story is written, try to estimate the development effort necessary to implement it.
• Weekly Cycle – plan work a week at a time. Have a meeting at the start of the week to review progress, have customers pick a weeks worth of stories and break the stories into tasks.
• Quarterly Cycle – plan work a quarter at a time. Once a quarter reflect on the team, the project, its progress, and its alignment with larger goals.
• Slack – in any plan, include some minor tasks that can be dropped if you get behind.
• Ten-Minute Build – automatically build the whole system and run all the tests in ten minutes, any longer, and it will be used less often, missing the opportunity for feedback.
• Continuous Integration – integrate and test changes after no more than a couple of hours. The longer you wait to integrate, the more it costs and the more unpredictable it becomes.
• Test-First Programming – write a failing automated test before changing any code. This helps address scope creep, coupling and cohesion, and trust.
• Incremental Design – strive to make the design of the system an excellent fit for the needs of the system that day.

Secondary Practices of eXtreme Programming

The secondary practices should only be adopted after successful adoption of the primary practices. It would be dangerous to deploy everyday without a low defect rate (due to test-first programming, continuous integration etc.).

• Real Customer Involvement – people whos lives and business are affected by your system should be part of the team. Visionary customers could be part of the quarterly or weekly planning.
• Incremental Deployment – big “D Day” deployment hardly ever works. Deploy limited functionality at a time and run both systems in parallel.
• Team Continuity – keep effective teams together.
• Shrinking Teams – as a team grows in capability, keep its workload constant but gradually reduce its size.
• Root-Cause Analysis – every time a defect is found after deployment, eliminate the defect and its cause. The goal is to make sure the team will never make the same kind of mistake again.
• Shared Code – anyone on the team can improve any part of the system at any time.
• Code and Tests – maintain only the code and tests as permanent artifacts. Generate other documents from code and tests.
• Single Code Base – there is only a single code stream. You can develop in a temporary branch, but never let it live longer than a few hours.
• Daily Deployment – put new software into production every night. Any gap between what is on a programmer’s desk and what is in production is a risk.
• Negotiated Scope Project – write contracts for software development that fix time, costs and quality but call for an ongoing negotiation of the precise scope of the system.
• Pay-Per-Use – with a pay-per-use system, you charge for every time the system is used. Money is the ultimate feedback.

So that covers the basic values, principles and practices of XP. For a more detailed look check out Beck’s book, eXtreme Programming Explained [aff].

Related posts:

1. The Agile Manifesto
2. What Is Interaction Design?

A deductive reasoning agent is one that contains an explicitily represented, symbolic model of the world. It then makes decisions via symbolic reasoning.

Limitations

When building an agent this way there are two key problems that have to be solved.

The Transduction Problem

This is the problem of translating the real world into accurate, adequate symbolic description, in time for that description to be useful…

These are problems of vision, speech understanding, learning etc.

The Representation/Reasoning Problem

This is the problem of how to symbolically represent information about complex real-world entities and processes and how to get agents to reason with this information in time for the results to be useful…

These are problems of knowledge representation, automated reasoning, automatic planning etc.

Related posts:

1. Agent Architecture
2. What is an Agent?
3. Program Comprehension Strategies

After defining some basic concepts related to agent architecture it is important that we understand how to provide agents with the means to complete tasks.

We want agents to be able to complete the tasks we specify but without us having to tell them how to complete the task.

Utility

One possibility of having agents complete tasks is to associate utilities with individual states and then have the agent aim to bring about states that maximise utility.

A task specification is a function: u : E -> R (where R is a real number). So we associate a value with every environment state.

But with this idea, what is the utility of a run (remember that a run is a set of states)… ?

Another possibility is to assign a utility to runs themselves:

u : R -> R.

This takes a more long term view than the previous approach.

Optimal Agents

The optimal agent in an environment is the one that maximises the expected utility.

Some agents cannot be implemented on some computers (some functions may require more memory than is available).

A bounded optimal agent is the agent, that can be implemented, that maximises expected utility.

Task Specification

0 or 1 can be assigned to previous runs, where 1 indicates that the agent succeeds, otherwise it fails.

These are known as predicate task specifications.

A task environment is a pair of enviornments and predicate task specifications.

Achievement and Maintenance Tasks

The two most common types of tasks are achievement and maintenance tasks.

An achievement task is one of the form: “achieve state of affairs”.

A maintenance task is one of the form: “maintain state of affairs”.

Related posts:

1. Agent Architecture
2. What is an Agent?
3. Deductive Reasoning Agents

Following on from our introduction to agents it’s important to understand the architecture of agents.

Abstract Architecture

Environment

We assume the environment may be in any of a finate set of discrete, instantaneous states, defined as:

E = {e,e,,...}.

Actions

Agents are assumed to have a repertoire of possible actions:

Ac = {α,α,,...}.

Run

A run of an agent in an environment is a sequence of interleaved environment states and actions:

α0 α1 α2 αn
r : e0 -> e1 -> e2 -> ... -> en

State Transformer

Let R be the set of all possible finate sequences over E and Ac.

Let RAc be the subset of these that end in an action.

Le RE be the supset of these that end with an environment state.

A state transformer function represents behaviour of the environment:

t : RAc -> 2E

If t(r) = the empty set, then there are no possible successor states to r and the system has ended its run.

Agent

An agent is a function that maps runs into actions:

Ag: RE -> Ac

An agent makes a decision about what to perform based on the history of the system that it has witnessed to date.

Perception

An agent can determine atrributes of the environment through sensors.

The see function is the agent’s ability to observe its environment, whereas the action function is the agent’s decision making process.

The output of the see function is a percept:

see : Per* -> Ac

Also, action is now a function, it maps sequences of percepts to actions:

action : Per* -> Ac

Reactive Agents

Reactive agents decide what to do without reference to history. They base their decision making entirely on the present. They have actions corrosponding to particular percepts, and perform them when they sense them.

Agents with State

Some agents maintain state. They have an internal data structure used to record information about the environment state.

Let I be the set of internal states of the agent. The agent function action is now defined as a mapping from internal states to actions:

action : I -> Ac

An additional function, next, is also introduced to map an internal state and a percept to another internal state:

next : I x Per -> I

Agent Control Loop

1. Agent starts in some initial internal state i0
2. Observes it’s environment state e, and generates a percept see(e)
3. Internal state of the agent is then updated via next function, becoming next(i0, see(e))
4. The action selected by the agent is action(next(i0, see(e)))
5. Goto 2

Agent Architectures

There are three particular types of agent architectures: deductive reasoning agents, practical reasoning agents and reactive/hybrid agents.

Related posts:

1. What is an Agent?
2. Agent Tasks
3. Deductive Reasoning Agents

An agent is a computer system that is capable of independent action on behalf its user/owner (figuring out what to be done to satisfy design objectives, not constantly being told).

The main idea behind agents is the idea that they are autonomous: they are able act independently, exhibiting control over their internal state.

Definition

An agent is a computer system capable of autonomous action in some environment in order to meet its design objectives.

Agent Environments

There are various types of environments an agent can exist in:

• Accessible vs. inaccessible
• Deterministic vs. non-deterministic
• Episodic vs. non-episodic
• Static vs. dynamic
• Discrete vs. continuous

An accessible environment is one where the agent can obtain complete, accurate, up-to-date information about the environment’s state. Most moderately complex environments are inaccessible.

A deterministic environment is one in which any agent action has a single guaranteed effect. In a non-deterministic environment an action could have many possible effects/outcomes.

In an episodic environment an agent sees the environment as separate “episodes” and need not worry about past or present “episodes” when making a decision.

In a static environment only the actions of the agent causes changes in the state of the environment.

An environment is discrete if there are only a certain number of actions and percepts in it, e.g. a chess board.

Agent Properties

There are some trivial examples of agents, e.g. a thermostat (if the temperature drops below x, turn the heating on) but an intelligent agent has a number of properties that allow it to perform flexible, autonomous actions within an environment.

Reactive

A reactive system is one that maintains an ongoing interaction with its environment, and responds to changes that occur within it.

Proactive

Proactiveness is about agents taking the initiative and seizing opportunities by generating and attempting to achieve goals.

Social Ability

The real world is a multi-agent environment, it’s not possible to achieve goals without taking others into account.

An agent’s social ability is the agent’s ability to interact with other agents (and possibly humans) through some kind of agent-communication language.

Related posts:

1. Agent Architecture
2. Agent Tasks
3. Deductive Reasoning Agents

If a project has no risk, don’t do it! Risks and benefits always go hand in hand.

A Risk Metaphor

Imagine your company, and your competitors as a set of down escalators. You are obliged to climb the escalator. If you pause, even for a second, you will begin to fall behind. Whoever, reaches the top of their escalator will find a leaver, allowing them to control the speed of their and their competitors escalators. It’s the risks you take that speed up the stairs for everyone else. Not taking them just ensures your world will be shaped and dominated by someone else.

In this era, risk taking is rewarded.

Project Management for Adults

Risk management can be thought of as project management for adults. When project managers do not explicitly manage risk, they are being childlike.

When a project manager considers only the rosy scenario, and ignores risks in the project plan, they are behaving like a kid.

Project managers need to grow up and take explicit note of the risks and plan accordingly.

Risk: A definition

Risk can be defined as:

risk n 1: a possible future event that will lead to an undesirable outcome 2: the undesirable outcome itself

Risks can also be related to problems, consider the following:

A risk is a problem that has yet to occur, a problem is a risk that has already materialised.

Transition and Mitigation

For every risk to be managed, there will be some kind of transition indicator. The reason to pay attention to the transition, is that when the indicator fires, the manager must take action.

Before the transition, it’s too early to take action – it may be too expensive or time consuming. However, some actions must be taken to allow you to keep your options open and make the correction after the transition, this work is called mitigation.

The Practice of Risk Management

• risk discovery: your initial risk brainstorm and subsequent triage, plus whatever mechanism you put in place to keep the process going
• exposure analysis: quantification of each risk in terms of its probability of materialising and its potential damage
• contingency planning: what you expect to do if and when the risk materialises
• mitigation: steps that must be taken before the transition in order to make the planned contingency actions possible and effective when required
• ongoing transition monitoring: tracking of managed risks, looking for materialisation

Why Manage Risk?

Imagine a software project manager approaches you and clearly states his uncertainty about your proposed project:

“there are unknowns here, and we have catalogued the following risks. Taken together these unknowns give us a fairly wide window of uncertainty around the delivery date.

But here is our plan for how we will act to contain and minimise the various downside risks, and here is how you will know at any point in the project how we are fairing.”

Now you can know where you stand. The willingness to commit to a risky project is a direct function of how well you can logically conclude that the risks have been assessed, quantified and confronted.

Other reasons to manage risk:

• Risk management decriminalises risk – risk management is a can’t-do activity. Announcing risks can have the announcer written off as a whiner. Formal risk management authorises people to think negatively, at least some of the time.
• Risk management sets up projects for success – in the absence of risk management, achieving anything but the most optimistic result is a failure.
• Risk management bounds uncertainty – risk management allows you to make thoughtful, informed decisions about how to proceed.
• Risk management provides minimum-cost downside protection – risk management allows you to know how much time and money to give yourself as sensible protection from risks.
• Risk management protects against invisible transfers of responsibility – in the absence of risk management, subtle transfers of risk responsibility may often go unnoticed.
• Risk management can save part of a failed effort – the failure of one component should not jeopardise the whole project.
• Risk management maximises opportunity for personal growth – by not taking risk, consequently, companies do not move into new territory, which is boring for employees, and the best may leave.
• Risk management maximises protects management from getting blindsided – risk management assures that risk won’t appear from out of the blue.
• Risk management focuses attention where it is needed – risk management is a focussing mechanism, one that puts resources where they belong.

Related posts:

1. Current Geek Reading List

Floyd-Hoare Logic is a formal system with a set of logical rules for reasoning rigorously about the correctness of computer programmes. The central feature is the Hoare triple.

Hoare Triples

A Hoare triple {P} C {Q} is a formula.

P, Q are fomulae in a base logic (e.g. full predicate logic etc.) and C is a programme in our imperative language.

P is known as the precondition, while Q is known as the postcondition.

This is known as a partial correctness specification and is valid, if and only if, starting from a state (s1,h1) satisfying P:

• No execution of C access an unallocated heap cell (no memory error).
• Whenever an execution of C terminates in state (s2,h2), then (s2,h2) |= Q.

Assignment Axiom

The assignment axiom applies to the following programme constructs:

E ::= x | n | E+E | -E | ... – Heap-independent expressions, where x = variable and n = constant.
C :: x := E – Assignment statements.

Hoare Inference Rule

{P[x -> E]} x := E {P} – All free occurrences of the variable x, are replaced by the variable E.

Free and Bound Variables

When a quantifier is used on a variable, this occurrence of the variable is bound. An occurrence of a variable that is not bound by a quantifier or set equal to a particular variable is free.

In the statement ∃x(x + y = 1), the variable x is bound by the existential quantification ∃x, but the variable y is free because it is not bound by a quantifier and no value is assigned to this variable.

However, in the statement ∃x(P(x) ∧ Q(x)) ∨ ∀xR(x) all variables are bound.

Examples:

{ (x + z . y)2 > 25 } x := x + z * y { x2 > 25 }
{ (z . y > 5) ∧ (∃x. y = xx) } x := z * y { (x > 5) ∧ (∃x. y = xx) }

Sequential Composition Rule

The sequential composition rule applies to the following programme construct:

C ::= C1, C2 – The sequencing of commands.

Hoare Inference Rule

{P} C1 {R}      {R} C2 {Q}

becomes…

{P} C1; C2 {Q}

Examples:

{y + z > 4} y := y + z - 1 {y > 3}      {y > 3} x := y + 2 {x > 5}

becomes…

{y + z > 4} y := y + z - 1; x := y + 2 {x > 5}

Rules of Consequence

Hoare Inference Rule

P ⇒ P1      {P1} C {Q1}      Q1 ⇒ Q

becomes…

{P} C {Q}

Examples:

(y > 4) ∧ (z > 1) ⇒ (y + z > 5)
{y + z >5} y := y + z {y > 5}
(y > 5) ⇒ (y > 3)

So by the rule of consequence, we can rewrite the second fragment as:

{(y > 4) ∧ (z > 1)} y := y + z {y > 3}

Conditional Rule

The conditional rule applies to the following programme constructs:

E ::= x | n | E+E | -E | ... – Heap independent expressions.
B ::= E=E | E>=E | B∧B | !B – Boolean conditions.
C ::= if B then C1 else C2 – Conditional statements.

Hoare Inference Rule

{P ∧ B } C1 {Q}      {P ∧ !B} C2 {Q}

becomes…

{P} if B then C1 else C2 {Q}

Examples:

{(y > 4) ∧ (z > 1)} y := y + z {y > 3}      {(y > 4) ∧ !(z > 1)} y := y - 1 {y > 3}

becomes…

{y > 4} if (z > 1) then y : y + z else y := y - 1 {y > 3}

While-Loop Rule

The while-loop rule applies to the following programme constructs:

E ::= x | n | E+E | -E | ... – Heap-independent expressions.
B ::= E=E | E>=E | B∧B | !B – Boolean conditions.
C ::= while B C – While loops.

Hoare Inference Rule

{P ∧ B} C {P}

becomes…

{P} while B C {P ∧ !B}

P is a loop invariant. Because we are looking at partial correctness, the semantics say that, if the loop does not terminate, the Hoare triple is vacuously satisfied. However, if it terminates, P ∧ !B must be satisfied.

Examples:

{(y = x + z) ∧ (z != 0)} x := x + 1; z := z - 1 {y = x + z}

becomes…

{y = x + z} while (z != 0) x := x + 1; z := z -1 {(y = x + z) ∧ (z = 0)}

Related posts:

1. Stacks, Heaps, Variables and Pointers
2. A Simple Assertion Language for Formal Verification

Following on from our introduction of the basic concepts required to start to understand formal verification, we shall define a simple assertion language.

An assertion is a logic formula describing a set of states with some “interesting” property. Also, recall that States = Stacks x Heaps, so an assertion can refer to both stack and heap.

E, F ::= x | n | E + F | -E | ... – Heap-independent expressions.
P, Q ::= E = F | E >= F – Boolean conditions.
| true | P ^ Q | !P | ∀x.P – Classical logic formula.
| emp | E -> F – Atomic predicates on heap. Where emp = empty heap and -> = single cell of the heap.

Semantics of Assertions

An expression is a map between a stack to an integer:

[[E]] : Stacks -> Vals – expressions are clearly heap independent.

The semantics of an assertion are given by a satisfaction relation between states and assertions:

(s,h) |= P – where s = stack, h = heap (s and h together = the state) and P = assertion.

Example assertions:

(s,h) |= E >= F iff [[E]]s, [[F]s ∈ Vals and [[E]]s >= [[F]s
The assertion is true, if and only if, the expression E and the expression F, on the stack, are members of the set of values and that the value E is greater than or equal to the value F.

(s,h) |= true
This assertion is always true.

(s,h) |= P ^ Q iff (s,h) |= P and (s,h) |= Q
The assertion is true, if and only if, both P is true and Q is true.

(s,h) |= !P iff not (s,h) |= P
The assertion is true, if and only if, P is not true.

(s,h) |= ∀x.P iff ∀v ∈ Vals.(s[x -> v],h) |= P
The assertion is true, if and only if, for all the possible values of x, P is true.

(s,h) |= emp iff h = []
The assertion is true, if and only if, the domain of the heap is equivalent to the empty set.

Example

Consider a program with two variables, x and y, both initialised to 0.

The assertion: P: x -> y and Q: y2 >= 20.

Apologies the table doesn’t fit so well but let me walk through the programme:

At PC = 1 we assign x to a new pointer variable, this then places the value of x, or in this case, the memory location of x (230), onto the stack; while the value of y is still 0. So in the heap is an entry for 230 (the memory location of x) with a value 2547 left from some previous programme or execution. Neither assertion is true in this case because 0 is not greater than or equal to 20 and x is not pointing to y.

At PC = 2 we assign y to the value 37, which places the value 37 onto the stack. Everything else remains the same. The assertion P is still false but 37^2> is greater than or equal to 20, so the assertion Q is satisfied.

At PC = 3 we point the variable x to the value of y, which overwrites the old value for x in the heap with the new value, 37. In this case both assertions, P and Q are satisfied.

At PC = 4, we assign x to a new pointer variable. This updates the value for x in the stack, to the new memory location (40), and adds a new entry to the heap (the memory location of x and an old value). In this case Q holds true while P is not true.

Related posts:

1. Stacks, Heaps, Variables and Pointers
2. Floyd-Hoare Logic

It is important to have a solid understanding of the difference between stacks and heaps, and variables and pointers, before one can embark on the task of learning about Formal Verification of C-like languages.

What’s Formal Verification?

Formal Verification is a branch of Computer Science responsible for formally proving the “correctness” of programmes. Usually, this would be overkill but for certain classes of mission/safety-critical programmes, it is becoming more popular. A short intro to formal verification can be found on wikipedia – otherwise stick around, we’ll be getting to formal verification shortly.

Primer: LValues and RValues

In C there is a concept of LValues and RValues.

LValues are values that have an address, meaning that they are variables or dereferenced references to a certain memory location. Conversely, RValues are not LValues.

An LValue, initially referred to values on the left side of an assignment operator, hence the name. An example of an RValue is an “immediate value”, such as the expression 13 + 4. There is no explicit memory location of that value. On the other hand: x = 13 + 4 – x is an LValue holding a reference to the memory location of the value of the expression.

Primer: Variables

A variable is simply a construct such as: y = 3 (or in our simple language, see below: y := 3). The variable is stored on the stack with a reference to the value.

Primer: Pointers

A pointer is a special type of variable that in the stack, instead of referencing the value, references a memory location, and at that memory location is the value of the variable.

In our simple language (see below) a pointer is constructed in the following manner:

x := new(1) – create a new pointer variable at a random, free memory location (it may already contain a value if that particular memory location was previously written to).
[x] := 3 – at the memory location, referenced by the pointer, set the value to 3.

Primer: [Call] Stacks

A stack is a last-in, first-out (LIFO) data structure. The easiest way to visualise it is to think of a stack of plates. The last plate placed (pushed) onto the stack, will be the first plate pulled (popped) off the stack. A stack, in this case, is a fixed area of memory, accessed in a last-in, first-out manner. The stack has a limited/fixed size but generally has quicker allocation time than the heap (see below).

The call stack, often just called the stack, is used to store data about a program during its execution. That data includes space for storing local variables within subroutines.

The stack always (in our simplified language at least, see below) maintains a value for each variable in the programme. This is regardless of whether or not the variable is a pointer.

So for example, if y = 43, in the stack will be the variable y with a reference to the value 43. If however, y = new(1) (new pointer), then in the stack will be the variable y with a reference to the memory address/location of the value of y.

Primer: Heaps

The heap, in this case, is a large pool of unused (free) memory address space.

A Simple Imperative Language

To simplify the verification work a simple, imperative language is defined, similar to a C-like language:

E ::= x | n | E+E | -E | ... – Heap-independent expressions.
B ::= E=E | E>=E | B^B | !B | – Boolean conditions.
C ::= x:=E | C;C | if B then C else C – Standard constructs.
| while B C – Looping constructs.
| X := new(E1,...En) – Allocation on heap.
| x := [E] – Lookup of heap.
| [E1] := E2 – Mutation of heap.
| dispose (E) – Deallocation of heap.

A Simple Storage Model

Along with our simple imperative language, we have a simple storage model:

Variables = { x, y, z, ... }
Locations = { 1, 2, 3, 4, ... } – as in memory locations.
Heaps = Locations -> Values – A heap entry is a location pointing to a value.
Stacks = Variables -> Values – A stack entry is a variable pointing to a value.
States = Stacks x Heaps – A state is a pair of stacks and heaps.

Related posts:

1. A Simple Assertion Language for Formal Verification
2. Floyd-Hoare Logic