Software Server for Automatic Generation of Audio Lectures ...
Software engineering modelings lectures
-
Upload
eng-marwa -
Category
Engineering
-
view
30 -
download
4
Transcript of Software engineering modelings lectures
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.