Summary and Revision 1

1
Summary and Revision (1)

• Initially Software Engineering centered upon
  Formal Methods (of software specification)
• Such methods were powerful, they involved
  specifications in advance of developing
  implementations
• Specifications could be proved to be consistent
  complete
• But software systems in mainstream use became
  ever-larger in scale, and in some cases
  complexity
• Specifications, even when partitioned into
  separate related documents, became difficult to
  reason about in their entirety
• In any case, mainstream I.T. developers were
  capable of developing systems of sufficient scale
  and reliability that they did not adopt Formal
  Methods
• Several reasons for the lack of adoption of
  Formal Methods can be identified, including
• Lack of adequate tools, e.g. ??
• Lack of adequate mathematical sophistication in
  developers.
• What can developers still do??
• Incompatibility with conventional techniques.
• Conventional techniques emphasise ???
• High costs associated with their use.
• - e.g. cost of ??
• Overselling by their advocates.
• For I.T. systems validation as important as
  verification!

2
(2)

• Whilst Formal Methods have not been widely
  adopted by mainstream I.T. software developers,
  simpler formal notation techniques are widely
  used
• see tutorial on equivalent notations
• Even simpler notations are concerned with
  verification only
• Validation is not a concern of Formal Methods nor
  simpler formal notation techniques
• More recently, UML has become de-facto standard
  notation for software design
• Although a combination of several competing
  notation techniques, these techniques have now
  been better integrated (i.e. in UML2) and (at
  last!) formalised
• But, UMLs formalisation (i.e. its syntax and
  semantics) has been criticised as being-
• Difficult for mere UML users to understand
• Ambiguous about the relations between models
  represented in UML (even internally consistent
  models) and the subject that is being modelled
• Lacking a justification that explains why the
  presented set of modelling concepts is necessary
  and sufficient (to represent the scope of UML
  models)

3
(3)

• What is The Problem in Software Engineering?
• Few texts mention the nature of software
  itself, i.e. software is not built from physical
  materials using physical processes
• Traditional engineering disciplines are generally
  limited by the physical interconnection
  constraints of the building blocks used to
  construct artefacts, and benefit from the
  presence of a set of well understood (within that
  particular engineering discipline) and
  standardised building blocks.
• The problem Complexity and its management
• With software, the nature of the interconnections
  between elements provides an unlimited number of
  degrees of freedom, and hence complexity.
• Also, the lack of truly universal standardisation
  for the building blocks of software (e.g.
  components) provides a barrier to making more
  complex (where complex is synonymous with useful)
  software structures out of simpler, well
  understood elements which will have well-defined
  characteristics.
• Managing the complexity of ever larger-scale
  software systems involves managing the
  process(es) by which they are developed too
• When programming, the language(es) used provide
  support for managing complexity, e.g. via scope,
  encapsulation, information hiding, etc
• And in modern class-based OO programming
  languages, classes/objects, and inheritance
  generics (for reuse)

4
(4)

• Hence, modern S.E. practice involves
  process-oriented techniques
• The intention is that software development is a
  process that can be predicted, planned, managed
  and controlled as in any other branch of
  engineering
• Software execution may be internal to a computer,
  but design process should be visible to all (i.e.
  including all levels of management)
• Transition from analysis of requirements to
  software specification/design is most crucial
  stage
• All parts of specification/design subjected to
  review by most able experienced software
  architects/engineers
• Large implementation teams then share experience
  judgement of best available architects/engineers
  
• Involves inspections, walkthroughs, reviews, etc,
  
• At final stage, i.e. code review, formal
  comments in form of assertions, preconditions,
  post-conditions and invariants
• Testing discipline should detect 1) inadequacy in
  methods of development, 2) lack of concentration
  and skills of software designers and implementors
• Modern process-oriented techniques are iterative
  and incremental
• Both imply the exploitation of feedback
• Iterative add onto approach, control of
  unpredictability via feedback, i.e. frequent
  production of working versions of final system.
• Each version has larger subset of required
  features of final version, must be capable of
  supporting demands on final version, is fully
  integrated and tested as rigorously as final
  version.
• Incremental gradual improvement approach.
• Again, control of unpredictability via feedback,
  but feedback from an initial design proposal or
  prototype implementation which is then evaluated
  and improved incrementally.

5
(5) RUP

• Is use-case driven
• Iterative (in its software development lifecycle)
• Embraces OO concepts, principles and techniques
• Often involves activities that involve
  constructing models described in UML
• Is itself a product (with a web-enabled
  guidebook)
• RUP is widely believed to be most effective at
  requirements management
• RUP (as a process) describes who does what, how
  and when
• Role who, behaviour and responsibilities of
  individual, or group as a team
• Activities how, behaviour expressed in terms of
  activities, responsibilities in terms of
  artefacts or work products created, modified or
  controlled
