1

This series of lectures was prepared for the third class of software engineering /

Aliraqia University/ Baghdad/ Iraq.

In prepared these lectures, I depend on the book “Software Engineering 9th ed

(intro txt) - I. Sommerville (Pearson, 2011) BBS", and I depend on some lectures

of the University of Technology/ software engineering / Baghdad/ Iraq / , and

internet

These lectures are not finished yet, i will improve it in the future

Forgive me for anything wrong by mistake, I wish you can profit from these

lectures

My regard

Marwa Moutaz/ M.Sc. studies of Communication Engineering / University of

Technology/ Bagdad / Iraq.

2

3

Introduction to Software Engineering

1.1 Introduction

Virtually all countries now depend on complex computer-based systems. Most

electrical products include a computer and controlling software. Industrial

manufacturing and distribution is completely computerized, as is the financial

system. Therefore, producing and maintaining software cost-effectively is essential

for the functioning of national and international economies. Software engineering is

an engineering discipline whose focus is the cost effective development of high-

quality software systems. Software is abstract and intangible. It is not constrained

by materials, or governed by physical laws or by manufacturing processes. In some

ways, this simplifies software engineering as there are no physical limitations on the

potential of software. However, this lack of natural constraints means that software

can easily become extremely complex and hence very difficult to understand.

The notion of software engineering was first proposed in 1968 at a conference held

to discuss what was then called the 'software crisis'. This software crisis resulted

directly from the introduction of new computer hardware based on integrated

circuits. Their power made hitherto unrealizable computer applications a feasible

proposition. The resulting software was orders of magnitude larger and more

complex than previous software systems. Early experience in building these systems

showed that informal software development was not good enough. Major projects

were sometimes years late. The software cost much more than predicted, was

unreliable, was difficult to maintain and performed poorly. Software development

was in crisis. Hardware costs were tumbling whilst software costs were rising

rapidly. New techniques and methods were needed to control the complexity

inherent in large software systems. These techniques have become part of software

engineering and are now widely used. However, as our ability to produce software

has increased, so too has the complexity of the software systems that we need. New

technologies resulting from the convergence of computers and communication

systems and complex graphical user interfaces place new demands on software

engineers. As many companies still do not apply software engineering techniques

effectively, too many projects still produce software that is unreliable, delivered late

and over budget. The tremendous progress since 1968 and that the development of

software engineering has markedly improved software. Effective methods of

software specification, design and implementation have been developed. New

notations and tools reduce the effort required to produce large and complex systems.

4

There is no single 'ideal' approach to software engineering. The wide diversity of

different types of systems and organizations that use these systems means that we

need a diversity of approaches to software development. However, fundamental

notions of process and system organization underlie all of these techniques, and

these are the essence of software engineering.

1.2 Software and Software Engineering

Software is (1) instructions (computer programs) that when executed provide desired

function and performance, (2) data structures that enable the programs to adequately

manipulate information, and (3) documents that describe the operation and use of

the programs. Software engineers are concerned with developing software products,

i.e., software which can be sold to a customer. There are two fundamental types of

software product:

1. Generic products these are stand-alone systems that are produced by a

development organization and sold on the open market to any customer who is able

to buy them. Examples of this type of product include software for PCs such as

databases, word processors, drawing packages and project management tools.

2. Customized (or bespoke) products these are systems which are commissioned by

a particular customer. A software contractor develops the software especially for that

customer. Examples of this type of software include control systems for electronic

devices, systems written to support a particular business process and air traffic

control systems. An important difference between these types of software is that, in

generic products, the organization that develops the software controls the software

specification. For custom products, the specification is usually developed and

controlled by the organization that is buying the software. The software developers

must work to that specification. However, the line between these types of products

is becoming increasingly unclear. More and more software companies are starting

with a generic system and customizing it to the needs of a particular customer.

Software engineering is an engineering discipline that is concerned with all aspects

of software production from the early stages of system specification to maintaining

the system after it has gone into use. In this definition, there are two key phrases:

1. Engineering discipline Engineers make things work. They apply theories,

methods and tools where these are appropriate,. But they use them selectively and

always try to discover solutions to problems even when there are no applicable

5

theories and methods. Engineers also recognize that they must work to

organizational and financial constraints, so they look for solutions within

These constraints.

2. All aspects of software production Software engineering is not just concerned with

the technical processes of software development but also with activities such as

software project management and with the development of tools, methods and

theories to support software production. In general, software engineers adopt a

systematic and organized approach to their work, as this is often the most effective

way to produce high-quality software. However, engineering is all about selecting

the most appropriate method for a set of circumstances and a more creative, less

formal approach to development may be effective in some circumstances. Less

formal development is particularly appropriate for the development of web-based

systems, which requires a blend of software and graphical design skills.

1.3 Software Characteristics

To gain an understanding of software (and ultimately an understanding of software

engineering), it is important to examine the characteristics of software that make it

different from other things that human beings build. When hardware is built, the

human creative process (analysis, design, construction, testing) is ultimately

translated into a physical form. If we build a new computer, our initial sketches,

formal design drawings, and prototype evolve into a physical product (chips, circuit

boards, power supplies, etc.). Software is a logical rather than a physical system

element. Therefore, software has characteristics that are considerably different than

those of hardware:

1-Software is developed or engineered; it is not manufactured in the classical sense.

Although some similarities exist between software development and hardware

manufacture, the two activities are fundamentally different. In both activities, high

quality is achieved through good design, but the manufacturing phase for hardware

can introduce quality problems that are nonexistent (or easily corrected) for

software. Both activities are dependent on people, but the relationship between

people applied and work accomplished is entirely different. Both activities require

the construction of a "product" but the approaches are different.

2- Software doesn't "wear out."

6

Figure 1: failure rate for hardware

Figure 1 depicts failure rate as a function of time for hardware. The relationship,

often called the "bathtub curve," indicates that hardware exhibits relatively high

failure rates early in its life (these failures are often attributable to design or

manufacturing defects); defects are corrected and the failure rate drops to a steady-

state level (Ideally, quite low) for some period of time. As time passes, however, the

failure rate rises again as hardware components suffer from the cumulative effects

of dust, vibration, abuse, temperature extremes, and many other environmental

maladies. Stated simply, the hardware begins to wear out.

Software is not susceptible to the environmental maladies that cause hardware to

wear out. In theory, therefore, the failure rate curve for software should take the form

of the “idealized curve” shown in Figure 2. Undiscovered defects will cause high

failure rates early in the life of a program. However, these are corrected (ideally,

without introducing other errors) and the curve flattens as shown. Figure2:

7

Figure2: Idealized and actual failure curves for software

The idealized curve is a gross oversimplification of actual failure models for

software. However, the implication is clear—software doesn't wear out. But it does

deteriorate. This seeming contradiction can best be explained by considering the

“actual curve” shown in Figure.2. During its life, software will undergo change

(maintenance). As changes are made, it is likely that some new defects will be

introduced, causing the failure rate curve to spike as shown in Figure 2. Before the

curve can return to the original steady-state failure rate, another change is requested,

causing the curve to spike again. Slowly, the minimum failure rate level begins to

rise—the software is deteriorating due to change. Another aspect of wear illustrates

the difference between hardware and software. When a hardware component wears

out, it is replaced by a spare part. There are no software spare parts. Every software

failure indicates an error in design or in the process through which design was

translated into machine executable code. Therefore, software maintenance involves

considerably more complexity than Hardware maintenance.

8

3-Although the industry is moving toward component-based assembly, most

software

continues to be custom built. Considering the manner in which the control hardware

for a computer-based product is designed and built. The design engineer draws a

simple schematic of the digital circuitry, does some fundamental analysis to assure

that proper function will be achieved, and then goes to the shelf where catalogs of

digital components exist. Each integrated circuit (called an IC or a chip) has a part

number, a defined and validated function, a well-defined interface, and a standard

set of integration guidelines. After each component is selected, it can be ordered off

the shelf. As an engineering discipline evolves, a collection of standard design

components is created. Standard screws and off-the-shelf integrated circuits are only

two of thousands of standard components that are used by mechanical and electrical

engineers as they design new systems. The reusable components have been created

so that the engineer can concentrate on the truly innovative elements of a design,

that is, the parts of the design that represent something new. In the hardware world,

component reuse is a natural part of the engineering process. In the software world,

it is something that has only begun to be achieved on a broad scale. A software

component should be designed and implemented so that it can be reused in many

different programs. In the 1960s, scientific subroutine libraries that were reusable in

a broad array of engineering and scientific applications had been built. These

subroutine libraries reused well-defined algorithms in an effective manner but had a

limited domain of application. Today, the view of reuse has been extended to

encompass not only algorithms but also data structure. Modern reusable components

encapsulate both data and the processing applied to the data, enabling the software

engineer to create new applications from reusable parts. For example, today's

graphical user interfaces are built using reusable components that enable the creation

of graphics windows, pull-down menus, and a wide variety of interaction

mechanisms. The data structure and processing detail required to build the interface

are contained with a library of reusable components for interface construction.

1.4 The attributes of good software

As well as the services that it provides, software products have a number of other

associated attributes that reflect the quality of that software. These attributes are not

directly concerned with what the software does. Rather, they reflect its behavior

while it is executing and the structure and organization of the source program and

associated documentation. Examples of these attributes (sometimes called

9

nonfunctional attributes) are the software s response time to a user query and the

understandability of the program code. The specific set of attributes that you might

expect from a software system obviously depends on its application. Therefore, a

banking system must be secure; an interactive game must be responsive, and so on.

These can be generalized into the set of attributes shown in Table 1, which are the

essential characteristics of a well-designed software system.

Table 1: Essential attributes of good software

10

Exercise:-

1- What we mean by software engineering? And why it is important in our

lives?

2- What are the factors that led to “software crisis”?

3- What is the difference between hardware and software? Depend on your

answer about what you understand from our lecture.

4- What are the four important attributes that all professional software

should have? Suggest four other attributes that may sometimes be

significant.

11

12

The Software Life cycle

2.1 Software Processes

A software process is a set of activities that leads to the production of a software

product. These activities may involve the development of software from scratch in

a standard programming language like Java or C. Increasingly, however, new

software is developed by extending and modifying existing systems and by

configuring and integrating off-the-shelf software or system components. Software

processes are complex and, rely on people making decisions and judgments.

Because of the need for judgment and creativity, attempts to automate software

Processes have met with limited success. Computer-aided software engineering

(CASE) tools can support some process activities. However, there is no possibility,

at least in the next few years, of more extensive automation where software takes

over creative design from the engineers involved in the software process. One reason

the effectiveness of CASE tools is limited is because of the immense diversity of

software processes. There is no ideal process, and many organizations have

developed their own approach to software development.

Processes have evolved to exploit the capabilities of the people in an organization

and the specific

Characteristics of the systems that are being developed. Although there are many

software processes, some fundamental activities are common to all software

processes:

1. Software specification. The functionality of the software and constraints on its

operation must be defined.

2. Software design and implementation. The software to meet the specification must

be produced.

3. Software validation. The software must be validated to ensure that it does what

the customer wants.

4. Software evolution. The software must evolve to meet changing customer needs.

Although there is no 'ideal' software process, there is scope for improving the

software process in many organizations. Processes may include outdated techniques

or may not take advantage of the best practice in industrial software engineering.

13

Indeed, many organizations still do not take advantage of software engineering

methods in their software development.

Software processes can be improved by process standardization where the diversity

in software processes across an organization is reduced. This leads to improved

communication and a reduction in training time, and makes automated process

support more economical. Standardization is also an important first step in

introducing new software engineering methods and techniques and good software

engineering practice.

2.2 Software process models

A software process model or a software engineering paradigm is an abstract

representation of a software process. Each process model represents a process from

a particular perspective, and thus provides only partial information about that

process. In the sections that follow, a variety of different process models for software

engineering are discussed.

2.3 Prescriptive process models

2.3.1 The Linear Sequential Model (waterfall model)

Sometimes called the classic life cycle or the waterfall model, the linear sequential

model suggests a systematic, sequential approach to software development that

begins at the system level and progresses through analysis, design, coding,

testing, and support. Figure 1 illustrates the linear sequential model for software

engineering.

14

Figure1: The linear sequential model

The linear sequential model encompasses the following activities:

System/information engineering and modeling. Because software is always part

of a larger system (or business), work begins by establishing requirements for all

