Design

What Is the UML?

• The Unified Modeling Language (UML) is a
language for
• Specifying
• Visualizing
• Constructing
• Documenting
the artifacts of a software-intensive system
The UML Provides Standardized Diagrams
 What Is a Process?
A process defines Who is doing What, When and
How to reach a certain goal. In software
engineering the goal is to build a software product
or to enhance an existing one

New or changed Software Engineering New or changed

requirements Process system
 An Effective Process ...
• Provides guidelines for efficient development of
quality software
• Reduces risk and increases predictability
• Captures and presents best practices
– Learn from other’s experiences
– Mentor on your desktop
– Extension of training material
• Promotes common vision and culture
• Provides roadmap for applying tools
• Delivers information on-line, at your finger tips
Representing Architecture: The 4+1 View
Model
Business Process Models

A Comparison
 Selection of Appropriate Model
Prior to selection one must understand the strengths
and weaknesses of each of the models
 Waterfall Model
• Cascading processes, Plan driven model
System’s services, constraints and goals established

Allocate requirements to hardware/software

Design is realized as programs

or program units

Verifying each unit meets specification

Longest lifecycle phase, correcting errors uncovered during

testing, improving or enhancing system functioning
 Software Process Models: ..Waterfall
Advantages:
– Organized approach, provides robust separation of
phases
– Reflects common engineering practice
Disadvantages:
– Doesn’t cope well with changes required by the client
– Development teams might wait for each other
– A working version of the product is available only late
Applicability:
– When requirements are well known and few changes
are likely to be needed
– Can be used also for parts of larger software systems

12
 Software Process Models:
..Evolutionary Development

13
 Software Process Models:
..Evolutionary Development
Advantages:
– Deals constantly with changes
– Provides quickly an initial version of the system
– Involves all development teams
Disadvantages:
– Quick fixes may be involved
– “Invisible” process, not well-supported by
documentation
– The system’s structure can be corrupted by continuous
change

14
 Software Process Models:
…Evolutionary Development
Disadvantages [cont’d]:
– Special tools and techniques may be necessary
– The client may have the impression the first version is
very close to the final product and thus be less patient
Applicability:
– When requirements are not well understood
– When the client and the developer agree on a “rapid
prototype” that will be thrown away
– Good for small and medium-sized software systems

15
 Software Process Models:
..Component-based Software Engineering

16
 Software Process Models:
..Component-based Software Engineering
Advantages:
– Reduces considerably the software to be developed
“in-house”
– Allows faster delivery
– In principle, more reliable systems, due to using
previously tested components

17
 Software Process Models:
…Component-based Software Engineering
Disadvantages:
– Compromises in requirements are needed
– Less control over the system’s evolution
Applicability:
– When there is a pool of existing components that could
satisfy the requirements of the new product
– Emerging trend: integration of web services from a
range of suppliers

18
Software Process Models:
..Incremental
 Software Process Models:
..Incremental
Advantages:
– Provides better support for process iteration
– Reduces rework in the software construction process
– Some decisions on requirements may be delayed
– Allows early delivery of parts of the system
– Supports easier integration of sub-systems
– Lower risk of project failure
– Delivery priorities can be more easily set
 Software Process Models:
...Incremental
Disadvantages:
– Increments need be relatively small
– Mapping requirements to increments may not be easy
– Common software facilities may be difficult to identify
Applicability:
– When it is possible to deliver the system “part-by-part”

21
 Choosing a Right Model
Step 1: Learn About SDLC models
make effective comparison all models, their usages,
advantages and disadvantages, selection based on
experience and familiarity with model
Step2: Assess the needs of stakeholders
study the business domain, user requirements, business
priorities, technology constraints
Step3: Define criteria
 Defining Criteria
• Is the SDLC appropriate for the size of our team and
their skills?
• Is the SDLC appropriate with the selected technology
we use for implementing the solution?
• Is the SDLC appropriate with client and stakeholders
need and priorities?
• Is the SDLC appropriate for the geographical
situation (co-located or geographically dispersed)?
 Defining Criteria
• Is the SDLC appropriate for the size and complexity
of our software?
• Is the SDLC appropriate for the type of projects we
do?
• Is the SDLC appropriate for our engineering
capability?
 Model Selection

Evolutionary Iterative and Agile

Factors Waterfall V-Shaped Spiral
Prototyping Incremental Methodologies

Unclear User
Poor Poor Good Excellent Good Excellent
Requirement
Unfamiliar
Poor Poor Excellent Excellent Good Poor
Technology

Complex System Good Good Excellent Excellent Good Poor

Reliable system Good Good Poor Excellent Good Good

Short Time
Poor Poor Good Excellent Excellent Excellent
Schedule
Strong Project
Excellent Excellent Excellent Excellent Excellent Excellent
Management
 Model Selection
Agile
Evolutionary Iterative and
Factors Waterfall V-Shaped Spiral Methodolog
Prototyping Incremental
ies

Cost limitation Poor Poor Poor Poor Excellent Excellent

Visibility of
Good Good Excellent Excellent Good Excellent
Stakeholders

Skills limitation Good Good Poor Poor Good Poor

Documentations Excellent Excellent Good Good Excellent Poor

Component
Excellent Excellent Poor Poor Excellent Poor
reusability
 Process Modeling Guidelines
G1: Use as few elements in the model as possible
The size of the model has undesirable effects on
understand ability and likelihood of errors

G2: Minimize the routing paths per element

The higher the degree of an element in the process
model, i.e. the number of input and output arcs together, the
harder it becomes to understand the model

Reference: Seven Process Modeling Guidelines (7PMG), J. Mendling , H.A. Reijers, W.M.P. van der Aalst
 Process Modeling Guidelines
G3: Use one start and one end event
Most work-flow engines require a single start and end node
. Moreover, models satisfying this requirement are easier to
understand and analyse

G4: Model as structured as possible

Reference: Seven Process Modeling Guidelines (7PMG), J. Mendling , H.A. Reijers, W.M.P. van der Aalst
 Process Modeling Guidelines
G5: Use verb-object activity labels
like “Inform complainant”, as significantly less
ambiguous and more useful than action-noun labels e.g.
“Complaint analysis”

G6: Decompose the model if it has more than 50

elements
large models should be split up into smaller models

Reference: Seven Process Modeling Guidelines (7PMG), J. Mendling , H.A. Reijers, W.M.P. van der Aalst
 Which model to choose?
• A system to control anti-lock braking in a car
• A virtual reality system to support software
maintenance
• A university accounting system that replaces an
existing system
• An interactive system that allows railway
passengers to find train times from terminals
installed in stations.