Fundamentals of Software Engineering MIDTERM

State machine models

1. These model the behaviour of the system in response to external and internal events. 2. They show the system's responses to stimuli so are often used for modelling real-time systems. 3. State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another. 4. Statecharts are an integral part of the UML and are used to represent state machine models.

Software validation activities

1. Unit testing 2. Module testing 3. Sub-system testing 4. System testing 5. Acceptance testing

Semantic data models

1. Used to describe the logical structure of data processed by the system. 2. An entity-relation-attribute model sets out the entities in the system, the relationships between these entities and the entity attributes 3. Widely used in database design. Can readily be implemented using relational databases. 4. No specific notation provided in the UML but objects and associations can be used.

Architectural conflicts

1. Using large-grain components improves performance but reduces maintainability. 2. Introducing redundant data improves availability but makes security more difficult. 3. Localising safety-related features usually means more communication so degraded performance.

Examples of software process models

1. Workflow model: Sequence of activities in the process along with their inputs, outputs and dependencies. 2. Data-flow or activity model: A set of activities that carry out some data transformation (input -> output) 3. Role/action model: Represents roles of people involved in the software process and activities for which they are responsible.

Test case design

1.Involves designing the test cases (inputs and outputs) used to test the system. 2. The goal of test case design is to create a set of tests that are effective in validation and defect testing. Design approaches: - Requirements-based testing (i.e. trace test cases to the requirements) - Partition testing; - Structural testing.

Spiral development

A hybrid model where the development of the system spirals outward from an initial outline through to the final developed system. Each loop in the spiral represents a phase of the software process

Incremental development

A hybrid model where the software specification, design, implementation, and testing is broken down into a series of increments which are developed and delivered

What is a software process model ?

A representation of software process from a specific perspective.

What is a software process?

A set of activities and associated results which produce a software product

Spiral development: Plus & Minuses

Advantages 1. Explicit consideration of risks (alternative solutions are evaluated in each cycle) 2. More detailed processes for each development phase Disadvantages 1. Cost 2. Sometime difficult to implement or too time consuming

Evolutionary development: advantages and challenges

Advantages 1. Happier customers since you help them define requirements 2. Flexibility in modifying requirements 3. Prototypes are very visual, hence no ambiguities Challenges 1. Hard to trace the "process" due to the ad-hoc nature 2. Systems are often poorly structured 3. Special tools and techniques may be required (for rapid development) that may be incompatible 4.Not cost-effective to produce documents

Incremental development: Advantages and Challenges

Advantages 1. Products delivered incrementally hence faster 2. Lower risk of overall project failure 3. Requirements are implemented based on priority Challenges 1. Relationship between different increments may be cumbersome or non-cohesive 2. Size of each increment and the number of increments may cause challenges

Client-server characteristics

Advantages - Distribution of data is straightforward; - Makes effective use of networked systems. May require cheaper hardware; - Easy to add new servers or upgrade existing servers. Disadvantages - No shared data model so sub-systems use different data organisation. Data interchange may be inefficient; - Redundant management in each server; - No central register of names and services - it may be hard to find out what servers and services are available.

Repository model characteristics

Advantages - Efficient way to share large amounts of data; - Sub-systems need not be concerned with how data is produced Centralised management e.g. backup, security, etc. - Sharing model is published as the repository schema. Disadvantages - Sub-systems must agree on a repository data model. Inevitably a compromise; - Data evolution is difficult and expensive; - No scope for specific management policies; - Difficult to distribute efficiently.

Waterfall model: Plus and Minuses

Advantages 1. Simple to follow 2.Relatively simple to track progress 3. Good structural design Challenges 1. In practice, often phases overlap 2. Hard to modify and implement changes 3. Need complete requirements from customers to start (the biggest challenge)

Reuse-oriented: Plus and Minuses

Advantages: 1. Reduced cost and risk 2. Fast delivery Challenges: 1. Requires a large enough component base 2. Some control over the system evolution is lost as new versions of reusable components are not under the control of organization using the component 3. Potential issues in backward/forward compatibility

What is software engineering?

An engineering discipline which is concerned with all aspect of software production

Control styles

Are concerned with the control flow between sub-systems. There are many different system decomposition model Including: 1. Call-return model 2. Manager model 3. Event-Driven Systems -Broadcast model -Interrupt-Driven Model

Behavioural models

Behavioural models are used to describe the overall behaviour of a system. Two types of behavioural model are: - Data processing models that show how data is processed as it moves through the system; - State machine models that show the systems response to events.

Computer-Aided Software Engineering (CASE)

CASE is the name given to software that is used to support software process activities such as requirements engineering, design, program development and testing (Design editors, compilers, data dictionaries, debuggers, and other system building tools...).

