8.

Aspect-oriented software engineering (AOSE) Pg – 566

Aspect-oriented software engineering (AOSE) is an approach to software development
that is intended to address this problem and so make programs easier to maintain and reuse.
AOSE is based around abstractions called aspects, which implement system functionality that
may be required at several different places in a program. An executable aspect-oriented program
is created by automatically combining (weaving) objects, methods, and aspects, according to
specifications that are included in the program source code.
An important characteristic of aspects is that they include a definition of where they
should be included in a program, as well as the code implementing the cross-cutting concern.
The key benefit of an aspect-oriented approach is that it supports the separation of concerns.
Separating concerns into independent elements rather than including different concerns in the
same logical abstraction is good software engineering practice. For example, user authentication
may be represented as an aspect that requests a login name and password. This can be
automatically woven into the program wherever authentication is required.
15. Three different approaches to aspect weaving
There are three different approaches to aspect weaving:
1. Source code pre-processing, where a weaver takes source code input and gener-ates new
source code in a language such as Java or C++, which can then be com-piled using the standard
language compiler. This approach has been adopted for the AspectX language with its
associated XWeaver.
2. Link time weaving, where the compiler is modified to include an aspect weaver. An aspect-
oriented language such as AspectJ is processed and standard Java bytecode is generated. This
can then be executed directly by a Java interpreter or further processed to generate native
machine code.
3. Dynamic weaving at execution time. In this case, join points are monitored and when an
event that is referenced in a pointcut occurs, the corresponding advice is integrated with the
executing program.
14. The WSDL conceptual model elements
The WSDL conceptual model shows the elements of a service description. Each element
is expressed in XML and may be provided in separate files. These elements are:
1. An introductory part that usually defines the XML namespaces used and that may include a
documentation section providing additional information about the service.
2. An optional description of the types used in the messages exchanged by the service.
3. A description of the service interface, that is, the operations that the service provides for
other services or users.
4. A description of the input and output messages processed by the service.
5. A description of the binding used by the service, that is, the messaging protocol that will be
used to send and receive messages.
6. An endpoint specification that is the physical location of the service, expressed as a URI-the
address of a resource that can be accessed over the Internet.

Figure - Organization of a WSDL specification

13. Survivable system four-stage process key activities
Survivable systems analysis is a four-stage process that analyzes the current or proposed system
requirements and architecture, identifies critical services, attack scenarios, and system
“softspots,” and proposes changes to improve the survivability of a system. The key activities in
each of these stages are as follows:
(1) System understanding For an existing or proposed system, review the goals of the system
(sometimes called the mission objectives), the system requirements, and the system
architecture.
(2) Critical service identification The services that must always be maintained and the
components that are required to maintain these services are identified.
(3) Attack simulation Scenarios or use cases for possible attacks are identified, along with the
system components that would be affected by these attacks.
(4) Survivability analysis Components that are both essential and compromisable by an attack
are identified, and survivability strategies based on resistance, recognition, and recovery are
identified.

Figure - Stages in survivability analysis

12. Three types of threats (Pg - 413)
Three types of threats have to be considered in resilience planning:
(1) Threats to the confidentiality of assets In this case, data is not damaged, but it is made
available to people who should not have access to it. An example of a threat to
confidentiality is when a credit card database held by a company is stolen, with the potential
for illegal use of card information.
(2) Threats to the integrity of assets These are threats where systems or data are damaged in
some way by a cyberattack. This may involve introducing a virus or a worm into software or
corrupting organizational databases.
(3) Threats to the availability of assets These are threats that aim to deny use of assets by
authorized users. The best-known example is a denial-of-service attack that aims to take
down a website and so make it unavailable for external use.
11. 10 types of security requirements
10 types of security requirements that may be included in a system specification:
(1) Identification requirements specify whether or not a system should identify its users before
interacting with them.
(2) Authentication requirements specify how users are identified.
(3) Authorization requirements specify the privileges and access permissions of identified
users.
(4) Immunity requirements specify how a system should protect itself against viruses, worms,
and similar threats.
(5) Integrity requirements specify how data corruption can be avoided.
(6) Intrusion detection requirements specify what mechanisms should be used to detect
attacks on the system.
(7) Nonrepudiation requirements specify that a party in a transaction cannot deny its
involvement in that transaction.
(8) Privacy requirements specify how data privacy is to be maintained.
(9) Security auditing requirements specify how system use can be audited and checked.
(10) System maintenance security requirements specify how an application can prevent
authorized changes from accidentally defeating its security mechanisms.
10. Model checking
Model checking has been widely used to check hardware systems designs. It is
increasingly being used in critical software systems such as the control software in NASA’s
Mars exploration vehicles and by Airbus in avionics software development.
The models used by model-checking systems are extended finite-state models of the
software. Models are expressed in the language of whatever model-checking system is used—for
example, the SPIN model checker uses a language called Promela. A set of desirable system
properties are identified and written in a formal notation, usually based on temporal logic. For
example, in the wilderness weather system, a property to be checked might be that the system
will always reach the “transmitting” state from the “recording” state.
Model checking is particularly useful in the validation of concurrent systems, which are
notoriously difficult to test because of their sensitivity to time. The checker can explore
interleaved, concurrent transitions and discover potential problems.
9. Explain why it is practically impossible to validate reliability specifications when these are
expressed in terms of a very small number of failures over the total lifetime of a system.
Validating reliability specifications that involve very small numbers of failures over a system's
lifetime can be practically impossible due to several key challenges:

1. Statistical Limitations

 Sample Size: When the failure rate is extremely low, the number of observed failures
during testing or operational use may be insufficient to draw statistically significant
conclusions.
2. Testing Constraints

 Long Testing Time: Reliability testing often requires long durations to observe
enough failures, especially for systems designed to operate for extended periods.
3. Rare Events

 Environmental Variability: Reliability can be influenced by various environmental

factors that may not be present during testing, further complicating validation efforts.
4. Data Interpretation

 Modeling Assumptions: Many reliability models rely on assumptions that may not
hold true for all systems, especially when dealing with very low failure rates.
5. Cost Implications

 Economic Feasibility: Extensive testing to validate low failure rates can be

prohibitively expensive. Organizations may not have the budget to conduct the
necessary long-term studies or to implement redundant systems to gather more data.