Software Engineering Final

Architectural Design

Architectural Design

Identifies the main components. Output is a model that describes the set of communicating components.

expensive

Refactoring the system architecture is usually ________ because it impacts so many components.

Types of architectural abstraction

In the small: How individual components are decomposed into components.

In the large: Architecture of complex enterprise systems that include other systems, programs, and program components.

Why use architectural models?

Facilitate discussion about the system. Documentation

What are architectural design decisions?

A creative process that depends on the system is built. There are common decisions that span all design processes which affect the non-functional characteristics of a system.

What is architecture reuse?

Systems in a similar domain (industry) have similar architectures. Reuse these rather than innovate a new solution.

Architecture and system characteristics (5 of them)

Performance: Localize critical operations and minimize communications. Uses larger components rather than fine-grained.

Security: Layered architectures

Safety: Localize safety-critical features in a small number of sub-systems.

Availability: Redundant components and mechanisms for fault tolerance.

Maintainability: Use fine-grained, replaceable components.

What are architectural views?

Each model shows one view or perspective of the system. Typically want multiple views of the software architecture.

Types of view models (4 of them)

Logical view: Shows the key abstractions as objects or classes.

Process view: Shows the interacting processes and run-time.

Development view: How the software is decomposed for development.

Physical view: Shows system hardware and how software components are distributed across the processors in the system.

Architectural patterns

A stylized description of good design practice, which has been tried and tested.

Types of architectural patterns and how they work (5 of them)

Model-View-Controller: Used when there are multiple ways to view and interact with data. Allows data to change independently of its representation. Ca involve code complexity in simple interactions. Model: manages system data and associated operations on the data. View: defines and manages how the data is presented to the user. Controller: manages user interaction and passes interactions to the view and model.

Layered architecture: Used when building facilities on top of existing systems or when development is spread across several teams. Also used when there is a requirement for security. It allows the replacement of entire layers and has increased security and dependability. In practice, providing a clean separation between layers is difficult.

Repository architecture: Used when a system where large volumes of data need to be stored for a long time. Components are independent, and changes made to the data by one can be propagated to all components. However, the repository is a single point of failure.

Client-server: Used when data in a shared database has to be accessed from various locations. Also, each server will handle each service. Servers can be distributed across a network. Each server is a single point of failure and is susceptible to network attacks like DOS.

Pipe and filter: Used in data processing applications. It is easy to use and can be implemented in sequential or concurrent systems. However, the data and transfer format must be agreed upon before processing.

What are application architectures?

Application systems are designed to meet an organizational need. Generic application architecture is an architecture that may be configured and adapted to create a system that meets specific requirements.

Use of application architecture

A starting point for architectural design.

As a design checklist.

A way of organizing the work for teams.

Assessing components for reuse.

Examples of application types

Data processing applications --> Transaction processing applications.

E-commerce systems or reservation systems

Event processing systems.

Language processing systems --> Compiler and interpreters.

Transaction processing systems

Process user requests for information from a database or requests to update the database. It should be asynchronous.

Design, Implementation

______ and _____are often inter-leaved in agile development.

Object class identification

Identifying different object classes or components within a system.

Approaches to identification

Natural language description of the system.

Using tangible things in the applications domain.

Identify objects based on their participation and behavior.

Analyze scenarios to discover objects, attributes, and methods

Subsystems models

Show logical groupings of objects into subsystems. Usually modeled in UML

Interface specification

Interfaces define the signatures and semantics of the services provided by the object or group of objects.

UML uses class diagrams for interface specification.

What is a design pattern?

A pattern is a description of the problem and the essence of the solution. It should be sufficiently abstract to be reused. Usually take advantage of OOP characteristics such as inheritance and polymorphism.

Design pattern elements (4 of them)

Name

Problem Description

Solution Description

Consequences

Implementation issues (3 of them)

Reuse: You should make as much use as possible of existing code.

Configuration management: Keeping track of different versions of each software component in a configuration management system.

Host-target development: You develop it on one computer(host) and execute it on a separate computer(target)

Why do we reuse code?

Code was initially written from scratch, but costs and scheduling pressure made this approach unviable.

Levels of reuse (4 of them)

