History and Overview

1
 History
 Software engineering has evolved steadily from its
founding days in the 1940s until today in the 2000s.

 Applications have evolved continuously.

 The ongoing goal to improve technologies and

practices, seeks to improve the productivity of
practitioners and the quality of applications to users.

2
 1945 to 1965: The Origins
 The term software engineering first was used in the
late 1950s and early 1960s.

 Programmers have always known about civil, electrical

and computer engineering and debated what
engineering might mean for software.

 The NATO Science Committee sponsored two

conferences on software engineering in 1968 and 1969,
which gave the field its initial boost.

 Many believe these conferences marked the official

start of the profession.
3
1965 to 1985: The Software Crisis
 Software engineering was spurred by the so-called
software crisis of the 1960s, 1970s and 1980s, which
identified many of the problems of software
development.
 Many software projects ran over budget and schedule.
 Some projects caused property damage.
 A few projects caused loss of life.
 Some used the term software crisis to refer to their
inability to hire qualified programmers. The software
crisis was originally defined in terms of productivity,
but evolved to emphasize quality.

4
 Cost and Budget Overruns: The OS/360 operating
system was a classic example.

 This decade-long project from the 1960s and 1970s

eventually produced one of the most complex software
systems ever created. The OS/360 was one of the first
large, 1000 programmer, software projects.

 Fred Brooks claims in 'Mythical Man Month' that he

made a multi-million dollar mistake by not developing
a coherent architecture before starting development.

5
 Property Damage: Software defects can cause property
damage.

 Poor software security allows hackers to steal

identities, costing time, money, and reputations.

 An expensive European Ariane rocket exploded

because of software.

6
 Life and Death: Software defects can kill.
 Some embedded systems used in radiotherapy
machines failed so catastrophically that they
administered lethal doses of radiation to patients.
 Peter G. Neumann keeps a contemporary list of
software problems and disasters at Computer Risks.
 The software crisis has been slowly fizzling out,
because it is unrealistic to remain in crisis mode for
more than twenty years.
 SEs are accepting that the problems of SE are truly
difficult and only hard work over many decades can
solve them.

7
1985 to Present: No Silver Bullet

 For decades, solving the software crisis was paramount

to researchers. Seemingly, they trumpeted every new
technology and practice from the 1970s to the 1990s as
a silver bullet to solve the software crisis.

 Tools, discipline, formal methods, process, and

professionalism were touted as silver bullets.

8
 Tools: Especially emphasized were tools.
 Structured programming, object-oriented
programming, CASE tools, Ada, documentation,
standards, and UML were touted as silver bullets.
 Discipline: Some pundits argued that the software
crisis was due to the lack of discipline of programmers.
 Formal methods: Some believed that if formal
engineering methodologies would be applied to
software development, then production of software
would become as predictable an industry as other
branches of engineering. They advocated proving all
programs correct.
 Process: Many advocated processes and
methodologies like CMM.
 Professionalism: This led to work on a code of ethics,
licenses and professionalism.
9
 Major Developments
 There are a numbers of areas where the evolution of
software engineering is notable.

 Emergence as a profession: From the mid-1990s to the

mid-2000s, software engineering emerged as a bona
fide profession, to stand beside computer science and
traditional engineering.

10
 Role of women:
 In the 1940s, 1950s, and 1960s, software was often written by
women.
 Men often filled the highest prestige hardware engineering roles.
 Grace Hopper and many other unsung women filled many
programming jobs during the first several decades of software
engineering.
 Today, fewer women work in software engineering than in other
professions. Saying that this is sexual discrimination is too
simple because it related directly to individual identity.
 In one sense, software engineering is the masculinization of
programming.
 The roles women fill in SE continue evolving.
 Today, more women in software engineering fill the social roles
of analysis, training, documentation and management; and
fewer do hardcore technical development.

11
 Software is more than just a program code.

 A program is an executable code, which serves some

computational purpose.

 Software is considered to be collection of executable

programming code, associated libraries and
documentations.

 Software, when made for a specific requirement is

called software product.

12
 Engineering on the other hand, is all about
developing products, using well-defined, scientific
principles and methods.

 Software engineering is an engineering branch

associated with development of software product
using well-defined scientific principles, methods and
procedures.
 The outcome of software engineering is an efficient
and reliable software product.

13
IEEE defines software engineering as:
(1) The application of a systematic, disciplined,
quantifiable approach to the development,
operation, and maintenance of software; that is,
the application of engineering to software.

