CSC 506: Software Engineering and

Knowledge Engineering

Dr. Syed Noman Hasany

Course Outline

• Review of known methodologies • Analysis of software requirements • Real-time software • Software cost, quality, testing and measurements • Object programming • Knowledge engineering issues: knowledge

representation using rules, frames & logic, basics of logical inference, and basics of search.

The mother of Qualities: Simplicity

• Work very hard to keep everything as simple as you can

• We all have an intuitive notion of simplicity• We recognize simplicity

• In clear and easy to understand speaking and writing• In uncluttered (neat and organized) forms• In a good teacher’s explanation• In a leader’s setting of goals and strategies

Simplicity

• Many of these intuitive ideas can be applied to programming as well.

• Simpler programs are easier to use, review, document and modify with the result of significantly reduced cost in all phases of the process

• Software engineering is also, in large part, about rendering artifacts readable and usable by people as well as (if not more so than) by machines.

Achieving Simplicity is NOT simple• Achieving simplicity sometimes requires extra work.• Documentation written from the point of view of the

writer is not nearly so useful as document written from the point of view of the reader.

• Achieving the reader’s perspective requires more work, but results in a document that is vastly simpler to understand , to reference, to use, than one that results from an author’s stream of consciousness.

• “I had happily spend two hours pondering how to make a simple sentence clearer” --- E. Dijkstra (the inventor of many software Engineering principles)

What is software?

• Computer programs and associated documentation

Software Products Categories• Software products may be

• Generic - developed to be sold to a range of different customers

• Bespoke (custom) - developed for a single customer according to their specification

Software Engineering (In general)

Software engineering is an engineering disciplinea which is concerned with all

aspects of software productionb

Software Engineering Definitions

• Classic Definition (1969)• “The establishment and use of sound engineering

principles in order to obtain economically software that is reliable and works efficiently on real machines”

• IEEE Definition (1993)• “Software engineering (1) The application of a systematic,

disciplines, quantifiable approach to the development, operation and maintenance of software; that is the application of engineering to software. (2) The study of approaches as in (1).”

Difference between software engineering and computer science

• Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software.

• Computer science theories are currently insufficient to act as a complete underpinning (foundation) for software engineering.

• Software engineers must often use ad hoc approaches to develop the software. (Research is in progress and will remain in progress!)

What is a software process?

• A set of activities whose goal is the development or evolution of software

• Mostly carried out by software Engineers• Generic activities in all software processes are:

• Specification - what the system should do and its development constraints

• Development - production of the software system• Validation - checking that the software is what the

customer wants• Evolution - changing the software in response to changing

demands

Software costs• Software costs often dominate system costs. The

costs of software on a PC are often greater than the hardware cost.

• Software costs more to maintain than it does to develop. For systems with a long life, maintenance costs may be several times development costs

• Software engineering is concerned with cost-effective software development

What are the costs of software engineering?

• Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs

• Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability

• Distribution of costs depends on the development model that is used

Product development costs

Specification Development System testing

25 50 75 1000

For software products that are (mostly) sold for PCs, the cost profile is likely to be different. Specification costs are relatively low. However, because they are intended for use on a range of different configurations, they must be extensively tested.

Activity cost distributionWaterfall model

Iterative development

Component-based software engineering

Development and evolution costs for long-lifetime systems

System evolution

10 200 30 4000

System development

Specification Design Development Integration and testing

25 50 75 1000

Specification Development Integration and testing

25 50 75 1000

Specification Iterative development System testing

25 50 75 1000

What is CASE (Computer-Aided Software Engineering)

• Software systems which are intended to provide automated support for software process activities. CASE systems are often used for method support

• Upper-CASE• Tools to support the early process activities of

requirements and design

• Lower-CASE• Tools to support later activities such as programming,

debugging and testing

Attributes of good software• The software should deliver the required functionality

and performance to the user and should be maintainable, dependable and usable

• Maintainability• Software must evolve to meet changing needs

• Dependability• Software must be trustworthy

• Efficiency• Software should not make wasteful use of system

resources• Usability

• Software must be usable by the users for which it was designed

Key challenges facing Software Engineering• Coping with legacy systems, coping with increasing

diversity and coping with demands for reduced delivery times

• Legacy systems• Old, valuable systems must be maintained and updated

• Heterogeneity• Systems are distributed and include a mix of hardware

and software• Delivery

• There is increasing pressure for faster delivery of software

Professional and ethical responsibility

• Software engineering involves wider responsibilities than simply the application of technical skills

• Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals

• Ethical behaviour is more than simply upholding the law.

Plan-driven and agile processesPlan-driven processes are processes where all of

the process activities are planned in advance and progress is measured against this plan.

In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements.

In practice, most practical processes include elements of both plan-driven and agile approaches.

There are no right or wrong software processes.

20

Generic Software process modelsA. The waterfall modelB. Incremental developmentC. Reuse-oriented software engineeringD. SpiralE. RUP In practice, most large systems are developed

using a process that incorporates elements from all of these models.

21

A. The waterfall model

22

Waterfall model problemsThe main drawback of the waterfall model is the difficulty of

accommodating change after the process is underway. In principle, a phase has to be complete before moving onto the next phase.

Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.◦ Therefore, this model is only appropriate when the

requirements are well-understood and changes will be fairly limited during the design process.