system elements and then allocating some subset of these requirements to software.

This system view is essential when software must interact with other elements such

as hardware, people, and databases. System engineering and analysis encompass

requirements gathering at the system level with a small amount of top level design

and analysis

Software requirements analysis. The requirements gathering process is intensified

and focused specifically on software. To understand the nature of the program(s) to

be built, the software engineer ("analyst") must understand the information domain

for the software, as well as required function, behavior, performance, and interface.

Requirements for both the system and the software are documented and reviewed

with the customer.

Design. Software design is actually a multistep process that focuses on four distinct

attributes of a program: data structure, software architecture, interface

representations, and procedural (algorithmic) detail. The design process translates

requirements into a representation of the software that can be assessed for quality

before coding begins. Like requirements, the design is documented and becomes

part of the software configuration.

Code generation. The design must be translated into a machine-readable form. The

code generation step performs this task. If design is performed in a detailed manner,

code generation can be accomplished mechanistically.

Testing. Once code has been generated, program testing begins. The testing process

focuses on the logical internals of the software, ensuring that all statements have

been tested, and on the functional externals; that is, conducting tests to uncover

errors and ensure that defined input will produce actual results that agree with

required results.

Support. Software will undoubtedly undergo change after it is delivered to the

customer (a possible exception is embedded software). Change will occur because

errors have been encountered, because the software must be adapted to

accommodate changes in its external environment (e.g., a change required because

of a new operating system or peripheral device), or because the customer requires

functional or performance enhancements. Software support/maintenance reapplies

15

each of the preceding phases to an existing program rather than a new one the linear

sequential model is the oldest and the most widely used paradigm for software

engineering. However, criticism of the paradigm has caused even active

supporters to question its efficacy. Among the problems that are sometimes

encountered when the linear sequential model is applied are:

1. Real projects rarely follow the sequential flow that the model proposes. Although

the linear model can accommodate iteration, it does so indirectly. As a result,

changes can cause confusion as the project team proceeds.

2. It is often difficult for the customer to state all requirements explicitly. The linear

sequential model requires this and has difficulty accommodating the natural

uncertainty that exists at the beginning of many projects.

3. The customer must have patience. A working version of the program(s) will

not be available until late in the project time-span. A major blunder, if undetected

until the working program is reviewed, can be disastrous. In an interesting analysis

of actual projects Bradac, found that the linear nature of the classic life cycle leads

to “blocking states” in which some project team members must wait for other

members of the team to complete dependent tasks. In fact, the time spent waiting

can exceed the time spent on productive work! The blocking state tends to be more

prevalent at the beginning and end of a linear sequential process. Each of these

problems is real. However, the classic life cycle paradigm has a definite and

important place in software engineering work. It provides a template into which

methods for analysis, design, coding, testing, and support can be placed. The classic

life cycle remains a widely used procedural model for software engineering. While

it does have weaknesses, it is significantly better than a haphazard approach to

software development.

2.3.2The Prototyping Model

Often, a customer defines a set of general objectives for software but does not

identify detailed input, processing, or output requirements. In other cases, the

developer may be unsure of the efficiency of an algorithm, the adaptability of

an operating system, or the form that human/machine interaction should take.

In these, and many other situations, a prototyping paradigm may offer the best

approach. The prototyping paradigm (Figure 2) begins with requirements gathering.

Developer and customer meet and define the overall objectives for the software,

identify whatever requirements are known, and outline areas where further definition

16

is Mandatory. A "quick design" then occurs. The quick design focuses on a

representation of those aspects of the software that will be visible to the

customer/user (e.g., input approaches and output formats). The quick design leads

to the construction of a prototype. The prototype is evaluated by the customer/user

and used to refine requirements for the software to be developed. Iteration occurs as

the prototype is tuned to satisfy the needs of the customer, while at the same time

enabling the developer to better understand what needs to be done.

Figure 2: The prototyping paradigm

Ideally, the prototype serves as a mechanism for identifying software requirements.

If a working prototype is built, the developer attempts to use existing program

fragments or applies tools (e.g., report generators, window managers) that enable

working programs to be generated quickly. But what do we do with the prototype

when it has served the purpose just described?

Brooks provides an answer: "In most projects, the first system built is barely usable.

It may be too slow, too big, and awkward in use or all three. There is no alternative

but to start again, smarting but smarter, and build a redesigned version in which these

problems are solved . . . When

a new system concept or new technology is used, one has to build a system to throw

away, for even the best planning is not so omniscient as to get it right the first time.

17

“The prototype can serve as "the first system." The one that Brooks recommends we

throw away. But this may be an idealized view. It is true that both customers and

developers like the prototyping paradigm. Users get a feel for the actual system and

developers get to build something immediately. Yet, prototyping can also be

problematic for the following reasons:

1. The customer sees what appears to be a working version of the software, unaware

that the prototype is held together “with chewing gum and baling wire,” unaware

that in the rush to get it working no one has considered overall software quality or

long term maintainability. When informed that the product must be rebuilt so that

high levels of quality can be maintained, the customer cries foul and demands that

"a few fixes" be applied to make the prototype a working product. Too often,

software development management relents.

2. The developer often makes implementation compromises in order to get a

prototype working quickly. An inappropriate operating system or programming

language may be used simply because it is available and known; an inefficient

algorithm may be implemented simply to demonstrate capability. After a time, the

developer may become familiar with these choices and forget all the reasons why

they were inappropriate. The less-than-ideal choice has now become an integral part

of the system. Although problems can occur, prototyping can be an effective

paradigm for software engineering. The key is to define the rules of the game at the

beginning; that is, the customer and developer must both agree that the prototype is

built to serve as a mechanism for defining requirements. It is then discarded (at least

in part) and the actual software is engineered with an eye toward quality and

maintainability.

Exercise:-

1- What is the difference between waterfall model and prototype model?

2- What is the advantage and disadvantage of waterfall & prototype models?

18

19

2.3.4 The Evolutionary Process Models

There is growing recognition that software, like all complex systems, evolves over

a period of time. Business and product requirements often change as development

proceeds, making a straight path to an end product unrealistic; tight market deadlines

make completion of a comprehensive software product impossible, but a limited

version must be introduced to meet competitive or business pressure; a set of core

product or system requirements is well understood, but the details of product or

system extensions have yet to be defined. In these and similar situations, software

engineers need a process model that has been explicitly designed to accommodate a

product that evolves over time.

The linear sequential model is designed for straight-line development. In essence,

the waterfall approach assumes that a complete system will be delivered after the

linear sequence is completed. The prototyping model is designed to assist the

customer (or developer) in understanding requirements. In general, it is not designed

to deliver a production system.

The evolutionary nature of software is not considered in either of these classic

software engineering paradigms. Evolutionary models are iterative. They are

characterized in a manner that enables software engineers to develop increasingly

more complete versions of the software.

2.3.3 The Incremental Model

The incremental model combines elements of the linear sequential model (applied

repetitively) with the iterative philosophy of prototyping. Referring to Figure 1, the

incremental model applies linear sequences in a staggered fashion as calendar time

progresses. Each linear sequence produces a deliverable “increment” of the software.

For example, word-processing software developed using the incremental paradigm

might deliver basic file management, editing, and document production functions in

the first increment; more sophisticated editing and document production capabilities

in the second increment; spelling and grammar checking in the third increment; and

advanced page layout capability in the fourth increment. It should be noted that the

process flow for any increment can incorporate the prototyping paradigm.

20

Figure 1: The incremental model

When an incremental model is used, the first increment is often a core product. That

is, basic requirements are addressed, but many supplementary features (some

known, others unknown) remain undelivered. The core product is used by the

customer (or undergoes detailed review).

As a result of use and/or evaluation, a plan is developed for the next increment. The

plan addresses the modification of the core product to better meet the needs of the

customer and the delivery of additional features and functionality. This process is

repeated following the delivery of each increment, until the complete product is

produced. The incremental process model, like prototyping and other

evolutionary approaches, is iterative in nature. But unlike prototyping, the

incremental model focuses on the delivery of an operational product with each

increment. Early increments are stripped down versions of the final product, but

they do provide capability that serves the user and also provide a platform for

evaluation by the user.

21

For example:

In the diagram above when we work incrementally we are adding piece by piece

but expect that each piece is fully finished. Thus keep on adding the pieces until it’s

complete. As in the image above a person has thought of the application. Then he

started building it and in the first iteration the first module of the application or

product is totally ready and can be demoed to the customers. Likewise in the second

iteration the other module is ready and integrated with the first module. Similarly,

in the third iteration the whole product is ready and integrated. Hence, the product

got ready step by step. This model need a clear and complete definition of the whole

system before it can be broken down and built incrementally.

Incremental development is particularly useful when staffing is unavailable for

a complete implementation by the business deadline that has been established

for the project. Early increments can be implemented with fewer people. If the core

product is well received, then additional staff (if required) can be added to implement

the next increment. In addition, increments can be planned to manage technical

risks. For example, a major system might require the availability of new hardware

that is under development and whose delivery date is uncertain. It might be possible

to plan early increments in a way that avoids the use of this hardware, thereby

enabling partial functionality to be delivered to end-users without inordinate delay.

When to use the Incremental model:

This model can be used when the requirements of the complete system are

clearly defined and understood.

Major requirements must be defined; however, some details can evolve with

time.

There is a need to get a product to the market early.

22

A new technology is being used

Resources with needed skill set are not available

There are some high risk features and goals.

2.3.5 The Spiral model

The spiral model, the spiral model is similar to the incremental model, with more

emphasis placed on risk analysis. It is an evolutionary software process model that

couples the iterative nature of prototyping with the controlled and systematic aspects

of the linear sequential model. It provides the potential for rapid development of

incremental versions of the software. Using the spiral model, software is developed

in a series of incremental releases. During early iterations, the incremental release

might be a paper model or prototype. During later iterations, increasingly more

complete versions of the engineered system are produced.

A spiral model is divided into a number of framework activities, also called task

regions. Typically, there are between three and six task regions. Figure2 depicts a

spiral model that contains six task regions: Figure

23

Figure 2 A typical spiral model

Customer communication—tasks required to establish effective communication

between developer and customer.

Planning Phase: Requirements are gathered during the planning phase.

Requirements like ‘BRS’ that is ‘Business Requirement Specifications’ and ‘SRS’

that is ‘System Requirement specifications’.

Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk

and alternate solutions. A prototype is produced at the end of the risk analysis phase.

If any risk is found during the risk analysis then alternate solutions are suggested

and implemented.

Engineering—tasks required to build one or more representations of the

application.

24

Construction and release—tasks required to construct, test, install, and provide

user support (e.g., documentation and training).

Customer evaluation—tasks required to obtain customer feedback based on

evaluation of the software representations created during the engineering stage and

implemented during the installation stage. As this evolutionary process begins, the

software engineering team moves around the spiral in a clockwise direction,

beginning at the center. The first circuit around the spiral might result in the

development of a product specification; subsequent passes around the spiral might

be used to develop a prototype and then progressively more sophisticated versions

of the software. Each pass through the planning region results in adjustments to the

project plan. Cost and schedule are adjusted based on feedback derived from

customer evaluation. In addition, the project manager adjusts the planned

number of iterations required to complete the software.

Unlike classical process models that end when software is delivered, the spiral

model can be adapted to apply throughout the life of the computer software.

The spiral model is a realistic approach to the development of large-scale systems

and software. Because software evolves as the process progresses, the developer and

customer better understand and react to risks at each evolutionary level. The spiral

model uses prototyping as a risk reduction mechanism but, more important, enables

the developer to apply the prototyping approach at any stage in the evolution

of the product. It maintains the systematic stepwise approach suggested by the

classic life cycle but incorporates it into an iterative framework that more

realistically reflects the real world. The spiral model demands a direct

consideration of technical risks at all stages of the project and, if properly

applied, should reduce risks before they become problematic.

When to use Spiral model:

When costs and risk evaluation is important

For medium to high-risk projects

Long-term project commitment unwise because of potential changes to

economic priorities

Users are unsure of their needs

Requirements are complex

25

New product line

Significant changes are expected (research and exploration)

Exercise:-

1- What is the difference between incremental model and spiral model? If you

want to build a small system program, what you will choose from the two

models above.

2- If you want to build a program for a small company, with clear specification

but the program in evolution for the short term, what you will choose? If you

want to build a program for the market and it used by many users, the