(2) The study of approaches as in the above statement.

 Fritz Bauer, a German computer scientist, defines
software engineering as:
 “Software engineering is the establishment and use of
sound engineering principles in order to obtain
economically software that is reliable and work
efficiently on real machines.”
14
 The following are components used to construct computer
based information system.
 Software Engineering components:
 Methodologies
 Overall approach, usually within a framework or architecture
 Techniques
 A way to do a specific task (e.g. interview, observation, etc)

 Tools
 CASE tools (e.g., Visio, ArgoUML, and Rational Rose) to assist
in application of techniques to the analysis and design process

15
 Major problems in software developments …

The requirements The developers This is how the problem

understood it in This is how the
specification was is solved now
that way problem was
defined like this
solved before.

This is how the program is This, in fact, is what the

described by marketing customer wanted … ;-)
That is the program after
department
debugging
16
Chapter Two: Software Process
 Process - A sequence of steps performed for a given
purpose. What you do.

 Software process - A set of activities, methods,

practices and transformations that people employ to
develop and maintain software products.

 Software process capability - Range of expected results

by following a certain software process.
 Software process performance - The actual results
achieved by following a software process.
17
 Information system
 System that achieves a business outcome

 Computerized information system

 COTS (commercial off-the-shelf) package
 Custom information system
 ERP system
 Open source system

18
 Custom Information System
 Custom Information System is an information system
that has been developed for one specific client

 Stakeholders
 Client: the one who is paying for the information system
to be developed
 Users: future users of the information system
 Developers: those who build the information system

19
 COTS Software
 COTS (Commercial Off-The-Shelf) packages provide
functionality that meets the needs of many users

 Well known COTS packages include MS Office and

Peachtree Accounting

 Stakeholders
 Users
 Developers

20
Enterprise Resource Planning (ERP)
System
 Enterprise Resource Planning (ERP) system integrate
business functions into modules enabling a single seamless
transaction to cut across functional boundaries
 Examples: PeopleSoft, SAP

 ERP system provides almost all the information needs of a

large corporation, including accounting, payroll, inventory,
personnel, etc

 ERP system has to be customized to the specific

requirements of each organization

21
 Open Source System
 Open Source Systems are freely available (most of the
time including source code)
 Developed by a community of interested people
 Performs the same functions as commercial software
 Examples: Linux, mySQL, Firefox

22
Software Development Life Cycle
 Software Development Life Cycle, SDLC for short, is a
well-defined, structured sequence of stages in software
engineering to develop the intended software product.

 SDLC provides a series of steps to be followed to

design and develop a software product efficiently.

 Every textbook author and information systems

development organization uses a slightly different life-
cycle model, with anywhere from 3 to almost 20
identifiable phases.

23
 Basic Problem Solving Flow

WHAT

HOW

DO

TEST

USE

24
Development Process
 Commonly has these activities:
1. Requirements analysis,
2. Design
3. Coding,
4. Testing,
5. Maintenance

 Different models perform them in different manner!

Software Process 25
1. Requirement Analysis
 State the problem precisely!
 Forms the basis of agreement between user and
developer
 Specifies “what” not “how”
 Hard task - needs often not understood well
 Requirement specifications of even medium
systems can be many hundreds of pages
 Output is the SW Requirements Spec (SRS)
document

Software Process 26
2. Design
 A major step in moving from problem domain
to solution domain
 Three main tasks
1. Architecture design – components and connectors
that should be there in the system
2. High level design – modules and data structures
needed to implement the architecture
3. Detailed design – logic of modules
 Most methodologies focus on architecture or
high level design
 Outputs are arch/des/logic design docs

Software Process 27
3) Coding
 Converts design into code in specific language
 Goal: Implement the design with simple and
easy to understand code

 Coding phase affects both testing and

maintenance
 Well written code reduces testing and maintenance
effort
 Output is code

Software Process 28
4) Testing & Quality Assurance
 Defects are introduced in each phase
 Must be found and removed to achieve high
quality
 Goal: Identify most of defects
 Very expensive task; must be properly planned
and executed
 Outputs are
 Test plans/results, and
 the final tested (hopefully reliable) code

Software Process 29
5) Maintenance
 Modify the system
 Remove any remaining faults
 Correcting mistake
 Extend (Upgrade) the system in some way

30
Financial implications of Maintenance
 For very 1 Birr spent on development, at least
2 Birr is spent on maintenance