Abstraction level: You do not reuse the software directly but use the knowledge of successful abstractions in the design.

Object level: Directly reuse objects from a library.

Component level: Components are reused.

System level: Reuse entire application systems.

Reuse costs

It depends on the system you are developing.

Configuration management

The general process of managing a changing software system

Configuration management activities (3 of them)

Version management

System integration

Problem tracking

Host-target development

Most software is developed on one computer(the host). Runs on separate machine (the target)

Development platform tools

An integrated compiler and syntax-directed editing system allow you to create, edit and compile code.

Graphical editing tools to edit UML models Testing tools like JUnit

Integrated development environment

Software development tools grouped together.

Component/system deployment factors

If a component is designed for specific hardware or software, it must be deployed on a platform that provides the required hardware and software.

Open source development

Source code of the system is published, and volunteers are invited to participate in the development process.

Goals of program testing

Verification vs. validation

Verification: Check that the software meets its functional and non-functional requirements.

Validation: Software meets the customer's expectations.

Done to establish confidence that the system is ‘fit for purpose’

V & V confidence (How much confidence do you need for different situations)

Software purpose: How critical is the software to an organization? A higher level of confidence is needed for critical systems.

User expectations: The confidence level depends on the users' expectations.

Marketing environment: Getting a product to market early may be more important than finding defects in the program.

Inspections and testing (static and dynamic verification)

Inspections (Static verification): Concerned with analyzing the static system representation to discover problems. Advantages of Inspections: This does not require system execution. Concerned with examining the source code. No extra cost to be inspected. Can check compliance with standards, portability, and maintainability.

Testing (Dynamic verification): Concerned with exercising and observing product behavior. Advantages of Testing: Checks non-functional requirements.

Stages of testing

Development testing: test during development to discover bugs and defects

Release testing: Testing a complete version before release

User testing: Users test the system in their own environment

Development testing types

Unit testing: Test individual program units, objects, or classes. It focuses on testing the functionality of these methods. Defect testing process.

Component testing: Where several individual units are integrated to create composite components. Each component has an interface which is what is tested.

System testing: Where some or all of the components in a system are integrated, and the system is tested as a whole. Focus on testing component interactions.

Automated testing

Unit testing should be automated so that tests are run and checked without manual intervention.

Automated test components (as in what are the different parts of automated testing)

Setup: Initialize the system with the test case, namely the inputs and expected outputs.

Call: Call the object or method to be tested.

Assertion: Compare results with expected results.

Two types of unit test cases

Reflecting normal operation

Using abnormal inputs to check that these are properly processed and do not crash the component.

Testing strategies

Partition testing: Identity groups of inputs with common characteristics should be processed similarly.

Guideline-based testing: Use testing guidelines to choose test cases. Guidelines reflect the experience of other programmers.

General testing guidelines

Choose inputs that force errors

Design inputs that cause input buffers to overflow

Repeat the same input numerous times.

Force invalid outputs to be generated.

Force computation results to be too large or too small.

Types of interfaces

Parameter interfaces: Data passed from one method or process to another.

Shared memory interfaces: A block of memory is shared between procedures or functions.

Procedural interfaces sub-system: Encapsulates a set of procedures to be called by other sub-systems.

Message passing interfaces: Request services from other subsystems.

Interface errors

Interface misuse: An example is calling parameters in the wrong order.

Interface misunderstanding: Assumptions about the behavior are incorrect.

Timing errors: Operate at different speeds and out-of-date information is accessed.

Interface testing guidelines

Parameters to a called procedure are at the extreme ends of their ranges.

Always test pointer parameters with null pointers

Design tests that force the container to fail

Stress test

In shared mem components, vary the order in which components are activated.

Why do we use use case testing?

Developed to identify system interactions

Testing Policies

Policies are put in place because exhaustive testing of an entire system is impossible.

Test-driven development

Inter-leave testing and code development.

Tests are written before writing the code; passing the tests is a stage of development.

Develop a test for the increment and then develop the code.

Test-driven development activities

Identify the functionality required for an increment.

Write a test

Run the test along with every other developed test. It will fail.

Implement the functionality and rerun test.

Benefits of test-driven development

Code coverage: Every code segment has at least one associated test.