specification is still undefined or may be changes in the future for the long

term, what you will choose?

26

27

2.3.6 Concurrent Models

The concurrent development model, sometimes called concurrent engineering,

allows a software team to represent iterative and concurrent elements of any of the

process models described in this chapter. For example, the modeling activity defined

for the spiral model is accomplished by invoking one or more of the following

software engineering actions: prototyping, analysis, and design. Figure 1 provides a

schematic representation of one software engineering activity within the modeling

activity using a concurrent modeling approach. The activity—modeling—may be in

any one of the states12 noted at any given time. Similarly, other activities, actions,

or tasks (e.g., communication or construction) can be represented in an analogous

manner. All software engineering activities exist concurrently but reside in different

states

28

Figure 1 one element of the concurrent process model

Concurrent modeling defines a series of events that will trigger transitions from state

to state for each of the software engineering activities, actions, or tasks. For example,

during early stages of design (a major software engineering action that occurs during

the modeling activity), an inconsistency in the requirements model is uncovered.

This generates the event analysis model correction, which will trigger the

requirements analysis action from the done state into the awaiting changes state.

Concurrent modeling is applicable to all types of software development and provides

an accurate picture of the current state of a project. Rather than confining software

engineering activities, actions, and tasks to a sequence of events, it defines a process

network. Each activity, action, or task on the network exists simultaneously with

other activities, actions, or tasks. Events generated at one point in the process

network trigger transitions among the states.

2.4 The unified process models

The Unified Process fits the general definition of a process: a set of activities that a

team performs to transform a set of customer requirements into a soft- ware system.

However, the Unified Process is also a generic process frame- work that people

can customize by adding and removing activities based on the particular needs

and available resources for a project.it is a popular iterative and incremental

software development process framework.

2.5 Unified Process Characteristics

2.5.1 Iterative and Incremental

The Unified Process is an iterative and incremental development process. The

Elaboration, Construction and Transition phases are divided into a series of

timeboxed iterations as shown in figure 2. (The Inception phase may also be divided

into iterations for a large project.) Each iteration results in an increment, which is a

release of the system that contains added or improved functionality compared with

the previous release.

29

Although most iterations will include work in most of the process disciplines (e.g.

Requirements, Design, Implementation, Testing) the relative effort and emphasis

will change over the course of the project.

Figure 2 Iterative and Incremental

2.5.2 Architecture Centric

In the context of software, the term architecture has different meanings depending

on whom you ask. The definition here Explained is as follow:-

The fundamental organization of the system as a whole. Aspects of an architecture

include static elements, dynamic elements, how those elements work together, and

the overall architectural style that guides the organization of the system. Architecture

also addresses issues such as performance, scalability, reuse, and economic and

technological constraints.

The Unified Process specifies that the architecture of the system being built, as the

fundamental foundation on which that system will rest, must sit at the heart of the

project team’s efforts to shape the system, and also that architecture, must drive the

30

exploration of all aspects of the system. You might think of the architecture as

expressing the common vision that all members of the team must share in order for

the resulting system to be suitably robust, flexible, expandable, and cost-effective

2.5.3 Risk Focused

The Unified Process requires the project team to focus on addressing the most critical

risks early in the project life cycle. The deliverables of each iteration, especially in

the Elaboration phase, must be selected in order to ensure that the greatest risks are

addressed first.

2.6 Project Lifecycle (Phases of Unified Process)

The Unified Process divides the project into four phases:

Inception

Elaboration

Construction

Transition

2.6.1 Inception phase

Inception is the smallest phase in the project, and ideally it should be quite short. If

the Inception Phase is long then it may be an indication of excessive up-front

specification, which is contrary to the spirit of the Unified Process.

The following are typical goals for the Inception phase.

Establish a justification or business case for the project

Establish the project scope and boundary conditions

Outline the use cases and key requirements that will drive the design tradeoffs

Outline one or more candidate architectures

Identify risks

Prepare a preliminary project schedule and cost estimate

The Lifecycle Objective Milestone marks the end of the Inception phase.

Develop an approximate vision of the system, make the business case, define the

scope, and produce rough estimate for cost and schedule.

31

2.6.2 Elaboration Phase

During the Elaboration phase the project team is expected to capture a healthy

majority of the system requirements. However, the primary goals of Elaboration

are to address known risk factors and to establish and validate the system

architecture. Common processes undertaken in this phase include the creation of

use case diagrams, conceptual diagrams (class diagrams with only basic notation)

and package diagrams (architectural diagrams).

The architecture is validated primarily through the implementation of an Executable

Architecture Baseline. This is a partial implementation of the system which includes

the core, most architecturally significant, components. It is built in a series of small,

time boxed iterations. By the end of the Elaboration phase the system architecture

must have stabilized and the executable architecture baseline must demonstrate that

the architecture will support the key system functionality and exhibit the right

behavior in terms of performance, scalability and cost.

The final Elaboration phase deliverable is a plan (including cost and schedule

estimates) for the Construction phase. At this point the plan should be accurate and

credible, since it should be based on the Elaboration phase experience and since

significant risk factors should have been addressed during the Elaboration phase.

2.6.3 Construction Phase

Construction is the largest phase in the project. In this phase the remainder of the

system is built on the foundation laid in Elaboration. System features are

implemented in a series of short, timeboxed iterations. Each iteration results in an

executable release of the software. It is customary to write full text use cases during

the construction phase and each one becomes the start of a new iteration. Common

UML (Unified Modelling Language) diagrams used during this phase include

Activity, Sequence, and Collaboration, State (Transition) and Interaction.

2.6.4 Transition Phase

The final project phase is Transition. In this phase the system is deployed to the

target users. Feedback received from an initial release (or initial releases) may result

32

in further refinements to be incorporated over the course of several Transition phase

iterations. The Transition phase also includes system conversions and user training.

Exercise

1- What is the difference between concurrent models and waterfall models?

2- What is the unified process model? And what is the spatialized of this

model over the previous models in previous lectures?

3- What is the characteristic of unified process model?

33

34

2.5 PERSONAL AND TEAM PROCESS MODELS

The best software process is one that is close to the people who will be doing the

work. If a software process model has been developed at a corporate or

organizational level, it can be effective only if it is amenable to significant adaptation

to meet the needs of the project team that is actually doing software engineering

work. In an ideal setting, you would create a process that best fits your needs, and at

the same time, meets the broader needs of the team and the organization.

Alternatively, the team itself can create its own process, and at the same time meet

the narrower needs of individuals and the broader needs of the organization. Watts

Humphrey ([Hum97] and [Hum00]) argues that it is possible to create a “personal

software process” and/or a “team software process.” Both require hard work,

training, and coordination, but both are achievable.

2.5.1 Personal Software Process (PSP)

The Personal Software Process (PSP) is a structured software development process

that is intended to help software engineers better understand and improve their

performance by tracking their predicted and actual development of code. It claims

to give software engineers the process skills necessary to work on a Team Software

Process (TSP) team.

The PSP aims to provide software engineers with disciplined methods for improving

personal software development processes. The PSP helps software engineers to:

Improve their estimating and planning skills.

Make commitments they can keep.

Manage the quality of their projects.

Reduce the number of defects in their work.

PSP structure

PSP training follows an evolutionary improvement approach: an engineer learning

to integrate the PSP into his or her process begins at the first level - PSP0 - and

progresses in process maturity to the final level - PSP2.1. Each Level has detailed

scripts, checklists and templates to guide the engineer through required steps and

helps the engineer improve his own personal software process. Humphrey

35

encourages proficient engineers to customize these scripts and templates as they gain

an understanding of their own strengths and weaknesses.

Process

The input to PSP is the requirements; requirements document is completed and

delivered to the engineer.

PSP0, PSP0.1 (Introduces process discipline and measurement)

PSP0 has 3 phases: planning, development (design, coding, and test) and a post

mortem. A baseline is established of current process measuring: time spent on

programming, faults injected/removed, size of a program. In a post mortem, the

engineer ensures all data for the projects has been properly recorded and analyzed.

PSP0.1 advances the process by adding a coding standard, a size measurement and

the development of a personal process improvement plan (PIP). In the PIP, the

engineer records ideas for improving his own process.

PSP1, PSP1.1 (Introduces estimating and planning)

Based upon the baseline data collected in PSP0 and PSP0.1, the engineer estimates

how large a new program will be and prepares a test report (PSP1). Accumulated

data from previous projects is used to estimate the total time. Each new project will

record the actual time spent. This information is used for task and schedule planning

and estimation (PSP1.1).

PSP2, PSP2.1 (Introduces quality management and design)

PSP2 adds two new phases: design review and code review. Defect prevention and

removal of them are the focus at the PSP2. Engineers learn to evaluate and improve

their process by measuring how long tasks take and the number of defects they inject

and remove in each phase of development. Engineers construct and use checklists

for design and code reviews. PSP2.1 introduces design specification and analysis

techniques

(PSP3 is a legacy level that has been superseded by TSP.)

36

The importance of data

One of the core aspects of the PSP is using historical data to analyze and improve

process performance. PSP data collection is supported by four main elements:

Scripts

Measures

Standards

Forms

The PSP scripts provide expert-level guidance to following the process steps and

they provide a framework for applying the PSP measures. The PSP has four core

measures:

Size – the size measure for a product part, such as lines of code (LOC).

Effort – the time required to complete a task, usually recorded in minutes.

Quality – the number of defects in the product.

Schedule – a measure of project progression, tracked against planned and

actual completion dates.

Applying standards to the process can ensure the data is precise and consistent.

Data is logged in forms, normally using a PSP software tool. The SEI has

developed a PSP tool and there are also open source options available, such as

Process Dashboard.

The key data collected in the PSP tool are time, defect, and size data – the time

spent in each phase; when and where defects were injected, found, and fixed; and

the size of the product parts. Software developers use many other measures that are

derived from these three basic measures to understand and improve their

performance.

Using the PSP

The PSP is intended to help a developer improve their personal process; therefore

PSP developers are expected to continue adapting the process to ensure it meets their

personal needs.

37

In practice, PSP skills are used in a TSP team environment. TSP teams consist of

PSP-trained developers who volunteer for areas of project responsibility, so the

project is managed by the team itself. Using personal data gathered using their PSP

skills; the team makes the plans, the estimates, and controls the quality.

Using PSP process methods can help TSP teams to meet their schedule commitments

and produce high quality software. For example, according to research by Watts

Humphrey, a third of all software projects fail, but an SEI study on 20 TSP projects

in 13 different organizations found that TSP teams missed their target schedules by

an average of only six percent.

Successfully meeting schedule commitments can be attributed to using historical

data to make more accurate estimates, so projects are based on realistic plans – and

by using PSP quality methods, they produce low-defect software, which reduces

time spent on removing defects in later phases, such as integration and acceptance

testing.

Quality

High-quality software is the goal of the PSP, and quality is measured in terms of

defects. For the PSP, a quality process should produce low-defect software that

meets the user needs.

The PSP phase structure enables PSP developers to catch defects early. By catching

defects early, the PSP can reduce the amount of time spent in later phases, such as

Test.

The PSP theory is that it is more economical and effective to remove defects as close

as possible to where and when they were injected, so software engineers are

encouraged to conduct personal reviews for each phase of development. Therefore

the PSP phase structure includes two review phases:

Design Review

Code Review

38

To do an effective review, you need to follow a structured review process. The PSP

recommends using checklists to help developers to consistently follow an orderly

procedure.

The PSP follows the premise that when people make mistakes, their errors are

usually predictable, so PSP developers can personalize their checklists to target their

own common errors. Software engineers are also expected to complete process

improvement proposals, to identify areas of weakness in their current performance

that they should target for improvement. Historical project data, which exposes

where time is spent and defects introduced, help developers to identify areas to

improve.

PSP developers are also expected to conduct personal reviews before their work

undergoes a peer or team review.

2.5.2 Team Software Process (TSP)

In combination with the Personal Software Process (PSP), the Team Software

Process (TSP) provides a defined operational process framework that is designed to

help teams of managers and engineers organize projects and produce software

products that range in size from small projects of several thousand lines of code

(KLOC) to very large projects greater than half a million lines of code. The TSP is

intended to improve the levels of quality and productivity of a team's software

development project, in order to help them better meet the cost and schedule

commitments of developing a software system.

TSP Works

Before engineers can participate in the TSP, it is required that they have already