31
 Maintenance Activities
 There are three main maintenance activities:

 Corrective maintenance
 Fixing faults

 Perfective maintenance
 Adding functionality

 Adaptive maintenance
 Making changes because the environment changes

 Enhancement: Perfective + Adaptive maintenance

32
Why there is No Planning phase
 We cannot plan until we have accurate, detailed
information

 There are three types of planning activities:

 There is preliminary planning at the start of the project
 The project management plan is drawn up after the
specifications have been approved by the client
 Management monitor the plan all through the project

33
 Cont’d
 Planning activities are carried out through all the life cycle

 There is no separate planning phase

34
Why there is No Documentation phase

 The documentation must be complete, correct, and up to

date at all times
 Personnel turnover in the information system industry
 Performing a phase requires the documentation from the
previous phase

 Testing activities require documentation

 Maintenance activities require documentation

 There is no separate documentation phase

35
 Software Process Model
 A (software/system) process model is a description of
the sequence of activities carried out in a SE project,
and the relative order of these activities.

 It provides a fixed generic framework that can be

tailored to a specific project.

 Normally, a process model covers the entire lifetime

of a product.
 From birth of a commercial idea to final de-
installation of last release

36
 There are hundreds of different process models to
choose from, e.g:
• waterfall,
• code-and-fix
• spiral
• rapid prototyping
• V-shaped
• agile methods, extreme programming (XP)
• COTS …
 SW developers select among various process models
regarding the character of the particular SW system they
are to develop.

37
 The Waterfall Model
 The waterfall model is the classic process model – it is
widely known, understood and used.
 All the phases of SDLC will function one after another
in linear manner.
 That is, when the first phase is finished then only the
second phase will start and so on.
 This model assumes that everything is carried out and
taken place perfectly as planned in the previous stage
and there is no need to think about the past issues that
may arise in the next phase.

38
 This model does not work smoothly if there are some
issues left at the previous step.
 The sequential nature of model does not allow us to go
back and undo or redo our actions.
 This model is best suited when developers already
have designed and developed similar software in the
past and are aware of all its domains.
Requirements
definition

System and
software design

Implementation
and unit testing

Integr ation and

system testing

Operation and
maintenance

39
 Iterative Model
 Leads the software development process in iterations.
 It projects the process of development in cyclic
manner repeating every step after every cycle of SDLC
process.

 The software is first developed on very small scale and

all the steps are followed which are taken into
consideration.

 Then, on every next iteration, more features and

modules are designed, coded, tested, and added to the
software.

40
 Every cycle produces a software, which is complete in
itself and has more features and capabilities than that
of the previous one.
 After each iteration, the management team can do
work on risk management and prepare for the next
iteration.
 Because a cycle includes small portion of whole
software process, it is easier to manage the
development process but it consumes more resources.

41
 Spiral Model
 Spiral model is a combination of both, iterative model
and one of the SDLC model. It can be seen as if you
choose one SDLC model and combined it with cyclic
process (iterative model).

42
 This model considers risk, which often goes un-
noticed by most other models.
 The model starts with determining objectives and
constraints of the software at the start of one iteration.

 Next phase is of prototyping the software. This

includes risk analysis.
 Then one standard SDLC model is used to build the
software.

 In the fourth phase of the plan of next iteration is

prepared.
43
 V-Model
 The major drawback of waterfall model is we move to
the next stage only when the previous one is finished
and there was no chance to go back if something is
found wrong in later stages.
 V-Model provides means of testing of software at each
stage in reverse manner.

44
 At every stage, test plans and test cases are created to verify
and validate the product according to the requirement of
that stage.
 For example, in requirement gathering stage the test team
prepares all the test cases in correspondence to the
requirements.
 Later, when the product is developed and is ready for
testing, test cases of this stage verify the software against its
validity towards requirements at this stage.
 This makes both verification and validation go in parallel.
This model is also known as verification and validation
model.
 Verification and Validation: is the process of checking that
a software system meets specifications and that it fulfills its
intended purpose.
 Validation: Are we building the right system?
 Verification: Are we building the system right?
45
 Big Bang Model
 This model is the simplest model in its form.
 It requires little planning, lots of programming and
lots of funds.
 This model is conceptualized around the big bang of
universe. As scientists say that after big bang lots of
galaxies, planets, and stars evolved just as an event.

 Likewise, if we put together lots of programming and

funds, you may achieve the best software product.

46
 For this model, very small amount of planning is
required.
 It does not follow any process, or at times the customer