◦ Few business systems have stable requirements.The waterfall model is mostly used for large systems engineering

projects where a system is developed at several sites.◦ In those circumstances, the plan-driven nature of the waterfall

model helps coordinate the work.

23

B. Incremental development

24

Incremental development

• In outline description, customers identify the services to be provided by the system.

• Concurrent means in parallel.• Incremental development in some form is now the

most common approach for the development of application systems. This approach can be either plan-driven, agile, or, more usually, a mixture of these approaches.

• In a plan-driven approach, the system increments are identified in advance;

• if an agile approach is adopted, the early increments are identified but the development of later increments depends on progress and customer priorities.

25

C. Reuse-oriented software engineeringBased on systematic reuse where systems are

integrated from existing components or COTS (Commercial-off-the-shelf) systems.

Process stages◦ Component analysis;◦ Requirements modification;◦ System design with reuse;◦ Development and integration.

Reuse is now the standard approach for building many types of business system

26

Reuse-oriented software engineering

27

D. Boehm’s spiral model

A risk-driven software process framework proposed by Boehm (1988).

Process is represented as a spiral rather than as a sequence of activities with backtracking.

Each loop in the spiral represents a phase in the process (the innermost loop might be concerned with system feasibility, the next loop with requirements definition, the next loop with system design, and so on)

No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.

Chapter 2 Software Processes 28

Boehm’s spiral model of the software process

29

Risk

• Risk simply means something that can go wrong. For example, if the intention is to use a new programming language, a risk is that the available compilers are unreliable or do not produce sufficiently efficient object code.

• Risks lead to proposed software changes and project problems such as schedule and cost overrun, so risk minimization is a very important project management activity.

E. The Rational Unified Process

A modern hybrid generic process model derived from the work on the UML and associated process.

Hybrid because it brings together aspects of the 3 generic process models discussed previously.

Phases in the RUP are more closely related to business rather than technical concerns.

Normally described from 3 perspectives◦ A dynamic perspective that shows phases over time;◦ A static perspective that shows process activities;◦ A practice perspective that suggests good practice.

Chapter 2 Software Processes 31

Phases in the Rational Unified Process

Chapter 2 Software Processes 32

RUP phases (dynamic)Inception

◦ Establish the business case for the system.Elaboration

◦ The goals of the elaboration phase are to develop an understanding of the problem domain, establish an architectural framework for the system, develop the project plan, and identify key project risks. On completion of this phase you should have a requirements model for the system, which may be a set of UML use-cases, an architectural description, and a development plan for the software.

Construction◦ System design, programming and testing.

Transition◦ Deploy the system in its operating environment.

Chapter 2 Software Processes 33

RUP iteration

• In-phase iteration• Each phase is iterative with results developed

incrementally.

• Cross-phase iteration• As shown by the loop in the RUP model, the whole set

of phases may be enacted/passed incrementally.

Chapter 2 Software Processes 34

Requirements• The requirements are the descriptions of the system

services and constraints that are generated during the requirements engineering process.

• It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.

35

Requirements engineering• The process of establishing:

• the services that the customer requires from a system and • the constraints under which it operates and is developed.

• The outcome is a requirements document, which may be part of the system development contract.

36

User and system requirements: example

37

1. Functional and non-functional requirementsFunctional 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.

May state what the system should not do.Non-functional requirements

Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

Often apply to the system as a whole rather than individual features or services.

Domain requirementsConstraints on the system from the application domain (e.g.

medical domain)

38

Functional requirements for the MHC-PMSA user shall be able to search the appointments lists

for all clinics.The system shall generate each day, for each clinic, a

list of patients who are expected to attend appointments that day.

Each staff member using the system shall be uniquely identified by his or her 8-digit employee number.

39

Non-functional requirements implementationNon-functional requirements may affect the overall

architecture of a system rather than the individual components.

For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components.

A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required.

40

Types of nonfunctional requirement

41

Non-functional classificationsProduct requirements

Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.

Organisational requirements Requirements which are a consequence of organisational policies

and procedures development process requirements that specify the programming language, the development environment or process standards to be used, and environmental requirements that specify the operating environment of the system.

External requirements Requirements which arise from factors which are external to the

system and its development process e.g. interoperability requirements, legislative requirements, etc.

42

Examples of nonfunctional requirements in the MHC-PMS

43

Product requirementThe MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day.

Organizational requirementUsers of the MHC-PMS system shall authenticate themselves using their health authority identity card.

External requirementThe system shall implement patient privacy provisions as set out in HStan-03-2006-priv.

The software requirements documentThe software requirements document is the official

statement of what is required of the system developers.

Should include both a definition of user requirements and a specification of the system requirements.

It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it.

44

Users of a requirements document

45

Traceability

• Part of requirement management process

• Technique to provide relationship between requirement design and final implementation

• How and why system development products satisfy stakeholders requirements

• Ability to discover the history of every feature of a system

• A quality factor

• Many standards (2167-A then 498) require the development of traceability documents

The Role of Traceability in Systems Development

• Definition of traceability:• "The degree to which a relationship can be established between

two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another; for example, the degree to which the requirements and design of a given software component match." (IEEE 610.12-1990)

• Experience has shown that the ability to trace requirements through the stages of specification, architecture, design, implementation, and testing is a significant factor in assuring a quality software implementation.