Component testing

Component or unit testing is the process of testing individual components in isolation. It is a defect testing process. Components may be: - Individual functions or methods within an object; - Object classes with several attributes and methods; - Composite components with defined interfaces used to access their functionality.

Context models

Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries.

Data dictionaries

Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included. Advantages - Support name management and avoid duplication; - Store of organisational knowledge linking analysis, design and implementation;

Evolutionary development

Develop an initial implementation, expose to users comments, refine until satisfied

Formal systems development

Development is based on formal mathematical transformation of system specification to an executable program

Domain requirements

Domain requirements are derived from the application domain of the system rather than from the specific needs of the system users.

Spiral development loops

Each loop in the spiral is split into four sectors: 1. Object Setting: set specific object for that phase 2. Risk assessment and reduction 3. Development and validation: select a development model based on risk levels 4. Planning: decide if a next loop is required

Ethnography

Ethnography is an observational technique that can be used to understand social and organizational requirements.

Evolutionary development types

Exploratory development 1. Start with requirements that are well defined 2. Add new features when customers propose new requirements Throw-away prototyping 1. Objective is to understand customer's requirements (i.e. they often don't know what they want, hence poor requirements to start 2. Use means such as prototyping to focus on poorly understood requirements, redefine requirements as you progress

What is a requirement?

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

Requirements Engineering (RE) processes

Processes used to discover, analyse and validate system requirements - Requirements elicitation - Requirements analysis - Requirements validation - Requirements management

Multiple inheritance

Rather than inheriting the attributes and services from a single parent class, a system which supports multiple inheritance allows object classes to inherit from several super-classes. This can lead to semantic conflicts where attributes/services with the same name in different super-classes have different semantics. Multiple inheritance makes class hierarchy reorganisation more complex.

PDL-based requirements definition

Requirements may be defined operationally using a language like a programming language but with more flexibility of expression

Reuse-oriented development

Reuse-oriented approach relies on a large base of reusable software components! Design system to capitalize on the existing components

Software inspections

Software Inspection involves examining the source representation with the aim of discovering anomalies and defects without execution of a system. They may be applied to any representation of the system (requirements, design, configuration data, test data, etc.).

Static and dynamic verification

Software inspections. Concerned with analysis of the static system representation to discover problems (static verification) - May be supplement by tool-based document and code analysis Software testing. Concerned with exercising and observing product behaviour (dynamic verification) - The system is executed with test data and its operational behaviour is observed

Project Management

Software management is distinct and often more difficult from other engineering managements mainly because: - Software product is intangible - There are no standard software processes - Large software projects are usually different from previous projects

Structural testing

Sometime called white-box testing. Derivation of test cases according to program structure. Knowledge of the program is used to identify additional test cases. Objective is to exercise all program statements (not all path combinations).

UML Diagram Types

Static diagrams: 1. Class 2. Component 3. Deployment 4. Interaction overview 5. Object 6. Package Dynamic diagrams: 1. Activity 2. Communication 3. Composite structure 4. Sequence 5. State machine 6. Timing 7. Use case

Black Box Testing

Testing, either functional or non-functional, without reference to the internal structure of the component or system.

Software architecture

The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design. The output of this design process is a description of the software architecture.

Cleanroom software development

The name is derived from the 'Cleanroom' process in semiconductor fabrication. The philosophy is defect avoidance rather than defect removal. This software development process is based on: - Incremental development; - Formal specification; - Static verification using correctness arguments; - Statistical testing to determine program reliability.

Software Requirements

The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. Requirements may be functional or non-functional: - Functional requirements describe system services or functions - Non-functional requirements is a constraint on the system or on the development process

Modular decomposition

The structural level where sub-systems are decomposed into modules. Two modular decomposition models are: - An object model where the system is decomposed into interacting object; - A pipeline or data-flow model where the system is decomposed into functional modules which transform inputs to outputs.

Inspection roles

Typically 6 people involved in any inspection: - 2 people: Code Author or Owner - 2 people: Code Inspectors - 1 Person: Reader & Scriber - 1 Person: Session Moderator

Types of requirements

User requirements - Statements in natural language (NL) plus diagrams of the services the system provides and its operational constraints. Written for customers System requirements - A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor Software specification - A detailed software description which can serve as a basis for a design or implementation. Written for developers

Verification vs validation

Verification: "Are we building the product right". The software should conform to its specification. Validation: "Are we building the right product". The software should do what the user really requires.

Independent paths

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14 1, 2, 3, 4, 5, 14 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, ... 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, ... Test cases should be derived so that all of these paths are executed A dynamic program analyser may be used to check that paths have been executed

CASE workbenches