is not sure about the requirements and future needs.
So the input requirements are arbitrary.
 This model is not suitable for large software projects
but good one for learning and experimenting.

47
 Software Metrics
A software metric is a measure of software
characteristics which are measurable or countable.
 Software metrics are valuable for many reasons,
including measuring software performance, planning
work items, measuring productivity, and many other
uses.
 Within the software development process, many
metrics are there, that are all connected.
 Software metrics are similar to the four functions of
management: Planning, Organization, Control, or
Improvement.

48
 Classification of Metrics
Software metrics can be classified into two types as follows:
1. Product Metrics: These are the measures of various
characteristics of the software product. The two important
software characteristics are:
 Size and complexity of software.
 Quality and reliability of software.
 These metrics can be computed for different stages of
SDLC.
2. Process Metrics: These are the measures of various
characteristics of the software development process.
 For example, the efficiency of fault detection. They are
used to measure the characteristics of methods,
techniques, and tools that are used for developing software.

49
 Types of Metrics
 Internal metrics: Internal metrics are the metrics
used for measuring properties that are viewed to be of
greater importance to a software developer. For
example, Lines of Code (LOC) measure.
 External metrics: External metrics are the metrics
used for measuring properties that are viewed to be of
greater importance to the user, e.g., portability,
reliability, functionality, usability, etc.

50
 Hybrid metrics: Hybrid metrics are the metrics that
combine product, process, and resource metrics.
 For example, cost per FP where FP stands for Function
Point Metric.
 Project metrics: Project metrics are the metrics used
by the project manager to check the project's progress.
 Data from the past projects are used to collect various
metrics, like time and cost; these estimates are used as
a base of new software.
 Note that as the project proceeds, the project manager
will check its progress from time-to-time and will
compare the effort, cost, and time with the original
effort, cost and time.

51
 Chapter 3
Requirement Engineering
 The software requirements are description of features
and functionalities of the target system.
 Requirements convey the expectations of users from
the software product.
 Requirement Engineering is the process of
gathering the software requirements from client,
analyze, and document it.
 Goal is to develop and maintain sophisticated and
descriptive ‘System Requirements Specification’
document.

52
Requirement Engineering Process

 It is a four step process, which includes –

 Feasibility Study
 Requirement Gathering
 Software Requirement Specification
 Software Requirement Validation

53
 Feasibility Study
 What all functions the software must perform and
which all features are expected from the software.
 The analysts do a detailed study about whether the
desired system and its functionality are feasible to
develop.
 This study analyzes whether the software product can
be practically materialized in terms of
 implementation,
 contribution of project to organization,
 cost constraints, and
 as per values and objectives of the organization.

54
 It explores technical aspects of the project and product
such as usability, maintainability, productivity, and
integration ability.

 The output of this phase should be a feasibility study

report that should contain adequate comments and
recommendations for management about whether or
not the project should be undertaken.

55
 Requirement Gathering
 If the feasibility report is positive towards undertaking
the project, next phase starts with gathering
requirements from the user.

 Analysts and engineers communicate with the client

and end-users to know their ideas on what the
software should provide and which features they want
the software to include.

56
Software Requirement Specification
 SRS is a structured document created by system
analyst after the requirements are collected from
various stakeholders.

 SRS defines how the intended software will interact

with hardware, external interfaces, speed of operation,
response time of system, portability of software across
various platforms, maintainability, speed of recovery
after crashing, Security, Quality, Limitations etc.

57
 Software Requirement Validation
 After requirement specifications are developed, the
requirements mentioned in this document are validated.
 User might ask for illegal, impractical solution or experts
may interpret the requirements inaccurately.

 Requirements can be checked against following conditions

 If they can be practically implemented
 If they are valid and as per functionality and domain of
software
 If there are any ambiguities
 If they are complete
 If they can be demonstrated

58
 Software Requirement Elicitation
 Requirement elicitation process can be depicted using
the following diagram:

 Requirements gathering - The developers discuss

with the client and end users and know their
expectations from the software.
 Organizing Requirements - The developers
prioritize and arrange the requirements in order of
importance, urgency and convenience.

59
 Negotiation & discussion - If requirements are
ambiguous or there are some conflicts in requirements
of various stakeholders, it is then negotiated and
discussed with the stakeholders.
 Requirements may then be prioritized and reasonably
compromised.
 The requirements come from various stakeholders.
 To remove the ambiguity and conflicts, they are
discussed for clarity and correctness. Unrealistic
requirements are compromised reasonably.
 Documentation - All formal and informal, functional