learned about the PSP, so that the TSP can work effectively. Training is also required

for other team members, the team lead, and management.

The TSP software development cycle begins with a planning process called the

launch, led by a coach who has been specially trained, and is either certified or

provisional. The launch is designed to begin the team building process, and during

this time teams and managers establish goals, define team roles, assess risks,

estimate effort, allocate tasks, and produce a team plan. During an execution phase,

developers track planned and actual effort, schedule, and defects, meeting regularly

(usually weekly) to report status and revise plans. A development cycle ends with a

39

Post Mortem to assess performance, revise planning parameters, and capture lessons

learned for process improvement.

The coach role focuses on supporting the team and the individuals on the team as

the process expert while being independent of direct project management

responsibility. The team leader role is different from the coach role in that, team

leaders are responsible to management for products and project outcomes while the

coach is responsible for developing individual and team performance

Exercise

1- What is the difference between PSP & TSP

2- What is the difference between PSP and evolutionary process

model

3- What is the difference between TSP and spiral process model

40

41

2.6 Process activities

Real software processes are interleaved sequences of technical, collaborative, and

managerial activities with the overall goal of specifying, designing, implementing,

and testing a software system. The four basic process activities of specification,

development, validation, and evolution are organized differently in different

development processes.

2.6.1 Software specification

Software specification or requirements engineering is the process of understanding

and defining what services are required from the system and identifying the

constraints on the system’s operation and development. Requirements engineering

is a particularly critical stage of the software process as errors at this stage inevitably

lead to later problems in the system design and implementation.

The requirements engineering process (Figure 6.1) aims to produce an agreed

requirements document that specifies a system satisfying stakeholder requirements.

Requirements are usually presented at two levels of detail. End-users and customers

need a high-level statement of the requirements; system developers need a more

detailed system specification.

There are four main activities in the requirements engineering process:

1. Feasibility study an estimate is made of whether the identified user needs may be

satisfied using current software and hardware technologies. The study considers

whether the proposed system will be cost-effective from a business point of view

and if it can be developed within existing budgetary constraints. A feasibility study

should be relatively cheap and quick. The result should inform the decision of

whether or not to go ahead with a more detailed analysis.

2. Requirements elicitation and analysis This is the process of deriving the system

requirements through observation of existing systems, discussions with potential

users and procurers, task analysis, and so on. This may involve the development of

one or more system models and prototypes. These help you understand the system

to be specified.

42

Figure (6.1) the engineering requirement process

3. Requirements specification Requirements specification is 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. User requirements are abstract statements of the system requirements for

the customer and end-user of the system; system requirements are a more detailed

description of the functionality to be provided

4. Requirements validation this activity checks the requirements for realism,

consistency, and completeness. During this process, errors in the requirements

document are inevitably discovered. It must then be modified to correct these

problems.

Of course, the activities in the requirements process are not simply carried out in a

strict sequence. Requirements analysis continues during definition and specification

and new requirements come to light throughout the process. Therefore, the activities

of analysis, definition, and specification are interleaved.

2.6.2 Software design and implementation

The implementation stage of software development is the process of converting a

system specification into an executable system. It always involves processes of

software design and programming,

43

A software design is a description of the structure of the software to be implemented,

the data models and structures used by the system, the interfaces between system

components and, sometimes, the algorithms used. Designers do not arrive at a

finished design immediately but develop the design iteratively. They add formality

and detail as they develop their design with constant backtracking to correct earlier

designs. Figure 6.2 is an abstract model of this process showing the inputs to the

design process, process activities, and the documents produced as outputs from this

process.

Figure 6.2 a general model of the design process

The diagram suggests that the stages of the design process are sequential. In fact,

design process activities are interleaved. Feedback from one stage to another and

consequent design rework is inevitable in all design processes.

Most software interfaces with other software systems. These include the operating

system, database, middleware, and other application systems. These make up the

‘software platform’, the environment in which the software will execute.

Information about this platform is an essential input to the design process, as

designers must decide how best to integrate it with the software’s environment. The

requirements specification is a description of the functionality the software must

provide and its performance and dependability requirements. If the system is to

process existing data, then the description of that data may be included in the

44

platform specification; otherwise, the data description must be an input to the design

process so that the system data organization to be defined.

The activities in the design process vary, depending on the type of system being

developed. For example, real-time systems require timing design but may not

include a database so there is no database design involved. Figure 6.2 shows four

activities that may be part of the design process for information systems:

1. Architectural design, where you identify the overall structure of the system, the

principal components (sometimes called sub-systems or modules), their

relationships, and how they are distributed.

2. Interface design, where you define the interfaces between system components.

This interface specification must be unambiguous. With a precise interface, a

component can be used without other components having to know how it is

implemented. Once interface specifications are agreed, the components can be

designed and developed concurrently.

3. Component design, where you take each system component and design how it

will operate. This may be a simple statement of the expected functionality to be

implemented, with the specific design left to the programmer. Alternatively, it may

be a list of changes to be made to a reusable component or a detailed design model.

The design model may be used to automatically generate an implementation.

4. Database design, where you design the system data structures and how these are

to be represented in a database. Again, the work here depends on whether an existing

database is to be reused or a new database is to be created.

These activities lead to a set of design outputs, which are also shown in Figure 6.2.

The detail and representation of these vary considerably. The development of a

program to implement the system follows naturally from the system design

processes. Programming is a personal activity and there is no general process that is

usually followed.

2.6.3 Software validation

Software validation or, more generally, verification and validation (V&V) is

intended to show that a system both conforms to its specification and that it meets

the expectations of the system customer. Program testing, where the system is

executed using simulated test data, is the principal validation technique. Validation

45

may also involve checking processes, such as inspections and reviews, at each stage

of the software process from user requirements definition to program development.

Figure (6.3) stages of testing

Except for small programs, systems should not be tested as a single, monolithic unit.

Figure 6.3 shows a three-stage testing process in which system components are

tested then the integrated system is tested and, finally, the system is tested with the

customer’s data. Ideally, component defects are discovered early in the process, and

interface problems are found when the system is integrated. However, as defects are

discovered, the program must be debugged and this may require other stages in the

testing process to be repeated. Errors in program components, say, may come to light

during system testing. The process is therefore an iterative one with information

being fed back from later stages to earlier parts of the process.

The stages in the testing process are:

1. Development testing the components making up the system are tested by the

people developing the system. Each component is tested independently, without

other system components. Components may be simple entities such as functions, or

object classes, or may be coherent groupings of these entities.

2. System testing System components are integrated to create a complete system.

This process is concerned with finding errors that result from unanticipated

interactions between components and component interface problems. It is also

concerned with showing that the system meets its functional and non-functional

requirements, and testing the emergent system properties. For large systems, this

may be a multi-stage process where components are integrated to form subsystems

that are individually tested before these sub-systems are themselves integrated to

form the final system.

3. Acceptance testing this is the final stage in the testing process before the system

is accepted for operational use. The system is tested with data supplied by the system

customer rather than with simulated test data. Acceptance testing may reveal errors

and omissions in the system requirements definition, because the real data exercise

the system in different ways from the test data. Acceptance testing may also reveal

46

requirements problems where the system’s facilities do not really meet the user’s

needs or the system performance is unacceptable.

Normally, component development and testing processes are interleaved.

Programmers make up their own test data and incrementally test the code as it is

developed.

2.6.4 Software evolution

Software evolution is the term used in software engineering (specifically software

maintenance) to refer to the process of developing software initially, then repeatedly

updating it for various reasons.

The aim of software evolution would be to implement (and revalidate) the possible

major changes to the system without being able a priori to predict how user

requirements will evolve. The existing larger system is never complete and continues

to evolve. As it evolves, the complexity of the system will grow unless there is a

better solution available to solve these issues. The main objectives of software

evolution are ensuring the reliability and flexibility of the system. During the 20

years past, the lifespan of a system could be on average 6–10 years .However, it was

recently found that a system should be evolved once every few months to ensure it

is adapted to

the real-world environment. This is due to the rapid growth of World Wide Web and

Internet Resources that make it easier for users to find related information. The idea

of software evolution leads to open source development as anybody could download

the source codes and hence modify it. The positive impact in this case is large

amounts of new ideas would be discovered and generated that aims the system to

have better improvement in variety choices.

47

Figure (6.4) system evolution

Exercise

1- What is the steps of testing any project?

2- What is the process activities? Are they constant in steps or interleaved?

3- What is the difference between software specification and software

design?

48

49

2.7 system modeling

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 (UML). However, it is also possible to develop formal (mathematical)

models of a system, usually as a detailed system specification.

Models are used during the requirements engineering process to help derive the

requirements for a system, during the design process to describe the system to

engineers implementing the system and after implementation to document the

system’s structure and operation. You may develop models of both the existing

system and the system to be developed:

1. Models of the existing system are used during requirements engineering. They

help clarify what the existing system does and can be used as a basis for discussing

its strengths and weaknesses. These then lead to requirements for the new system.

2. Models of the new system are used during requirements engineering to help

explain the proposed requirements to other system stakeholders. Engineers use these

models to discuss design proposals and to document the system for implementation.

In a model-driven engineering process, it is possible to generate a complete or partial

system implementation from the system model.

The Unified Modeling Language (UML) is a general-purpose modeling language

in the field of software engineering, which is designed to provide a standard way to

visualize the design of a system

The Unified Modeling Language (UML) offers a way to visualize a system's

architectural blueprints in a diagram (see image below), including elements such

as:

Any activities (jobs)

Individual components of the system

o And how they can interact with other software components.

50

How the system will run

How entities interact with others (components and interfaces)

External user interface

In this lecture, we use diagrams defined in UML, which has become a standard

modeling language for object-oriented modeling. The UML has many diagram types

and so supports the creation of many different types of system model. However, a

survey in 2007 (Erickson and Siau, 2007) showed that most users of the UML

thought that five diagram types could represent the essentials of a system:

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

processing.

51

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.

When developing system models, you can often be flexible in the way that the

graphical notation is used. You do not always need to stick rigidly to the details of a

notation. The detail and rigor of a model depends on how you intend to use it. There

are three ways in which graphical models are commonly used:

1. As a means of facilitating discussion about an existing or proposed system.

2. As a way of documenting an existing system.

3. As a detailed system description that can be used to generate a system

implementation.

In the first case, the purpose of the model is to stimulate the discussion amongst the

software engineers involved in developing the system. The models may be

incomplete (so long as they cover the key points of the discussion) and they may use

the modeling notation informally. This is how models are normally used in so-called

‘agile modeling’ (Ambler and Jeffries, 2002). When models are used as

documentation, they do not have to be complete as you may only wish to develop

models for some parts of a system. However, these models have to be correct—they

should use the notation correctly and be an accurate description of the system.

In the third case, where models are used as part of a model-based development

process, the system models have to be both complete and correct. The reason for this

is that they are used as a basis for generating the source code of the system.

Therefore, you have to be very careful not to confuse similar symbols, such as stick

and block arrowheads that have different meanings.

2.7.1 Context models

At an early stage in the specification of a system, you should decide on the system

boundaries. This involves working with system stakeholders to decide what

52

functionality should be included in the system and what is provided by the system’s

environment.

You may decide that automated support for some business processes should be

implemented but others should be manual processes or supported by different

systems. You should look at possible overlaps in functionality with existing systems

and decide where new functionality should be implemented. These decisions should

be made early in the process to limit the system costs and the time needed for

understanding the system requirements and design.

In some cases, the boundary between a system and its environment is relatively clear.

For example, where an automated system is replacing an existing manual or

computerized system, the environment of the new system is usually the same as the

existing system’s environment. In other cases, there is more flexibility, and you

decide what constitutes the boundary between the system and its environment during

the requirements engineering process.

For example, say you are developing the specification for the patient information

system for mental healthcare. This system is intended to manage information about

patients attending mental health clinics and the treatments that have been prescribed.

In developing the specification for this system, you have to decide whether the

system should focus exclusively on collecting information about consultations

(using other systems to collect personal information about patients) or whether it

should also collect personal patient information. The advantage of relying on other

systems for patient information is that you avoid duplicating data. The major

disadvantage, however, is that using other systems may make it slower to access

information. If these systems are unavailable, then the MHC-PMS cannot be used.

53

Fig (7.1) the context of the MHC-PMS

The definition of a system boundary is not a value-free judgment. Social and

