CN7021- ADVANCED SOFTWARE ENGINEERING

2
Introduction

Last week we learnt about software engineering and its importance as a solution to software crisis.
2
However, this week we shall learn the software development process. In the process, we shall identify

and analyze the significant tasks of software development process.

Objectives

By the end of this week, you should be able to:

 Understand clearly software development process.

 Understand the stages of software development process and function of each stage.

What is Software Development Process?

A software development process is a set of related activities towards the production of a software

product or system (Sommerville, 2016). These activities may involve the development of software from

scratch in any standard programming language or reuse of existing software components. For instance,

new enterprise application (business-oriented software) is now often developed by extending and

modifying existing systems or by configuring and integrating off-the-shelf software or system

components. We have a lot of literatures that describes techniques for carrying out these tasks.

Specifically, we shall consider the important activities that take place during software development

process (Pfleeger, 2009). These activities are:

1
 CN7021- ADVANCED SOFTWARE ENGINEERING

Figure 2.1 Stages of software development process (Sommerville, 2016)

1) A feasibility study: establishes whether or not the project worth being executed. The worth is

in terms of technicality, economy, ethics and legality. Feasibility study investigates cost-benefit

analysis.

2) Requirements engineering: it is about a formal elicitation and documentation of the software

functionalities or services. The requirements are contemplated and segregated into user

requirements, system requirements and functional requirements. The requirements are collected

using a number of practices as given -studying the existing or obsolete system and software.

Figure 2.2 The requirements elicitation and analysis process (Sommerville, 2016)

2
 CN7021- ADVANCED SOFTWARE ENGINEERING

a. Conducting interviews of users and developers

b. Referring to the database or

c. Collecting requirements from the questionnaires.

3) User interface design: providing a user-centered and interactive interface for the users of the

software.

4) Architectural design: proving a skeletal design for the system. This shows the components that

make the system, their functions and interactions.

5) Detailed design:

6) Coding or programming: transformation of detailed designs into instructions written in any

programming language.

7) System integration: this is often referred to as build. It is combining together individual

components that make the software system.

8) Validation (are we building the right system?): it is confirming that the software meets its users’

needs verification (are we building the system, right?):

9) Verification is concerned with the developer’s view – the internal implementation of the system

(Braude, 2011). Verification test here could be unit testing and system testing or integration

testing.

In unit testing, each module of the software is tested in isolation. The inputs to unit testing are:

a. The unit specification

b. The unit code

c. A list of expected test results.

However, integration testing is a combinational testing that involves testing two or more tested

units or modules. Here, inputs to system testing are the system specification and the code for

the complete system while the outcome of system testing is the completed, tested software,

proofing that the system meets its specification.

3
 CN7021- ADVANCED SOFTWARE ENGINEERING

10) Production: deployment

11) Documentation: making available necessary information about how to install the software, how

to de-install the software and how to use it.

12) Maintenance: making the software up to date at all times.

13) Project management:

Note: all these activities are the tasks involved in software development and can be regrouped into:

1) System Analysis:

a. a feasibility study

b. requirements engineering

Systems analysis defines the problems to be solved and provides the architecture of the

proposed system.

The terms analysis and synthesis come from Greek where they mean respectively "to take

apart" and "to put together" (Boehm, 2003).

Analysis is defined as the procedure by which we break down an intellectual or substantial

whole into parts.

While

Synthesis is defined as the procedure by which we combine separate elements or components

in order to form a coherent whole.

2) System Design: It involves:

a. Problem understanding: Looking at the problem from different angles to discover the

design requirements.

b. Identify one or more solutions: Evaluating possible solutions and choose the most

appropriate depending on the designer's experience and available resources.

4
 CN7021- ADVANCED SOFTWARE ENGINEERING

c. Describe solution abstractions: Using graphical, formal or other descriptive notations

to describe the components of the design.

d. Repeat: repeating the process for each identified abstraction until the design is

expressed in primitive terms.

System design is decomposed into:

a. user interface design

b. architectural design

c. detailed design

d. Coding and Testing:

3) Coding or programming

a. System integration

b. Validation (are we building the right system?)

c. Verification (are we building the system, right?)

4) Maintenance:

a. Production

b. Maintenance

c. Documentation

5) Project management

System Modelling

System modeling is the process of developing abstract models of a system, with each model presenting

a different view or perspective of that system. System modeling has generally come to mean

representing the system using some kind of graphical notation, which is now almost always based on

notations in the Unified Modeling Language (Sommerville, 2016). In this section we shall discuss

unified modelling language (UML) (Booch et al., 2005; Rumbaugh et al., 2004), which has become a