1. A coherent set of tools that is designed to support related software process activities such as analysis, design or testing. 2. Analysis and design workbenches support system modelling during both requirements engineering and system design. 3. These workbenches may support a specific design method or may provide support for a creating several different types of system model.

Structured language specifications

1. A limited form of natural language may be used to express requirements 2. This removes some of the problems resulting from ambiguity and flexibility and imposes a degree of uniformity on a specification 3. Often best supported using a form-based approach

Sub-systems and modules

1. A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems. 2. A module is a system component that provides services to other components but would not normally be considered as a separate system.

Architectural design

1. An early stage of the system design process. 2. Represents the link between specification and design processes. 3. Often carried out in parallel with some specification activities. 4. It involves identifying major system components and their communications.

What is software?

1. Computer programs 2. Configuration data and files 3. User and system documentation.

Difference between software engineering and computer science

1. Computer science is concerned with theory and fundamentals 2.Software engineering is concerned with practical aspects of developing and delivering software

Ethical Responsibility

1. Confidentiality (respect confidentiality of employer/client) 2. Competence (avoid misrepresenting the level of competence) 3. Intellectual property rights (local laws, patents, copyrights) 4. Computer misuse (Viruses, hacking, information theft)

Model types

1. Context Model - External View - Illustrates Boundaries - Component Based 2. Behavioural Models - Data Flow Models - State Machine Models 3. Semantic Data Models 4. Object Models

Software engineering challenges

1. Coping with legacy systems 2. Coping with increasing diversity (heterogeneous systems-many types of hardware/software) 3. Coping with faster, cheaper

Data-processing models

1. Data flow diagrams (DFDs) may be used to model the system's data processing. 2. These show the processing steps as data flows through a system. 3. DFDs are an intrinsic part of many analysis methods. 4. Simple and intuitive notation that customers can understand. 5. Show end-to-end processing of data.

Client-server model

1. Distributed system model which shows how data and processing is distributed across a range of components. 2. Set of stand-alone servers which provide specific services such as printing, data management, etc. 3. Set of clients which call on these services. 4. Network which allows clients to access servers.

Enduring and volatile requirements

1. Enduring requirements. Stable requirements derived from the core activity of the customer organisation. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain models 2. Volatile requirements. Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy

Stress testing

1. Exercises the system beyond its maximum design load. Stressing the system often causes defects to come to light. 2. Stressing the system test failure behaviour.. Systems should not fail catastrophically. Stress testing checks for unacceptable loss of service or data. 3. Stress testing is particularly relevant to distributed systems that can exhibit severe degradation as a network becomes overloaded.

Requirements Types

1. Functional requirements: services the system should provide 2. Non-functional requirements: constraints on the services of functions offered by the system. e.g. speed, time to market 3. Domain requirements: related to the application domain of the system (may be functional or non-functional requirements)

Function-oriented pipelining

1. Functional transformations process their inputs to produce outputs. 2. May be referred to as a pipe and filter model (as in UNIX shell). 3. Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems. 4. Not really suitable for interactive systems.

Functional requirements

1. Functionality or services that the system is expected to provide. 2. Functional requirements may also explicitly state what the system shouldn't do. 3. Functional requirements specification should be: - Complete: All services required by the user should be defined - Consistent: should not have contradictory definition (also avoid ambiguity -> don't leave room for different interpretations)

Partition testing

1. Input data and output results often fall into different classes where all members of a class are related. 2. Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member. 3. Test cases should be chosen from each partition.

Inspections and testing

1. Inspections and testing are complementary and not opposing verification techniques. 2. Inspections can check conformance with a specification but not conformance with the customer's real requirements. 3. Inspections cannot check non-functional characteristics such as performance, usability, etc. 4. Management should not use inspections for staff appraisal i.e. finding out who makes mistakes.

System testing

1. Involves integrating components to create a system or sub-system. 2. May involve testing an increment to be delivered to the customer. Two phases: - Integration testing - the test team have access to the system source code. The system is tested as components are integrated. - Release testing - the test team test the complete system to be delivered as a black-box.

Problems with natural language

1. Lack of clarity - Precision is difficult without making the document difficult to read 2. Requirements confusion - Functional and non-functional requirements tend to be mixed-up 3. Requirements amalgamation - Several different requirements may be expressed together 4. Ambiguity - The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult 5. Over-flexibility - The same thing may be said in a number of different ways in the specification

Classification of requirements

1. Mutable requirements - Requirements that change due to the system's environment 2. Emergent requirements - Requirements that emerge as understanding of the system develops 3. Consequential requirements - Requirements that result from the introduction of the computer system 4. Compatibility requirements - Requirements that depend on other systems or organizational processes

Object models