organizational concerns may mean that the position of a system boundary may be

determined by non-technical factors. For example, a system boundary may be

deliberately positioned so that the analysis process can all be carried out on one site;

it may be chosen so that a particularly difficult manager need not be consulted; it

may be positioned so that the system cost is increased and the system development

division must therefore expand to design and implement the system.

Once some decisions on the boundaries of the system have been made, part of the

analysis activity is the definition of that context and the dependencies that a system

has on its environment. Normally, producing a simple architectural model is the first

step in this activity.

Figure 7.1 is a simple context model that shows the patient information system and

the other systems in its environment. From Figure 7.1, you can see that the MHC-

PMS is connected to an appointments system and a more general patient record

54

system with which it shares data. The system is also connected to systems for

management reporting and hospital bed allocation and a statistics system that

collects information for research. Finally, it makes use of a prescription system to

generate prescriptions for patients’ medication.

Context models normally show that the environment includes several other

automated systems. However, they do not show the types of relationships between

the systems in the environment and the system that is being specified. External

systems might produce data for or consume data from the system. They might share

data with the system, or they might be connected directly, through a network or not

connected at all. They might be physically co-located or located in separate

buildings. All of these relations may affect the requirements and design of the system

being defined and must be taken into account.

Therefore, simple context models are used along with other models, such as business

process models. These describe human and automated processes in which particular

software systems are used.

Fig (7.2) Process model of involuntary detention

55

Figure7.2 is a model of an important system process that shows the processes in

which the MHC-PMS is used. Sometimes, patients who are suffering from mental

health problems may be a danger to others or to themselves. They may therefore

have to be detained against their will in a hospital so that treatment can be

administered.

Such detention is subject to strict legal safeguards—for example, the decision to

detain a patient must be regularly reviewed so that people are not held indefinitely

without good reason. One of the functions of the MHC-PMS is to ensure that such

safeguards are implemented.

Figure 7.2 is a UML activity diagram. Activity diagrams are intended to show the

activities that make up a system process and the flow of control from one activity to

another. The start of a process is indicated by a filled circle; the end by a filled circle

inside another circle. Rectangles with round corners represent activities, that is, the

specific sub-processes that must be carried out. You may include objects in activity

charts.

In Figure 7.2, we have shown the systems that are used to support different

processes.

We have indicated that these are separate systems using the UML stereotype feature.

In a UML activity diagram, arrows represent the flow of work from one activity to

another. A solid bar is used to indicate activity coordination. When the flow from

more than one activity leads to a solid bar then all of these activities must be

complete before progress is possible. When the flow from a solid bar leads to a

number of activities, these may be executed in parallel. Therefore, in Figure 7.2, the

activities to inform social care and the patient’s next of kin, and to update the

detention register may be concurrent.

Arrows may be annotated with guards that indicate the condition when that flow is

taken. In Figure 7.2, you can see guards showing the flows for patients who are

dangerous and not dangerous to society. Patients who are dangerous to society must

be detained in a secure facility. However, patients who are suicidal and so are a

danger to themselves may be detained in an appropriate ward in a hospital.

56

Exercise

1- What is the UML and what its diagrams types?

2- Give an example of activity diagrams for any system you choose, and

describe it in UML language.

57

58

2.7.2 Interaction models

All systems involve interaction of some kind. This can be user interaction, which

involves user inputs and outputs, interaction between the systems being developed

and other systems or interaction between the components of the system. Modeling

user interaction is important as it helps to identify user requirements. Modeling

system to system interaction highlights the communication problems that may arise.

Modeling component interaction helps us understand if a proposed system structure

is likely to deliver the required system performance and dependability.

In this section, we cover two related approaches to interaction modeling:

1. Use case modeling, which is mostly used to model interactions between a system

and external actors (users or other systems).

2. Sequence diagrams, which are used to model interactions between system

components, although external agents may also be included.

Use case models and sequence diagrams present interaction at different levels of

detail and so may be used together. The details of the interactions involved in a high

level use case may be documented in a sequence diagram. The UML also includes

communication diagrams that can be used to model interactions. We don’t discuss

these here as they are an alternative representation of sequence charts. In fact, some

tools can generate a communication diagram from a sequence diagram.

2.7.2.1 Use case modeling

Use case modeling was originally developed by Jacobson et al. (1993) in the 1990s

and was incorporated into the first release of the UML. Use case modeling is widely

used to support requirements elicitation. A use case can be taken as a simple scenario

that describes what a user expects from a system.

Each use case represents a discrete task that involves external interaction with a

system. In its simplest form, a use case is shown as an ellipse with the actors involved

in the use case represented as stick figures. Figure 7.3 shows a use case from the

MHC-PMS that represents the task of uploading data from the MHC-PMS to a more

general patient record system. This more general system maintains summary data

59

about a patient rather than the data about each consultation, which is recorded in the

MHC-PMS.

Figure (7.3) Transfer data use case

Notice that there are two actors in this use case: the operator who is transferring the

data and the patient record system. The stick figure notation was originally

developed to cover human interaction but it is also now used to represent other

external systems and hardware. Formally, use case diagrams should use lines

without arrows as arrows in the UML indicate the direction of flow of messages.

Obviously, in a use case messages pass in both directions. However, the arrows in

Figure 7.3 are used informally to indicate that the medical receptionist initiates the

transaction and data is transferred to the patient record system.

Use case diagrams give a fairly simple overview of an interaction so you have to

provide more detail to understand what is involved. This detail can either be a simple

textual description, a structured description in a table, or a sequence diagram as

discussed below. You chose the most appropriate format depending on the use case

and the level of detail that you think is required in the model. We found a standard

tabular format to be the most useful. Figure7.4 shows a tabular description of the

‘Transfer data’ use case.

Composite use case diagrams show a number of different use cases. Sometimes, it

is possible to include all possible interactions with a system in a single composite

use case diagram. However, this may be impossible because of the number of use

60

cases. In such cases, you may develop several diagrams, each of which shows related

use cases. For example, Figure 7.5 shows all of the use cases in the MHC-PMS in

which the actor ‘Medical Receptionist’ is involved.

M

HC-PMS Figure (7.4): Tabular description of the ‘Transfer data’ use case

PMS Figure (7.5): Use cases involving the role ‘medical receptionist’

61

2.7.2.2 Sequence diagrams

Sequence diagrams in the UML are primarily used to model the interactions between

the actors and the objects in a system and the interactions between the objects

themselves.

The UML has a rich syntax for sequence diagrams, which allows many different

kinds of interaction to be modeled. We don’t have space to cover all possibilities

here so we focus on the basics of this diagram type.

As the name implies, a sequence diagram shows the sequence of interactions that

take place during a particular use case or use case instance. Figure 7.6 is an example

of a sequence diagram that illustrates the basics of the notation. This diagram models

the interactions involved in the View patient information use case, where a medical

receptionist can see some patient information.

The objects and actors involved are listed along the top of the diagram, with a dotted

line drawn vertically from these. Interactions between objects are indicated by

annotated arrows. The rectangle on the dotted lines indicates the lifeline of the object

concerned (i.e., the time that object instance is involved in the computation). You

read the sequence of interactions from top to bottom. The annotations on the arrows

indicate the calls to the objects, their parameters, and the return values. In this

example, we also show the notation used to denote alternatives. A box named alt is

used with the conditions indicated in square brackets.

You can read Figure 5.6 as follows:

1. The medical receptionist triggers the View Info method in an instance P of the

Patient Info object class, supplying the patient’s identifier, PID. P is a user interface

object, which is displayed as a form showing patient information.

2. The instance P calls the database to return the information required, supplying the

receptionist’s identifier to allow security checking (at this stage, we do not care

where this UID comes from).

62

Figure (7.6) Sequence diagram for View patient information

3. The database checks with an authorization system that the user is authorized for

this action.

4. If authorized, the patient information is returned and a form on the user’s screen

is filled in. If authorization fails, then an error message is returned.

Figure 7.7 is a second example of a sequence diagram from the same system that

illustrates two additional features. These are the direct communication between the

actors in the system and the creation of objects as part of a sequence of operations.

In this example, an object of type Summary is created to hold the summary data that

is to be uploaded to the PRS (patient record system). You can read this diagram as

follows:

1. The receptionist logs on to the PRS.

2. There are two options available. These allow the direct transfer of updated patient

information to the PRS and the transfer of summary health data from the MHC-PMS

to the PRS.

63

3. In each case, the receptionist’s permissions are checked using the authorization

system.

4. Personal information may be transferred directly from the user interface object to

the PRS. Alternatively, a summary record may be created from the database and that

record is then transferred.

5. On completion of the transfer, the PRS issues a status message and the user logs

off.

Figure (7.7) Sequence diagram for transfer data

64

Unless you are using sequence diagrams for code generation or detailed

documentation, you don’t have to include every interaction in these diagrams. If you

develop system models early in the development process to support requirements

engineering and high-level design, there will be many interactions which depend on

implementation decisions. For example, in Figure 7.7 the decision on how to get the

user’s identifier to check authorization is one that can be delayed. In an

implementation, this might involve interacting with a User object but this is not

important at this stage and so need not be included in the sequence diagram.

Exercise

1- What is the difference between interaction models and context models?

2- Give an example of sequence diagram & case modeling for any system

you choose, and describe it in UML language.

65

66

2.7.3 Structural models

Structural models of software display the organization of a system in terms of the

components that make up that system and their relationships. Structural models may

be static models, which show the structure of the system design or dynamic models,

which show the organization of the system when it is executing. These are not the

same things—the dynamic organization of a system as a set of interacting threads

may be very different from a static model of the system components.

You create structural models of a system when you are discussing and designing the

system architecture. Architectural design is a particularly important topic in software

engineering and UML component, package, and deployment diagrams may all be

used when presenting architectural models. In this section, we focus on the use of

class diagrams for modeling the static structure of the object classes in a software

system.

2.7.3.1 Class diagrams

Class diagrams are used when developing an object-oriented system model to show

the classes in a system and the associations between these classes. Loosely, an object

class can be thought of as a general definition of one kind of system object. An

association is a link between classes that indicates that there is a relationship between

these classes. Consequently, each class may have to have some knowledge of its

associated class.

When you are developing models during the early stages of the software engineering

process, objects represent something in the real world, such as a patient, a

prescription, a doctor, etc. As an implementation is developed, you usually need to

define additional implementation objects that are used to provide the required system

functionality. Here, we focus on the modeling of real-world objects as part of the

requirements or early software design processes.

Class diagrams in the UML can be expressed at different levels of detail. When you

are developing a model, the first stage is usually to look at the world, identify the

essential objects, and represent these as classes. The simplest way of writing these

67

is to write the class name in a box. You can also simply note the existence of an

association

Figure (7.8) UML classes and association

By drawing a line between classes. For example, Figure 7.8 is a simple class diagram

showing two classes: Patient and Patient Record with an association between them.

In Figure 7.8, we illustrate a further feature of class diagrams—the ability to show

how many objects are involved in the association. In this example, each end of the

association is annotated with a 1, meaning that there is a 1:1 relationship between

objects of these classes. That is, each patient has exactly one record and each record

maintains information about exactly one patient. As you can see from later examples,

other multiplicities are possible. You can define that an exact number of objects are

involved or, by using a *, as shown in Figure 5.9, that there are an indefinite number

of objects involved in the association.

Figure 7.9 develops this type of class diagram to show that objects of class Patient

are also involved in relationships with a number of other classes. In this example,

we show that you can name associations to give the reader an indication of the type

of relationship that exists. The UML also allows the role of the objects participating

in the association to be specified.

At this level of detail, class diagrams look like semantic data models. Semantic data

models are used in database design. They show the data entities, their associated

attributes, and the relations between these entities. This approach to modeling was

first proposed in the mid-1970s by Chen (1976); several variants have been

developed since then, all with the same basic form.

68

The UML does not include a specific notation for this database modeling as it

assumes an object-oriented development process and models data using objects and

their relationships. However, you can use the UML to represent a semantic data

model. You can think of entities in a semantic data model as simplified object classes

Figure (7.9) Classes and associations in the MHC-PMS

69

Figure (7.10) the consultation class

(They have no operations), attributes as object class attributes and relations as named

associations between object classes.

When showing the associations between classes, it is convenient to represent these

classes in the simplest possible way. To define them in more detail, you add

information about their attributes (the characteristics of an object) and operations