standard modeling language for object-oriented modeling. The UML has many diagram types (activity,

5
 CN7021- ADVANCED SOFTWARE ENGINEERING

use case, sequence, class diagram and state diagrams) and so supports the creation of many different

types of system model. Sommerville (2016) summarized these different types of diagrams in UML as:

1) Activity diagrams, which show the activities involved in a process or in data processing.

2) Use case diagrams, which show the interactions between a system and its environment.

3) Sequence diagrams, which show interactions between actors and the system and between

system components.

4) Class diagrams, which show the object classes in the system and the associations between these

classes.

5) State diagrams, which show how the system reacts to internal and external events.

Unified Modeling Language UML: a unified modeling language that contains a robust notation for

the modeling and development of object-oriented systems (Pressman & Maxim, 2015). It is an outcome

of a work started by Wirfs et al., (1990), Rumbaugh et al., (1999) and Jacobson (1992).

Diagrams of Various Types

Visualize, specify, construct, and record a system

 Structural: focus on the system's static aspects. The term "class" refers to a group of classes and

their interrelationships. An interface is a collection of operations that define a class's service.

Object, a set of items and their connections. Component, a collection of parts and their

interrelationships. Component, physical realization of a logical grouping of elements (for

example, classes and interfaces). Deployment, a set of nodes and their relationships that occurs

at runtime and represents a computational resource. Each node usually contains one or more

components. Package, a grouping of related UML entities (for example, classes and interfaces)

organized for readability and abstraction.

 Behavioral: focus on the system's dynamic aspects (changing parts). Interaction Diagrams. Use

case: coordinate system behaviors – user goals (high-level system services) – perspective from

6
 CN7021- ADVANCED SOFTWARE ENGINEERING

external organizations (actors). Sequence, pay attention to the order in which messages are sent.

Collaboration, pay special attention to the structural organization of artifacts that send and

receive messages. State chart, the system's evolving state as a result of events Focus on the

movement of power from one operation to the next.

What is a Use-Case Analysis?

Use case is a text narrative or template that describes a system function or feature from the user’s point

of view (Pressman & Maxim, 2015). It is written by the user and serves as a basis for the creation of a

more comprehensive analysis model. A use-case captures some user observable feature. This can be a

large or small function, depends on the degree of detail in your modeling effort. A use-case achieves a

discrete objective for the user. Examples, format a document, request an elevator.

User Interactions vs. User Goals

When editing a document, keep the following in mind: define a style, change a style, copy a style from

one document to the next versus the latter is a user objective, what the user wishes to accomplish. The

former are user experiences, things the user does to the system to achieve the goal. Both goals and

experiences have their position. Capture the user goals. Capture how the user can accomplish the goals,

capture user interactions, sequences of user interactions. Thus, start with the user goals and then refine

the user goals into many (many) users’ interactions.

Building a Use Case Diagram

A Use Case diagram is a graphical representation of the high-level system scope. It shows the

interactions between a system and its environment (Sommerville, 2016). It includes use cases, which

are pieces of functionality the system will provide, and actors, who are the users of the system. Looking

at a Use Case diagram, you should easily be able to tell what the system will do and who will interact

with it. Someone can create one or more Use Case diagrams for a single system. If one create more than

7
 CN7021- ADVANCED SOFTWARE ENGINEERING

one, then each will show a subset of the actors and/or use cases in the system. The use cases and actors

can be grouped into packages to help organize the model.

Α Use Case diagram can be helpful in communicating with the end users of the system. It is designed

to be straightforward and non-technical so that everyone on the team can come to a common

understanding of the system scope. It is usually created by the technical team, but in conjunction with

an end user representative.

A Use Case diagram shows a subset of the use cases and actors in the system. You can

create as many Use Case diagrams as you need to fully document the system scope.

Actors

An actor is a person, system, piece of hardware, or other thing that interacts with your

system. It is denoted with a stick figure. We differentiate active actors, who initiate

interactions with a system, and passive actors, who are targets of requests or who are

activated by the system.

Use Case

A use case is a piece of functionality the system will provide. Use cases are a requirements discovery

technique that were first introduced in the Objectory method (Jacobson et al., 1993). It is usually named

in the format <verb><noun>, such as “Deposit Check” or “Withdraw Cash”. Use cases are high level

and implementation-independent.

Relationships

Communicates relationship

A communicates relationship between an actor and a use case indicates that the actor initiates the use

case. An actor may initiate one or more use cases.

Example: Consider the following requirements of a flight booking and hotel reservation

system. A customer can purchase a ticket for a flight without having to book a hotel.