• Artefacts what, that which is created, modified
  or controlled
• Disciplines when, group activities into
  meaningful sets that form a result, shows how
  workers interact

Activities
Role
Designer
Use-Case Analysis
Use-Case Design
Responsible for
Artefact
Use-Case Realisation
6
(6) RUP (continued)

• In addition, RUP introduces
• Specific techniques in form of guidelines mapped
  to activities
• Templates for major artefacts
• Tool mentors to guide use of software tools
• RUP especially good at requirements management
• Introduces a requirements discipline (one of nine
  core disciplines)
• Requirements discipline produces and updates
  artefacts
• Several artefacts involved-
• Stakeholder requests and any other kinds of
  request
• Vision Document
• Use-Case model set(s) of Use-Cases (i.e. the
  main requirements to be satisfied)
• Supplementary specification requirements not
  captured by Use-Cases (e.g. non-functional reqs
  and design constraints)
• Requirement attributes shared repository of
  requirements-related information, used to track
  status of requirements and make them traceable
• Use-Case storyboards, derived from essential
  Use-Cases involving human actors to model
  user-interface and elaborate useability reqs
• User-interface prototypes
• Project Glossary, defines terms used elsewhere

7
RUP continued (7)

• Requirements discipline involves different kinds
  of of requirement that vary from user-needs to
  reqs for design and test documentation

Requirement Kind
Vision
User need
Features
Supplementary Specification
Software requirements
Stakeholder Requests
Design test documentation requirements
Design Model
Test Plan
End-user Docs and Training Materials
8
RUP continued (8)

• Workers involved (in requirements process)
  include
• Stakeholder(s), customers(s), end-user(s) or
  anyone providing input to requirements process
• Systems analyst who leads and co-ordinates
  requirements process
• Use-case specifier
• User-interface designer
• Requirements reviewer (usually several team
  members)
• Requirements discipline activities and steps
  organised into six smaller discipline details
• Analysing the problem
• Understanding user and stakeholder needs
• Defining the system
• Managing scope
• Refining the system definition
• Managing changing requirements
• Each of the above discipline details is further
  elaborated in the suggested text book(s)

9
(9) PRINCE2

• PRINCE2 is a structured approach to project
  management
• Provides a method for managing projects within a
  clearly defined framework
• Describes procedures to coordinate people and
  activities during a project
• How to design and supervise a project
• How to adjust project if development goes wrong
• Each process is specified with its key input
  outputs
• Process has specific goals and activities that
  are undertaken
• These goals and activities intended to enable
  automatic control of any deviation from the
  plan
• Divides project into manageable stages
• Enables efficient control of resources.
• Close monitoring of project performed in a
  controlled and organized manner
• IS process-driven, i.e. defines 45 (!!)
  sub-processes and organises these into eight
  higher-level processes
• Starting Up a Project (SU)
• Planning (PL)
• Initiating a Project (IP)
• Directing a Project (DP)
• Controlling a Stage (CS)
• Managing Product Delivery (MP)
• Managing Stage Boundaries (SB)

10
(10) PRINCE2 continued

• The PRINCE2 has its (own specific/particular)
  Process Model

Corporate and Programme Management
Directing a Project (DP)
Project Mandate
Managing Stage Boundaries (SB)
Initiating a Project (IP)
Starting up a Project (SU)
Control of a Stage (CS)
Closing a Project (CP)
Managing Product Delivery (MP)
Planning (PL)

11
(11) PRINCE2 continued

• PRINCE2 processes and their relationships (Note
  arrows in this diagram denote flow of
  information)

Corporate and Programme Management
Directing a Project (DP)
Managing Stage Boundaries (SB)
Initiating a Project (IP)
Starting up a Project (SU)
Control of a Stage (CS)
Closing a Project (CP)
Managing Product Delivery (MP)
Planning (PL)
12
(12) PRINCE2 continued

• Each of the higher-level processes has a detailed
  structure e.g. Starting Up a Project (SU)
• During SU a project team is appointed
• A project brief is prepared - an outline only
• describes what the project is attempting to
  achieve
• Gives a business justification for doing so I
• Also, overall approach to be taken is decided
  and
• Next stage of the project is planned.
• Once this work is done, project board is asked to
  authorise the proposed next stage, i.e.
  Initiating the Project (IP).
• SU subprocesses are-
• SU1 Appointing a Project Board Exec and Project
  ManagerSU2 Designing a Project Management
  TeamSU3 Appointing a Project Management TeamSU4
  Preparing a Project BriefSU5 Defining Project
  ApproachSU6 Planning an Initiation Stage
• The above is only for SU, there are also DP, IP,
  CS, PL etc.
• These should be understood too!

13
(13) PRINCE2 continued