(the things that you can request from an object). For example, a Patient object will

have the attribute Address and you may include an operation called Change Address,

which is called when a patient indicates that they have moved from one address to

another. In the UML, you show attributes and operations by extending the simple

rectangle that represents a class. This is illustrated in Figure 7.10 where:

1. The name of the object class is in the top section.

2. The class attributes are in the middle section. This must include the attribute

names and, optionally, their types.

70

3. The operations (called methods in Java and other OO programming languages)

associated with the object class are in the lower section of the rectangle.

Figure 7.10 shows possible attributes and operations on the class Consultation. In

this example, we assume that doctors record voice notes that are transcribed later to

record details of the consultation. To prescribe medication, the doctor involved must

use the Prescribe method to generate an electronic prescription.

2.7.3.2 Generalization

Generalization is an everyday technique that we use to manage complexity. Rather

than earn the detailed characteristics of every entity that we experience, we place

these entities in more general classes (animals, cars, houses, etc.) and learn the

characteristics of these classes. This allows us to infer that different members of

these classes have some common characteristics (e.g., squirrels and rats are rodents).

We can make general statements that apply to all class members (e.g., all rodents

have teeth for gnawing).

Figure (7.11) a generalization hierarchy

71

In modeling systems, it is often useful to examine the classes in a system to see if

there is scope for generalization. This means that common information will be

maintained in one place only. This is good design practice as it means that, if changes

are proposed, then you do not have to look at all classes in the system to see if they

are affected by the change. In object-oriented languages, such as Java, generalization

is implemented using the class inheritance mechanisms built into the language.

The UML has a specific type of association to denote generalization, as illustrated

in Figure 7.11. The generalization is shown as an arrowhead pointing up to the more

general class. This shows that general practitioners and hospital doctors can be

generalized as doctors and that there are three types of Hospital Doctor— those that

have just graduated from medical school and have to be supervised (Trainee Doctor);

those that can work unsupervised as part of a consultant’s team

(Registered Doctor); and consultants, who are senior doctors with full decision-

making responsibilities.

In a generalization, the attributes and operations associated with higher-level classes

are also associated with the lower-level classes. In essence, the lower-level classes

are subclasses inherit the attributes and operations from their super classes.

These lower-level classes then add more specific attributes and operations. For

example, all doctors have a name and phone number; all hospital doctors have a staff

number and a department but general practitioners don’t have these attributes as they

work independently. They do however, have a practice name and address. This is

illustrated in Figure 7.12, which shows part of the generalization hierarchy that I

have extended with class attributes. The operations associated with the class Doctor

are intended to register and de-register that doctor with the MHC-PMS.

72

Figure (7.12) a generalization hierarchy with added detail

2.7.3.3 Aggregation

Objects in the real world are often composed of different parts. For example, a study

pack for a course may be composed of a book, PowerPoint slides, quizzes, and

recommendations for further reading. Sometimes in a system model, you need to

illustrate this. The UML provides a special type of association between classes called

aggregation that means that one object (the whole) is composed of other objects (the

parts). To show this, we use a diamond shape next to the class that represents the

whole. This is shown in Figure 5.13, which shows that a patient record is a

composition of Patient and an indefinite number of Consultations.

73

Figure (7.13) the aggregation association

74

75

2.7.4 Behavioral models

Behavioral models are models of the dynamic behavior of the system as it is

executing. They show what happens or what is supposed to happen when a system

responds to a stimulus from its environment. You can think of these stimuli as being

of two types:

1. Data some data arrives that has to be processed by the system.

2. Events some event happens that triggers system processing. Events may have

associated data but this is not always the case.

Many business systems are data processing systems that are primarily driven by data.

They are controlled by the data input to the system with relatively little external

event processing. Their processing involves a sequence of actions on that data and

the generation of an output. For example, a phone billing system will accept

information about calls made by a customer, calculate the costs of these calls, and

generate a bill to be sent to that customer. By contrast, real-time systems are often

event driven with minimal data processing. For example, a landline phone switching

system responds to events such as ‘receiver off hook’ by generating a dial tone, or

the pressing of keys on a handset by capturing the phone number, etc.

2.7.4.1 Data-driven modeling

Data-driven models show the sequence of actions involved in processing input data

and generating an associated output. They are particularly useful during the analysis

of requirements as they can be used to show end-to-end processing in a system. That

is, they show the entire sequence of actions that take place from an input being

processed to the corresponding output, which is the system’s response.

Data-driven models were amongst the first graphical software models. In the 1970s,

structured methods such as DeMarco’s Structured Analysis (DeMarco, 1978)

introduced data-flow diagrams (DFDs) as a way of illustrating the processing steps

in a system. Data-flow models are useful because tracking and documenting how the

data associated with a particular process moves through the system helps analysts

and designers understand what is going on. Data-flow diagrams are simple and

76

intuitive and it is usually possible to explain them to potential system users who can

then participate in validating the model.

The UML does not support data-flow diagrams as they were originally proposed and

used for modeling data processing. The reason for this is that DFDs focus on system

functions and do not recognize system objects. However, because data-driven

systems are so common in business, UML 2.0 introduced activity diagrams, which

are similar to data-flow diagrams. For example, Figure 7.14 shows the chain of

processing involved in the insulin pump software. In this diagram, you can see the

processing steps (represented as activities) and the data flowing between these steps

(represented as objects).

An alternative way of showing the sequence of processing in a system is to use UML

sequence diagrams. You have seen how these can be used to model interaction but,

if

Figure (7.14) An sequence diagram of the Order processing

You draw these so that messages are only sent from left to right, then they show the

sequential data processing in the system. Figure 7.15 illustrates this, using a

sequence model of the processing of an order and sending it to a supplier. Sequence

77

models highlight objects in a system, whereas data-flow diagrams highlight the

functions. The equivalent data-flow diagram for order processing is shown on the

book’s web pages.

2.7.4.2 Event-driven modeling

Event-driven modeling shows how a system responds to external and internal events.

It is based on the assumption that a system has a finite number of states and that

events (stimuli) may cause a transition from one state to another. For example, a

system controlling a valve may move from a state ‘Valve open’ to a state ‘Valve

closed’ when an operator command (the stimulus) is received. This view of a system

is particularly appropriate for real-time systems. Event-based modeling was

introduced in real-time design methods such as those proposed by Ward and Mellor

(1985) and Harel (1987, 1988).

The UML supports event-based modeling using state diagrams, which were based

on Statecharts (Harel, 1987, 1988). State diagrams show system states and events

that cause

Figure (7.15) insulin pump’s operation

78

Transitions from one state to another. They do not show the flow of data within the

system but may include additional information on the computations carried out in

each state.

we use an example of control software for a very simple microwave oven to illustrate

event-driven modeling. Real microwave ovens are actually much more complex than

this system but the simplified system is easier to understand. This simple microwave

has a switch to select full or half power, a numeric keypad to input the cooking time,

a start/stop button, and an alphanumeric display. we have assumed that the sequence

of actions in using the microwave is:

1. Select the power level (either half power or full power).

2. Input the cooking time using a numeric keypad.

3. Press Start and the food is cooked for the given time.

79

For safety reasons, the oven should not operate when the door is open and, on

completion of cooking, a buzzer is sounded. The oven has a very simple

alphanumeric display that is used to display various alerts and warning messages.

In UML state diagrams, rounded rectangles represent system states. They may

include a brief description (following ‘do’) of the actions taken in that state. The

labeled arrows represent stimuli that force a transition from one state to another. You

can indicate start aFrom Figure 7.16, you can see that the system starts in a waiting

state and responds initially to either the full-power or the half-power button. Users

can change their mind after selecting one of these and press the other button. The

time is set and, if the door is closed, the Start button is enabled. Pushing this button

starts the oven operation and cooking takes place for the specified time. This is the

end of the cooking cycle and the system returns to the waiting state.

80

Figure (7.16) States and stimuli for themicrowave oven

81

The UML notation lets you indicate the activity that takes place in a state. In a

detailed system specification you have to provide more detail about both the stimuli

and the system states. I illustrate this in Figure 7.17, which shows a tabular

description of each state and how the stimuli that force state transitions are

generated.

The problem with state-based modeling is that the number of possible states

increases rapidly. For large system models, therefore, you need to hide detail in the

Figure (7.17) Microwave oven operation

Models. One way to do this is by using the notion of a super state that encapsulates

a number of separate states. This super state looks like a single state on a high-level

model but is then expanded to show more detail on a separate diagram. To illustrate

this concept, consider the Operation state in Figure 7.15. This is a superstate that can

be expanded, as illustrated in Figure 7.18.

82

The Operation state includes a number of sub-states. It shows that operation starts

with a status check and that if any problems are discovered an alarm is indicated and

operation is disabled. Cooking involves running the microwave generator for the

specified time; on completion, a buzzer is sounded. If the door is opened during

operation, the system moves to the disabled state, as shown in 1.Figure7.15

83

84

2.7.5 Model-driven engineering

Model-driven engineering (MDE) is an approach to software development where

models rather than programs are the principal outputs of the development process.

The programs that execute on a hardware/software platform are then generated

automatically from the models. Proponents of MDE argue that this raises the level

of abstraction in software engineering so that engineers no longer have to be

concerned with programming language details or the specifics of execution

platforms.

Model-driven engineering has its roots in model-driven architecture (MDA) which

was proposed by the Object Management Group (OMG) in 2001 as a new software

development paradigm. Model-driven engineering and model-driven architecture

are often seen as the same thing.

As we discuss later in this section, MDA focuses on the design and implementation

stages of software development whereas MDE is concerned with all aspects of the

software engineering process. Therefore, topics such as model-based requirements

engineering, software processes for model-based development, and modelbased

testing are part of MDE but not, currently, part of MDA.

Although MDA has been in use since 2001, model-based engineering is still at an

early stage of development and it is unclear whether or not it will have a significant

effect on software engineering practice. The main arguments for and against MDE

are:

1. For MDE Model-based engineering allows engineers to think about systems

at a high level of abstraction, without concern for the details of their

implementation. This reduces the likelihood of errors, speeds up the design

and implementation process, and allows for the creation of reusable, platform-

independent application models. By using powerful tools, system

implementations can be generated for different platforms from the same

model. Therefore, to adapt the system to some new platform technology, it is

only necessary to write a translator for that platform. When this is available,

all platform-independent models can be rapidly rehosted on the new platform.

85

2. Against MDE As we discussed earlier in this chapter, models are a good way

of facilitating discussions about a software design. However, it does not

always follow that the abstractions that are supported by the model are the

right abstractions for implementation. So, you may create informal design

models but then go on to implement the system using an off-the-shelf,

configurable package. Furthermore, the arguments for platform independence

are only valid for large long-lifetime systems where the platforms become

obsolete during a system’s lifetime. However, for this class of systems, we

know that implementation is not the major problem—requirements

engineering, security and dependability, integration with legacy systems, and

testing are more significant.

There have been significant MDE success stories reported by the OMG on their Web

pages (www.omg.org/mda/products_success.htm) and the approach is used within

large companies such as IBM and Siemens. The techniques have been used

successfully in the development of large, long-lifetime software systems such as air

traffic management systems. Nevertheless, at the time of writing, model-driven

approaches are not widely used for software engineering

As the case with formal methods, it is not clear whether the costs and risks of model-

driven approaches outweigh the possible benefits.

2.7.5 .1 Model-driven architecture

Model-driven architecture is a model-focused approach to software design and

implementation that uses a sub-set of UML models to describe a system. Here,

models at different

86

Fig (7.19) MDA transformation

Levels of abstraction are created. From a high-level platform independent model it

is possible, in principle, to generate a working program without manual intervention.

The MDA method recommends that three types of abstract system model should be

produced:

1. A computation independent model (CIM) that models the important domain

abstractions used in the system. CIMs are sometimes called domain models. You

may develop several different CIMs, reflecting different views of the system.

For example, there may be a security CIM in which you identify important security

abstractions such as an asset and a role and a patient record CIM, in which you

describe abstractions such as patients, consultations, etc.

2. A platform independent model (PIM) that models the operation of the system

without reference to its implementation. The PIM is usually described using UML

models that show the static system structure and how it responds to external and

internal events.

3. Platform specific models (PSM) which are transformations of the platform

independent model with a separate PSM for each application platform. In principle,

there may be layers of PSM, with each layer adding some platform specific detail.