The Traceability Relationship

• A traceability relationship is a relationship between two project elements.

• A traceability relationship is a type of dependency relationship between elements.

• A dependency relationship states that a change in one element (A) may affect another element (B), but the reverse is not necessarily true.

A model of traceability

Syst_components

Verification_procedRequirement Developed_for

DeriveAllocated_to

External_System

Performed_onsatisfy

Interface_with

A Generalized Traceability Model

Traceability Matrix: User Needs versus Features

Traceability Matrix: User Needs versus Features

• After establishing all known need–feature relationships, there is again a need to examine the traceability matrix for potential indications of error.

• If inspection of a row fails to detect any Xs, a possibility exists that no feature is yet defined to respond to a user need.

• If inspection of a column fails to detect any Xs, a possibility exists that a feature has been included for which there is no defined product need.

Representation – Traceability Table

• Show the relationships between requirements or between requirements and other activities

• Table can be set up to show links between several different elements

A good Example: http://www.softwaretestinghelp.com/requirements-traceability-matrix/

Simple Traceability List• A simplified form of a traceability matrix may be used

where, along with each requirement description, one or more lists of the identifiers of related requirements are maintained

Using Traceability Tools

• Offer a simple user-guided procedure to "point and click" through the explicit relationships that may exist between two elements of the lifecycle.

• Allow building large matrices required for more sophisticated projects and to examine the data automatically for many of the types of potential red flags.

• Provide support for some of the implicit forms of traceability (e.g. use case to use-case realization), and provide navigational mechanisms and other methods to help assure that the implementation is correct as the application evolves.

Proceeding without Traceability Tools • Many of the matrix relationships could be easily

handled with a spreadsheet.

• The problem with spreadsheets, however, is maintenance, especially in extensive hierarchies of relationships.

• The other alternative is to use a database.

System modelingSystem modeling is the process of developing

abstract models of a system, with each model presenting a different view or perspective of that system.

• A picture is a replacement of thousands of words.

57

Data driven behavioral model• Many business systems are data processing

systems that are primarily driven by data. They are controlled by the data input to the system with relatively little external event processing. Their processing involves a sequence of actions on that data and the generation of an output.

• For example, a phone billing system will accept information about calls made by a customer, calculate the costs of these calls, and generate a bill to be sent to that customer.

58

Data Flow Diagrams (DFDs)• Used for data-driven modelling • Data flow diagrams (DFDs) are one of the

diagramming techniques(graphical models) used in structured systems analysis and design

• Data flow diagrams show:• Data flowing through a system to or from users (external

entities)• The processes that transform the data• The data stores that hold the data

59

DFD Elements• Process

• Activity/function that is performed for some specific business reason. Names start with a verb and ending with a noun (e.g., “Determine request quantity”).

• Data Flow• A data flow is a single piece of data (e.g., quantity available)

(also called a data element), should be named with a noun.• Data Store

• collection of data that is stored in some way, named with a noun and is assigned an identification number.

• External Entity• a person, organization, organization unit, or system that is

external to the system, but interacts with it.60

61

Data Flow Diagram Symbols

DFD Levels Decomposition is the process of

modeling the system and its components in increasing levels of detail. Context DFD

Overview of the organizational system. Level-0 DFD

Representation of system’s major processes at high level of abstraction.

Level-1 DFD

Results from decomposition of Level 0 diagram. Level-n DFD

Results from decomposition of Level n-1 diagram.62

Context Diagram

Context diagram shows the system boundaries, external entities that interact with the system, and major information flows between entities and the system.NOTE: only one process symbol, and no data stores

shown.63

Level-0 DFD

Level-0 DFD shows the system’s major processes, data flows, and data stores at a high level of abstraction.

Processes are labeled 1.0, 2.0, etc. These will be decomposed into more primitive (lower-level) DFDs. Depletion means reduction.

64

Level-1 DFD

Level-1 DFD shows the sub-processes of one of the processes in the Level-0 DFD.

This is a Level-1 DFD for Process 4.0.

Processes are labeled 4.1, 4.2, etc. These can be further decomposed in more primitive (lower-level) DFDs if necessary. 65

Level-n DFD

Level-n DFD shows the sub-processes of one of the processes in the Level n-1 DFD.

This is a Level-2 DFD for Process 4.3.Processes are labeled 4.3.1, 4.3.2, etc. If this is the

lowest level of the hierarchy, it is called a primitive DFD.

66

DFD Diagramming Rules Process

No process can have only outputs or only inputs. Processes must have both outputs and inputs.

Process labels should be verb phrases.67

DFD Diagramming Rules Data Store

Data Store labels should be noun phrases.

All flows to or from a data store must move through a process.

68

DFD Diagramming Rules Source/Sink

Source and Sink labels should be noun phrases.

No data moves directly between external entities without going through a process.

Interactions between external entities without intervening processes are outside the system and therefore not represented in the DFD.

69

Bidirectional flow between process and data store is represented by two separate arrows.

Forked data flow must refer to exact same data item (not different data items) from a common location to multiple destinations.

DFD Diagramming Rules Data Flow

70

Joined data flow must refer to exact same data item (not different data items) from multiple sources to a common location.

Data flow cannot go directly from a process to itself, must go through intervening processes.

DFD Diagramming Rules Data Flow