8
 CN7021- ADVANCED SOFTWARE ENGINEERING

They also have the opportunity to reserve a hotel room or change a reservation without

having to book a flight. Finally, they can hire a rental car for their holiday. Create a

simple Use Case diagram for the above problem.

Includes relationship

An “includes” relationship suggests that one use case must include another. In other words,

running one use case means that the other must be run as well. One use case may be

included by one or more other use cases. It is denoted by a dashed unidirectional arrow

from the source use case(s) to the target use case.

Extends relationship

An “extends” relationship is used when one use case optionally extends the functionality

provided by another. In other words, if one use case runs, an extending use case may or

may not run.

Example: Consider the following flight check-in subsystem requirements. In order to

successfully check-in passengers, the attendant must weigh the passengers’ luggage and

assign them a seat. There are two ways to assign a seat: assigning a window seat and

assigning an aisle seat, but only one need be completed in the process of assigning the

passenger a seat. Create a simple Use Case diagram for the above problem.

Generalization relationship

A generalization relationship between actors or use cases indicates that one actor or use

case (the child) inherits the characteristics of another actor or use case (the parent). The

child actor may initiate all of the use cases that the parent can initiate.

Example: Consider the following credit granting system for a bank where a customer can

apply for different types of credit. The types of customer are:

9
 CN7021- ADVANCED SOFTWARE ENGINEERING

1) Home

2) Owner

3) Home Buyer

4) Auto Buyer

5) Credit Card Applicant

If the customer is a home owner then a loan officer must process the customer’s home

equity loan application but if the customer is a home buyer then a loan officer must

process the customer’s home mortgage loan application. In both cases an assessor

(independent of the bank) is required to assess the home value. If the customer is an auto

buyer then a loan officer must process the customer’s auto loan application. Finally, if the

customer is a credit card applicant, a loan officer must process the credit card application.

For all types of customers (except for home owners) it is required that a credit history

check is made on the customer. This information can be obtained by the local credit

bureau. Create a Use Case diagram for the above problem.

Class Diagram

A Class diagram is used to show a subset of the classes, interfaces, packages of classes, and relationships

in the system. A Class diagram includes a subset of the classes, attributes, operations, relationships, and

packages of classes in the system. Someone can create as many Class diagrams as needed to fully

document a system design. Class diagram is a UML diagram type that shows the object classes in a

system and their relationships (Sommeville, 2016).

Figure 2.3 Declaration for attributes of a class

10
 CN7021- ADVANCED SOFTWARE ENGINEERING

An attribute is a piece of information associated with a class. All objects in a given class will share the

same attributes, but each object may have its own attribute values.

An operation is a method within the class.

Figure 2.4. Declaration for methods of a class

Adding Class Relationships

There are many different types of relationships between classes. An association relationship indicates

that one class needs to communicate with another. Associations may be unidirectional or bidirectional.

An aggregation

An aggregation relationship suggests a whole/part relationship between two classes. A generalization

relationship indicates a parent/child inheritance relationship between two classes. Finally, a dependency

relationship is a weaker form of association, suggesting that a change to one class may affect another.

Association names can be added to a relationship to clarify the relationship's purpose. Role names can

also be used that show what role each class plays in the relationship. Multiplicity settings show how

many instances of one object are related to a single instance of the other object.

Relationships are drawn on Class diagrams as arrows between the two related classes. Different types

of arrows are used to indicate different types of relationships.

Object Oriented Modelling

11
 CN7021- ADVANCED SOFTWARE ENGINEERING

The OO model closely resembles the problem domain; base your model on the problem domain's

objects; refine the high-level model iteratively until you have an implementation. During the creation

process, try to avoid making large conceptual leaps.

Object’s characteristics

Discrete and distinguishable entities. Classification, abstract entities with the same structure (attributes)

and actions (operations) into groups. Polymorphism, discrete and distinguishable entities. Inheritance,

on different classes, the same operation can behave differently. Based on a hierarchical arrangement,

attributes and operations are shared (Schach, 2010).

Object, something that makes sense in the application context (application domain), J.Q. Public,

Joe’s Homework Assignment 1, J. Q. Public’s driver’s license. All objects have identity and are

distinguishable. NOT objects, Person, Driver’s license.

Class, describes a group of objects with similar properties (attributes), common behavior (operations),

common relationships to other classes, and common semantics. Person, J. Q.

Public, Joe Smith, D. Q. Public. Card, Credit card, Driver’s license, Teller card.

Figure 2.5. Class Diagram

12
 CN7021- ADVANCED SOFTWARE ENGINEERING