• PRINCE2 has a number of components
• Business Case Justification behind the project.
• Organization How the personnel involved are
  structured.
• Plans Documents describing
• what the project should accomplish,
• how the work should be carried out
• when it should be carried out and by whom.
• Controls How project manager and project board
  should exercise control over the project.
• Management of Risk How project should approach
  and manage risk.
• PRINCE2 defines a risk as uncertainty of
  outcome, i.e. as either a positive opportunity
  or a negative threat.
• Once analyzed risks are managed where appropriate
  to remove, reduce the effect of a negative threat
  and to take advantage of positive opportunities.
• Quality in a Project Environment - How project
  should ensure that a quality product is
  delivered.
• Configuration Management How project's products
  are identified and tracked.
• Change Control How project manages any changes
  to specification(s) or scope(s) of its products.

14
(14) Work Packages

• Central to PRINCE2 (and many other structured
  project management techniques) is the concept of
  a Work Package (WP)
• WP defines logical units of work
• In PRINCE2 projects are broken down into stages
  and these sub-processes stipulate how each
  individual stage should be controlled.
• Most fundamentally this includes how WPs are
  authorised and received.
• Also specifies how progress is monitored and how
  the news of progress is reported to project
  board.
• Some means for capturing and assessing project
  issues is proposed plus corrective measures
• Also stipulates method by which certain project
  issues should be escalated to the project board.
• Example1- In Controlling a Stage (CS) there are
  the following sub-processes
• CS1 Authorizing Work PackageCS2 Assessing
  ProgressCS3 Capturing Project IssuesCS4
  Examining Project IssuesCS5 Reviewing Stage
  StatusCS6 Reporting HighlightsCS7 Taking
  Corrective ActionCS8 Escalating Project
  IssuesCS9 Receiving Completed Work Package
• Example2- In Managing Product delivery (MP)
  three sub-processes concern how work packages are
  accepted, executed and delivered.
• MP1 Accepting a Work PackageMP2 Executing a Work
  PackageMP3 Delivering a Work Package

15
(15) Work Packages continued

• The set of information relevant to the creation
  of one or more products.
• It contains the Product Description(s)
• Details of any constraints on production such as
  time, cost and interfaces.
• Also includes confirmation of the agreement
  between the Project Manager and the person or
  Team Manager who is to implement the Work Package
  that the work can be done within the constraints.
  
• Work is released to a team Manager or member in
  an authorised Work Package.
• In Controlling A Project (CP), product delivery
  involves-
• Accepting a Package
• Executing a Package
• Delivering a Package
• Work Packages are mechanism for Project Manager
  to collate details of and pass responsibility for
  work or delivery to a Team Manager, team member,
  external supplier.
• WP may be informal or formal
• WP contains
• Product Description(s)
• Techniques, processes, procedures to be used
• Interfaces to be satisfied by work
• Interfaces to be maintained during work
• Quality checking arrangements
• Reporting requirements

16
(16) Problem-solving techniques

• See earlier slides for grammars (and the tutorial
  again)
• In its simplest guise stepwise refinement (aka
  functional decomposition) underpins effective use
  of simple formal notations, e.g. when defining
  grammars (irrespective of notation used)
• Each new component of the definition (e.g. each
  further production rule) introduces one (and only
  one) new concept into the definition
• The resulting definition (e.g. the production
  rules) and their refinement should be repeatable
  because of the size of the step involved
• UML
• A UML class diagram corresponds to a type
  diagram, i.e. from a type-oriented perspective
  each box denotes a type.
• This is a useful perspective BECAUSE types are
  the basis for type checking, i.e. automated type
  checking
• From an implementation viewpoint, e.g. in Java,
  types are defined using either classes or
  interfaces.
• XML
• XML is a (proper, strict) sublanguage of SGML
  whose grammar (a.k.a. concrete syntax) has been
  defined in EBNF
• Had several design goals (to make it an effective
  grammar notation-technique)
• IF only well-formedness is required of an XML
  document THEN XML is a generic framework for
  storing a) any amount of text or b) any data,
  both of whose structure can be represented as a
  tree.
• A syntactically correct XML document has a root
  element (or document element) enclosing text
  between a root opening tag and a (corresponding)
  closing tag.

17
(16) Continued Representing concrete syntax
(including programming languages)

• Grammars (recall tutorial Equivalence of Simple
  Formal Notations)
• e.g. for a SIMple programming language
• ltsimgt PROGRAM ltidentifiergt
• ltblockgt .
• ltidentifiergt ltchargt (ltchargt ltdigitgt)
• ltblockgt ltdeclaration_listgt
• BEGIN
• ltstatement_listgt
• END
• ltdeclaration listgt ltemptygt VAR
  ltdeclarationgt (ltdeclarationgt )