71

Some Common Errors

72

Balancing Balancing involves insuring that

information presented at one level of a DFD is accurately represented in the next level DFD.

73

Balancing the DFD

74

Unbalanced DFD

This is unbalanced because the process of the context diagram has only one input but the Level-0 diagram has two inputs.

1 input

1 output

2 inputs

1 output

75

Balanced DFD

These are balanced because the numbers of inputs and outputs of context diagram process equal the number of inputs and outputs of Level-0 diagram. 76

Balanced DFD (cont.)

These are balanced because the numbers of inputs and outputs to Process 1.0 of the Level-0 diagram equals the number of inputs and outputs to the Level-1 diagram.

1 input

4 outputs

77

An Example: Tune Source(from System analysis and design, by Dennis, Wixom, Roth; 5th Ed.)

• Tune Source is a company headquartered in southern California, known as the place to go to find rare audio recordings.

• Tune Source currently has a website that enables customers to search for and purchase CDs. This site was initially developed by an Internet consulting firm and is hosted by a prominent local Internet Service Provider (ISP) in Los Angeles. The IT department at Tune Source has become experienced with Internet technology as it has worked with the ISP to maintain the site.

78

An Example: Tune Source(from System analysis and design, by Dennis, Wixom, Roth; 5th Ed.)

• Business Need: • This project has been initiated to increase sales by creating the

capability of selling digital music downloads to customers through kiosks(stalls) in our stores, and over the Internet using our website.

• Business Requirements: • Using the Web or in-store kiosks, customers will be able to search

for and purchase digital music downloads. The specific functionality that the system should have includes the following:

• Search for music in our digital music archive.• Listen to music samples.• Purchase individual downloads at a fixed fee per download.• Establish a customer subscription account permitting unlimited

downloads for a monthly fee.• Purchase music download gift cards.

79

An Example: Tune Source(from System analysis and design, by Dennis, Wixom, Roth; 5th Ed.)

80

81

82

83

Find errors??

UML• The Unified Modeling Language is a set of 14 different

diagram types that may be used to model software systems.

• It emerged from work in the 1990s on object-oriented modeling where similar object-oriented notations were integrated to create the UML. A major revision (UML 2) was finalized in 2004.

• The UML is universally accepted as the standard approach for developing models of software systems. Variants have been proposed for more general system modeling.

84

Why DFDs aren’t used in O-O• In DFDs a clear separation is made between processes

and stored data.• It is assumed that all data is ‘visible’ to any process

that needs to access it.• In an O-O system the processes that operate on data

are the methods of the classes that contain the data as attributes.

• Data is encapsulated within objects, and may be hidden too.

8585

UML diagrams• The UML has many diagram types and so supports the creation of many

different types of system model. However, a survey in 2007 (Erickson and Siau, 2007) showed that most users of the UML thought that five diagram types could represent the essentials of a system:

1. Activity diagrams, which show the activities involved in a process or in data processing.

2. Use case diagrams, which show the interactions between a system and its environment.

3. Sequence diagrams, which show interactions between actors and the system and between system components.

4. Class diagrams, which show the object classes in the system and the associations between these classes.

5. State diagrams, which show how the system reacts to internal and external events.

86

UML diagrams• Fortunately, four UML diagramming techniques have

come to dominate object-oriented projects: • Use case diagrams, • Class diagrams, • Sequence diagrams, and • Behavioral state machine diagrams.

• The other diagramming techniques are useful for their particular purposes, but these four techniques form the core of UML as used in practice today

87

UML diagrams• The use case diagram is always created first, but the order in which the

other diagrams are created depends upon the project and the personal preferences of the analysts.

• Then class diagrams, sequence diagrams, and behavioral state machine diagrams are used to further define the evolving system from various perspectives.

• Most analysts start either with the class diagrams (showing what objects contain and how they are related, much like ERDs) or the sequence diagrams (showing how objects dynamically interact, much like DFDs), but in practice, the process is iterative.

• Developing sequence diagrams often leads to changes in the class diagrams and vice versa, so analysts often move back and forth between the two, refining each in turn as they define the system. Generally speaking, behavioral state machine diagrams are developed later, after the class diagrams have been refined.

88

Interaction modelsModeling user interaction is important as it helps to

identify user requirements. Modeling system-to-system interaction highlights the

communication problems that may arise. Modeling component interaction helps us understand

if a proposed system structure is likely to deliver the required system performance and dependability.

Use case diagrams and sequence diagrams may be used for interaction modeling.

89

Use case modelingUse cases were developed originally to support

requirements elicitation and now incorporated into the UML.

Each use case represents a discrete task that involves external interaction with a system.

Actors in a use case may be people or other systems.

90

Use cases in the MHC-PMS involving the role ‘Medical Receptionist’

91

Creating a Use Case Diagram• Identify Use Cases• Draw the System Boundary• Place the Use Cases on the Diagram• Identify the Actors• Add Association Relationships

92

Use Case Relationships

• Relationships• Represent communication between actor and use

case• Depicted by line or double-headed arrow line• Also called association relationship

• Other Types of Relationships for Use Cases• Generalization (From child to parent)• Include• Extend

93

Use Case Relationships

94

Use Case Relationships

• Include Relationship• Represents the inclusion of the functionality of

one use case within another • Common use case included in other use

