Compiler Construction: Requirements Engineering and Object-Oriented Design, Papers of Computer Science

This document, from dr. Tom way's csc 4181 lectures, covers the topics of requirements engineering and object-oriented design in compiler construction. It explains the process of establishing system requirements, the difference between functional and non-functional requirements, and the importance of writing clear and consistent requirements. Additionally, it introduces the concept of object-oriented design using the unified modeling language (uml) and provides examples of object communication and inheritance.

Typology: Papers

Pre 2010

Uploaded on 08/16/2009

koofers-user-iqa
koofers-user-iqa 🇺🇸

9 documents

1 / 5

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Dr. Tom Way CSC 4181 Slide 1
CSC 4181 – Compiler Construction
Software Engineering Lectures
Part 2
Dr. Tom Way CSC 4181 Slide 2
Software Requirements
Dr. Tom Way CSC 4181 Slide 3
Requirements engineering
zThe process of establishing the services that the
customer requires from a system and the
constraints under which it operates and is
developed.
zThe requirements themselves are the
descriptions of the system services and
constraints that are generated during the
requirements engineering process.
Dr. Tom Way CSC 4181 Slide 4
What is a requirement?
zIt may range from a high-level abstract statement
of a service or of a system constraint to a
detailed mathematical functional specification.
zThis is inevitable as requirements may serve a
dual function
May be the basis for a bid for a contract - therefore
must be open to interpretation;
May be the basis for the contract itself - therefore
must be defined in detail;
Both these statements may be called requirements.
Dr. Tom Way CSC 4181 Slide 5
Types of requirement
zUser requirements
Statements in natural language plus diagrams of the
services the system provides and its operational
constraints. Written for customers.
zSystem requirements
A structured document setting out detailed
descriptions of the system’s functions, services and
operational constraints. Defines what should be
implemented so may be part of a contract between
client and contractor.
Dr. Tom Way CSC 4181 Slide 6
Functional and non-functional requirements
zFunctional requirements
Statements of services the system should provide, how the
system should react to particular inputs and how the system
should behave in particular situations.
zNon-functional requirements
constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
process, standards, etc.
zDomain requirements
Requirements that come from the application domain of the
system and that reflect characteristics of that domain.
pf3
pf4
pf5

Partial preview of the text

Download Compiler Construction: Requirements Engineering and Object-Oriented Design and more Papers Computer Science in PDF only on Docsity!

Dr. Tom Way CSC 4181 Slide 1

CSC 4181 – Compiler Construction

Software Engineering Lectures

Part 2

Dr. Tom Way CSC 4181 Slide 2

Software Requirements

Dr. Tom Way CSC 4181 Slide 3

Requirements engineering

z The process of establishing the services that the

customer requires from a system and the

constraints under which it operates and is

developed.

z The requirements themselves are the

descriptions of the system services and

constraints that are generated during the

requirements engineering process.

Dr. Tom Way CSC 4181 Slide 4

What is a requirement?

z It may range from a high-level abstract statement

of a service or of a system constraint to a

detailed mathematical functional specification.

z This is inevitable as requirements may serve a

dual function

  • May be the basis for a bid for a contract - therefore

must be open to interpretation;

  • May be the basis for the contract itself - therefore

must be defined in detail;

  • Both these statements may be called requirements.

Types of requirement

z User requirements

  • Statements in natural language plus diagrams of the

services the system provides and its operational

constraints. Written for customers.

z System requirements

  • A structured document setting out detailed

descriptions of the system’s functions, services and

operational constraints. Defines what should be

implemented so may be part of a contract between

client and contractor.

Functional and non-functional requirements

z Functional requirements

  • Statements of services the system should provide, how the

system should react to particular inputs and how the system

should behave in particular situations.

z Non-functional requirements

  • constraints on the services or functions offered by the system

such as timing constraints, constraints on the development

process, standards, etc.

z Domain requirements

  • Requirements that come from the application domain of the

system and that reflect characteristics of that domain.

Dr. Tom Way CSC 4181 Slide 7 Functional requirements z Describe functionality or system services. z Depend on the type of software, expected users and the type of system where the software is used. z Functional user requirements may be high-level statements of what the system should do but functional system requirements should describe the system services in detail. Dr. Tom Way CSC 4181 Slide 8 Requirements imprecision z Problems arise when requirements are not precisely stated. z Ambiguous requirements may be interpreted in different ways by developers and users. z Consider the term ‘appropriate viewers’

  • User intention - special purpose viewer for each

different document type;

  • Developer interpretation - Provide a text viewer that

shows the contents of the document.

Dr. Tom Way CSC 4181 Slide 9 Requirements completeness and consistency

z In principle, requirements should be both complete and

consistent.

z Complete

  • They should include descriptions of all facilities

required.

z Consistent

  • There should be no conflicts or contradictions in the

descriptions of the system facilities.

z In practice, it is impossible to produce a complete and

consistent requirements document.

Dr. Tom Way CSC 4181 Slide 10 Non-functional requirements z These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. z Process requirements may also be specified mandating a particular CASE system, programming language or development method. z Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless. Non-functional classifications

z Product requirements

  • Requirements which specify that the delivered product must

behave in a particular way e.g. execution speed, reliability, etc.

z Organisational requirements

  • Requirements which are a consequence of organisational

policies and procedures e.g. process standards used,

implementation requirements, etc.

z External requirements

  • Requirements which arise from factors which are external to the

system and its development process e.g. interoperability

requirements, legislative requirements, etc.

Domain requirements z Derived from the application domain and describe system characteristics and features that reflect the domain. z Domain requirements be new functional requirements, constraints on existing requirements or define specific computations. z If domain requirements are not satisfied, the system may be unworkable.

Dr. Tom Way CSC 4181 Slide 19 Object communication

z Conceptually, objects communicate by

message passing.

z Messages

  • The name of the service requested by the calling object;
  • Copies of the information required to execute the service

and the name of a holder for the result of the service.

z In practice, messages are often implemented

by procedure calls

  • Name = procedure name;
  • Information = parameter list. Dr. Tom Way CSC 4181 Slide 20 Message examples // Call a method associated with a buffer // object that returns the next value // in the buffer v = circularBuffer.Get () ; // Call the method associated with a // thermostat object that sets the // temperature to be maintained thermostat.setTemp (20) ; Dr. Tom Way CSC 4181 Slide 21 Generalisation and inheritance

z Objects are members of classes that define

attribute types and operations.

z Classes may be arranged in a class hierarchy

where one class (a super-class) is a generalisation of one

or more other classes (sub-classes).

z A sub-class inherits the attributes and

operations from its super class and may add

new methods or attributes of its own.

z Generalisation in the UML is implemented as inheritance

in OO programming languages.

Dr. Tom Way CSC 4181 Slide 22 A generalisation hierarchy UML associations

z Objects and object classes participate in relationships

with other objects and object classes.

z In the UML, a generalised relationship is indicated by an

association.

z Associations may be annotated with information that

describes the association.

z Associations are general but may indicate that an

attribute of an object is an associated object or that a

method relies on an associated object.

An association model

Use-case models z Use-case models are used to represent each interaction with the system. z A use-case model shows the system features as ellipses and the interacting entity as a stick figure. Use-cases for the weather station