• ltdeclarationgt ltidentifiergt lttypegt
• ltstatement_listgt ltemptygt ltstatementgt (
  ltstatement)
• ltstatementgt ltvariablegt ltexpressiongt
• ltexpressiongt ltdigitgt ltvariablegt
• lttypegt Boolean integer
• ltchargt a..z A..Z
• ltdigitgt 0..9

PROGRAM example VAR i integer BEGIN
i0 END.
18
(16) Continued Representing concrete syntax (not
programming languages)

• ltperfect_tv_usergt On (ltchange_settingsgt) Off
• ltchange_settingsgt (ltchannelgt source)
• ltchannelgt ltdigitgt ltdigitgt
• ltdigitgt 0..9

19
(16) Continued Representing state

• State transition diagram (n.b. also part of UML),
  and c.f. tutorial again

20
(16) Continued... Representing behaviour

• The purpose of a use case is to define a piece of
  coherent behaviour without revealing the internal
  structure of the system.
• Easier to understand if we see its refinement
  (or evolution)

21
(17) (Useful) Separations of Concerns

• Separations of Concerns (i.e. useful ones!)
  include-
• Separation of concrete and abstract syntax
• In game-playing applications that involve board
  games
• In programming languages
• concrete syntax syntax rules
• abstract syntax semantics
• In design models e.g. MVC
• View concrete syntax
• Model abstract syntax
• Separation of interface and implementation
• In imperative-procedural languages
• PROCEDURE/FUNCTION declaration (or signature)
  vs PROCEDURE/FUNCTION body
• In modular languages, INTERFACE and
  IMPLEMENTATION components of a module
• Styles of module use
• HIDDEN types
• In classes and class instances
• Method interface
• Messages and method invocation
• Again, in design models, e.g. MVC

22
(18) Object Orientation

• Has several related perspectives
• Claims to promote (effective) reuse
• Re-use is by replacement
• Replacement in OO only requires approximate
  agreement between original and replacer, i.e.
  replacing object has at least same set of
  attributes
• Two forms of replacement
• Objects may replace other objects
• Methods may replace other methods
• Replacing methods in two ways-
• Overriding (replacement of methods from
  superclass)
• Inheritance (reusing existing methods)
• May be (usefully) combined, in modern programming
  (and software design notations) with
  parametric/parameterised types (or generics)
• Concept of an Object is usually modelled in terms
  of record types (cartesian products) that are
  themselves extensible (and hence inheritance is
  obtained) plus extensible operations bound to
  the record types
• OO strongly-influenced by (separate) notion of
  Abstract Data Type (ADT)
• i.e. OO abstract data type polymorphism

23
(18) Continued ADTs and equational specification
MODULE queue_adt INTERFACE USES item,
Boolean TYPE queue FUNCTION
empty_queue queue
FUNCTION is_empty (q queue )
Boolean FUNCTION append (i item q
queue) queue FUNCTION front (q queue
) item FUNCTION remove (q
queue ) queue SPECIFICATION VAR
i item q queue EQUATIONS
is_empty(empty_queue) true
is_empty(append(i, q)) false
front(append(i, q)) IF is_empty(q) THEN i
ELSE front(q)
remove(append(i, q)) IF is_empty(q)
THEN empty_queue
ELSE append(i, remove(q))
front(empty_queue) error
remove(empty_queue) error END.
is_empty(append(k, remove(append(j, append(i,
empty_queue))))) false
24
(18) Continued ADTs and equational
specification Example proof
is_empty(empty_queue) true is_empty(append(i,
q)) false front(append(i, q)) IF
is_empty(q) THEN i ELSE
front(q) remove(append(i, q)) IF
is_empty(q) THEN empty_queue
ELSE append(i, remove(q))
front(empty_queue) error remove(empty_que
ue) error
append(k, remove(append(j, append(i,
empty_queue)))) append(k, append(j,
remove(append(i, empty_queue)))) (by Axiom
4) append(k, append(j, remove(append(i,
empty_queue)))) append(k, append(j,
empty_queue)) (by Axiom 4) is_empty(append(k
, append(j, empty_queue))) false (by Axiom
2)
25
(19) OO continued

• Central to OO is notion of inheritance (in
  class-based languages by subclassing)
• OO introduces a Principle
• LSP
• Objects need not be defined in terms of their
  class
• e.g. object-based languages
• OO has introduced its own jargon
• Has generated important academic debate
• i.e. such debates were important in identifying
  and formalising fundamental and general concepts
  and principles, in some cases entirely new ones)
• e.g. on variance
• and hence the
• Contra-variance rule
• In some contexts Covariance (although enforced)
  is inappropriate
• Has spawned further concepts, abstractions and
  debate, e.g.
• Design patterns (and anti-patterns)