cases (avoids duplicate functionality)• Arrow is drawn from the base use case to the

used use case• Write << include >> above arrowhead line• Include = reuse of functionality

95

Use Case Relationships

• Extend relationship• Represents the extension of the use case to

include optional functionality • Arrow is drawn from the extension use case to

the base use case• Write << extend >> above arrowhead line• Extends = new and/or optional functionality

• For example “assess fee” for ATM user drawing money from X-banks’ ATM where he does not have the account!

96

Sequence diagramsSequence diagrams are part of the UML and are used

to model the interactions between the actors and the objects within a system.

A sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance.

The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these.

Interactions between objects are indicated by annotated arrows.

97

98

Elements of a Sequence Diagram• Actors and objects participating in the sequence are

placed across the top of the diagram, depicted by actor symbols from the use case diagram or unlabeled rectangles.

• For each of the objects, the name of the class that they are an instance of is given after the object’s name.

• A dotted line runs vertically below each actor and object to denote the lifeline of the actors/objects over time.

99

Elements of a Sequence Diagram• A thin, rectangular box, called the execution occurrence, is

overlaid onto the lifeline to show when the classes are sending and receiving messages.

• A message is a communication between objects that conveys information, with the expectation that activity will ensue, and messages passed between objects are shown by solid lines connecting two objects, called links.

• The arrow on the link shows which way the message is being passed, and any argument values for the message are placed in parentheses next to the message’s name. The order of messages goes from top to bottom, so messages located higher on the diagram represent messages that occur earlier in the sequence, versus the lower messages that occur later.

100

Elements of a Sequence Diagram• There are times that a message is sent only if a

condition is met. In those cases, the condition is placed between a set of [], such as [Authorization Ok]

• It is possible to explicitly show the return from a message, with a return link, a dashed message. However, adding return links tends to clutter the diagram. Therefore, unless the return links add a lot of information to the diagram, they should be omitted.

• The interaction operator alt means that the combined fragment represents a choice or alternatives of behavior.

101

Sequence diagram for “View patient information”

102

Description of the sequence diagram

a. The medical receptionist triggers the ViewInfo method in an instance P of the PatientInfo object class, supplying the patient’s identifier, PID. P is a user interface object, which is displayed as a form showing patient information.

b. The instance P calls the database to return the information required, supplying the receptionist’s identifier to allow security checking.

c. The database checks with an authorization system that the user is authorized for this action.

d. If authorized, the patient information is returned and a form on the user’s screen is filled in. If authorization fails, then an errormessage is returned.

103

Sequence diagram for Transfer Data

104Chapter 5 System modeling

Description of the sequence diagram1. The receptionist logs on to the PRS.

2. There are two options available. These allow the direct transfer of updated patient information to the PRS and the transfer of summary health data from the MHC-PMS to the PRS.

3. In each case, the receptionist’s permissions are checked using the authorization system.

4. Personal information may be transferred directly from the user interface object to the PRS. Alternatively, a summary record may be created from the database and that record is then transferred.

5. On completion of the transfer, the PRS issues a status message and the user logs off.

105

Real-time system• A real-time system is a software system where the

correct functioning of the system depends on the results produced by the system and the time at which these results are produced

• A ‘soft’ real-time system is a system whose operation is degraded if results are not produced according to the specified timing requirements

• A ‘hard’ real-time system is a system whose operation is incorrect if results are not produced according to the timing specification

Stimulus/Response Systems• Given a stimulus, the system must produce a

response within a specified time• Periodic stimuli. Stimuli which occur at predictable

time intervals• For example, a temperature sensor may be polled 10

times per second

• Aperiodic stimuli. Stimuli which occur at unpredictable times

• For example, a system power failure may trigger an interrupt which must be processed by the system

System elements

• Sensors control processes• Collect information from sensors. May buffer

information collected in response to a sensor stimulus

• Data processor• Carries out processing of collected information

and computes the system response• Actuator control

• Generates control signals for the actuator

Sensor/actuator processes

Dataprocessor

Actuatorcontrol

Actuator

Sensorcontrol

Sensor

Stimulus Response

R-T systems design process• Identify the stimuli to be processed and the

required responses to these stimuli• For each stimulus and response, identify the timing

constraints• Aggregate the stimulus and response processing

into concurrent processes. A process may be associated with each class of stimulus and response

R-T systems design process• Design algorithms to process each class of stimulus

and response. These must meet the given timing requirements

• Design a scheduling system which will ensure that processes are started in time to meet their deadlines

• Integrate using a real-time executive or operating system

Timing constraints

• May require extensive simulation and experiment to ensure that these are met by the system

• May mean that certain design strategies such as object-oriented design cannot be used because of the additional overhead involved

• May mean that low-level programming language features have to be used for performance reasons

Real-time executives• Real-time executives are specialised operating

systems which manage the processes in the RTS• Responsible for process management and resource

(processor and memory) allocation• May be based on a standard RTE kernel which is

used as it is i.e. unchanged or modified for a particular application

• Does not include facilities such as file management.

14

Executive components• Real-time clock

• Provides information for process scheduling.

• Interrupt handler• Manages aperiodic requests for service.

• Scheduler• Chooses the next process to be run.

• Resource manager• Allocates memory and processor resources.

• Despatcher• Starts process execution.