1. Natural ways of reflecting the real-world entities manipulated by the system 2. More abstract entities are more difficult to model using this approach 3. Object class identification is recognized as a difficult process requiring a deep understanding of the application domain 4. Object classes reflecting domain entities are reusable across systems -Structure the system into a set of loosely coupled objects with well-defined interfaces. -Object-oriented decomposition is concerned with identifying object classes, their attributes and operations. -When implemented, objects are created from these classes and some control model used to coordinate object operations.

Object model advantages

1. Objects are loosely coupled so their implementation can be modified without affecting other objects. 2. The objects may reflect real-world entities. 3. OO implementation languages are widely used. 4. However, object interface changes may cause problems and complex entities may be hard to represent as objects.

PDL disadvantages

1. PDL may not be sufficiently expressive to express the system functionality in an understandable way 2. Notation is only understandable to people with programming language knowledge 3. The requirement may be taken as a design specification rather than a model to help understand the system

Architecture and system characteristics

1. Performance - Localize critical operations and minimize communications. Use large rather than fine-grain components. 2. Security - Use a layered architecture with critical assets in the inner layers. 3. Safety - Localize safety-critical features in a small number of sub-systems. 4. Availability - Include redundant components and mechanisms for fault tolerance. 5. Maintainability - Use fine-grain, replaceable components.

System organization

1. Reflects the basic strategy that is used to structure a system. 2. Two organizational models are widely used: - Data repository Model - Client-Server Model

Waterfall model (Life cycle)

1. Requirements 2. Software design 3. Code & Unit test 4. Integration & Testing 5. Maintenance

Non-Functional requirements

1. Requirements that are not directly concerned with the specific functions delivered by the system 2. Typically relate to the system as a whole rather than the individual system features 3. Often could be deciding factor on the survival of the system (e.g. reliability, cost, response time)

Risk Management

1. Risk Identification (project, product, business, technology) 2. Risk Analysis (likelihood and consequences, low/medium/high) 3. Risk Planning (avoiding, minimizing risk effects, contingency planning) 4. Risk Monitoring (constant assessment, mitigation i.e. reduce risk severity)

Four fundamental process activities

1. Software specification 2. Software development 3. Software validation (i.e. It does what it intended to do based on software spec.) 4. Software evolution (i.e. Change/enhancement/maintenance)

Cleanroom process teams

1. Specification team. Responsible for developing and maintaining the system specification. 2. Development team. Responsible for developing and verifying the software. The software is NOT executed or even compiled during this process. 3. Certification team. Responsible for developing a set of statistical tests to exercise the software after development. Reliability growth models used to determine when reliability is acceptable.

Automated static analysis

1. Static analysers are software tools for source text processing. 2. They parse the program text and try to discover potentially erroneous conditions and bring these to the attention of the V & V team. 3. They are very effective as an aid to inspections - they are a supplement to but not a replacement for inspections.

Alternatives to NL specification

1. Structured Natural language (via standard forms & templates) 2. Program Description Language (PDL) 3. Use-Cases (scenario-based technique) 4. Mathematical specification (notations based on mathematical concepts such as finite-state machines or set.)

The repository model

1. Sub-systems must exchange data. Shared data is held in a central database or repository and may be accessed by all sub-systems; 2. When large amounts of data are to be shared, the repository model of sharing is most commonly used.

Inspection procedure

1. System overview presented to inspection team. 2. Code and associated documents are distributed to inspection team in advance. 3. Inspection takes place and discovered errors are noted. 4. Modifications are made to repair errors. 5. Re-inspection may or may not be required. 6. Checklist of common errors should be used to drive the inspection. Examples: Initialization, Constant naming, loop termination, array bounds...

Test automation

1. Testing is an expensive process phase. Testing workbenches provide a range of tools to reduce the time required and total testing costs. 2. Systems such as Junit support the automatic execution of tests. 3. Most testing workbenches are open systems because testing needs are organisation-specific. 4. They are sometimes difficult to integrate with closed design and analysis workbenches.

Object models and the UML

1. The UML is a standard representation devised by the developers of widely used object-oriented analysis and design methods. 2. It has become an effective standard for object-oriented modelling.

Path testing

1. The objective of path testing is to ensure that the set of test cases is such that each path through the program is executed at least once. 2. The starting point for path testing is a program flow graph that shows nodes representing program decisions and arcs representing the flow of control. 3. Statements with conditions are therefore nodes in the flow graph.

Release testing

1. The process of testing a release of a system that will be distributed to customers. 2. Primary goal is to increase the supplier's confidence that the system meets its requirements. 3. Release testing is usually black-box or functional testing - Based on the system specification only; - Testers do not have knowledge of the system implementation.

The requirements document

1. The requirements document is the official statement of what is required of the system developers 2. Should include both a definition and a specification of requirements 3. 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