and non-functional requirements are documented and
made available for next phase processing.
60
Requirement Elicitation Technique
 Requirements Elicitation is the process to find out the
requirements for an intended software system by
communicating with client, end users, system users,
and others who have a stake in the software system
development.

 There are various ways to discover requirements. Some

of them are explained below:
 Surveys: organization may conduct surveys among
various stakeholders by querying about their
expectation and requirements from the upcoming
system.
61
 Interviews: are strong medium to collect
requirements.
 Organization may conduct several types of interviews
such as:
 Structured (closed) interviews
 Non-structured (open) interviews
 Oral interviews
 Written interviews
 One-to-one interviews
 Group interviews

62
 Questionnaires: A document with pre-defined set of
objective questions and respective options is handed
over to all stakeholders to answer, which are collected
and compiled.
 A shortcoming of this technique is, if an option for
some issue is not mentioned in the questionnaire, the
issue might be left unattended.

 Task analysis: Team of engineers and developers may

analyze the operation for which the new system is
required.
 If the client already has some software to perform
certain operation, it is studied and requirements of
proposed system are collected.

63
 Domain Analysis: Every software falls into some domain
category. The expert people in the domain can be a great
help to analyze general and specific requirements.
 Brainstorming: An informal debate is held among various
stakeholders and all their inputs are recorded for further
requirements analysis.

 Observation: Team of experts visit the client’s

organization or workplace.
 They observe the actual working of the existing installed
systems, workflow at the client’s end and how execution
problems are dealt. The team itself draws some conclusions
which aid to form requirements expected from the
software.
64
 Prototyping: is building user interface without
adding detail functionality for user to interpret the
features of intended software product.

 It helps giving better idea of requirements. If there is

no software installed at client’s end for developer’s
reference and the client is not aware of its own
requirements, the developer creates a prototype based
on initially mentioned requirements.

 The prototype is shown to the client and the feedback

is noted. The client feedback serves as an input for
requirement gathering.
65
 Software Requirements
Characteristics
 Gathering software requirements is the foundation of the entire
software development project.
 A complete Software Requirement Specifications must be:
 Clear
 Correct
 Consistent
 Coherent
 Comprehensible
 Modifiable
 Verifiable
 Prioritized
 Unambiguous
 Traceable
 Credible source

66
 Software Requirements
 SR are categorized in two categories:
Functional Requirements
 Requirements, which are related to functional aspect of
software.
 They define functions and functionality within and from
the software system.
 EXAMPLES -
 Search option given to user to search from various invoices.
 User should be able to mail any report to management.
 Users can be divided into groups and groups can be given
separate rights.
 Should comply business rules and administrative functions.
 Software is developed keeping downward compatibility
intact.

67
Non-Functional Requirements
 Requirements, which are not related to functional aspect of
software.
 They are implicit or expected characteristics of software,
which users make assumption of.
 Non-functional requirements include -
 Security
 Logging
 Storage
 Configuration
 Performance
 Cost
 Interoperability
 Flexibility
 Disaster recovery
 Accessibility

68
 Requirements are categorized logically as:
 Must Have : Software cannot be said operational
without them.
 Should have : Enhancing the functionality of software.
 Could have : Software can still properly function with
these requirements.
 Wish list : These requirements do not map to any
objectives of software.

 While developing software, ‘Must have’ must be

implemented, ‘Should have’ is a matter of debate with
stakeholders and negation, whereas ‘Could have’ and
‘Wish list’ can be kept for software updates.
69
 System Model
 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 now come to mean representing

a system using some kind of graphical notation, which
is now almost always based on notations in the Unified
Modeling Language (UML).

 System modeling helps the analyst to understand the

functionality of the system and models are used to
communicate with customers.
70
Existing and Planned System Model
 Models of the existing system are used during
requirements engineering.
 Helps to 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.
 Models of the new system are used during requirements
engineering.
 Helps to 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.

71
 System Perspectives
 An external perspective, where you model the context
or environment of the system.
 An interaction perspective, where you model the
interactions between a system and its environment, or
between the components of a system.
 A structural perspective, where you model the
organization of a system or the structure of the data
that is processed by the system.
 A behavioral perspective, where you model the
dynamic behavior of the system and how it responds
to events.

72
 UML Diagram Types
 Activity diagrams, which show the activities involved
in a process or in data processing .
 Use case diagrams, which show the interactions
between a system and its environment.
 Sequence diagrams, which show interactions between