So, the first-level PSM could be middleware-specific but database independent.

When a specific database has been chosen, a database specific

87

PSM can then be generated.

As we have said, transformations between these models may be defined and applied

automatically by software tools. This is illustrated in Figure 7.19, which also shows

a final level of automatic transformation. A transformation is applied to the PSM to

generate executable code that runs on the designated software platform. At the time

of writing, automatic CIM to PIM translation is still at the research prototype stage.

It is unlikely that completely automated translation tools will be available in the near

future. Human intervention, indicated by a stick figure in Figure 7.19, will be needed

for the foreseeable future. CIMs are related and part of the translation

Fig (7.20) multiple platform specific models

Process may involve linking concepts in different CIMs. For example, the concept

of a role in a security CIM may be mapped onto the concept of a staff member in a

hospital

CIM. Mellor and Balcer give the name ‘bridges’ to the information that supports

mapping from one CIM to another.

The translation of PIMs to PSMs is more mature and several commercial tools are

available that provide translators from PIMs to common platforms such as Java and

88

J2EE. These rely on an extensive library of platform-specific rules and patterns to

convert the PIM to the PSM. There may be several PSMs for each PIM in the system.

If a software system is intended to run on different platforms (e.g., J2EE and .NET),

then it is only necessary to maintain the PIM. The PSMs for each platform are

automatically generated. This is illustrated in Figure 7.20. Although MDA-support

tools include platform-specific translators, it is often the case that these will only

offer partial support for the translation from PIMs to PSMs. In the vast majority of

cases, the execution environment for a system is more than the standard execution

platform (e.g., J2EE, .NET, etc.) .It also includes other application systems,

application libraries that are specific to a company, and user interface libraries. As

these vary significantly from one company to another, standard tool support is not

available. Therefore, when MDA is introduced, special purpose translators may have

to be created that take the characteristics of the local environment into account. In

some cases (e.g., for user interface generation), completely automated PIM to PSM

translation may be impossible.

There is an uneasy relationship between agile methods and model-driven

architecture. The notion of extensive up-front modeling contradicts the fundamental

ideas in the agile manifesto and I suspect that few agile developers feel comfortable

with model-driven engineering. The developers of MDA claim that it is intended to

support an iterative approach to development and so can be used within agile

methods. If transformations can be completely automated and a complete program

generated from a PIM, then, in principle, MDA could be used in an agile

development process as no separate coding would be required. There are no MDA

tools that support practices such as regression testing and test-driven development.

89

2.7.5 .2 Executable UML

The fundamental notion behind model-driven engineering is that completely

automated transformation of models to code should be possible. To achieve this, you

have to be able to construct graphical models whose semantics are well defined. You

also need a way of adding information to graphical models about the ways in which

the operations defined in the model are implemented. This is possible using a subset

of UML 2, called Executable UML or xUML I don’t

Have space here to describe the details of xUML, so I simply present a short

overview of its main features. UML was designed as a language for supporting and

documenting software design, not as a programming language. The designers of

UML were not concerned with semantic details of the language but with its

expressiveness. They introduced useful notions such as use case diagrams that help

with the design but which are too informal to support execution. To create an

executable sub-set of UML, the number of model types has therefore been

dramatically reduced to three key model types:

1. Domain models identify the principal concerns in the system. These are defined

using UML class diagrams that include objects, attributes, and associations.

2. Class models, in which classes are defined, along with their attributes and

operations.

3. State models, in which a state diagram is associated with each class and is used to

describe the lifecycle of the class.

The dynamic behavior of the system may be specified declaratively using the object

constraint language (OCL) or may be expressed using UML’s action language. The

action language is like a very high-level programming language where you can refer

to objects and their attributes and specify actions to be carried out.

90

KEY POINTS

A model is an abstract view of a system that ignores some system details.

Complementary system models can be developed to show the system’s context,

interactions, structure, and behavior.

_ Context models show how a system that is being modeled is positioned in an

environment with other systems and processes. They help define the boundaries

of the system to be developed.

_ Use case diagrams and sequence diagrams are used to describe the interactions

between user the system being designed and users/other systems. Use cases

describe interactions between a system and external actors; sequence diagrams

add more information to these by showing interactions between system objects.

Structural models show the organization and architecture of a system. Class

diagrams are used to define the static structure of classes in a system and their

associations.

_ Behavioral models are used to describe the dynamic behavior of an executing

system. This can be modeled from the perspective of the data processed by the

system or by the events that stimulate responses from a system.

Activity diagrams may be used to model the processing of data, where each

activity represents one process step.

State diagrams are used to model a system’s behavior in response to internal or

external events.

Model-driven engineering is an approach to software development in which a

system is represented as a set of models that can be automatically transformed

to executable code.

91

92

Q: you have to design a program for calculating student’s grade as shown in the

figure below

Explain the set of activities that led to the production of the product by each of the

following process models

Waterfall model, prototype model

Which model is the best for you from your opinion? What is the advantage and

disadvantage of the model you choose over the other?

1- Waterfall model

In waterfall model, we follow a sequential steps to design the program and these

steps or activities are:-

System/information engineering and modeling.

In this step we must gather information about the whole system we interact

with that include: - hardware, software, people, and data base and give

93

requirements for each of it. the following table shows the requirements for

each of the system information

Software requirements analysis

In this step, we focus on the software and studied its information domain to

understand the following:

Required function: - the function of this program is to calculate

student’s grade for first course, second course, midterm, and the final

grade.

Behavior/ performance :- the program must give the best

performance, easy to used, not need a specific H.W/ S.F / users

Interface:- we need a database like access to store the information

about the students.

94

Requirements for both the customer and system are documented and

reviewed with the customer.

Design

Software design is actually a multistep process that focuses on four distinct

attributes of a program:

data structure:- we need a specific information about

Student’s:- numbers, grades, names, stage/college/school, external

activities

Subjects: - names, grades.

software architecture:- we use VB.NET language to design the

program and the software architecture will look like the following

picture

interface representations:- as we said before : the interface include

the environments that interact with the system like : system H.w & S.f

, people, database, etc … and we specify the properties of it earlier

95

Here, we do not used access to store the data at the beginning, but it is an

idea that would be evolve in the future

Procedural (algorithmic) detail:- it will be explained next in the code

in details

The design is documented and becomes part of the software configuration.

Code generation.

Double click the الخاص بلفصل االل \"احسب " and write the following code

Double click the االول"الخاص بلفصل \"تفريغ الخانات and write the following

code

96

Double click the السنة"الخاص بنصف \"احسب and write the following code

97

Double click the button ON and write the following code

Double click the button OFF and write the following code

Testing: - there are three types of test that should be covered to ensure that

that defined input will produce actual results that agree with required

results, these tests are

Component test

System test

Acceptance testing

At this step the error will be discovered and required solutions and redesign

are necessary

98

Support:- Software support/maintenance reapplies each of the preceding

phases to an existing program rather than a new one, to adapted to

accommodate changes in its external environment, in our design , next we

will connect vb.net by access program to store and review the students

grade easily.

………………………………………………………………………………

……………..

2- Prototype model

Gathering information: - in this step we gather information about system

and user requirements, in most cases user doesn’t know detailed

description about ip/op requirements. The gathered information is slimier

to the table shown in the above model, but the requirements here doesn’t

documented to the user next time, instead, engineer go to the next step

immediately

A prototype model is designed and used to focus on a representation of

aspects of the software that will be visible to the customer/user (e.g., input

approaches and output formats), the design may be not complete and not

good first

The prototype is evaluated by the customer/user and used to refine

requirements for the software to be developed. Iteration occurs as the

prototype is tuned to satisfy the needs of the customer, while at the same

time enabling the developer to better understand what needs to be done, in

this example , the program is easy and clear, so it may achieve its goal at

the first design or need a second design to achieve the goal

From our opinion and for the following reasons

It is clearly impossible to design a program for the user and the user

agree about it at the first time.

Any user give just a simple idea about what he want, and doesn’t give

detailed description of the requirements of the program.

The program continue to evolve with future

99

The program is easy and simple to programing , instead of losing time

by document the system and requirements to the user , we use this time

to build the prototype that maybe 70% meet the need of the user.

Because of the sequential steps of the waterfall model, it cause delay

in sketch dual time

So that we choose the prototype model.

The above points is part of the advantages of prototype model over waterfall

model but the disadvantages are

The developer often makes implementation compromises in order to

get a prototype working quickly. An inappropriate operating system or

programming language may be used simply because it is available and

known; an inefficient algorithm may be implemented simply to

demonstrate capability.

The customer sees what appears to be a working version of the

software, unaware that in the rush to get it working no one has

considered overall software quality or long term maintainability. When

informed that the product must be rebuilt so that high levels of quality

can be maintained, the customer cries foul and demands that "a few

fixes" be applied to make the prototype a working product. Too often,

software development management relents.

………………………………………………………………………………………

…………….

Q: - for the following cases choose the write model to process the design, maybe,

more than one model is ok for the answer, choose the best one.

You want to design a program that is clarify in details, requirements is fixed

and clear, short program and the technology used is understood?

Waterfall model is the best model for this case because the requirements is clear

and fixed and the program doesn’t evolve in the future, short program.

100

You want to design a program that is simple and short, the program must

deliver to the user in a short time, you didn’t sure what the users need?

Prototype model is the best model for this case because the user doesn’t have a

clarify details about the requirements and the program must deliver in a short

time, no delay in sketchdual is needed.

Your professor ask you to design a program to extract coverage for Baghdad

and gives you 4 months to do it, you didn’t know anything about the

requirements , you should search about this case , and you didn’t sure what

algorithm you should choose

Prototype model is the best model for this case because you don’t have any ideas

about the case, you didn’t sure what algorithm you should choose, and you must

deliver the program in 4 months, so prototype model gives you a space to try

different things and choose the best one.

You want to design a program that has clarify requirements, the program

evolve for the short term , it must deliver to the customer in one month , it

has some high risk and goals

For the above reasons and because there is some high risk in the program,

Incremental model is the best one for this

You want to design a program that is huge and developed for a long term, the

company require a staff of team to produce the program, the company make

4 groups of engineers for analysis, design, implementation , and delivery , the

delivery group required 4 more engineers to complete deliver the program in

different countries?

Because there is a reduction in the staff, the incremental model will be the best

model for this program, because it can manipulate the situation, early increments

can be implemented with

Fewer people. Then additional staff can be added to implement the next

increment.

101

A small company is designing a medium system for communication, the

system consist of special hardware that used to extract signal strength for the

region and deliver this measurements to the software to compere the real

parameter with the test data , the program must deliver to the company in one

month for testing, the hardware will be ready later by 2 weeks

The incremental model is the best model for this situation, because it can manipulate

the situation, it plan the first increment without using this H.W, just deliver the

program to test the input data, and real data from database measured earlier, and

next develop the programing or supply the H.W to make all functionality happened.

Q: - when to use the waterfall model and what is the advantages and disadvantages

of it

102

Q: you have to design a program for calculating student’s grade as shown in the

figure below

Explain the set of activities that led to the production of the product by the following

process model

PSP model

103

In the PSP model, the first thing we must do, is gathering requirements about the

system and program, the following table shows the requirements for each of the

system information

PSP0/ PSP0.1:-

In this step there is 3 phases

1- Planning :- in this step , the engineer makes a plan to produce the program ,

he takes all the requirements in to consideration ,choose the system, the

programing language, and the algorithm used , to begin with the next phase

2- Development :- the development have 3 steps

Design :- design the program and perform more than one

representation for the program and choose the best one that best

104

satisfies the requirements, in this program the best design for now

that satisfies the condition of designing is as shown in the figure

below , the design is made by VB.net

Coding:- the code is similar to the code in the question one

Test:- - there are three types of test that should be covered to ensure

that that defined input will produce actual results that agree with

required results, these tests are

Component test

System test

Acceptance testing

At this step the error will be discovered and required solutions and redesign

are necessary

A baseline is established of current process measuring:

Time spent on programming: the program is simple and clear, the time spend on

programing will be short, it takes from 1-3 days

105

Faults injected/removed: - the program doesn’t have any type of connection by

another system or program, so faults will produced from wrong programing, each

code will review in the documents and in the test to find faults and remove it.

Size of a program: - each component in the program is simple and its size is

simple, so the whole program will be small in size, doesn’t exceed 1Mb