Real-time executive components

Process resourcerequirements

Scheduler

Schedulinginformation

Resourcemanager

Despatcher

Real-timeclock

Processesawaitingresources

Readylist

Interrupthandler

Availableresource

list

Processorlist

Executingprocess

Readyprocesses

Releasedresources

Process priority• The processing of some types of stimuli must

sometimes take priority• Interrupt level priority. Highest priority which is

allocated to processes requiring a very fast response

• Clock level priority. Allocated to periodic processes• Within these, further levels of priority may be

assigned

Interrupt servicing• Control is transferred automatically to a

pre-determined memory location• This location contains an instruction to jump to an

interrupt service routine• Further interrupts are disabled, the interrupt

serviced and control returned to the interrupted process

• Interrupt service routines MUST be short, simple and fast

Periodic process servicing

• In most real-time systems, there will be several classes of periodic process, each with different periods (the time between executions), execution times and deadlines (the time by which processing must be completed)

• The real-time clock ticks periodically and each tick causes an interrupt which schedules the process manager for periodic processes

• The process manager selects a process which is ready for execution

Process switching

• The scheduler chooses the next process to be executed by the processor. This depends on a scheduling strategy which may take the process priority into account

• The resource manager allocates memory and a processor for the process to be executed

• The despatcher takes the process from ready list, loads it onto a processor and starts execution

Program testing• Testing is intended to show that a program does what

it is intended to do and to discover program defects before it is put into use.

• When software is tested, a program may be execute using artificial data.

• Can reveal the presence of errors NOT their absence.• Testing is part of a more general verification and

validation process, which also includes static validation techniques.

120

Testing process goals• Validation testing

• To demonstrate to the developer and the system customer that the software meets its requirements

• A successful test shows that the system operates as intended.

• Defect testing• To discover faults or defects in the software where its

behavior is incorrect or not in conformance with its specification

• A successful test is a test that makes the system perform incorrectly and so exposes a defect in the system.

121

• Verification: "Are we building the product right”.

• The software should conform to programs specification.

• Validation: "Are we building the right product”.

• The software should do what the user really requires.

Verification vs validation

122

Software inspections• These involve people examining the source

representation with the aim of discovering anomalies and defects.

• Inspections not require execution of a system so may be used before implementation.

• Inspection is done to any representation of the system (requirements, design, configuration data, test data, etc.).

123

Inspection and Testing

124

A model of the software testing process

125

Stages of testingA. Development testing: the system is tested during

development to discover bugs and defects. B. Release testing: a separate testing team test a

complete version of the system before it is released to users.

C. User testing: users or potential users test the system in their own environment.

126

Development testing• Development testing includes all testing activities that

are carried out by the team developing the system. • Unit testing: Individual program units or object classes are

tested. E.g. Testing class of summarize_data• Component testing: Several individual units are integrated to

create composite components. Main focus on testing component interfaces. E.g. Testing report generation

• System testing: some or all components are integrated and the system is tested as a whole. Main focus on testing component interactions.

127

Automated testing• Unit testing can be automated so that tests are run and

checked without manual intervention.• A test automation framework (such as JUnit) is available to

write and run program tests. • The tests are embedded in a separate program that runs

the tests and invokes the system that is being tested. Using this approach, it is possible to run hundreds of separate tests in a few seconds.

128

Automated test components• A setup part, where you initialize the system with

the test case, namely the inputs and expected outputs.

• A call part, where you call the object or method to be tested.

• An assertion part where you compare the result of the call with the expected output. If the assertion evaluates to true, the test has been successful if false, then it has failed.

129

Test-driven development• Test-driven development (TDD) is an approach to

program development in which you inter-leave testing and code development.

• Tests are written before code and ‘passing’ the tests is the critical driver of development.

• Code is developed incrementally along with a test for that increment; moving to the next increment is allowed when the developed code passes its test.

130

Test-driven development

131

"Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure." -- Martin Fowler

TDD process activities• Start by identifying the increment of functionality that

is required. This should normally be small and implementable in a few lines of code.

• Write a test for this functionality and implement this as an automated test.

• Run the test, along with all other tests that have been implemented. Initially, you have not implemented the functionality so the new test will fail.

• Implement the functionality and re-run the test. • Once all tests run successfully, you move on to

implementing the next chunk of functionality.

132

Benefits of test-driven development• Code coverage

• Every code segment that you write has at least one associated test so all code parts written has at least one test.

• Regression testing • A regression (deterioration) test suite (group) is developed

incrementally as a program is developed. • Simplified debugging

• When a test fails, it should be obvious where the problem lies. The newly written code needs to be checked and modified.

• System documentation • The tests themselves are a form of documentation that describe

what the code should be doing.

133

B. Release testing• Release testing is the process of testing a particular

release of a system that is intended for use outside of the development team.

• The primary goal is to convince the supplier of the system that it is good enough for use.

• Release testing, therefore, has to show that the system delivers its specified functionality, performance and dependability, and that it does not fail during normal use.

• It is usually a black-box testing process where tests are only derived from the system specification.

134

Release testing and system testing

• Release testing is like system testing, but…• Important differences:

• A separate team that has not been involved in the system development, should be responsible for release testing.

• System testing by the development team should focus on discovering bugs in the system (defect testing). The objective of release testing is to check that the system meets its requirements and is good enough for external use (validation testing).