Regression testing: A regression test suite is developed.

Simplified debugging: When a test fail it is clear where the problem lies.

System documentation: The tests are a form of documentation that describe what the code should be doing.

Regression testing

Testing the system to check that changes have not ‘broken’ previous code.

All tests are run every time a change is made to the program.

Release testing

Process of testing a particular system release for use outside the development team. The primary goal is to convince the supplier of the system that the system is good enough for use. This is a form of system testing. A separate team should be responsible for release testing.

Performance testing

Usually involves planning a series of tests where the load is steadily increased until performance becomes unacceptable.

Stress testing

The system is deliberately overloaded to test its failure behavior.

User testing

Users or customers provide input and advice on system testing.

Types of user testing (3 types)

Alpha testing: Test at the developers' site.

Beta testing: The release of the software is made and tested by users.

Acceptance testing: Customers test a system to decide whether or not it is ready to be accepted.

Stages in the acceptance testing process (6 stages)

Define acceptance criteria

Plan acceptance testing

Derive acceptance tests

Run acceptance tests

Negotiate test results

Reject/accept the system

acceptability

In agile, the user/customer is a part of the development team and is responsible for making decisions on the ________of the system. Tests are defined by the user/customer

Why is software change inevitable?

New requirements emerge when the software is used

The business environment changes

Errors must be repaired

New computers and equipment are added to the system

The performance or reliability of the system may have to be improved

existing

The core problem for all organizations is implementing and managing change to their ______ systems

Importance of Evolution

Software systems are huge investments to organizations and are seen as critical business assets. The only way to maintain the value of a system is to change and update. The majority of the software budget in large companies is allocated to changing and evolving existing software

Timeline of a software (4 main parts)

Software development

Software evolution

Software Servicing

Software Retirement

Evolution

While the software is in use, it is evolving as new requirements are proposed and implemented in the system.

Servicing

The only changes made to the software are those required to keep it operational (ex, bug fixes). No new functionality is added at this stage

Phase out

While the system may still be in use, there are no further changes made to it

What is the software evolution process dependent on?

The type of software being maintained

The development processes used

The skills and experience of the people involved

Proposals for change

When proposing change you should take into account the components that are affected by the change to estimate the true cost and impact of the change.

Change implementation

Iteration of the development process where the revisions to the system are designed, implemented, and tested

Program Understanding

The first stage of change implementation, especially if the original system developers are not responsible for the change implementation. The developers have to understand how the program is structured, how it delivers functionality, and how the proposed change might affect the program.

Urgent Changes may be implemented without going through all the stages of the software engineering process if:

A serious system fault has to be repaired to allow normal operation to continue.

Changes to the system’s environment (ex, an OS upgrade) have unexpected effects.

There are business changes that require a very rapid response (ex the release of a competing product)

Agile Method and Evolution (easy? hard?)

The incremental development of agile methods makes the transition from development to evolution an easy one since evolution is the continuation of the development process based on frequent system releases.

Automated Regression Testing

Regression testing is testing the system to check that changes have not broken previously working code.

Handover Problems

When the development team used an agile approach that the evolution team is unfamiliar with since they prefer a plan-based approach. The evolution team may expect detailed documentation to support evolution but they were not produced during the development.

When the development team used a plan-based approach, but the evolution team preferred to use agile methods the evolution team may have to develop automated tests from scratch and the code in the system may not have been refactored and simplified as it is in agile development

Legacy Systems

Older systems that rely on languages and technologies that are no longer used for new systems development. They are not just software systems but are broader social-technical systems including hardware, software, libraries and other supporting software

Legacy Software

May be dependent on older hardware such as mainframe computers and may have associated legacy processes and procedures.

Components of a Legacy System (6 parts)

System Hardware: may no longer be available

Support Software: may be obsolete or unsupportable

Application Software: that provides the business services is usually made of a number of application programs

Application Data: that are processed by the application system may be inconsistent, duplicated, or held in a different database

Business Process: that are used to achieve some business objective and may be designed around a legacy systems and constrained by the functionality that it provides

Business Policies and Rules: define how the business should be carried out and constraints on the business. The use of the legacy application system may be embedded within the policies and rules

Legacy System Layers (5 layers)

