Software Engineering Final

studied byStudied by 39 people
0.0(0)
get a hint
hint

Architectural Design

1 / 102

Tags and Description

Pertains to chapters 6, 7, 8, 9

103 Terms

1

Architectural Design

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

New cards
2

expensive

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

New cards
3

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.

New cards
4

Why use architectural models?

Facilitate discussion about the system. Documentation

New cards
5

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.

New cards
6

What is architecture reuse?

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

New cards
7

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.

New cards
8

What are architectural views?

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

New cards
9

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.

New cards
10

Architectural patterns

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

New cards
11

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.

New cards
12

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.

New cards
13

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.

New cards
14

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.

New cards
15

Transaction processing systems

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

New cards
16

Design, Implementation

______ and _____are often inter-leaved in agile development.

New cards
17

Object class identification

Identifying different object classes or components within a system.

New cards
18

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

New cards
19

Subsystems models

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

New cards
20

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.

New cards
21

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.

New cards
22

Design pattern elements (4 of them)

Name

Problem Description

Solution Description

Consequences

New cards
23

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)

New cards
24

Why do we reuse code?

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

New cards
25

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.

New cards
26

Reuse costs

It depends on the system you are developing.

New cards
27

Configuration management

The general process of managing a changing software system

New cards
28

Configuration management activities (3 of them)

Version management

System integration

Problem tracking

New cards
29

Host-target development

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

New cards
30

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

New cards
31

Integrated development environment

Software development tools grouped together.

New cards
32

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.

New cards
33

Open source development

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

New cards
34

Goals of program testing

New cards
35

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’

New cards
36

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.

New cards
37

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.

New cards
38

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

New cards
39

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.

New cards
40

Automated testing

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

New cards
41

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.

New cards
42

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.

New cards
43

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.

New cards
44

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.

New cards
45

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.

New cards
46

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.

New cards
47

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.

New cards
48

Why do we use use case testing?

Developed to identify system interactions

New cards
49

Testing Policies

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

New cards
50

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.

New cards
51

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.

New cards
52

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.

New cards
53

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.

New cards
54

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.

New cards
55

Performance testing

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

New cards
56

Stress testing

The system is deliberately overloaded to test its failure behavior.

New cards
57

User testing

Users or customers provide input and advice on system testing.

New cards
58

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.

New cards
59

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

New cards
60

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

New cards
61

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

New cards
62

existing

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

New cards
63

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

New cards
64

Timeline of a software (4 main parts)

Software development

Software evolution

Software Servicing

Software Retirement

New cards
65

Evolution

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

New cards
66

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

New cards
67

Phase out

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

New cards
68

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

New cards
69

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.

New cards
70

Change implementation

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

New cards
71

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.

New cards
72

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)

New cards
73

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.

New cards
74

Automated Regression Testing

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

New cards
75

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

New cards
76

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

New cards
77

Legacy Software

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

New cards
78

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

New cards
79

Legacy System Layers (5 layers)

Socio-Technical System

Business Processes

Application Software

Platform and infrastructure software

Hardware

New cards
80

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

New cards
81

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

New cards
82

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

New cards
83

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

New cards
84

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

System end-users

Business customers

Line managers

IT managers

Senior manager

New cards
85

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

New cards
86

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?

New cards
87

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?

New cards
88

Factors in Application Assessment (8 factors)

Understandability

Documentation

Data

Performance

Programming Language

Configuration Management

Test Data

Personnel Skills

New cards
89

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.

New cards
90

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

New cards
91

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

New cards
92

greater

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

New cards
93

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

New cards
94

Maintenance prediction

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

New cards
95

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.

New cards
96

Complexity of a system depends on (3 main things)

Control Structures

Data Structures

Object, method, and module size

New cards
97

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

New cards
98

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

New cards
99

Advantages of Re-engineering (2 main advantages)

Reduce Risk

Reduce Cost

New cards
100

Re-engineering Process Activities (5 of them)

Source code translation

Reverse engineering

Program structure improvement

Program Modularization

Data re-engineering

New cards

Explore top notes

note Note
studied byStudied by 2 people
Updated ... ago
5.0 Stars(1)
note Note
studied byStudied by 43 people
Updated ... ago
5.0 Stars(1)
note Note
studied byStudied by 58 people
Updated ... ago
5.0 Stars(1)
note Note
studied byStudied by 4 people
Updated ... ago
5.0 Stars(1)
note Note
studied byStudied by 59 people
Updated ... ago
5.0 Stars(5)
note Note
studied byStudied by 10850 people
Updated ... ago
4.9 Stars(51)
note Note
studied byStudied by 4 people
Updated ... ago
5.0 Stars(1)
note Note
studied byStudied by 17 people
Updated ... ago
5.0 Stars(1)

Explore top flashcards

flashcards Flashcard39 terms
studied byStudied by 8 people
Updated ... ago
5.0 Stars(2)
flashcards Flashcard52 terms
studied byStudied by 2 people
Updated ... ago
5.0 Stars(1)
flashcards Flashcard42 terms
studied byStudied by 2 people
Updated ... ago
5.0 Stars(1)
flashcards Flashcard33 terms
studied byStudied by 2 people
Updated ... ago
5.0 Stars(1)
flashcards Flashcard30 terms
studied byStudied by 2 people
Updated ... ago
5.0 Stars(1)
flashcards Flashcard42 terms
studied byStudied by 29 people
Updated ... ago
5.0 Stars(2)
flashcards Flashcard128 terms
studied byStudied by 53 people
Updated ... ago
5.0 Stars(1)
flashcards Flashcard50 terms
studied byStudied by 51 people
Updated ... ago
5.0 Stars(2)