135

Release testing types• Requirements-based testing• Scenario testing• Performance testing

136

B1. Requirements based testing• Requirements-based testing involves examining each

requirement and developing a test or tests for it.• MHC-PMS requirements:

• If a patient is known to be allergic to any particular medication, then prescription of that medication shall result in a warning message being issued to the system user.

• If a prescriber chooses to ignore an allergy warning, they shall provide a reason why this has been ignored.

137

Requirements tests: Example• Set up a patient record with no known allergies. Prescribe medication for

allergies that are known to exist. Check that a warning message is not issued by the system.

• Set up a patient record with a known allergy. Prescribe the medication to that the patient is allergic to, and check that the warning is issued by the system.

• Set up a patient record in which allergies to two or more drugs are recorded. Prescribe both of these drugs separately and check that the correct warning for each drug is issued.

• Prescribe two drugs that the patient is allergic to. Check that two warnings are correctly issued.

• Prescribe a drug that issues a warning and overrule that warning. Check that the system requires the user to provide information explaining why the warning was overruled.

138

B2. Scenario Testing• A scenario is a story that describes one way in which

the system might be used. • Scenarios should be realistic and real system users

should be able to relate to them.• In a short paper on scenario testing, Kaner (2003)

suggests that a scenario test should be a narrative story that is credible and fairly complex.

139

Scenario Testing Example

• It tests a number of features of the MHC-PMS:1. Authentication by logging on to the system.2. Downloading and uploading of specified patient records to a laptop.3. Home visit scheduling, etc…

140

B3. Performance testing• Performance testing is concerned both with

demonstrating that the system meets its requirements and discovering problems and defects in the system.

• Performance tests usually involve planning a series of tests where the load is steadily increased until the system performance becomes unacceptable.

• Stress testing is a form of performance testing where the system is deliberately overloaded to test its failure behavior.

141

Performance testing: pros and cons• In performance testing, this means stressing the

system by making demands that are outside the design limits of the software. This is known as ‘stress testing’.

• For example, say you are testing a transaction processing system that is designed to process up to 300 transactions per second. You start by testing with fewer than 300 transactions per second. You then gradually increase the load beyond 300 transactions per second until it is well beyond the maximum design load of the system and the system fails.

142

Performance testing: pros and cons• It tests the failure behavior of the system.• It is particularly relevant to distributed systems

based on a network of processors. These systems often exhibit severe degradation when they are heavily loaded.

143

User testing• User or customer testing is a stage in the testing

process in which users or customers provide input and advice on system testing.

• User testing is essential, even when comprehensive system and release testing have been carried out.

• The reason for this is that influences from the user’s working environment have a major effect on the reliability, performance, usability and robustness of a system. These cannot be replicated in a testing environment.

144

Types of user testing• Alpha testing

• Users of the software work with the development team to test the software at the developer’s site.

• Beta testing• A release of the software is made available to users to allow

them to experiment and to raise problems that they discover with the system developers.

• Acceptance testing• Customers test a system to decide whether or not it is ready

to be accepted from the system developers and deployed in the customer environment. Primarily for custom systems.

145

Plan-driven vs Agile approach

• Agile approach to software development consider design and implementation to be the central activities in the software process. They incorporate other activities, such as requirements elicitation and testing, into design and implementation.

• By contrast, a plan-driven approach to software engineering identifies separate stages in the software process with outputs associated with each stage. The outputs from one stage are used as a basis for planning the following process activity.

146

Plan-driven vs Agile approach

147

Agile methods and acceptance testing• In agile methods, the user/customer is part of the

development team and is responsible for making decisions on the acceptability of the system.

• Tests are defined by the user/customer and are integrated with other tests in that they are run automatically when changes are made.

• There is no separate acceptance testing process.• Main problem here is whether or not the embedded

user is ‘typical’ and can represent the interests of all system stakeholders.

148

Knowledge

• What is knowledge?• Knowledge is the sort of information that

people use to solve problems. • Knowledge includes:

• facts, concepts, procedures, models, heuristics, examples.

• Knowledge may be:• specific or general• exact or fuzzy• procedural or declarative

Expert systems

• What is an expert system?• A particular kind of knowledge-based system• One in which the knowledge, stored in the knowledge

base, has been taken from an expert in some particular field.

• Therefore, an expert system can, to a certain extent, act as a substitute for the expert from whom the knowledge was taken.

Knowledge in Expert Systems

Conventional Programming

Knowledge-Based Systems

Algorithms

+ Data Structures

= Programs

Knowledge

+ Inference

= Expert System

152

Components of Knowledge Base System

Knowledge base

Inference engine

User interface

Explanation and

reasoning

Self-learning

Figure 1.10: General structure of KBS

Enriches the system with self-learning capabilities

Provides explanation and

reasoning facilities

Knowledge base is a repository of domain knowledge and metaknowledge.

Inference engine is a software program that infers the knowledge available in

the knowledge base.

What is logic?• Logic determines whether it is justified to reason

from given assumptions to a conclusion

• note: a logician cannot determine whether it rains• he can conclude it rains from the assumptions if I hear

drips on the roof, then it rains and I hear drips on the roof• There exist many logics.

Logic• The basis of logic programming is formal logic.• Logic determines whether it is justified to reason from

