CSC 506: Software Engineering and Knowledge Engineering Dr. Syed Noman Hasany.
-
Upload
marcia-leonard -
Category
Documents
-
view
215 -
download
0
Transcript of CSC 506: Software Engineering and Knowledge Engineering Dr. Syed Noman Hasany.
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