TM354 Software Engineering 1

Software Engineering
TM354 Final Rev 2023
 TM354 Software Engineering 2

Unit 1 section 2:
▪ component as a unit of reuse or replacement in a software system So, a component could be a module or
class with certain properties that make it reusable or replaceable in a given system architecture (Enterprise
Java Beans (Net and CORBA are examples of standards for components)
▪ A service is a unit of reuse corresponding to a piece of functionality, described in a standard language, with
published interfaces through which the service execution can be requested.
A service-oriented architecture (SOA) structures software as a set of services. notion of services
accessed remotely through a web browser as a service (SaaS) (Gmail and Google Docs).
▪ Similarities and differences between components and Services
▪ Similarities
a. Both promote reuse and flexibility
b. Both use public interfaces to allow requesters to use of functionality without relying on implementation
▪ Differences
a. A component is usually implemented in a specific object-oriented technology therefore only clients
compliant with that technology can easily communicate and integrate with it
b. A service uses communication standards that allow the interoperation of diverse technologies
c. Components tend to be associated with business entities, while services tend to be associated to
business processes, they may realize part or the whole of the functions within such a process and may
involve several business entities
Unit 1 section 3:
▪ Waterfall model It is the classic model where the five activities (analysis design implementation, testing,
and maintenance) are arranged into a single sequence (purely sequential life cycle.
▪ Why has Waterfall model not proven satisfactory in practice?
a. A working version of the software system will not be available until late in the testing activity.
b. Errors will be detected in testing activity, and this is so significant because developer needs to check all
the previous activities to check the source of the error which may cause delay in delivery at the end.
▪ Real projects rarely follow a purely sequential life cycle
▪ Iterative and incremental development
o It is often difficult to identify all requirements and state them explicitly at the outset of a development
project It is a good idea to start with a subset of the requirements and incrementally grow the system
with feedback from each iteration This approach is known as iterative and incremental development.
o Each iteration is a complete small project, with a short, fixed timeframe timeboxed consisting of
requirements, design, implementation testing and integration, and resulting in a partially working
system Each of these repeated short iterations adds complexity until the final system is produced
▪ Dealing with risk
o A software solution to a problem needs to be considered in the broad context of the domain to allow
you to manage the risks associated with a development project
o There are additional risks when developing large projects because the chances of failure increase as
the size of a software project increases as more errors are likely to be introduced Effective
communication between the members of a large team also becomes more difficult
o Assessing risks and taking steps to reduce them are important activities in software development this is
known as risk management
 TM354 Software Engineering 3

Unit 1 section 4
use case view contains the basic scenarios that describe the users and the tasks that they need to
perform with the aid of a software system. (Scenarios are partitioned into use cases).
logical view concerned with FR. What should the software do for its intended users? It involves
construction models that represent main elements of a system and how they interact.
implementation concerned with organization of code modules that comprise a system.
view it addresses the management of source code, data files and executables
deployment concerned with the relationship between the various executables (and other run-time
view components) and their intended computer systems.
process view concerned with aspects of concurrency. What are the processes and threads? How do
they interact? It deals with such things as response time, deadlock and fault tolerance.
Artefacts refer to model and other document, it produced from an activity is used to feed into next activity
- Domain modeling: Understanding of an environment in which any system that is designed operate.
During domain modelling, we produce the following artefacts:
1. Dynamic model: a description of the business processes and behavior of the domain.
2. Business rules: constraints on the way the above model operates.
3. Glossary: definitions of relevant terms.
4. Structural domain model: an initial structural model representing the significant concepts in the
domain and how they are related.

Unit 2 section 2 Activities of the requirements engineering process

1. requirements elicitation: identifying the requirements this is done by
a. consulting the stakeholders. b. reading existing documents. c. understanding the domain.
d. defining system boundaries. e. understanding the possibilities for change.
- many techniques for elicitation [interviews- focus groups- team meetings- brainstorming sessions-
crowd sourcing.
2. requirements analysis and negotiation.
- is the activity where requirements are categorized and prioritized, and examined for their properties of
consistency, completeness and non-ambiguity.
- Models of requirements are created to help communication with the customers and developers.
3. requirements documentation.
- is usually done using a template document
- Documentation also includes the modelling artefacts.
4. requirements validation.
- consists of a careful check of overall requirements documentation, by following a checklist of questions
- This is a way of ensuring that the requirements correspond to what is really intended of the system.

Unit 2: Section 3: Functional requirements

- Sommerville distinguishes two types of requirements as follows:
Requirements specification [ the activity of translating the information gathered during the analysis
activity into a document that defines a set of requirements Two types of requirements may be included
in this document
1. User requirements are abstract statements of the software requirements for the customer and end
user of the system
2. System requirements are a more detailed description of the functionality to be provided.
 TM354 Software Engineering 4

Unit 2 section 5:
▪ Fit criteria added to FR and NFR to make it measurable and testable at the end to see if they meet users
need These criteria are known as fit criteria
▪ A fit criterion is a precise and testable statement of a requirement It may specify
▪ A quantitative measure for some aspect of the system s behavior or performance
▪ Benefits of attaching fit criteria to requirements
a. Helps to clarify the requirement
b. Helpful communication tool for interacting with different stakeholders to check that the criteria
being specified are acceptable and reflect the correct understanding of the requirement.
Unit 3 section 5:
▪ The developers would normally start the prototyping process because they have detected or identified a
particular problem in their requirements analysis.
▪ The intended users should test it, For example, if you developed a series of interfaces as part of a prototype
for the borrowing and returning of books, the library members would be the testers Why?
1. They know their own needs for their day to day role, and
2. they have the most to gain from a successful implementation

▪ The main goal is to make sure that the prototype meets the needs of its intended users
▪ Next, the developer needs to document what has been achieved This will provide the information on the
final software system for all those people involved in its development
▪ Finally, the people who should be involved in the development of the prototype are the real users

Unit 5 section 2: Agile modelling principles

1- relevant when thinking about how much precision and correctness should go into drawing diagrams.
2- They stress that modelling is not ultimate goal, software is Lightness and simplicity take precedence over
completeness and complexity.
3- Models should only be pursued while they are of use.
4- Ease of change and adaptability also need to be part of the modelling process.

Unit 5 section 3: Domain Structure Model

▪ distinguish between objects and classes
a. An object stands for something real in a domain expert ‘s world (specific customer a specific room)
b. The attributes of an object have values that can be tested
c. An object is considered as an instance of the class

▪ Types of Association
a. Recursive association represents an association between a class and itself.
b. derived associations: when other associations and attributes in the model can be combined to
achieve the same navigation. deducible to avoid association redundancy.
c. Qualified association: when classes has an attribute that acts as a unique identifier.
It is an association at one end of which there is a qualifier consisting of one or more attributes.
d. The navigation of associations is established, based on the way objects in the system need to
collaborate to realize the system operations
e. Navigation expressions are names used to indicate specific objects or attributes of objects, and
do not take navigability into account
 TM354 Software Engineering 5

Unit 7 section 5
▪ Packages: UML provides a way of grouping model elements into a unit called a package.
- A UML package is a much more general idea than a Java package.
- A package can be used to group almost anything we please.
- Use cases can be grouped into packages, for example – and so can other packages!
▪ Each package defines a namespace.
- Any two distinct model elements in the same namespace (package) must always have different names.
- Elements in different namespaces (packages) can have the same name.
- One package can be associated with another if some of the model elements in the first package are
associated with model elements in the second.
- A package can depend on another package.
- A package cannot have an interface, so packages cannot interact with one another.

▪ There are three main reasons for partitioning a software system:

1.To manage size and complexity;
2.For information hiding;
3.For logical decomposition.

▪ In UML, there are two stereotypes in which you may see other packages:
a. <<import>>: When you import a package, all public elements of that package is visible.
- «import» stereotype can give rise to a naming problem, because an «import» adds the names of the
elements in the target package to the source package.
- The result is that, if an imported name clashes with an existing name, you have to qualify the imported
elements with their package name in order to distinguish them.
b. <<access>>: In this case also, all public elements of target package will be visible to source package.
- «access» stereotype allows simpler traceability, because other packages must use the full name of an
accessed element, such as PackageName::ElementName. So naming problem will not arise.
 TM354 Software Engineering 6

Unit 9: section 3
A major aspiration of software engineering is reuse taking what you or others have done or created in the
past and using it either unchanged or with relatively little adaptation
▪ Following are some reasons why reuse is desirable
1. It avoids duplication of effort and reinventing already existing solutions which saves resources
2. It promotes reliability because developers can use tried and trusted solutions
3. It speeds up development (we take existing solutions without starting from beginning every time.
4. It is a mechanism for spreading good practice among the software development community and
familiarizing practitioners’ developers) with tried and tested solutions
Reuse on different levels
Reuse can involve software components replaceable and reusable software elements, It involve reuse of:
1. knowledge in the elicitation of requirements, known as requirements patterns
2. ways of solving conceptual analysis problems, known as analysis patterns
3. architecture this may just involve reusing a structural idea or it may go further.
4. ways of solving problems of design and implementation, known as design patterns
5. ways of doing things in a particular language these are small units of reuse known as idioms.
Unit 9 section 4
Architectural styles: in general level identify a number of basic plans used in software architecture.
1- Client–server 2- Peer-to-peer 3- Call-return

caller makes a procedure call to

resembles the client–server another component and waits for the
server waits for requests from call to return.
clients, processes, and returns a style.
except that all the components In OOP call is a method invocation by
response to the client one object on another by the sending
are both clients and servers
of a message.
 TM354 Software Engineering 7

5- Service-oriented a set of service providers makes services available

to a set of service consumers.

communication is facilitated by a virtual

communication channel called an Enterprise
Service Bus (ESB)

6- Independent components: 7- Notification (publish– subscribe)

2 kinds of components are observers and subjects.

it execute concurrently and are decoupled as far as Observers can register themselves with a subject in
possible, but can communicate by messages that allow order to be kept notified whenever some particular
them to exchange data or coordinate their event happens at the subject’s end.
operations. Subscribers register to receive updates (often
messages) whenever a publisher posts a new item.

8- Layered architecture style 9- Data flow or Pipes and filter:

series of layers as stacked on top of another components are objects or small independent
Each layer uses services provided by the layers subprograms ( that process a stream of data and pass the
below It also supplies services to the layer above results on to other components.
Components are various services in each layer and Communication is unidirectional and uses fixed channels.
connectors are the calls made on the services. Each filter has no knowledge of other filters but accepts
a layer communicates only with layers above and the data, processes it and passes it on.
below There is no communication between Connectors are services, provided by operating
components in the same layer environment that pipe data from one filter to another
Ex: a compiled Java program, client server Ex: Unix OS for combining functions and is also seen in
architecture, in which there are just the two layers the Stream application programming interface (
and the connector takes the form of a request and introduced from Java 8 onwards).
response, often over a network
 TM354 Software Engineering 8

Unit 10- section 1

▪ component based development CBD (to develop systems by assembling them from reusable self)
contained software components.
▪ Components have two types of interfaces a provided interface and a required interface
▪ Building a software by plugging together off the shelf components approach is known as CBD

Advantages Disadvantages
1- Reusing a standard component should be cheaper 5- Using standard components may restrict what
than developing software from scratch we can do since we have to work with the
2- Using off the shelf components will allow capability of the components
applications to be developed more quickly. 1- Some additional software is likely to be
3- Standard components will have been used in many needed as “plumbing”
other projects, so their behavior will be well ▪ If the interfaces of components are
understood, and any bugs are likely to be known incompatible, adapters will have to be
4- Components are pluggable, so it is often possible to written
replace one with another providing it has same ▪ Creating a system by plugging together off
interface and behaves in the same way the shelf components may not be as simple
as it sounds
Unit 10 section-3: Service-oriented architecture SOA
- A service is an abstract description of some unit of business functionality, usually described in terms that
are meaningful from both a business and a technical perspective
- A service must be implemented by a service provider and accessed over a network by a client service
- consumer or service requester
- By combining a set of services it is possible to build applications and structuring them as service oriented
architecture (SOA)

▪ The services can be classified into 3 types of

1- Utility services which provide some generic functionality useful in a wide range of applications
2- Business services which implement a specific business function
3- Coordination services which coordinate workflows composed of a number of individual services
 TM354 Software Engineering 9

▪ Services have two properties which may sometimes apply to components as well
a. Statelessness A service or component is stateless if it responds to each request as a one off without
retaining any memory of previous requests This reduces complexity, because each request can be dealt
with in the same way.
b. Location transparency Clients can use a service without needing to know its physical location the
advantage of location transparency is that the service or component can be moved to a different
computer without clients being affected.

▪ Advantages of SOA
1. Agile and flexible response.
- Can respond quickly to changes in customers’ requirements,
2. Less duplication.
- Repeated functions can be packaged as a service and made available for reuse.
3. Integration of legacy applications
- Legacy software can be wrapped as a service and made to interoperate with other applications.
4. Use of third-party services:
- Credit card validation or online payment, provided as services by external suppliers.
5. Language independence:
- Services written in different languages can interoperate using standard protocols.
 TM354 Software Engineering 10

Unit 11- section 2 SQF

1- Correctness: How well the software does what the customer wants
2- Reliability: How well the software does what it is supposed to do;
3- Efficiency: How well the system runs on the customer's hardware.
4- Integrity: How well the data is secured.
5- Usability: How easy the system is to use
6- Maintainability: How easily bugs can be found and fixed.
7- Flexibility: How easily the system can be changed while in service
8- Testability: How easily the system can be tested to show customer's requirements have been met
9- Portability: H ow easily the system can be used on another machine.
10- Reusability: How easy to reuse some of software to make future developments more cost effective.
11- Interoperability: How easy it is to interface the system with another one required by the customer.

SQFs
are affected by 3 types of requirements:

Product operation req. Product revision req.

Product transition req.
[How product will be used] [How the product will be
changed] [How product will be modified for
different operating environments]
Correctness
Maintainability
Reliability Portability
Flexibility
Efficiency Reusability
Testability
Integrity Interoperability

Usability

How to measure the primary SQFs?

Correctness is measured by defects per thousand lines of code (defects per KLOC).
A defect (bug) is a verified lack of conformance to requirements.

How to measure integrity:

- by considering the proportion of attacks on a product as opposed to bona fide uses
- In cases where integrity is of great importance and different kinds of attack can be identified, it can be
useful to measure or estimate quantities such as the likelihood that an attack of a given type will occur
within a given time and the likelihood that an attack of a given type will be repelled
- If historical data is available that allows these probabilities to be calculated with some accuracy, for
example using information from a log file, then it becomes possible to assign numerical values in a
simple way to the integrity of a system.
 TM354 Software Engineering 11

Section 4 Testing
Object Oriented Complexity metrics
1. Depth of inheritance tree DIT: largest number of hops through an object s super classis.
2. Coupling between objects CBO: the number of relationships the class has with other classes
(The more relationships a class has, and so the higher the value of this metric, the more difficult it is to
understand the use of the given class).
3. Number of children NOC :the number of immediate children for that class This metric is a measure of
the number of classes that will be affected by changes to a given parent class
4. Response for a class RFC: the size of the response set for the class, which consists of all the methods of
this class (including methods inherited from super classes together with all the methods that are
invoked on objects of other classes
Classes with high values for this metric will be more difficult to understand than classes with low values
5. Lack of cohesion in methods LCOM: the number of pairs of methods that do not make reference to the
same attributes, minus the number of pairs of methods that do, or zero should this be negative.
6. Weighted methods per class WMPC: sum of the cyclomatic complexities of each method of class

System testing consists of the following generic 8 tests

1. User command testing (or operator testing) tests all user commands from the point of view of tolerance
to syntax errors and data input errors
2. Interface and protocol testing if the system communicates with other systems in the outside world,
tests its interaction with the communication system
3. Start up and initialization testing tests the system s ability to be started in a working hardware/software
configuration
4. Restart testing tests the ability of the system to recover from errors of internal state
5. Performance testing tests that the system meets all specified operating requirements for speed,
number of concurrent users permitted, etc
6. Stress testing tests that the system can operate reliably at the limits of each of its resources (for
example, to stress test a web server, we may simulate the accesses of hundreds or thousands of users all
at the same time to see if it can cope with the load
7. Security testing tests that the system does not offer opportunities to breach security
8. Acceptance testing is performed by the customer and after which, all being well, the system is accepted