given assumptions to a conclusion.• A proposition can be thought of as a logical statement

that may or may not be true.• Symbolic logic can be used for the three basic needs

of formal logic: • To express propositions, • To express the relationships between propositions, and • To describe how new propositions can be inferred from

other propositions that are assumed to be true.

Proposition• A statement in some language that can be evaluated

to either true or false (cannot be both at a time).

Example propositions:• It is raining.• 5 + 5 = 10.• Turkey is in Asia.

Not propositions:• Where are you?• Oh no!• You are not.

Connectives• The syntax of propositional logic is made up of

propositions and connectives.• Propositions are combined through connectives.

The main connectives of propositional logic are:• Conjunction (and): Λ • Disjunction (or): v • Negation (not): ¬ • Implication (if..then): → • Equivalence / Bi-implication(if and only if): ↔

Modus Ponens• (Latin term means) Affirming the antecedent • This takes the following form:

p → q, p ╞ q• Essentially, this argument states that given the

premise p → q, and the premise p then we must conclude q.

Premises: - If it is raining then ground is wet (p → q),- It is raining (p),

Conclusion:- Therefore, the ground is wet (q).

Modus Tollens

• Denying the consequent• Another important derivation rule is modus tollens (also known

as the contraposition) have the following form:p → q, ¬q ╞ ¬p

• Example:

Premises: - If it is raining then the ground is wet (p → q),- The ground is not wet (¬q)

Conclusion:- Therefore, it is not raining (¬p).

Entailment

Example: {¬q, p q} ╞ ¬p

means that ¬p is true, iff both ¬q and p q are true. Thus, the premises entail the conclusion.

p q

T

T

F

F

T

F

T

F

F

F

T

T

F

T

F

T

T

F

T

T

(p q)¬p ¬q

Truth Table

For a set of formulae which are true, then as a logical consequence of this, some particular formula must also be true.

╞ is an Entailment Operator.

EntailmentLines 1, 2 and 3 all have false truth assignments so

we disregard them.This means that we are left with one assignment,

where all assignments for the formula are true. i.e. ¬q is true, p q is true and ¬p is true.

Therefore, ¬p is entailed by {¬q, p q} , or more formally: {¬q, p q} ╞ ¬p

Exercise

Can we entail otherwise in modus tollens?

The Origins of Prolog• "Programming with Logic"• ?- consult(goodman).• 'consult()‘ is a build-in command of PROLOG. It just load

your file and compile it. When you see 'yes', that is to say PROLOG has accepted your program.

Knowledge Base 1woman(mia).

woman(jody).

woman(yolanda).

playsAirGuitar(jody).

party.

© Patrick Blackburn, Johan Bos & Kristina Striegnitz

?- woman(mia).true?- playsAirGuitar(jody).true?- playsAirGuitar(mia).false

Knowledge Base 2happy(yolanda).

listens2music(mia).

listens2music(yolanda):- happy(yolanda).

playsAirGuitar(mia):- listens2music(mia).

playsAirGuitar(yolanda):- listens2music(yolanda).

© Patrick Blackburn, Johan Bos & Kristina Striegnitz

Head body/goal

There are five clauses in this knowledge base:two facts, and three rules.

The end of a clause is marked with a full stop.

There are three predicates in this knowledge base:happy, listens2music, and playsAirGuitar

fact

factrule

rule

rule

Knowledge Base 2happy(yolanda).

listens2music(mia).

listens2music(yolanda):- happy(yolanda).

playsAirGuitar(mia):- listens2music(mia).

playsAirGuitar(yolanda):- listens2music(yolanda).

© Patrick Blackburn, Johan Bos & Kristina Striegnitz

?- playsAirGuitar(mia).yes?- playsAirGuitar(yolanda).yes

Knowledge Base 3happy(vincent).

listens2music(butch).

playsAirGuitar(vincent):- listens2music(vincent), happy(vincent).

playsAirGuitar(butch):- happy(butch).

playsAirGuitar(butch):- listens2music(butch).

© Patrick Blackburn, Johan Bos & Kristina Striegnitz

?- playsAirGuitar(vincent). no?- playsAirGuitar(butch). yes

The comma “," expresses conjunction in Prolog

Expressing Disjunctionhappy(vincent).

listens2music(butch).

playsAirGuitar(vincent):- listens2music(vincent), happy(vincent).

playsAirGuitar(butch):- happy(butch).

playsAirGuitar(butch):- listens2music(butch).

© Patrick Blackburn, Johan Bos & Kristina Striegnitz

happy(vincent).listens2music(butch).playsAirGuitar(vincent):- listens2music(vincent), happy(vincent).playsAirGuitar(butch):- happy(butch); listens2music(butch).

Variables• A sequence of characters of upper-case letters, lower-

case letters, digits, or underscore, starting with either an uppercase letter or an underscore

• Examples:

X, Y, Variable, Vincent, _tag

© Patrick Blackburn, Johan Bos & Kristina Striegnitz

Variableswoman(mia).woman(jody).woman(yolanda).

loves(vincent, mia).loves(marsellus, mia).loves(pumpkin, honey_bunny).loves(honey_bunny, pumpkin).

© Patrick Blackburn, Johan Bos & Kristina Striegnitz

?- woman(X).X=mia;X=jody;X=yolanda;no