Post mortem, in the post mortem we recorded and analyzed all the data gathered

in the first steps.

PSP0.1 we advances the process by adding

A coding standard: - we always try to get the best performance, so we but

some standardization, our engineers will follow this standardization to

introduce best solutions to the problems and best coding for the design.

a size measurement :- gathered the subprograms size to measure the fall size

Personal process improvement plan (PIP):- In the PIP, each engineer

records ideas for improving his own process. We can improve this program

on the future by making database for each stage in the school, and save and

take information from this database , and make charts about successful rate in

each year , extracts the first students and many others features that can be

added to the design now or in the future

PSP1/ , PSP1.1:-

PSP1

A test report will prepared in this step, simulating the size of the program depending

on the measurements gathered in PSP0 and PSP0.1, of course the program will be

small in size, didn’t need any sophisticated system properties to operate .

PSP1.1

In this phase, Estimation and planning of the total time and schedule is reported

depended on the Accumulated data from previous projects. Each new project will

record the actual time spent. For now, the system is simple, doesn’t have changes to

code or system, so the first assumption will be constant and that is: - It need from 1

to 3 days to be ready.

106

PSP2, PSP2.1:-

Each phase of the operation is reviewed to find faults and defects and remove it,

Engineers construct and use checklists for design and code reviews. in this program

,Engineers do not spend a lot of time by reviewed code and design because the

program is simple , but in other systems , it takes a time to review all phases , PSP2.1

introduces design specification and analysis techniques

107

108

SYSTEM MODELING

ACTIVITY DIAGRAMS

Activity diagram is basically a flow chart to represent the flow form one activity to

another activity. The activity can be described as an operation of the system. Activity

diagram is used to show message flow from one activity to another.

Purpose:-

Draw the activity flow of a system.

Describe the sequence from one activity to another.

Describe the parallel, branched and concurrent flow of the system.

How to draw Activity Diagram?

1- Before drawing an activity diagram we must have a clear understanding

about the elements used in activity diagram. The main element of an activity

diagram is the activity itself. An activity is a function performed by the

system.

2- After identifying the activities we need to understand how they are associated

with constraints and conditions.

3- So before drawing an activity diagram we should identify the following

elements:

Activities

Association

Conditions

Constraints

4- Once the above mentioned parameters are identified we need to make a

mental layout of the entire flow. This mental layout is then transformed into

an activity diagram.

EXAMPLE: - draw an activity diagram to model an order management system

in a restraint.

In the diagram four activities are identified which are associated with conditions.

One important point should be clearly understood that an activity diagram cannot be

exactly matched with the code. The activity diagram is made to understand the flow

of activities and mainly used by the business users.

109

Four main activities:

Send order by the customer

Receipt of the order

Confirm order

Dispatch order

After receiving the order request condition checks are performed to check if it is

normal or special order. After the type of order is identified dispatch activity is

performed and that is marked as the termination of the process.

Example: - draw an activity diagram to model the teaching technique (theory and

lab) between the teacher and students in the university?

110

The teacher technique in teaching the students is different from university to other

and from one teacher to other, here we listed the main activities that made by the

teacher and who these activates are flowed from the beginning of the course to the

final of the course

The main activities are

Prepared the lectures

Teaching the students

Made the list menu for students

Made a Quizzes every week

Final exam

After teaching the students, the teacher checked if the students are understand

what he said! If ok then he go to the next step, if no then he return to repeat the

subject and answer any question from the students

111

Q: - Make the activity diagram for the teaching technique (lab)

…………………………………………………………………………………

……………

UASE-CASE DIAGRAMS

Use case diagrams are used to gather the requirements of a system including internal

and external influences. These requirements are mostly design requirements. So

when a system is analyzed to gather its functionalities use cases are prepared

and actors are identified.

Now when the initial task is complete use case diagrams are modelled to present the

outside view.

So in brief, the purposes of use case diagrams can be as follows:

Used to gather requirements of a system.

Used to get an outside view of a system.

Identify external and internal factors influencing the system.

Show the interacting among the requirements are actors.

How to draw Use Case Diagram?

We can say that uses cases are nothing but the system functionalities written in an

organized manner.

In a brief when we are planning to draw a use case diagram we should have the

following items identified.

Functionalities to be represented as an use case

Actors

Relationships among the use cases and actors.

So after identifying the above items we have to follow the following guidelines to

draw an efficient use case diagram.

The name of a use case is very important. So the name should be chosen in

such a way so that it can identify the functionalities performed.

Give a suitable name for actors.

Show relationships and dependencies clearly in the diagram.

112

Do not try to include all types of relationships. Because the main purpose of

the diagram is to identify requirements.

Use note whenever required to clarify some important points.

EXAMPLE: - draw the use- case diagram for the order management in restraint

First we must define the actors: - The small restraint consist of chef, waiter, client,

cashier

Second we must identify the functions of the actors: The main activities or

functions of each of the above are as follows

Chef------ cook food

Client{𝑜𝑟𝑑𝑒𝑟 𝑓𝑜𝑜𝑑

𝑒𝑎𝑡𝑝𝑎𝑦 𝑓𝑜𝑟 𝑓𝑜𝑜𝑑

Waiter -------- serve food

Cashier -------- accept payment

Order may extend to contain both food and wine

Third we must identify the relationship between actors

113

Example: - draw the use-case diagram for internet café

First we must define the actors: - The small internet cafe consist of administrator,

customer, cushier.

Second we must identify the functions of the actors: The main activities or

functions of each of the above are as follows

Administrator------- calculate hour of service

Customer {𝑜𝑟𝑑𝑒𝑟 𝑖𝑛𝑡𝑒𝑟𝑛𝑒𝑡𝑢𝑠𝑒 𝑖𝑛𝑡𝑒𝑟𝑛𝑒𝑡

𝑝𝑎𝑦 𝑓𝑜𝑟 𝑖𝑛𝑡𝑒𝑟𝑛𝑒𝑡

Cashier -------- accept payment

Third we must identify the relationship between actors

114

Example: - draw the use-case diagram for the library management system

Note: - A library management system, also known as an automated library system

is software that has been developed to handle basic housekeeping functions of a

library. You can access the library online by internet, but to request a book, first

you must registered.

First we must define the actors: - The basic library management system consist of

librarian, books database, user, and vender.

Second we must identify the functions of the actors: The main activities or

functions of each of the above are as shown in the figure below

115

Third we must identify the relationship between actors

SEQUANCE DIAGRAM

5 steps to draw sequence diagrams

116

Here we give example of drawing sequence diagram of ATM system

Note:- ATM (Automatic Teller Machine machine) system is A banking terminal

that accepts deposits and dispenses cash. ATMs are activated by inserting a cash or

credit card that contains the user's account number and PIN on a magnetic stripe.

117

In the simplest form, the objects or rules in our example are

UTM user, card reader, ATM system

ATM system consist of card reader, display screen, keyboard, bank database as

shown below

To simplify the diagram we gather display, keyboard, and bank data as ATM

system

In this example, we will discuss each point in details, follow the pictures below

118

119

120

Example:- draw the sequence diagram for the online quiz system

The system consist of the user and admin that administrate the system and data base

Online quiz system differs in steps from one system to another, each engineer can

give its own vision of the deign steps, here the admin ask the user to enter his id,

then a check process is happened, the quiz is begin, after finish, the result is

calculated and given to the user

Example: - draw a sequence diagram for on line shopping

121

Online shopping system differs in steps from one system to another, each engineer

can give its own vision of the deign steps.

Here: the steps of online shopping is as follows that are translate into a sequence

diagram

122

CONTEXT MODELS

123

Example: - draw the context diagram for the order management in restraint

First we must define the actors: - The small restraint consist of chef, waiter, client,

cashier

Second: - we must define the connections or flow of data

Each of the waiter, customer, and chef are working in 2 way

Customer order the food and eat food so 2 way connection

Chef receive the order and cook the food so 2 way connection

Waiter receive the order and serve the food so 2 way connection

Cashier accept the payment so 1 way connection

Third:- we draw the context diagram for the system

Example 2:- draw the context diagram for the library management system

124

First we must define the actors: - The simple library system consist of user,

librarian, vendor, database

Second: - we must define the connections or flow of data

Each of the above actors are working in 2 ways

User request for books and take the books so 2 way connection

Librarian request/issue books and information from users and vendor so 2 way

connection

Vendor receive request from library/ supply books to library so 2 way connection

Database use to i/p & o/p data so 2 way connection

Third: - we draw the context diagram for the system

CLASS DIAGRAMS

The following points should be remembered while drawing a class diagram:

125

The name of the class diagram should be meaningful to describe the aspect

of the system.

Each element and their relationships should be identified in advance.

Responsibility (attributes and methods) of each class should be clearly

identified.

For each class minimum number of properties should be specified. Because

unnecessary properties will make the diagram complicated.

Use notes whenever required to describe some aspect of the diagram.

Because at the end of the drawing it should be understandable to the

developer/coder.

Finally, before making the final version, the diagram should be drawn on

plain paper and rework as many times as possible to make it correct.

Now the following diagram is an example of an Order System of an application. So

it describes a particular aspect of the entire application.

First of all Order and Customer are identified as the two elements of the

system and they have a one to many relationship because a customer can

have multiple orders.

We would keep Order class is an abstract class and it has two concrete

classes (inheritance relationship) SpecialOrder and NormalOrder.

The two inherited classes have all the properties as the Order class. In

addition they have additional functions like dispatch () and receive ().

So the following class diagram has been drawn considering all the points mentioned above:

126

Example:-

Draw the class diagram for the bank account

Answer: - in the bank. We deposit money and withdrawal money, so there are

two subclasses drawing from the main class bank account

Each bank account have some attributes, of sure the main attributes of it, is the

amount of money or balance, and the date created …etc

(Each engineer is free of adding other attributes to the diagram)

127

128

Example:-

Draw class diagram for the library management system

129

Example:-

Draw class diagram for the order management system in restraint

130

STATE DIAGRAM

Purpose

Define different states of an object during its lifetime. And these states are changed

by events.

Statechart diagram describes the flow of control from one state to another state.

States are defined as a condition in which an object exists and it changes when some

event is triggered. So the most important purpose of Statechart diagram is to model

life time of an object from creation to termination.

How to draw Statechart Diagram?

Statechart diagram is used to describe the states of different objects in its life cycle.

So the emphasis is given on the state changes upon some internal or external events.

These states of objects are important to analyze and implement them accurately.

Before drawing a Statechart diagram we must have clarified the following points:

Identify important objects to be analyzed.

Identify the states.

Identify the events.

Example: - draw state diagram for books in library management system

First of all we must analyzed the object, states, condition

The object to be analyzed is books

The book comes through two state in its life time, available & order to customer

If the customer order the book (condition) then the books transform from the

available state to issue the book to user / if the user return the book ( condition)

then the book return to the available state

Note: - state diagrams are not restrict and each engineer can give its own vision

of the diagrams

131

Example: - draw state diagram for librarian in library management system

Example:- draw state diagram for the telephone

132

The following is an example of a Statechart diagram where the state of Order object

is analyzed.

The first state is an idle state from where the process starts. The next states are

arrived for events like send request, confirm request, and dispatch order. These

events are responsible for state changes of order object.

133

During the life cycle of an object (here order object) it goes through the following

states and there may be some abnormal exists also. This abnormal exit may occur

due to some problem in the system. When the entire life cycle is complete it is

considered as the complete transaction as mentioned below.

The initial and final state of an object is also shown below.

134

Questions

1- You have been asked to develop a system that will help with planning large-

scale events

And parties such as weddings, graduation celebrations, birthday parties, etc. Using

an Activity diagram, model the process context for such a system that shows the

activities Involved in planning a party (booking a venue, organizing invitations, etc.)

and the system elements that may be used at each stage.

2- Develop a sequence diagram showing the interactions involved when a student

registers for a course in a university. Courses may have limited enrollment, so

the registration process must include checks that places are available. Assume

that the student accesses an electronic course catalog to find out about available

courses.

3- Look carefully at how messages and mailboxes are represented in the e-mail

system that you use. Model the object classes that might be used in the system

implementation to represent a mailbox and an e-mail message.

4- Based on your experience with a bank ATM, draw an activity diagram that

models the data processing involved when a customer withdraws cash from the

machine.

5- Draw state diagrams of the control software for an automatic washing machine

that has different programs for different types of clothes.