Socio-Technical System

Business Processes

Application Software

Platform and infrastructure software

Hardware

Why is it risky to replace legacy systems?

Lack of complete system specification

Tight integration of system and business processes

Undocumented business rules embedded in the legacy system

New software development may be late and/or over budget

Why is legacy system change expensive? (6 main reasons)

No consistent programming style

Use of obsolete programming languages with few people available with these language skills

Inadequate system documentation

System structure degradation

Program optimization may make them hard to understand

Data errors, duplication, and inconsistency

Legacy System Management Strategies (4 main stratagies)

Scrap the system completely and modify business processes so that it is no longer required

Continue maintaining the system

Transform the system by re-engineering to improve its maintainability

Replace the system with a new system

Legacy System Categories (4 main categories)

Low Quality Low business value systems should be scrapped

Low-quality, high business value systems should be re-engineered or replaced if a suitable system is available

High-quality, low-business value systems should be replaced with COTS, scrapped completely or maintained

High-quality, high business value systems should continue in operation using normal system maintenance

Viewpoints that should be taken into account for value assessment. (5 main viewpoints)

System end-users

Business customers

Line managers

IT managers

Senior manager

Issues in Business Value assessment

If systems are only user occasionally or by a small number of people they may have a low business value

A system may have a low business value if it forces the use of inefficient business processes

If a system is not dependable and the problems directly affect business customers the system has a low business value

If the business depends on system outputs then the system has a high business value

System Quality Assessment

Business Process Assessment → how well does the business process support the current goals of the business?

Environment Assessment → How effective is the system’s environment and how expensive is it to maintain?

Application Assessment → What is the quality of the application software system?

Factors used in Environment Assessment (7 factors)

Supplier Stability → is the supplier still in existence, financially stable, and likely to continue in existence? If not is there someone else to maintain the system?

Failure Rate → Does the hardware have a high rate of failure? Does the support software crash and force system restarts?

Age → How old is the hardware and software? The older it is the more obsolete the system will be.

Performance → Is the performance adequate or do performance problems have significant effect on system users?

Support Requirements → What local support is required by the hardware and software? If there are high costs associated with this support consider system replacement

Maintenance Costs → Older hardware may have higher maintenance costs than modern systems. Support software may have high annual licensing costs

Interoperability → Are there problems interfacing the system to other systems?

Factors in Application Assessment (8 factors)

Understandability

Documentation

Data

Performance

Programming Language

Configuration Management

Test Data

Personnel Skills

System Measurement

The higher the number of system change requests is the lower the quality of the system is. The more user interfaces the system has the more likely there is to be inconsistencies and redundancies. As the volume of the data processed by the system incessantly increases, so do the inconsistencies and errors in that data.

Software Maintenance

Modifying a custom software after it was been put in use and does not usually involve major changes to the system architecture. Changes are implemented buy modifying existing components and adding new components to the system

Types of Maintenance (3 types)

Fault Repairs to fix bugs/vulnerabilities and correct deficiencies

Environmental Adaptation to adapt software to a different operating environment

Functionality Addition and Modification to satisfy new requirements

greater

Maintenance costs are usually ________ than development costs and increases as software is maintained due to corruption to the system's structure

maintainable

It is usually more expensive to add new features to a system during maintenance since there is no incentive for the development team to write _________software

Maintenance prediction

The assessment of which parts of the system may cause problems and have high maintenance costs

Change Prediction

Predicting the number of changes requires an understanding of the relationships between a system and its environment. Tightly coupled systems require changes whenever the environment is changed.

Complexity of a system depends on (3 main things)

Control Structures

Data Structures

Object, method, and module size

Process Metrics (an increase in these may indicate a decline in maintainability)

Number of requests for corrective maintenance

Average time required for impact analysis

Average time taken to implement a change request

Number of outstanding change requests

Software Reengineering

Restructuring or rewriting part or all of a legacy system without changing its functionality. Involves adding effort to make them easier to maintain including re-structuring and re-documentation

Advantages of Re-engineering (2 main advantages)

Reduce Risk

Reduce Cost

Re-engineering Process Activities (5 of them)

Source code translation

Reverse engineering

Program structure improvement

Program Modularization

Data re-engineering