Transcript Object-Oriented Technology

Chapter 6
View Alignment Techniques
and Method Customization
(Part I)
Object-Oriented Technology
From Diagram to Code with Visual Paradigm for UML
Curtis H.K. Tsang, Clarence S.W. Lau and Y.K. Leung
McGraw-Hill Education (Asia), 2005
Objectives

After you have read this chapter, you should be able
to
 Appreciate the benefits of using a method for
software development.
 Understand the limitations of current software
development methods.
 Understand the framework of View Alignment
Techniques.
 Apply the View Alignment Techniques to customize
and create a method.
 Use the Activity Analysis Approach effectively for
developing workflow-oriented and activity
intensive software systems.
2
What Is Software Development
Method?



A software development method consists of a
complete set of activities needed to transform users’
requirements into a consistent set of artifacts that
represent a software product.
Typically, a software development method specifies a
series of stages that encompass requirements
gathering, design, development, testing, delivery,
maintenance and enhancement of a system, and
helps the developer build software systems in a
reliable and consistent way.
In general, software development methods allow the
building of models from model elements that
constitute the fundamental concepts for representing
systems or phenomena.
3
Components of Software
Development Methods (cont’d)


Representation. A set of recommended
representation (notation), e.g., the Unified Modeling
Language (UML)) consisting of one or more forms of
a notation that can be used to model both the
structure of the initial problem (requirements) and
the intended solution, using one or more viewpoints
(models) and different levels of abstraction.
Process. It provides a framework from which a
comprehensive plan for software development should
be established. This development plan consists of a
specific ordered set of tasks aimed at producing
software solutions, e.g. Unified Process.
4
Components of Software
Development Methods (cont’d)

Techniques. They are heuristics, guidelines and
procedures that help designers develop the software
development plan for their project. In other words,
they help customize the process framework for the
system being developed, such as defining the order
of tasks to be carried out within the process,
selecting the models and their perspective to be
focused at the optimum level of abstraction.
5
Components of Software
Development Methods

A software development method primarily comprises
three components:



a process,
a representation system or a modeling notation, and
techniques, heuristics, steps or procedures
6
Why Traditional Software
Methods Didn’t Work Miracles?



There is no universal method that can be
readily applied to all problems in any
circumstances without the need for
customization.
Demarco points out that to ensure success
the project team should tailor the method to
needs of the individual project rather than
attempt force-fitting the project into the
Methodology.
Spolsky’s story
7
Hurdles in Applying the
Object-oriented Approach


The UML provides an extremely rich set of
notations for representing systems. Booch
suggests that 80% of software projects use
only about 20% of the UML notation.
To the designer, it would be rather difficult to
decide which subset of UML notation should
be used for the project at hand.
8
Hurdles in Applying the Objectoriented Approach (cont’d)
Class Diagram
Object Diagram
Use Case Diagram
Component Diagram
Sequence Diagram
Models
Deployment Diagram
Collaboration
Diagram
Activity Diagram
State Diagram
9
Hurdles in Applying the Objectoriented Approach (cont’d)

Designers are often confronted with many
questions throughout the development life
cycle, and the following are some typical ones:




What models are required to represent the system?
How do I apply the selected models to perform
the development work?
Which model should I use first, and which model(s)
should follow next?
How can I ensure that the models of the system
are consistent?
10
Current Object-oriented
Development Approaches


The Unified Modeling Language is now the de
facto standard graphical language for
representing systems in the software industry.
The Unified Process is a widely used software
development process. In the Unified Process,
a system is built incrementally through a
number of iterations in which the designer
may perform requirements capturing, analysis,
design, implementation and testing tasks.
11
Unified Process

The iterations are divided into four
phases: inception, elaboration,
construction and transition
12
Unified Process (cont’d)

Each phase has a different focus:




Inception Phase. This phase focuses on establishing the
business case, defining the scope of the system and
estimating the amount of resources including time required
to complete the project.
Elaboration Phase. In this phase, the core architecture of the
system is developed incrementally. Risks are resolved
according to priorities, and the scope of the system is
refined.
Construction Phase. In this phase, low risk elements of the
system are implemented and tested incrementally. The
system is prepared for deployment.
Transition Phase. Beta release of the system is deployed to
the end users. Bug fixes and other tasks such as refining the
system are performed.
13
Unified Process (cont’d)

The work activities of the Unified Process in the same
subject area are categorized as a workflow (some
authors call it a discipline).
14
Techniques




As mentioned earlier, the techniques part is the most difficult
component of the entire software development method.
Jacobson considers that teamwork should be the thing that glues
the representation and process components together but offers
very little details on how we can customize or create a method
to solve our problem.
Nonetheless, he does provide some hints on which model(s)
should be used in each workflow.
Each of these models associated with a workflow is elaborated
by a sub-figure indicating the types of diagrams likely to be used.
15
Techniques (cont’d)
Requirements
Analysis
Use Case
Model
Analysis
Model
Design
Model
Implementation
Deployment
Model
Implementation
Model
Design
Test Model
Test
Each workflow is associated
with one or more models.
16
Techniques (cont’d)
Use Case Diagram
Use Case
Model
Class
Diagram
Object
Diagram
Sequence Diagram
Analysis
Model
Collaboration Diagram
Design
Model
State Diagram
Implementation
Model
Activity Diagram
Deployment
Model
Test Model
Component
Diagram
Deployment
Diagram
17
Techniques (cont’d)
Use Case
Diagram
Class Diagram
Object Diagram
Use Case
Model
Sequence Diagram
Analysis
Model
Design
Model
Collaboration Diagram
State Diagram
Implementation
Model
Activity Diagram
Deployment
Model
Test Model
Component
Diagram
Deployment
Diagram
18
Techniques (cont’d)
Use Case
Model
Use Case
Diagram
Class
Diagram
Object
Diagram
Sequence Diagram
Analysis
Model
Collaboration Diagram
Design
Model
State
Diagram
Implementation
Model
Activity
Diagram
Component Diagram
Deployment
Model
Deployment Diagram
Test Model
19
Techniques (cont’d)


Despite these hints, little clue is provided on the
selection of the right model (UML diagram) to start
with and the order in which these models (UML
diagrams) should be developed.
Still don’t know how to develop the required UML
models.
20
Traceability and Models
Consistency



Another frequently asked question in developing
models is “how do we ensure the models we have
created are consistent?”
<<trace>> is one of the often used stereotypes in
Rambaugh, Booch and Jacobson’s publication entitled
The Unified Software Development Process.
Jacobson emphasizes many times in this book on the
traceability between a model and its subsequent
realization models, but there is little hint as to how
we can actually ensure traceability among the models.
21
Traceability and Models
Consistency (cont’d)
use case realizations
Analysis Model
<<trace>>
Design Model
<<trace>>
Use Case
Use Case
22
Need for Method Customization


There is no universally applicable design method.
There are many different factors that would affect
our design decisions:




the competence and skill levels and the prior experience of
the software development team
different application domains also require different focuses
or impose special constraints
lifecycle factors: time to market, expected life span, planned
future releases
technological factors:programming languages, development
tools, databases, middleware, communication, distribution,
etc.
23