Chapter 6View Alignment Techniques and Method Customization

(Part I)

Object-Oriented TechnologyFrom Diagram to Code with Visual Paradigm for

UML

Curtis H.K. Tsang, Clarence S.W. Lau and Y.K. Leung

McGraw-Hill Education (Asia), 2005Dr. Hussein Al-Zoubi

2

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.

3

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.

4

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.

5

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.

6

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

7

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

8

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.

9

Hurdles in Applying the Object- oriented Approach (cont’d)

Use Case Diagram

Class Diagram

Component Diagram

Object Diagram

Activity DiagramState Diagram

Deployment Diagram

CollaborationDiagram

Sequence Diagram

Models

10

Hurdles in Applying the Object- oriented 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?

11

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.

12

Unified Process

The iterations are divided into four phases: inception, elaboration, construction and transition

13

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.

14

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).

15

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.

16

Techniques (cont’d)

Use CaseModel

Requirements

Analysis

Design

Implementation

Test

Each workflow is associatedwith one or more models.

AnalysisModel

DesignModel

DeploymentModel

ImplementationModel

Test Model

17

Techniques (cont’d)

Use CaseModel

AnalysisModel

ImplementationModel

Test Model

DeploymentModel

DesignModel

Sequence Diagram

Use Case Diagram

State Diagram

Activity Diagram

Collaboration Diagram

ComponentDiagram

DeploymentDiagram

ClassDiagram

ObjectDiagram

18

Techniques (cont’d)

Use CaseModel

AnalysisModel

ImplementationModel

Test Model

DeploymentModel

DesignModel

Object DiagramClass Diagram

Sequence Diagram

Collaboration Diagram

State Diagram

Activity Diagram

Use CaseDiagram

ComponentDiagram

DeploymentDiagram

19

Techniques (cont’d)

ClassDiagram

ObjectDiagram

Use CaseDiagramUse Case

Model

AnalysisModel

ImplementationModel

Test Model

DeploymentModel

DesignModel

StateDiagram

ActivityDiagram

Sequence Diagram

Collaboration Diagram

Component Diagram

Deployment Diagram

20

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.

21

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.

22

Traceability and Models Consistency (cont’d)

Analysis Model Design Model

<<trace>> <<trace>>

Use Case Use Case

use case realizations

23

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.