Figure 2.6. Operations and Methods

Associations

Conceptual connection between classes. A credit card is issued-by a bank. A person works-for a

company

Figure 2.7. Associations in a Class

There is no direction implied in an association (Rumbaugh, 1991)

13
 CN7021- ADVANCED SOFTWARE ENGINEERING

Unified adds a direction indicator, inconsistently used.

One object can be related to many objects through the same association

One person can hold zero or more credit cards (0..*). Each card has zero or one holder (0..1)

Ternary association, Project, language, person

Seldom needed (and should be avoided)

14
 CN7021- ADVANCED SOFTWARE ENGINEERING

Associations can have properties the same way objects have properties

Attach names to the ends of an Association to clarify its meaning

Aggregation

The is-part-of association is a unique association. A paragraph is made up of sentences (a paragraph

consists of sentences). A paragraph is a section of a text (a document consists of paragraphs)

15
 CN7021- ADVANCED SOFTWARE ENGINEERING

Often used in parts explosion

Figure 2.8. Composition

Generalization and inheritance

The is-a relationship. Cards share several properties. Split the common properties into a separate class,

the base-card. Allow all cards to inherit from this class, resulting in all cards becoming base-cards (plus

possibly something more).

16
 CN7021- ADVANCED SOFTWARE ENGINEERING

Figure 2.9. Example

Aggregation vs. Association

Is it possible to use the phrases is-a-part-of or is-made-of? Are operations applied to the pieces

automatically? (for example, move), aggregation. It's unclear what it should be......

Aggregation vs. Inheritance

Do not confuse the is-a relation (inheritance) with the is-part-of relation (aggregation). Use inheritance

for special cases of a general definition and aggregation for parts explosion.

17
 CN7021- ADVANCED SOFTWARE ENGINEERING

A recursive aggregate contains (directly or indirectly) an instance of the same kind of aggregate

Figure 2.12. Class diagram Meta

Figure 2.13. Class diagram Meta model

18
CN7021- ADVANCED SOFTWARE ENGINEERING

(
Figure 2. 10. Use Case Meta model (Kooper, 2006)

Figure 2. 11. Use Case Meta model (Kooper, 2006)

Figure 2.14. Data flow (Kooper, 2006)diagram

Figure 2.15. Possible Meta model for

19
 CN7021- ADVANCED SOFTWARE ENGINEERING

Figure 2. 17. Revised Meta model for DFD (Kooper, 2006)

Figure 2.12. Architecture Meta model (Kooper, 2006)

Conclusion

There are many different software processes but all must include four activities that are fundamental to

software engineering: Software specification (the functionality of the software and constraints on its

operation must be defined); Software design and implementation (the software to meet the specification

must be produced); Software validation (the software must be validated to ensure that it does what the

customer wants) and Software evolution (the software must evolve to meet changing customer needs.

In some form, these activities are part of all software processes. In practice, of course, they are complex

activities in themselves and include sub-activities such as requirements validation, architectural design,

unit testing, etc. This week, we have been introduced to these software processes. You have been

informed of the various stages of software development process. In the coming week, we shall also

consider requirements engineering: Analysis, Specification and Validation.

20
 CN7021- ADVANCED SOFTWARE ENGINEERING

References

Boehm, B. (2003). Balancing Agility and Discipline: A Guide for the Perplexed. Boston. Addison-

Wesley.

Braude, E. (2011). Software Engineering: Modern Approaches (2nd Ed.). Wiley.

Jacobson, I., Object-Oriented Software Engineering, Addison-Wesley, 1992.

Jacobson, I., Christerson, M., Jonsson, P. and Overgaard, G. (1993). Object-Oriented Software

Engineering. Wokingham: Addison-Wesley.

Jalote, P. (2010). An Integrated Approach to Software Engineering (3rd Ed.). Springer.

Kooper. (2006). Visual Modeling for Software Intensive Systems.

Pfleeger, S. (2009). Software Engineering: Theory and Practice (4th Ed.). Prentice Hal.

Rumbaugh, J., Jacobson, I. and Booch, G. (1999). The Unified Software Development Process.

Reading, Mass.: Addison-Wesley.

Rumbaugh, J. (1991). Object-Oriented Modeling and Design. Prentice Hall.

Schach, S. (2010). Object-Oriented and Classical Software Engineering (8th Ed.). McGraw- Hill.

Sommerville, I. (2016). Software Engineering (10th Ed.). Harlow. Pearson Education.

Wirfs-Brock, R., B. Wilkerson, and L. Weiner, Designing Object-Oriented Software, Prentice Hall,

1990.

21