actors and the system and between system
components.
 Class diagrams, which show the object classes in the
system and the associations between these classes.
 State diagrams, which show how the system reacts to
internal and external events.

73
 Use of Graphical Models
 As a means of facilitating discussion about an existing
or proposed system
 Incomplete and incorrect models are OK as their role is
to support discussion.
 As a way of documenting an existing system
 Models should be an accurate representation of the
system but need not be complete.
 As a detailed system description that can be used to
generate a system implementation
 Models have to be both correct and complete.

74
 Context Models
 Context models are used to illustrate the operational
context of a system - they show what lies outside the
system boundaries.
 Social and organisational concerns may affect the
decision on where to position system boundaries.
 Architectural models show the system and its
relationship with other systems.

75
 System Boundaries
 System boundaries are established to define what is
inside and what is outside the system.
 They show other systems that are used or depend on the
system being developed.
 The position of the system boundary has a profound
effect on the system requirements.
 Defining a system boundary is a political judgment
 There may be pressures to develop system boundaries
that increase / decrease the influence or workload of
different parts of an organization.

76
 Process Perspective
 Context models simply show the other systems in the
environment, not how the system being developed is
used in that environment.
 Process models reveal how the system being developed
is used in broader business processes.
 UML activity diagrams may be used to define business
process models.

77
 Interaction Models
 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.
 Use case diagrams and sequence diagrams may be
used for interaction modeling.

78
 Use case Modeling
 Use cases were developed originally to support
requirements elicitation and now incorporated into
the UML.
 Each use case represents a discrete task that involves
external interaction with a system.
 Actors in a use case may be people or other systems.
 Represented diagrammatically to provide an overview
of the use case and in a more detailed textual form.

79
 Transfer-data use case
 A use case in the MHC-PMS

80
Tabular description of the ‘Transfer
data’ use-case

81
 Sequence diagrams
 Sequence diagrams are part of the UML and are used
to model the interactions between the actors and the
objects within a system.
 A sequence diagram shows the sequence of
interactions that take place during a particular use case
or use case instance.
 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.

82
Sequence diagram for View patient
information

83
 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.
 You create structural models of a system when you are
discussing and designing the system architecture.

84
 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.
 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 some relationship between these classes.
 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, doctor, etc.

85
Classes and associations in the
MHC-PMS

86
The Consultation Class

87
 Key points
 A model is an abstract view of a system that ignores 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.
 Use case diagrams and sequence diagrams are used to describe
the interactions between users and systems in the system being
designed. 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.

88
 Generalization
 Generalization is an everyday technique that we use to
manage complexity.

 Rather than learn 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.

89
 In modeling systems, it is often useful to examine the
classes in a system to see if there is scope for
generalization. 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.
 In a generalization, the attributes and operations
associated with higher-level classes are also associated
with the lower-level classes.
 The lower-level classes are subclasses inherit the
attributes and operations from their superclasses.
These lower-level classes then add more specific
attributes and operations.
90
A Generalization Hierarchy

91
A Generalization Hierarchy with
added detail

92
 Behavioral models
 Behavioral models are models of the dynamic behavior
of a 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:
 Data Some data arrives that has to be processed by the
system.
 Events Some event happens that triggers system
processing. Events may have associated data, although
this is not always the case.

93
 Data-driven modeling
 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.
 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.

94
 Event-driven modeling
 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.
 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.

95
 State machine models
 These model the behavior of the system in response to
external and internal events.
 They show the system’s responses to stimuli so are
often used for modeling real-time systems.
 State machine models show system states as nodes and
events as arcs between these nodes. When an event
occurs, the system moves from one state to another.
 Statecharts are an integral part of the UML and are
used to represent state machine models.

96
State diagram of a microwave oven

97
States and stimuli for the
microwave oven (a)

98
States and stimuli for the
microwave oven (b)

99
Microwave oven operation

100
 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.
101
 Model driven architecture
 Model-driven architecture (MDA) was the precursor of
more general model-driven engineering
 MDA is a model-focused approach to software design
and implementation that uses a subset of UML models
to describe a system.
 Models at different 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.

102
 Types of model
 A computation independent model (CIM)
 These model the important domain abstractions used in
a system. CIMs are sometimes called domain models.
 A platform independent model (PIM)
 These model 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.
 Platform specific models (PSM)
 These 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.
103
 Key points
 Behavioral models are used to describe the dynamic
behavior of an executing system. This behavior 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.

104