ENHANCEMENT OF RAPID OBJECT PROCESS FOR EMBEDDED SYSTEM
(ROPES) TO SUPPORT PATTERN ORIENTED DEVELOPMENT
MOHD ADHAM BIN ISA
A project report submitted in partial fulfilment of the
requirements for the award of the degree of
Master of Science (Computer Science)
Faculty of Computer Science and Information Systems
University of Technology Malaysia
OCTOBER 2009
ACKNOWLEDGEMENT
In preparing this project report, I wish to express my sincere appreciation to my
supervisor Dr. Dayang Norhayati Binti Abang Jawawi for the guidance, advice and
encouragement during my studying. The support and suggestion that Dr. Dayang gives
inspired me to going through in this project.
I would like to thanks to Software Engineering Lab members in Universiti
Teknologi Malaysia for their helps and supports.
Finally my special thanks to my parent for their love and care especially my
beloved wife Mastura Md. Hassan and my beautiful daughter Elya Darwisyah for their
support and cheering me up at those difficult time.
ABSTRACT
The complexity of Embedded Real Time (ERT) software development represents
a challenging of analysing, designing and building ERT software. From this standpoint,
the complexity of ERT software development means a challenging to adapt all ERT
software requirements such as timing and resource constraints into its software lifecycle.
Against these claims, a wide range of software development methodologies have been
devised such as patterns. Patterns codify an effective solution for recurring problems that
allows software engineers to reuse. By applying patterns into ERT software
development, the complexity of ERT software development can be decreased and at the
same time promote high degree of reuse through software patterns. In this project, the
integrated Rapid Object Process for Embedded System (ROPES) and Pattern-oriented
Analysis and Design (POAD) methodology has been developed to represent a promising
way to build ERT software with software patterns reuse. To make the integrated
methodology more compelling and confirm the rules of patterns oriented modelling, the
integrated ROPES and POAD metamodel has been developed. The aim of the integrated
metamodel is to conform the correctness of the integrated methodology modelling rules
in term of pattern uses. In addition, the integrated ROPES and POAD software process
also has been built as the continuity to describe concrete integrated software
development process. To verify the correctness of the integrated metamodel, the
mapping process of Meta-Object Facility (MOF) using graph theory has been conducted.
The results of implementing the integrated metamodel and software process for
Feedback Control System (FCS) shows that the complexity of ERT software
development has been decreased besides promote software patterns reuse.
ABSTRAK
Pembangunan perisian Sistem Masa Nyata Terbenam (ERT) yang kompleks
menunjukkan keunikan menganalisa, merekabentuk dan membina perisian ERT.
Daripada ciri-ciri ini, pembangunan perisian ERT yang kompleks bermakna cabaran
untuk merealisasikan semua keperluan perisian ERT seperti masa and kekekangan
sumber keatas proses kitaran pembangunan perisiannya. Berpandukan kenyataan
tersebut, pelbagai metodologi pembangunan perisian telah diubah atau dinaiktaraf
sebagai contoh adalah corak. Corak memberikan penyelesaian yang efektif bagi
penyelesain masalah yang berulang serta membolehkan jurutera perisian menggunakan
semula kaedah ini bagi menyelesaikan masalah lain. Dengan mengaplikasikan
penggunaan corak keatas pembangunan perisian ERT, kerumitan prosesnya dapat
dikurangkan selain menggalakkan penggunaan semula corak. Di dalam projek ini,
gabungan Rapid Object Process for Embedded System (ROPES) dan Pattern-oriented
Analysis and Design (POAD) metodologi telah dibangunkan. Untuk menjadikan
gabungan kedua-dua metodologi ini lebih kukuh dan mengikut peraturan pembangunan
perisian berasaskan corak, gabungan metamodel telah dihasilkan. Matlamat utamanya
adalah untuk memastikan rekabentuk perisian ERT mengikut corak. Selain itu,
pembangunan proses perisian juga telah dibangunkan. Untuk memastikan gabungan
metamodel tepat, proses teori graf bersama Meta-Object Facility (MOF) telah dilakukan.
Hasil keputusan keatas pelaksanaan gabungan metamodel dan proses pembangunan
perisian menunjukan kerumitan pembangunan perisian ERT telah dikurangkan dan
penggunaan semula corak keatas rekabentuk perisian telah ditingkatkan.
TABLE OF CONTENTS
CHAPTER
TITLE
PAGE
DECLARATION OF THESIS STATUS
SUPERVISOR DECLARATION
1
TITLE PAGE
i
STUDENT DECLARATION
ii
ACKNOWLEDGEMENT
iii
ABSTRACT
iv
TABLE OF CONTENT
vi
LIST OF TABLE
xi
LIST OF FIGURE
xii
LIST OF ABBREVATION
xv
LIST OF APPENDIX
xvi
PROJECT OVERVIEW
1.1
Introduction
1
1.2
Problem Background
4
1.3
Problem Statement
6
1.4
Project Aim
7
1.5
Objectives
7
1.6
Scopes
8
1.7
Significance of the project
8
1.8
2
Thesis Outline
9
LITERATURE REVIEW
2.1
Introduction
10
2.2
Component Based Software Engineering (CBSE)
11
2.2.1 Software Component Model
11
2.3
Component Oriented Development
13
2.4
Pattern Oriented Development
16
2.4.1 Software Pattern
17
2.4.1.1
Analysis Pattern
18
2.4.1.2
Design Pattern
19
2.4.1.3
Programming Pattern
19
2.4.2 Pattern Oriented Methodology
2.4.2.1
Pattern Oriented Analysis and
20
21
Design (POAD)
2.4.2.2
Pattern Driven Modelling and
25
Analysis (PDMA)
2.5
2.6
2.4.2.3
Metamodel POAD+PECOS
26
2.4.2.4
Design Pattern + CBSD
28
2.4.2.5
Comparative Evaluation
29
Embedded Real Time (ERT) System
30
2.5.1 ERT System Methodology
31
2.5.1.1
ROPES
32
2.5.1.2
OCTOPUS/UML
34
2.5.1.3
COMET
36
2.5.1.4
MARMOT
38
2.5.1.5
DESS
40
2.5.1.6
Comparative Evaluation
43
Discussion
45
3
4
RESEARCH METHODOLOGY
3.1
Introduction
47
3.2
The Software Engineering Research
48
3.3
Research Framework and Process
49
3.3.1 Problem Formulation
51
3.3.2 Literature Review
51
3.3.3 Integrated Metamodel POAD and ROPES
52
3.3.4 Define and Design Software Process
53
3.4
Feedback Control System (FCS)
54
3.5
Summary
56
INTEGRATED ROPES AND POAD METAMODEL
4.1
Introduction
57
4.2
Metamodel
58
4.2.1 UML Specification
59
4.3
POAD Metamodel
60
4.4
ROPES Metamodel
63
4.5
Integrated POAD and ROPES Metamodel
66
4.5.1 Mapping POAD to ROPES
66
4.5.1.1
Mapping POAD Metamodel to
67
ROPES Metamodel
4.5.1.2
Validation of the Integrated
72
ROPES and POAD Metamodel
4.5.1.3
Mapping ROPES Process to
77
POAD Process
4.5.1.4
Initial Result of POAD + ROPES
79
Development Process
4.5.2 Summary
5
THE INTEGRATED ROPES AND POAD
SOFTWARE PROCESS
82
5.1
Introduction
84
5.2
Software Process Engineering Process (SPEM)
85
5.3
The Process Model
86
5.3.1 Method Content
88
5.3.1.1
Role Definition
89
5.3.1.2
Work Product Definition
91
5.3.1.3
Task Definition
93
5.3.2 Process Content
94
5.3.2.1
Analysis Process
97
5.3.2.2
Design Process
102
5.4
Discussion On The Proposed Software Process
107
5.5
Comparative Evaluation on Pattern Oriented
108
Development
6
ANALYSIS AND DESIGN OF FEEDBACK
CONTROL SYSTEM
6.1
Introduction
111
6.2
Analysis Phase
111
6.2.1 Requirement Analysis
112
6.3
6.2.1.1
Main Use Case
113
6.2.1.2
Use Case Behaviour
114
6.2.1.3
Use Case Text
114
6.2.1.4
Sequence Diagram
117
6.2.1.5
Statechart
118
6.2.1.6
Pattern Selection
120
6.2.2 System Analysis
122
6.2.3 Object Analysis
123
6.2.3.1
Object Structural
124
6.2.3.2
Object Behaviour
126
6.2.4 Analysis Result Summary
128
Design Phase
129
6.3.1 Architectural Design
129
6.3.1.1
Component View
130
6.3.1.2
Deployment View
131
6.3.1.3
Pattern Level Diagram
132
6.3.1.4
Pattern Level with Interface
134
Diagram
6.3.2 Mechanistic Design
6.4
7
6.3.2.1
Design Pattern Internal Class
135
6.3.2.2
Refined Class Diagram
138
6.3.2.3
Sequence Diagram
141
6.3.2.4
Statechart Diagram
142
6.3.3 Detailed Design
145
6.3.4 Design Result Summary
146
Summary and Discussion
147
DISCUSSION AND FUTURE WORK
7.1
Introduction
149
7.2
Summary
150
7.3
Project Contribution
151
7.4
Future Work
152
REFERENCES
Appendix A
135
154
158-176
LIST OF TABLES
TABLE NO.
TITLE
PAGE
2.1
Comparative of Pattern-Oriented Methodology
29
2.2
Comparative Evaluation of ERT System
44
Development Methodology
3.1
Summary of research process
54
4.1
Metamodelling four-layer architecture
59
4.2
POAD Artefacts produced vs UML Meta model
61
4.3
Artefacts produced in ROPES Methodology
64
4.4
Mapping POAD to ROPES Metamodel
68
4.5
ROPES and POAD Development Phase Mapping
78
5.1
Comparative Evaluation on Pattern Oriented
109
Development Methodology
6.1
Pattern Selection Analysis
121
6.2
Subsystem Tasks
123
6.3
FCS Transaction Objects
124
6.4
Subsystem Objects
125
6.5
Patterns Package
132
6.6
Pattern Internal Classes
136
6.7
Refined FCS Class Diagrams Summary
139
6.8
Statechart Diagram
143
LIST OF FIGURES
FIGURE NO.
TITLE
PAGE
2.1
The CBSD Process (Sommerville, 2004)
14
2.2
V development process (Crnkovic, 2003)
15
2.3
Y development process (Fernando, 2005)
16
2.4
POAD Development Phase (Yacoub and Ammar,
22
2004)
2.5
Process in Analysis Phase (Yacoub and Ammar,
22
2004)
2.6
Process in Design Phase (Yacoub and Ammar, 2004)
23
2.7
Process in Design Refinement Phase (Yacoub and
24
Ammar, 2004)
2.8
Software Process for Integrated POAD and PECOS
27
(Jawawi, 2005)
2.9
CBSD Process Using Design Pattern (Yau and Dong,
28
2000)
2.10
ROPES Development Phases (Douglass, 1999)
33
2.11
Octopus/UML System Development Pattern
35
2.12
COMET System Development (Gomaa, 2001)
37
2.13
MARMOT Development Process and Component
39
Meta model (Christian et. all., 2007)
2.14
DESS Workflow Vs (Stefan et. all., 2001)
41
2.15
Realization Workflow (Stefan et. al., 2001)
42
2.16
Validation and Verification Workflow (Stefan et. al.,
42
2001)
2.17
Requirement Management Workflow (Stefan et. al.,
43
2001)
3.1
Research Framework
50
3.2
Block diagram for feedback control system
55
4.1
POAD Meta model
62
4.2
Enhancement of POAD Meta model (Jawawi, 2006)
63
4.3
ROPES Meta model
65
4.4
ROPES + POAD Metamodel
71
4.5
MOF Graph
73
4.6
Graph for The integrated ROPES and POAD
74
metamodel
4.7
Equation (3) and (4) Mapping
77
4.8
ROPES + POAD Development Process
80
5.1
Process Model Framework
86
5.2
Details of Process Content and Method Content
88
Elements
5.3
Roles Definition for ROPES+POAD Process Model
90
5.4
Analysis Work Product Definition for
91
ROPES+POAD Process Model
5.5
Design Work Product Definition for ROPES+POAD
92
Process Model
5.6
Task Definition for ROPES+POAD Process Model
93
5.7
Process of Flow of the Integrated ROPES and POAD
96
Software Process
5.8
Analysis Process for ROPES+POAD Process Model
97
5.9
Requirement Analysis Task Use Step
98
5.10
Pattern Selection: Pattern Selection Process Step
99
5.11
System Analysis Task Use Step
100
5.12
Object Analysis Task Use Step
101
5.13
Design Process for ROPES+POAD Process Model
102
5.14
Architectural Design Task Use Step
103
5.15
Design Pattern Modification Process Flow
104
5.16
Mechanistic Design Task Use Step Process
105
5.17
Design Pattern Internal Class Process Flow
105
5.18
Detailed Design Task Use Step Process
106
6.1
FCS Use Case
113
6.2
UC-00
115
6.3
Configure Use Case Sequence Diagram
117
6.4
Error Calculation Statechart
119
6.5
Collect Data Statechart
120
6.6
FCS Subsystem Composition
122
6.7
Subsystem Diagram
126
6.8
FFStrategy Object Statechart
127
6.9
Component View in FCS
130
6.10
Deployment View of FCS
131
6.11
Pattern Level Diagram in ErrorCalculation
133
Subsystem
6.12
Pattern Level Diagram with Interface for
134
ErrorCalculation Subsystem
6.13
FCS Class Diagram with Patterns
137
6.14
FCS Refined Class Diagram
141
6.15
Error Calculation Sequence Diagram
142
6.16
Plant Class Statechart
144
6.17
Plant Statechart Simulation Result
145
LIST OF ABBREVIATIONS
CBSE
Component Based Software Engineering
CBSD
Component Based Software Development
COMET
Concurrent Object Modelling and Architectural Design Method
DESS
Software Development Process for Real Time Embedded Software
System
EJB
Enterprise Java Bean
ERT
Embedded Real Time
FCS
Feedback Control System
MARMOT
Method for Component-based Real Time Object Oriented
Development and Testing
MOF
Meta Object Facility
OOA
Object Oriented Analysis
OOD
Object Oriented Design
OCL
Object Constraint Language
OMG
Object Management Group
PDMA
Pattern Driven Modelling and Analysis
PECOS
Pervasive Component System
POAD
Pattern Oriented Analysis and Design
POSA
Pattern Oriented Software Architecture
ROPES
Rapid Object Process for Embedded System
SOF
Special Octopus Feature
SPEM
Software Process Engineering Modelling
UML
Unified Modelling Language
LIST OF APPENDIX
APPENDIX
A
TITLE
Analysis and Design of FCS
PAGE
158
CHAPTER 1
PROJECT OVERVIEW
1.1
Introduction
The necessity of the complex systems was felt with the demand from the large
scale company or requirement. For the last fifty years, software systems have become
more complex and larger. Following the traditional approaches which is developed a
system from scratch eventually resulted the problems like failure to meet customer
requirements, budget constraint and extend deadline. Then, in order to overcome those
problems, it was realized that the software reusability is the essential factors that
contributing of minimizing the existing problems. Software reusability allows parts of
software component to be renewed or replaced by existing components. Thus, software
reusability helps software developers to concentrate on adding more complex system
functionalities rather than focusing on developing basic components. Here the concept
of software reusability was constructed which eventually creating the software
development methodology called Component Based Software Engineering (CBSE).
Component Based Software Engineering (CBSE) is the methodology that
ensuring the improvement of the software quality, increasing software productivity,
effective management for complex software and wider range of usability (Crnkovic,
2003). CBSE main principles are building the systems from the existing and selecting
components within the suitable software architecture. The software components are
composed together with the specific glue code and composition technique. Szyperski
(2002) defines a component is a unit of composition with specified interfaces and
explicit context dependencies only. A software component can be deployed
independently and is subjected to compose by a third party. Thus, a component must
have interface and hiding information that enable to be composed each other. JavaBeans,
EJB, COM, Koala, PECOS (Nierstransz et al., 2002) and ADLs (Clements, 1996) are the
examples of component technologies. In addition, a component is designed to solve
particular problems and resembles like a pattern that forces the developers to use
predefined process or design to be used in software development process.
A pattern was introduced into the software development process as a means of
manipulating hard-earned experience from the previous problems (Kotonya Hutchinson,
2005). Yacoub and Ammar (2004) defines a pattern as problems that frequently occurs
in software development and then defines the explicit solution that it can be reused while
Fernandez and Yuan (2000) defines a pattern is a recurring combination of meaningful
units that occur in some context. Then, a pattern is enabling software engineer to capture
the software requirements from early phases. Patterns can be divided into analysis
pattern, design pattern and programming pattern. Analysis pattern occurs at the early
phases and known as a group of concepts that representing a common construction in
business modelling (Fowler, 1997).
Design pattern is more matured than analysis
pattern (Sesera, 2000). Design pattern is a design solution to a frequently recurring
design problem in a given application domain (Yacoub et al., 2000).
There are many software development methodology based on patterns were
introduced such as POAD, PDMA, and Design pattern + CBSD. These methodologies
use software patterns as its core specification. POAD is one of the methodologies that
develop a system from the analysis phases until design phases by using software
patterns. Thus, POAD is a structural approach of software development rather than
behaviour approach (Yacoub and Ammar, 2004). In addition, POAD methodology leads
into the bridging the gaps between software abstraction into software designs by
combining software patterns artefacts into pattern-oriented software development. By
the existing of various software patterns, there is a growing demand of searching a new
and cost effective of software development paradigm. Then, one of the most promising
solutions today is the pattern-oriented development.
A pattern-oriented development is an approach to deal with the complexity of
software development. The complexity of the software development usually comes from
the extra requirements such as timing and resource constraints. By applying patternoriented development in the software development process, the skeleton of the software
can be perceived up-front by using knowledge of previously patterns. Moreover, it will
give the traceability of software artefacts from the analysis to design. Moreover, there
are a few advantages of using pattern in software development. The advantages are 1)
the reuse experienced, 2)the development of standards types of solution, and 3)a
normalized mechanism for abstracting form multiple example and method for
categorizing problems (Kotonya and Hutchinson, 2005). The effectiveness of
minimizing the complexity of software development can be realized by composing
software patterns into the software development process.
The complexity of software development process is known as the most critical
stage in the process of building software. Indeed, this is due to the complexity of the
embedded real-time software requirements as a solution for ever more demanding
applications required. ERT software requirements such as timing and resource
constraints represent a promising point of the complexity of ERT software product. Most
of the embedded systems are characterized as real time systems, which consist of real
time properties such as response time and worse case execution time (Crnkovic, 2005).
Consequently, the complexity of the demanding ERT requirements will be likely is
resulted the complexity of ERT software development.
The motivation of using software patterns in ERT software developments is
twofold. Firstly, despite ERT software are being touted as a complex software due to its
requirements, the most compelling form of ERT software would be to show how
adopting software patterns can decrease the complexity of ERT software development to
some standard of software process. This is clearly the major issue which this project
seeks to address. Secondly, because of the implementation of software patterns can
decrease the complexity of ERT software development to some degree that will have the
major impact of the degree reuse of software patterns. To some extent, the high degree
reuse of software patterns will decrease the complexity of the ERT software
development. Moreover, this is envisioned that CBSE will be the suitable solution to
inspire software reuse into ERT system with consideration of reusable, interoperable, up
gradable and reliable features. Thus, patterns are promoting the precise planning and
systematic software development process by using software pattern into ERT system
development
1.2
Problem Background
Nowadays, the use of software in the different domains is highly demanded such
as web application, windows environment as well as embedded real time system (ERT).
ERT system is a system that combines both hardware and software. The hardware
component of the system tries to persuade the timing constraints while software reduces
the overall cost and design flexibility (Jawawi, 2003). The interoperating of those
elements affects the complexity of the software development. ERT software
developments are crucial since the combination both hardware and software can lead
into the complexity of the process. All of this events must have a systematic process in
order to reduce the time and cost of development.
The design pattern is the defined solution of the hard-earned experience from the
previous software development (Kotonya and Hutchinson, 2005). Thus, the component
based is mechanism of software development which are the component is composed
together in order to build the real time system (Zhang and Yunsheng, 2007). The uses of
pattern and component together could reduce the complexity of the software process.
This is because of the use of pattern for the whole process glued together with the
component could reduce the time and cost of software development.
There a several methodologies that have been introduced focusing on component
based and pattern in the software developments. Pattern oriented analysis and design
(POAD) is a methodology that constraint on the uses of components and patterns from
the analysis stages until the design (Yacoub and Ammar, 2004). However, this
methodology only addresses to the general domain and does not specific for the ERT
system. Rapid object-oriented process for embedded system (ROPES) focusing on the
ERT software developments and capturing both system structural and behavioural
elements (Douglass, 1999). However, ROPES does not address the use of patterns
systematically in software development process. The patterns are occurs only at the
design stages as well as does not have the systematic approaches in term of selecting and
adopting the patterns. By considering the advantages and disadvantages of both
methodologies, the combination of POAD and ROPES that focuses on ERT software
development could reduce the complexity of ERT software development and at the same
time, can ensure the high degree reuse of software patterns.
1.3
Problem Statement
POAD methodology defined the process of analysis and design by using the
selected pattern and consistently defined the pattern for the whole process. ROPES
methodology defined the complex step of software development for ERT but there are
no systematic approaches of using the pattern for each process. To promote the
relevance of pattern-oriented for analysis and design level for the ERT domain, the
consideration falls into ROPES and POAD methodologies. Instead of developing the
new methodologies from the scratch, the hybrid methodologies for ROPES and POAD
can ensure the use of pattern subject to the ERT domain. Therefore, this project will
define the Metamodel and software process for the integrated ROPES and POAD. An
integrated Metamodel for both methodologies represents the abstractions and semantics
in system modelling in order to apply the use of patterns in ERT software development
process and then constructed it in software process in order to get well-defined software
development process. However, there are some problems need to be considered before
the integrated POAD and ROPES metamodel can be realized. The problem arises are
mapping process between both models, defining new development process for integrated
metamodel and selecting a tool for supporting the integrated metamodel. All of this
problems need to be solved in order to get suitable integrated metamodel and software
process.
Therefore, this study proposes the integrated ROPES and POAD methodology to
enable pattern oriented development for ERT domain. Hence, it may decrease the
complexity of ERT software development and promote high degree of reuse in software
patterns.
1.4
Project Aim
The aim of the project is to integrate POAD and ROPES methodologies. The
motivation is to propose the use of patterns by using POAD methodology into the ERT
software development in order to discover the weaknesses of the ROPES methodology.
Indeed, ROPES weaknesses compromise non-systematic use of patterns in its software
development lifecycle. Therefore, the integrated ROPES and POAD metamodel is
proposed and consequently defines the software process for the integrated metamodel.
To show the applicability of the proposed integrated methodology, the implementation
of analysis and design into selected case study of small scale ERT system will be
implemented by using selected modelling tool.
1.5
Objectives
The objectives of the study are:
i.
To study and propose the metamodel for integrated POAD and
ROPES methodologies.
ii. To define the software process for integrated POAD and ROPES
Metamodel using Software Process Engineering Metamodel
(SPEM).
iii. To demonstrate the applicability of the proposed process by using the
I-Logix Rhapsody tool into selected case study.
1.6
Scopes
The scopes of the study are:
i. The analysis and design of Pattern oriented analysis and design
(POAD) methodology.
ii. The analysis and design of Rapid Oriented Process for Embedded
System (ROPES) methodology will only consider to demonstrates the
pattern level analysis and modelling into the case study.
iii. The implementation only for small scale of embedded real time
(ERT) system.
iv. The I-Logix Rhapsody tool is selected to support the integrated
POAD and ROPES metamodel realization because I-Logix Rhapsody
tool support UML 2.0. Focusing on application engineering and assume
the components are already exists.
1.7
Significance of the project
The significance of this project is to promote the software pattern reuse in ERT
software development. The study concentrates on a deep understanding of POAD and
ROPES methodologies. Based on that knowledge, the integrated Metamodel will be
introduced that supports the use of pattern on ROPES methodology. By providing the
proposed Metamodel, the software process can be defined. The advantages that can be
derived from this study are to motivate the use of pattern besides to enhance the ERT
software development process in order to maximize the quality and minimize the cost of
development.
1.8
Thesis Outline
Chapter 2 discusses the pattern-oriented development methodologies and ERT
software development methodologies. The relationship between those methodologies
with the uses of pattern and component in software development are reviewed.
In Chapter 3, the research methodology is conducted in achieving the project
objectives and scopes. One case study is used that involving small scale ERT system.
Chapter 4 defines the construction of the integated ROPES and POAD
metamodel and validation process of the proposed metamodel by using Meta-Object
Facility (MOF) and graph theory.
Chapter 5 describes the definition of the integrated ROPES and POAD software
process into the formal form to enrich the systematic way of system development
process.
Chapter 6 purposes are to prove the applicability of the integrated ROPES and
POAD metamodel and software process. The proven process of proposed software
process heavily relied on case study. The Feedback Control System was selected to be
used for the proven process.
CHAPTER 2
LITERATURE REVIEW
2.1
Introduction
This chapter describes the profound understanding of component-oriented
development, pattern-oriented development, pattern based methodology and ERT
system development. Thus, a previous related works on those issues need to be covered
to discover the advantages and disadvantages of using component-oriented pattern
approach. Then this chapter shows the implicit idea on how the current issues are
critically analysed.
2.2
Component Based Software Engineering (CBSE)
Component Based Software Engineering (CBSE) is a part of software
engineering and computer science field. The motivation of CBSE originate from various
computer discipline such as object-oriented programming, software reuse, software
architecture, modelling languages and formal specification (Crnkovic et al., 2002). The
main goals of CBSE are the development of softwares from the components and the
development of components as reusable artefacts, and maintenance and upgrading of
software by replacing their components (Heinenam and Councill, 2001).
Basically, CBSE can be grouped into two major categories: component
engineering and application engineering. Components engineering is the process of
creating the components for general purposes but for specific domain such as for real
time system domain. The created components can be used to deploy a number of real
time systems by assembling the components together. Application engineering is the
process of software development by reusing existing components by gluing together
with specific techniques. CBSE offers much more than structuring a comprehensive
reuse program and it’s provide both methodology and process for developing
components (Heinenam & Councill, 2001).
2.2.1
Software Component Model
Component based software development (CBSD) is an emerging issue in
software engineering area. CBSD is also known as application engineering and aims to
build a system from the pre-built unit system or components. This approach can ensure
the reusability of components hence the reduction of the cost and time of software
development. However, in order to maximize the components reusability, the
components itself must have a good reuse ability and composition techniques and it must
well defined at the early stage of software development.
The heart of the CBSD lies at the software components model (Wang and Lau,
2005; 2007). Software components model defines what components are, how they can
be constructed, why we use components and where to put the components in the system.
This entire question is essential since it must well define and aims to have clear view
about the use of components. JavaBeans, EJB, COM, Koala, PECOS (Nierstransz et al.,
2002) and ADLs (Clements, 1996) are the examples of software components model.
Although there are a numerous number of software components model today, but
generally it can be grouped into the two main categories (Garlan and Shaw, 1996) which
are 1) object as object oriented programming and 2) architecture units. Components
model in group (1) is directly executable in their respective programming languages
such as JavaBeans and EJB (DeMicheil et al., 2001) and components model in group (2)
is architecture specification and usually needs to be implemented with the suitable
programming language such as ADLs (Clements, 1996).
Software components model have their own architecture that give the details
description on what the components are. Lau and Wang (2005) defines software
component model should define 1) the syntax of the component which is description on
how they can be constructed and represented, 2) the semantics of components which is
what component are meant to be such as their name, interface code and relationship and
3) composition which is description on how they are composed in order to built s
system. All of this properties is essential before the components are implemented and
their properties must well define into the systematic documentation hence in can be
derived from the component catalogue.
2.3
Component-Oriented Development
Over the few decades, software systems are becoming more complex and larger
and were used for the industries practitioners. Therefore, besides building the system
from the scratch, there are exist attractive idea that rapidly assembling the pre define set
of components to build the system. However, this idea must endure the rigorous
discipline of software development as well as strict design documentation and design
rules. Thus, the essential acquisitions for this method is the used of software
components. A component is a software element that can be used by others software
elements, posses an official usage description and not tied with specific set of clients
(Meyer, 2003).
Component based software development (CBSD) is the process of defining,
implementing and integrating a set of components into systems (Sommerville, 2004).
CBSD can ensure the improvement of the quality, productivity and manageable for the
wider use of usability (Brown, 2000). Based on Sommerville (2004), CBSD have
essential properties which are 1) Independency of components 2) Standardization of
component 3) Use of middleware and 4) a process of development.
Components need to be absolutely independent so that any changes on the
systems like replacing or modifying the components does not affect the whole system.
Then, components need the standard architecture likes interface and port. This is
important in order components can successful integrating one another if there exists
different language on different components. On top of that, we need the middleware to
support the integration of the components. Finally, the proper and systematic process of
development is must so that it can support the definition of CBSD.
In general, we must define the CBSD life cycles and try to accumulate the
existing of CBSD life cycles that have been introduced by several authors. This is
essential since the component oriented development definition is closely related to the
CBSD life cycles. There are a few researchers strictly focusing on CBSD life cycles
such as (Sommerville, 2004), (Crnkovic et al., 2005), (Crnkovic, 2003), (Fernando,
2005).
Traditional life cycles provided sequential approaches and generally have six
main steps (Sommerville, 2004). Figure 2.1 show the CBSD process.
Outline System
Requirements
Compose
Components to
Create System
Identify Candidate
Components
Identify Candidate
Components
Modify Requirements
According to Discovered
Components
Architectural
Design
Figure 2.1: The CBSD Process (Sommerville, 2004)
Figure 2.1 show the CBSD process. It consists of six main steps from the
analysis states until the implementation states. Sommerville (2004) approaches give less
emphasis to the component development lifecycle. This approach negotiates the
requirements in the two lifecycle which are after outline the initial requirements and
before architectural design.
The other CBSD lifecycle was introduced by Crnkovic (2003). The V
development process is the sequential approaches. Figure 2.2 show the V-development
process.
Requirements
System Test
Operation and
Maintenance
System Development
System
Design
System Integration
Unit Design
Unit Test
Unit Implementation
Select
Test
Adapt
Find
Evaluate
Component Development
Figure 2.2: V development process (Crnkovic, 2003)
Figure 2.2 shows the V development process. It consist a several steps
and provides the details information at the design phases. The main different compare to
the Sommerville (2004) is V-Development more emphasis for the component
development lifecycle. Component development lifecycle was considered as different
process. The selection phase gets input from the separate system that usually finds and
evaluates the suitable components to be composed into the system.
Finally, Fernando (2005) has introduced the enhancement of the previous
CBSD process by providing the importance of reusability during component based
production. However, in order to invoke the reusability with the proper form, Fernando
(2005) has introduced a new phases which are domain engineering, frame working,
archiving and assembly. Domain engineering emphasis the initial step to identify
essential properties before the selection of components comes out. Frame working treat
as initial skeleton for application from the selection components. Archiving is mainly for
storing the components and assembly is the selection proper components from the
developers. Figure 2.3 show the Y-development.
System Analysis
Maintenance
Design
Deployment
Implementation
Testing
Assembly
Archiving
Select
Adaptation
Frame working
Catalog
Storage
Domain
Engineering
Figure 2.3: Y development process (Fernando, 2005)
2.4
Pattern-oriented development
A pattern-oriented is an approach to deal with the complexity of software
development. By using pattern-oriented in the software development, the skeleton of the
software can be perceived up-front by using knowledge of previously patterns (Rajasree
et al., 2003). Moreover, it will give the traceability of software artefacts from the
requirements to design. There are a few advantages of using pattern in software
development. The advantages are 1) the reuse experienced 2) the development of
standards types of solution 3) a normalized mechanism for abstracting forms multiple
example and method for categorizing problems (Kotonya and Hutchinson, 2005).
Creating an exhaustive set of patterns is the essential step for the software
development and it consists of proven development phases such as analysis, design,
testing and implementation. In addition, requirements engineering deals with the early
phases of software development namely requirements elicitation, modelling,
specification and validation (Finklestein, 2000). All of these properties give a systematic
derivation to the analysis phases. Then, the use of Pattern Oriented Software
Architecture (POSA) approaches can give an accurate solution at the design level
(Buschman et al., 1996).
2.4.1
Software Pattern
Software pattern is a method that documenting the proven solution from the
various problems at each development phases by the expert. The recurring problems
then are documented into the formal form called pattern and it was used by the
developer for the next software development. Software pattern like analysis and design
patterns is becoming widely used among the developer and researcher. Software pattern
is established realm of software engineering field and are considered as identical as
design pattern (Gamma et al., 1995). Although most of the common use of pattern at the
design phases (Gamma et al., 1995; Coad et al., 1997; Nicola et al., 2001), many
researchers claims and believes that the use of pattern at analysis phases could
emphasizing the higher degree of reusability and software quality (Fernandez and Yuan,
2000).
2.4.1.1 Analysis Pattern
Object oriented analysis (OOA) is an approaches that representing the conceptual
or business model of the system. Conceptual models are related to the requirements
engineering since it concerned with the relationship of system behaviour and their
evolution. By observing the importance of conceptual models, then the use of pattern at
the analysis phases is must. Analysis pattern is believed can improve conceptual
modelling quality because they are proven solution and have been used by many
developers (Felix and Narashima, 2003).
Analysis pattern is a young concept and originally derived from the design
pattern. In principle, the analysis is focusing on what the system do rather than how the
system was going to be implemented. By recognizing the functionality of the system, it
can be incorporated into conceptual models. This pattern of analysis usually comes
across into the developers mind. Analysis result can be reused again by documenting the
pattern into the proper ways.
There are some benefits regarding of analysis pattern. Firstly, by using the
analysis pattern, usually system analysts will reuse the existing solution design and so
that they can minimize their effort to solve the solution and reduce the cost. Secondly,
analysis pattern could provide the common base vocabulary and viewpoint of the
problems. Finally, analysis pattern will give some indication to the system analysts to
identify the missing classes or architecture of the analysis pattern from the preliminary
study. Thus, it can improve analysis patterns from time to time (Felix and Narashima,
2003).
2.4.1.2 Design Pattern
Object oriented design (OOD) is an approach to representing the system design.
Design an object oriented is hard and design the reusable object oriented is even harder.
Design reusable object oriented can be derived as design pattern. Design pattern
(Gamma et al., 1995; Coad et al., 1997; Nicola et al., 2001) is an approaches the
documenting the previous design model by expert. Design pattern is a pioneer in the
field of software pattern before the existence of other software pattern.
There is some beneficial regarding the use of design pattern. Developers can
shorten development time by composing the design pattern into system model. Thus,
design pattern provides the common vocabulary and viewpoint of the problems.
2.4.1.3 Programming Pattern
In constructing the software, the application domain and the software design
model will be combined together. This result in a software implementation could bring
the design model more understandable. Implementations are technical artefacts which
run as a formalism on a computer and can be utilized as an application supporting its
users. Programming languages provide the notation for this model. On this level, a
programming pattern is a pattern whose form is described by means of programming
language constructs (Riehle and Zullighoven, 1996). These patterns were used to
implement a software design and programming pattern is based on programming
experience by programmers. An example of an implementation pattern is the wellknown C style:
loop
for (i=1; i<max; i++) {...}
It is important to realize that even on this rather low technical level there is something
like programming cultures and styles. Programming styles same as recurring coding in
programming that does can be categorized as programming patterns.
2.4.2
Pattern-Oriented Methodology
Pattern was introduced into the software development process as a means of
manipulating hard-earned experience from the previous problems (Kotonya and
Hutchinson, 2005). Moreover, software pattern could bring some advantages to the
developer such as reducing time and cost. Pattern oriented methodology is a method that
producing a system by using a special process, schema and notation. Thus, it can
encapsulate various software patterns such as analysis, architecture and design into the
specific form. It also includes the rules and guidelines for organizing the relationship
between these patterns. In this section, we will discuss about five pattern oriented
methodology. Those patterns methodology are Pattern Oriented Analysis and Design
(POAD) (Yacoub and Ammar, 2004; Jerry, 2007), Pattern Driven Modelling and
Analysis (PDMA) (Konrad, 2005), Pattern Oriented Software Architecture (POSA),
Meta model POAD + PECOS (Jawawi, 2005) and Design Pattern + CBSD (Yau and
Dong, 2000).
2.4.2.1 POAD
Pattern oriented analysis and design (POAD) is a methodology that concern in
developing a system using a set of patterns. A set of patterns includes analysis and
design patterns and there are some rules and guidelines to relate the relationship of those
phases. POAD is structural based development and the main aims is to promote the use
of patterns at the analysis and design phases systematically which is each result of each
phases are conveyed into the next phases. This process facilitates and encourages the use
of pattern of each development phases.
The POAD methodology is composed a set of design pattern at each phases.
Thus, design patterns is documented and describe a details about its structure, usage,
behaviour of participants, forces and consequences and rules and guidelines for
implementation (Yacoub and Ammar, 2004). Moreover, POAD strictly define a design
patterns as building blocks.
Generally, POAD methodology has three development phases which are
analysis phase, design phase and design refinement phase (Yacoub and Ammar, 2004).
Then, each phase has a special process that describes the selection and retrieval of
design patterns. Figure 2.4 show the POAD development phases.
Analysis
Design
Design Refinement
Figure 2.4: POAD Development Phase (Yacoub and Ammar, 2004)
Figure 2.4 illustrates POAD development phases. In general, POAD consists of
three phases and each phase has a specific process. Analysis phase aims is to identify the
system requirements and finding a suitable patterns from the patterns catalogue. Design
phases aims are to develop a system by using selected pattern in the Analysis phase.
Design refinement phase is a step to elaborate the software pattern level-design into the
profound class diagram. Figure 2.5 show the process involved in Analysis phase.
Application requirement
Requirement analysis
Acquitance
Pattern Library
Requirement conceptual component
Retrieval
Selection
Candidate
Pattern
Selected Pattern
Figure 2.5: Process in Analysis Phase (Yacoub and Ammar, 2004)
Figure 2.5 show the specific process in Analysis phase. There are several steps
within analysis phase which are acquaintance and retrieval. The purpose of acquaintance
is to identify conceptual components by mapping the system requirements into the
domain-specific library of components. After the conceptual components are identified,
the selections of potential components are made from the retrieval of candidate
components from domain-specific library of pattern. The final product is the selected
components and its will be used into the Design phase. Generally, Analysis phase needs
system requirements as an input and selected pattern as an output.
The next phase is Design phase. Figure 2.6 illustrates the process in Design phase.
Selected Patterns
Constructing Pattern Level
Model
Create Pattern Instances
Define Pattern
Relationship
Pattern Level
Diagram
Constructing model for pattern
Level with Interfaces
Pattern Level with Interfaces diagram
Construct Pattern Level
Diagram
Declare Pattern
Interfaces
Constructing model for Detailed
Pattern Level
Identify relationship
between pattern
interfaces
Detail Pattern Level Diagram
Figure 2.6: Process in Design Phase (Yacoub and Ammar, 2004)
The Design phase aim is to implement software design by composing the
selected pattern that have been identify in the Analysis phase. Software design consists
of three levels of products which are Pattern-level diagrams, Pattern-level with interface
diagram and Detailed-level pattern diagram. This entire diagram was created during
Design process. The activities were involved such as create pattern instance, define its
relationship, declare pattern interface and define relationship between pattern interfaces.
The last phase is the Design Refinement phase. Figure 2.7 shows the process in Design
Refinement phase.
Detailed Pattern Level
Diagram
Concretization
Instantiating pattern internal
Scoping
Domain specific Detailed Pattern Level
Diagram
Specialization
Develop class diagram
Initial UML class diagram
Reduction
Design Optimization
Merging and
grouping
Optimized class diagram
Figure 2.7: Process in Design Refinement Phase (Yacoub and Ammar, 2004)
The purposes of this phase are to create class diagram. Class diagrams are created
by gluing the patterns together at the high level design. Generally, this process takes
Detailed-level pattern diagram as an input and produce optimized class diagrams as an
output.
There are some advantages of POAD methodology. POAD methodology gives
good traceability from the analysis to the design phase. Then, POAD provide good
documentation of system design because of patter-level diagram provide high level
abstract view of system design. POAD methodology also gives the motivation use of
pattern, component, architecture view and design reuse. Thus, pattern level design gives
high quality of system development because systems are implemented by using proven
solution by previous experts. However, POAD methodology has some flaws within their
scope. POAD methodology is a structural development so that its lacks of behavioural
elements such as on how the system react within their subsystems.
2.4.2.2 PDMA
Pattern Driven Modelling and Analysis (PDMA) is another software
development based on pattern (Konrad, 2005). This approach concern on how we
stimulate a pattern to model the embedded systems. The derivation from pattern to
system modelling is the core of this method and based on the concept of object analysis
pattern. Object analysis pattern define the analysis of the relationship of the object
within the system and focusing on what the systems will do. Object analysis pattern in
PDMA uses UML notation to visualize the system structure and behaviour information
such as use case, sequence diagram, state chart diagram and system context diagram.
This UML notation then leads into the system conceptual model. The aims of this
approach is to guide and provide a rules on how we identify the embedded systems
properties such as timing and response time by giving some model examples using UML
notation.
PDMA provided some tools in order to support the graphical visualization within
UML notation. The tools supports PDMA are MINERVA, Hydra and Spin. The
MINERVA is the automated tool to correct the syntax of UML and consistency check
the results, simulation trace and path detection that lead to errors. The Hydra is the
automated tool that map UML notation to a target language. Then, Spin also automates
the execution of process to check temporal constraints against the conceptual model.
Generally, PDMA approach provides some helps to new developers to accelerate
the initial design of conceptual model by mapping the systems requirements into the
system analysis through object analysis pattern. Moreover, PDMA imply how a method
describes embedded system issues like timing, concurrency, event handling and message
communication. PDMA also provides tools to support the correctness of system
requirements transformation into the models by using simulation and checking process.
2.4.2.3 Meta model POAD+PECOS
This approaches using POAD and PECOS methodology as a basis to combine
pattern and component (Jawawi, 2005). The purposes of hybrid Meta model POAD and
PECOS is to motivate high reusable of ERT systems. But firstly, we must define the
POAD and PECOS Meta model before we combine them and Jawawi (2005) has
introduced an enhancement of POAD and PECOS. These two approaches need to
undergo enhancement process because they have different definition which is prevent
direct mapping. The mapping process is involving analysis phase in POAD and design
phase in PECOS.
However, there are some issues regarding on how the transformation process
needs to be done. The issues are 1) how to combine pattern to component, 2) how
interfaces of two Meta model can be mapped and 3) how real-time properties explicitly
expressed in these models. This issue has been solved by Jawawi (2005) by dividing
ERT development process into three phases. Figure 2.8 shows the phases of
transformation Meta model.
Capture the main
requirement using reusable
analysis pattern
Pattern oriented analysis
model
Transform pattern-oriented
analysis model into
component by providing
the interfaces and tracing
the interfaces to the
internal classes
Pattern component early
design model
Derived from internal
classes with the integrated
pattern and some
component from early
design model
Component based detailed
design model
Figure 2.8: Software Process for Integrated POAD and PECOS (Jawawi, 2005)
2.4.2.4 Design Pattern + CBSD
The combination design pattern and CBSD was introduced by Yau and Dong
(2000). This approach explicitly addresses the high reuse of patterns and components.
The main purposes of this approaches is to enable high software quality and productivity
by reusing the existing components by composing together using a certain technique.
But, to compose each component is not an easy task since it must have clear definition
and component interfaces. Then, these approaches present the use of design patterns to
automatic generation of components wrappers for component integration. Hence, these
approaches give an indication the use of component and pattern at design level and it
consist of design and implementation phases only.
Generally, this approaches using CBSD method in software development and
plug in with the design pattern into the component integration process. However, this
approach assumes design pattern is well defined and components are behaved as its
specification. This assumption may give some flaws since the design pattern needs to be
clarified first in order to enable the correctness of component integration. Figure 2.9
shows the design pattern + CBSD approaches.
Figure 2.9: CBSD Process Using Design Pattern (Yau and Dong, 2000)
2.4.2.5 Comparative Evaluation
In order to compare those four pattern oriented methodology, we define four main
criteria that reflect the selection of suitable methodology for this project. The criterions
are component-based, pattern oriented, pattern level and phase level. Component based
and pattern oriented arrangements were selected because to map the project
requirements. Thus, we compare which levels are pattern lies and what are the phases of
methodology are involved. Table 2.1 shows the comparative table of pattern
methodology.
Table 2.1: Comparative of Pattern-Oriented Methodology
Methodology
POAD
PDMA
Meta
Design
model
Pattern +
POAD +
CBSD
PECOS
Component
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Analysis
Analysis
Analysis
Design
Analysis
Analysis
Analysis
Design and
and
and
and
Implementatio
Design
Design
Design
n
No
Yes
No
Yes
based
Pattern
oriented
Pattern level
Design
Phase level
Tools
Table 2.1 shows the comparative of Pattern-oriented methodology. From the
observation, all methodologies are component based except for PDMA. This is due to
the close relationship between component and pattern. For the pattern oriented, all
methodologies are using pattern as a basis of their process. Then, all methodologies
except Design Pattern + CBSD were involved at analysis and design phase. As a
conclusion, most of the methodologies were implemented pattern at analysis and design
stages. This approach can strengthen the initial design of system conceptual model and
design architecture. Thus, the use of component based and pattern could give high
impact on modern software development.
Pattern oriented methodology is a method that producing a system by using a
special process, schema and notation. Thus, it can encapsulate various software patterns
such as analysis, architecture and design into the particular form. Based on comparative
evaluation in Table 2.1, it indicates that POAD methodology is the most systematic in
context of used of pattern and component based. POAD is structural approaches and
define the use of pattern at design stage. Thus, POAD methodology devotes useful
traceability from the analysis to the design phase and deliver some helpful
documentation of system design because of pattern-level diagram provide high level
abstract view of system design.
2.5
Embedded Real Time (ERT) System
Embedded system is computer systems that are part of the complex system. It
consists of hardware and software and subject to computational part and physical
constraints. The software and hardware in embedded system works closely due to the
execution some of the system requirements. Some examples of embedded systems are
mobile system, control, forecast, computer chip and so on (Crnkovic, 2005). Embedded
real time system is a part of embedded system. Embedded real time system is highly
dependent on timing, response time, worse case execution and message handling
(Crnkovic, 2005). Due to these real time properties, this system must have explicit view
on safety, reliability and some other properties of dependability.
The complexity of the embedded real system today leads into the new era of
system development. The system development of embedded real time system must
express some important indication such as requirements engineering, high level design,
explicit conceptual model and integration. This property must summarize the common
embedded real system behaviour like dependability, portability and maintainability.
Embedded real time system design is a derivation from the requirements into the
conceptual models. This common development phase is essential and they represent the
abstraction of the systems. The abstraction of the systems including all real time system
properties and due to this complexity, embedded real time system design must extremely
have a lower cost and time of development.
2.5.1
ERT System Methodology
ERT system is a part of computer system that highly dependent on software and
hardware interaction. The complexity of its architecture leads into the complexity of its
system development process. ERT system itself has systematic design lifecycle that
captured all of the system needs from the system requirements until the implementation.
The design approach should be based on the use of one or more formal models to
describe the behaviour of the system at a high level of abstraction, before a decision on
its decomposition into hardware and software components is taken. The final
implementation of the system should be made as much as possible using automatic
synthesis from this high level of abstraction to ensure implementations that are “correct
by construction.” Validation (through simulation or verification) should be done as
much as possible at the higher levels of abstraction.
In this section, we will discuss seven ERT system methodologies. Those
methodologies are Rapid Object-oriented Process for Embedded System (ROPES)
(Douglass, 1999), Octopus/UML (Domiczi et al., 2000), Concurrent Object Modelling
and Architectural Design Method (COMET) (Gomaa, 2001), Method for Componentbased Real Time Object Oriented Development and Testing (MARMOT) (Bunse et al.,
2008) and Software Development Process for Real Time Embedded Software System
(DESS) (Luigi and Bianco, 2000; Baelen et al., 2001).
2.5.1.1 ROPES
Rapid Object-oriented Process for Embedded System (ROPES) was introduced
by Douglass (1999). ROPES methodology is specific for embedded system development
and it use iterative lifecycle oriented to emphasize development process. Thus, ROPES
uses UML as its Meta model to show the semantic and notational schema on modelling
language.
ROPES methodology has four development phases which are analysis, design,
translating and testing. From the development phases, ROPES will generate three result
which are analysis model, design object model and application components. All of these
deliverables is essential since it must meet all initial system requirements. The main
aims of all development process including ROPES are to 1) increase the quality of end
product, 2) improve the repeatability and predictability of the development effort, and 3)
decrease the effort required end product (Douglass, 1999). To achieve all of this
purposes, ROPES methodology must consists the phases, activities and deliverables.
Phase is defining the set of activities that contain the high level of system abstraction.
Activities are a process that emphasizes the deliverables of the system. Figure 2.10
shows the ROPES development phases.
Figure 2.10: ROPES Development Phases (Douglass, 1999)
Figure 2.10 illustrates ROPES development process. It consists of four main
phases which are analysis, design, translating and testing. Each phase have different
artefacts since it have different view of system model. Analysis is divided into
requirements, systems and object analysis activities. Then, design phases are divided
into architectural, mechanistic and detailed design activities. This stage, the design
pattern is used to map into the design object model. The translating phases translate the
UML notation schema into the code and testing phase includes both integration and
validation testing where the test cases primarily upon the scenarios that are identified in
requirements and object analysis phase.
ROPES is primarily covered both structural and behavioural object model of the
system. Structural object model defining what the system does and map into the UML
Meta model such as use case and sequence diagram. Behavioural object model describes
how the system does such as state chart diagram, design context diagram and activity
diagram. Both artefacts are essential to support the completeness of system realization.
However, ROPES methodology lack of use a pattern. It uses a pattern only at design
phase through design pattern. Thus, ROPES did not have systematic way on how to
derive a pattern to another object model.
2.5.1.2 Octopus/UML
Octupus/UML is object-oriented software development that specific for
embedded real time system (Domiczi et al., 2000). This approaches complies with
terminology and notation that defined by UML. However, using UML notation to
describe real time modelling language is problematic. Then, (Domiczi et al., 2000) was
introduced Special Octopus Feature (SOF) as adornments term in order to model
efficiently real time issues. Although SOF is not UML complaint, there exist ongoing
researches to develop the mapping tool from SOF to UML. In general, Octopus/UML
using incremental and evolutionary life cycles oriented to emphasize on rapid
turnaround development process. The aims of this method are to define 1) which classes
and objects are exist 2) structure and behaviour of those classes and object 3) the
relationship between object 4) relationship between classes and 5) smooth transition
between objects and classes into task and processes (Domiczi et al., 2000).
The phases involved are system requirements specifications, system architecture,
analysis, design, implementation, testing and integration. Due to incremental and
evolutionary life cycle approaches, the development processes undergo the special
capabilities implementation. In the incremental model, user needs are determined and
system requirements are defined first. The rest of the development is then performed in a
sequence of increments. In the evolutionary model, a system is also developed in
increments, in acknowledging that the user needs are not fully understood and secondly,
in that all of the requirements cannot be defined up front. User needs and system
requirements are partially defined in the beginning and updated in each succeeding
increment. The evolutionary model does not assume that it will get the system right the
first time. Rather, the developers work on an increment and the results are fed back to
the development work of the next increment. Figure 2.11 show Octopus/UML system
development pattern.
Figure 2.11: Octopus/UML System Development Pattern
Figure 2.11 shows the system development pattern of Octopus/UML. A system
development starts with the system requirements specification and then system
architecture. From system architecture phase, the number of system increment follows,
which contains the analysis, design, implementation and testing of each subsystems.
Each subsystem potentially constructed in parallel in incremental development. The
parallel development motivates the resources sharing during subsystem implementation.
Thus, each subsystem will be integrated once it’s complete.
The Octopus/UML methodology is highly dependent on using UML notation as its
modelling language. Then, SOF was built in order to model the real tine issues and map
into the UML using special tools. Octopus/UML was arranged the development process
within incremental and evolutionary lifecycle. Both lifecycle integrated together to
enhance the effectiveness of system development. Generally, this methodology was
giving complete view the relationship of object oriented and real time. Thus, the
structure of objects and classes and its relationship have clear definition in each process.
However, this methodology did not covered component based and pattern oriented
development. They specify the analysis and design of subsystem by using current
analysis without adopted prior experience from previous developers.
2.5.1.3 COMET
Concurrent Object Modelling and Architectural Design Method (COMET) was
introduced by Gomaa (2001) and the main aims is for development of concurrent
application in particular distributed and real time systems. COMET methodology uses
UML notation as modelling language particularly to define the objects and models in
analysis and design phases. Thus, it solely to integrate object oriented with concurrent
processing concepts. The COMET development approach is highly iterative lifecycles.
COMET consists of three phases which are requirements, analysis and design.
Each phase have a detailed processes which are describing the details composition of
system requirements and models. Figure 2.12 shows the COMET development phase.
Static
Analysis Phase
Dynamic
System architecture
Design Phase
Architectural design of distributed
application
Task structuring
Detailed design
Figure 2.12: COMET System Development (Gomaa, 2001)
Figure 2.12 show the COMET development phase. In the requirements
modelling phase, the functional requirements of the system are identified by visualize it
by use cases and actors. Often, use case can be considered as black box because it
encapsulates all the details about the implementation of system functionality. Then, there
are two compositions in the analysis modelling phase which are static and dynamic
modelling. Static modelling defines the relationship between classes and system itself.
Thus, it defined on how the external system communicates with the system by
emphasizing the specific boundaries. In the UML notation, static modelling can be
visualized by system context class diagram. Dynamic modelling defines on how the
objects interacts with the system use case and usually using state chart diagram in order
to express the system behaviour. In the design modelling analysis, the main activities are
the transition from analysis into design. The systems are composed into the subsystems
which each are identified by subsystem interface. The design modelling can be broken
into four processes which are system architecture, architectural design of distributed
application, task structuring and detailed design. Thus, this phase will apply component
based approaches into the subsystem design.
In general, COMET methodology is highly expressed into the analysis and design
modelling of distributed and real time system. The concept of component based is
applied in the design phase. Hence, the component based approaches is essential since
real time system needs a subsystem as distributed designed self-contained components.
The advantages of this methodology are the transition from analysis phase into design
phase was clear by using UML notation modelling language. However, these
methodologies did not apply pattern oriented approaches whether in the analysis or
design phase.
2.5.1.4 MARMOT
Method for Component-based Real Time Object Oriented Development and
Testing (MARMOT) was developed based on model-driven development with
component (Bunse et al., 2008). The system development with components can ensure
the rapid development besides the ability to reuse existing components and ability to
compose sophisticated software (Crnkovic, 2005). The main aims of this methodology
are to develop embedded system with components with providing the systematic
templates, guidelines and models.
MARMOT consists of four main development activities which are the composition,
decomposition, embodiment and validation. Composition is the main activity in
MARMOT. The MARMOT is viewed as the composition of various component models,
which consists parent/child that ensuing the complete systems. Hence, the other
establishment is MARMOT is allowed the separation of components model
development so the component change does not affect any other component models.
Figure 2.13 illustrate MARMOT development activities.
Figure 2.13: MARMOT Development Process and Component Meta model (Bunse
et al.., 2007)
Figure 2.13 show MARMOT development process. The diagram was illustrated
as three dimensional diagrams which contain abstraction model (software model and
code) and concretization model (hardware constraint) and constructed with two major
development dimensions. The two major developments are Composition/Decomposition
and Abstraction Concretization that map into the four activities, decomposition,
embodiment, composition and validation (Bunse et al., 2008).
As the started of system development, the whole a system was viewed from the
different angle to represents which systems to be built. Decomposition defines the
identical of each component in abstract and logical context. Embodiment determines the
transformation from system modelling specification into the hardware composition.
Although system modelling specification and hardware can be treated as two different
views, but both is assumed as abstraction level description. Then, composition will be
assembled the components that have been implemented according to its abstract model.
After the whole processes have been gone through, the validation process will be
checking the concrete composition that corresponds to its abstract definition.
In general, MARMOT methodology represents the embedded system
construction with component based. This methodology allows an abstract view of
system composition from the software modelling until hardware level. They exerted
UML notation to express the system model visualization. Since MARMOT only
concentrate building a system with component composition, there prevails no indication
the use of software pattern for each process.
2.5.1.5 DESS
Software Development Process for Real Time Embedded Software System
(DESS) is a methodology of object oriented and component based development for ERT
system (Baelen et al., 2001). The goals of this methodology are to encourage the use of
components as building blocks as a part of their systems. It also provides the extendible,
evolution capable and reusable for the family products. To ensure the compatibility with
the existing approaches of system development, DESS methodology was built based on
Unified Process (UP) and V-Model approaches by modifying their semantics where
necessary. The UP approach was adopted to represent DESS workflow process and VModel is to group the process into its specific nature.
The DESS methodology has three processes that called Workflow Vs. Workflows Vs
consists of three main processes which are Realization, Validation and Verification and
Requirements Management. Figure 2.14 illustrate the DESS Workflow Vs.
Figure 2.14: DESS Workflow Vs (Baelen et al., 2001)
Figure 2.14 show the DESS workflow. Each workflow is a group of specific
development process based on UP approaches. All of this workflow will be implemented
using parallel processing. Figure 2.15, 2.16 and 2.17 indicate the composition of
realization, validation and verification and requirements management workflow. Each
workflow possesses the particular process and provides some artefacts as the
deliverables.
Figure 2.15: Realization Workflow (Baelen et al., 2001)
Figure 2.16: Validation and Verification Workflow (Baelen et al., 2001)
Figure 2.17: Requirement Management Workflow (Baelen et al., 2001)
In general, DESS methodology aims for the development of object oriented and
component based for embedded real time system. It used UML notation as modelling
language to express the structural and behavioural of the system. DESS methodology
was implemented by the basis of UP and V-Model by extending the semantics where
necessary. However, DESS does not cover the use of software pattern in the
development workflow whether in system analysis and design.
2.5.1.6 Comparative Evaluation
This section defines the comparative evaluation of ERT system development
methodology that already mention previously. There are seven criterions that have been
identified which are component-based, pattern-oriented, pattern-level, UML notation
support, tool, phase and process lifecycle approaches. These criterions have been chosen
in order to find the suitable methodology that support both component-based and
pattern-oriented. Table 2.2 show the comparative evaluation of ERT system
development methodology.
Table 2.2: Comparative Evaluation of ERT System Development
Methodology
Methodology
ROPES
Octopus/U
COMET
MARMOT
DESS
ML
Component-
Yes
No
Yes
Yes
Yes
Yes
No
No
No
No
based
Patternoriented
Pattern-Level
Design
UML
Yes
N/A
N/A
Special
N/A
N/A
Yes
Yes
Yes
Yes
Yes
Yes
Composition
Realiz
Octopus
Feature
(SOF) +
UML
Yes
Tool
Phase
Analysis
Design
Yes
System
Analysis
requirement
Design
specification
ation
Decompositi
on
Translatin
System
g
architecture
Valida
tion
Embodiment
and
verific
Testing
System
Validation
ation
incremental
development
Requir
ement
manag
ement
Lifecycle
Process
Iterative
Incremental
Iterative
and
Iterative
Iterativ
e
evolutionary
Based on table 2.2, most of the methodology provides the complete system
development. Thus, they use UML notation as modelling language to model the system
abstraction for each phases. Therefore, only ROPES methodology was indicate the use
of component based and pattern oriented at design level. The other methodology like
COMET, MARMOT and DESS is highly motivated to use component as a part of
system development. Even though Octopus/UML is giving the most complete and
systematic ERT system development approaches, this methodology does not cover the
use of component and pattern in system development.
ERT system development methodology was giving the systematic system development
which contains the notation, schema, process and deliverables. This properties will be
combined together to construct the ERT system development. However, by composing
the use of component-based and pattern-oriented in system analysis and design, the time
and cost of ERT system development can be decreased. ROPES methodology was
identified as the previous literature as the methodology that use both component-based
and software pattern. Thus, ROPES explains both structural and behavioural of the
system by modelling it in UML notation such as use case and state chart diagram.
2.6
Discussion
Based on comparative evaluation in Table 2.1 and Table 2.2, POAD was chosen as
pattern methodology and ROPES as ERT system development methodology. POAD was
adopted because it denotes the structural approaches to develop a system by
systematically exerting pattern at analysis and design phase. Hence, ROPES was
selected as ERT system development methodology because it provides the complete
process of ERT system development and express the use of component-based and
software pattern in development phase. By choosing these two approaches, we can
conclude that the hybrid methodology between ROPES and POAD will be carried out by
proposing Meta model and software process. Meta model is used to describe the
semantic and notation schema on how we model the intended software both structural
and behavioural elements. Thus, software process extends the functional of Meta model
by introducing on how the process of software development will be carried out.
CHAPTER 3
RESEARCH METHODOLOGY
3.1
Introduction
The main goal of this project is to promote the use of software pattern and
component at analysis and design level in hybrid ROPES and POAD methodology by
proposed the integrated Meta model and define the software process. Based on the
research works in Chapter 1 and Chapter 2, two important elements were identified to be
investigated in order to integrate both methodologies. The two elements are ERT system
development methodology and pattern-oriented methodology. In this project, those two
elements are essential since it must be studied in depth and the result can be used as the
basis of methodologies selection. In order to verify the results, we used comparative
evaluation as the validation techniques. This chapter will describe the research
methodology in detail which involves those two elements, the integration of two
methodologies and validation of the studies.
3.2
The Software Engineering Research
This section briefly explains the research strategies specifically in software
engineering domain. Shaw (2002) categorized research strategies into four important
elements. The elements are process, questions, results and validations. These elements
can be used as a basis to answer all research problems from the observation proses until
the final process.
There are various types of research questions need to be answered in software
engineering domain. The question whether is WHAT, HOW, WHY and WHERE. This
question leads the process into the required results. We can questions about the method,
methodology, design and feasibility of the system. Then, from the question we can
predict the expected results that we need to obtain. The expected results will act as the
goal for each research question and can be used as the guidance during the research
process. After the expected results are achieved, we must validate the results with a few
technique of validation such as analysis, experience, example, evaluation and
persuasion.
This research process strategy is very important during the research process in
order to ensure the correct questions meet the correct results with the suitable validation
techniques. The research process also experiences some systematically flows from phase
to phase regarding on research framework. Hence, it will help the researchers still
focuses on the objective of the project.
3.3
Research Framework and Processes
This section attempts to illustrate the research framework and explains the
processes are involved in the research framework. There are six process or phases
include in research framework. Each phase have their own activities as illustrated in
Figure 3.1.
There are four main processes and associated with the each phase in the research
framework. The four main processes are problem formulation, literature review,
integrated Meta model POAD and ROPES and define the software process. The
overview of research framework is shown in Figure 3.1.
Phases 1
Problems Formulation
Phases 2
Research Sources
Literature
review
Research area
Problems Description
Objectives
Scopes
Component-Oriented
Development
ERT System
Development
Methodology
Journals
Conference paper
Books
Theses
Pattern-oriented
Development
Phases 3
Evaluate on patternoriented methodology
Evaluate
on
ERT
system
development
methodology
Comparative
Evaluation result
Phases 4
Study the Meta model
of ROPES methodology
Study the Meta model
of POAD methodology
Need
improvement
Proposed an
integrated Meta model of
ROPES and POAD
methodologies
Need
improvement
Validate the proposed
integrated Meta model
Project 2
Phases 5
Define the software
process of integrated ROPES
and POAD Meta model
Validate software
Phases 6
Proposed Software
Process
Implement
Application
process
Report
Figure 3.1: Research Framework
3.3.1
Problems Formulation
In this process, the domain analysis and software pattern is performed in order to
specify the problems. The domain analysis will be based on ERT system development
methodologies and will be incorporated with the component-oriented pattern
methodology. During this process, a following research questions are asked:
1.
How to determine the current problems in ERT system development
methodology?
2.
How to motivate the use of patterns in ERT system development at analysis and
design level?
Early assumption is essential to clarify the objectives and scopes of the research.
This is to ensure the problem is well identified with assumption by undergoing some
reading on journals, conference papers, books and theses. Then, the literature review is
performed to validate the problem arises in problem formulation phase.
3.3.2
Literature Review
In this process, the current ERT system development and component-oriented
pattern methodologies were studied to validate the objectives of the research. Based on
related works reviewed in Chapter 2, four pattern-oriented methodologies and five ERT
system development methodologies are reviewed. This is to clarify and validate the
objectives of the research that states the use of POAD and ROPES methodology as the
basis if the research. The following research questions are asked:
1.
What is the best ERT system development methodology in terms of pattern uses?
2.
What is the best pattern-oriented methodology in term of pattern level uses?
The research questions are important as a guidance of the selection of those
methodologies. These methodologies were selected in the comparative evaluation
process and some important criterions are chosen to map with the needs of pattern uses.
3.3.3
Integrated Meta model POAD and ROPES
In this process, the Meta model of ROPES and POAD is identified and
incorporated with the UML 2.0 specific for embedded system. To specify the Meta
model of ROPES and POAD, we need to implement the ROPES and POAD
methodologies into the selected case studies. This work has been done by (Wan Zulkifli,
2008) and then we define Meta model for each methodology. The following questions
are asked to obtain the details of Meta model:
1. How to identify Meta model of ROPES and POAD methodologies?
2. How to produce Meta model of integrated ROPES and POAD
methodologies?
The results obtained from the above question are the main foundation of this
research. From that results, the integrated Meta model will be validate by composing
into the selected case study. The composing of integrated Meta model to case study is an
iterative process until the firm Meta model is obtained.
3.3.4
Define and Design Software Process
The results obtained from the above three processes are essential to define the
software process for Meta model of integrated ROPES and POAD methodologies.
Software process is the Meta model for define the concrete of software development
process. The research questions need to be answered in this process:
1.
How to define the software process for Meta model of integrated ROPES and
POAD methodologies?
2.
What tools, if any can be used to define the software process?
3.
How to validate the defined software process whether it can be used for the ERT
system?
4.
How to validate the defined software process whether it can be used to support
the use of patterns in ERT system development?
The main reason of this research is to promote the use of pattern in ERT system
development methodology with systematically derivation from analysis to design stage.
The two products were obtained as outputs from this research are Meta model and
software process of integrated ROPES and POAD methodologies.
The summary of the research process is shown in Table 3.1. The research
processes are grouped into four elements Shaw (2002) which are process, question,
expected result and validation. This element is important to clearly identify the goal of
the research.
Table 3.1: Summary of research process
Process
Question
Expected
Result
Determine
How
to
n
Objective
problems
identify
background
problem faces in project
ERT
Validatio
Analysis
the and scopes of the
system
development
today?
Evaluate
How
to
Comparativ
the ERT system identify the best e evaluation table
development and ERT
n
system
pattern-oriented
development
development
pattern-oriented
methodologies
development
and
methodologies
term
Evaluatio
of
in
pattern
uses.
Determine
How
the Meta model of identify
to
Meta model
the of
integrated
integrated ROPES ROPES and POAD ROPES and POAD n
and
POAD Meta model?
methodologies
methodologies
How
integrate
to
those
Analysis
Applicatio
Meta model?
Define the
software
How
process define
of Meta model of process
to
software process
of
Software
of
Applicatio
Meta n
Meta model of integrated
Experime
integrated ROPES model of integrated ROPES and POAD nt
and
POAD ROPES and POAD methodologies
methodologies
3.4
methodologies
Feedback Control System
In order to identify the suitable Meta model for both ROPES and POAD
methodologies, the small scale of ERT system are chosen to be composed with the both
methodology. This activity also can be incorporated with the UML 2.0 profile specific
for embedded system to find the suitable notation and Meta model for embedded system.
After the related Meta models are identified and integrated, the medium scale of ERT
system are chosen to be composed into the define software process. This process is to
ensure that the defined software process can be implemented into the any ERT system.
The case study that has been selected is Feedback Control Systems (Yacoub and
Ammar, 2004). This system was chosen because it’s denotes a small scale embedded
real time system and contains the real time behaviour properties.
Feedback Control Systems is developed to control the software components in a
system and to control external environment as well. There are three basic components in
this systems which are math model, diagram block and signal-flow graph. Figure 3.2
show the block diagram for a feedback control system.
Error (actuating)
signal
Reference input
Feed forward
element
Controlled
output
Plant
+
Feedback data
Feedback
elements
Measurement
Figure 3.2: Block diagram for feedback control system
A feedback control system is dependent on the output. It measured the output to
be compared to the system input so that the appropriate control action will be performed
same as the function of the output and the input. This system has been used widely in
ERT system whereby the feedback output needs to be considered to control the
controller. One of the main system elements are Plant. Plant is a system part that is
using feedback control system. Thus, controller output will be changed based on
requirements of false indication (Yacoub and Ammar, 2004).
3.5
Summary
This chapter outlined the research methodology for this project. The research
processes, questions, expected results and validations is an elements that clarify each
activities in the research framework. Each result in the research framework activities
will be carried out in detail in Chapter 4 to Chapter 6. Generally, research framework
will act as guidance for a researcher to implement research activities systematically.
CHAPTER 4
INTEGRATED ROPES AND POAD METAMODEL
4.1
Introduction
This chapter explains the Meta model of POAD and ROPES methodology and
how both Meta model will be integrated in order to define the ERT software modelling.
Based on Chapter 2, the POAD and ROPES methodology were discussed in depth
regarding its development process. The development process is essential in order to
define the artefacts produced in each respective output for each development phases.
These artefacts than will be mapping onto UML (OMG, 2007) Meta model and will be
supported by Meta Object Facility (MOF) (OMG, 2006) and Object Constraint
Language (OCL) profile. Both profiles are defined by Object Management Group
(OMG). Furthermore, by identifying the respective Meta model, then we define the
POAD and ROPES Meta model. Thus, both Meta model will be integrated in order to
motivate the use of pattern in ERT software development. This chapter will describe the
Meta model constructions in detail which involves POAD and ROPES methodology.
4.2
Metamodel
Computer software is a complex architecture that contains million lines of codes.
This complexity of creation often makes them hard to understand regarding on how the
parts of the system interact each other. Therefore, there must exist some approaches on
how the complexity of software more understandable. Then, modelling is one of the
solutions on how we describe the software in abstract level.
Model is an approach that makes larger system more understandable. Model
describes the specific aspects of the software and can perform an experiment on the
system without changing the actual system. In software engineering, a model is used to
describe the system. Thus, a model was realized by using modelling languages. Most
modelling languages are using some form of graphical notation in order to represent the
model artefacts. UML from OMG is one of the modelling languages that widely used by
software developers. This language is for general purposes that are not domain specific.
Since the model describes the whole software itself, then any level of abstraction
can be instanced into the level which it describes. Therefore, OMG come up with the
four-layered metamodelling architecture as shown in Table 4.1.
Table 4.1: Metamodelling four-layer architecture
Layer
Description
Meta-
The infrastructure for metamodelling architecture.
metamodel
Defines the language for specifying metamodelling.
Metamodel
An instance for a meta-metamodel. Defines a
language for specifying model.
Model
An instance for a metamodel. Defines the language
to describe information domain.
User object
An instance for a model. Defines a specific
information domain.
Table 4.1 shows the four-layered metamodelling. Meta models are a model too
and it lies in the above model layer. A model describes the software and a Meta model
describes the model. For the POAD and ROPES methodology, they represent their
model in the UML notation. To construct the POAD and ROPES Meta model, firstly we
must understand the concept of UML profile, MOF and OCL.
4.2.1
UML Specification
The Unified Modelling Language (UML) is a visual language that specifying,
constructing and documenting the software artefacts. This visual language is for general
purpose and they are not domain specific. In the other words, UML can be implemented
into the various type of application like real time system, business, widow application
and web based.
Since 1997, OMG was issued the UML 1.1 and continuously issued the UML
until today by the task force team. The latest UML versions are UML 2.1.2 and this
version is divided into two parts which are UML 2.0 Infrastructure and UML 2.0
Superstructure. Generally, UML have two packages which are Core and Profiles. Each
packages will be divided into several level of abstraction that describing the notation and
semantics of the Meta models. Hence, it will be supported by MOF and OCL in order to
describe invariants Meta model in modelling constraints.
The Meta Objet Facility (MOF) was issued by OMG standard that provides the
metadata management framework, and a set of metadata services to enable the
development and interaction within models. The first version was issued in 1997 and
called MOF 1.1. This version continuously adopted by OMG until today. The latest
version is MOF 2.0 and incorporated together with UML 2.0 to contribute significantly
in modelling languages.
The Object Constraint Language (OCL) was adapted by OMG to the UML
specification and it is used to help formalizing the semantics of the language and to
provide the facility for UML user to express precise constraints on the structure of their
models. OCL also is used to specify the model elements and invariants on classes and
types in class model. Thus, it will define the preconditions and postconditions on
operation and methods in class.
4.3
POAD Meta model
POAD methodology defines the composition of patterns at high level by using
UML as a means to captures all the software requirements. UML is the collection of
Meta model notation offers by OMG and consists of high level Meta model abstraction.
In order to define the POAD Meta model, firstly we must captures all the artefacts
produced in each development process and analyse the relationship between artefacts
and UML Meta model. Then, we can identify the respective Meta model and starting to
construct the Meta Model. Table 4.2 illustrates the artefacts produced in each phases.
Table 4.2: POAD Artefacts produced vs UML Meta model
Phase
Artefacts
UML Meta model
produced
Analysis
A set of pattern
with name
Design
Patterns
Namespace (from
Core)
with
Relationship
interface
Design
Refinement
Class diagram
Class diagram
Pattern
Dependency
dependencies
Pattern association
Association
Classifier
Table 4.2 shows the artefacts produced in each POAD development phase and
their relationship with UML Meta model. In analysis phase, a set of patterns are
retrieved from the pattern library. Then, the selected pattern will be integrated by using
association relationship in UML Meta model. After those patterns were integrated, we
defined the pattern interface in order to enable interaction between patterns.
Furthermore, the patterns must define a details class diagram in the pattern itself to cope
with the system requirements.
For the POAD Meta model construction, five key elements originally extended
from the UML meta-model to enable pattern-oriented composition using POAD. Those
five key elements are;

Pattern. A set of collaborating classes that originally retrieve from Namespace
(from Core)

PatternInterface. A set of classes and operations that define how the pattern
interfaces wirth the other pattern. Originally retrieved from Classifier.

PatternDependency. It shows the relationship between patterns.

PatternAssociation. It shows the relationship between pattern interfaces.

InterfaceBinder. It used to connect PatternInterface with its internal classes.
PatternDependency
1
2
Pattern
name
Interf aceBinder
PatternInterf ace
Class
Constraint
Relationship
2
connect
1
PatternAssociation
Operation
Attribute
Figure 4.1: POAD Meta model
Figure 4.1 illustrates the POAD Meta model that originally derived from the
UML metamodel. POAD metamodel is structural elements regarding on its model.
However, for real time system, the structural elements alone is not enough. It must cover
both structural and real time behaviour elements in other to represent how the ERT
system should react with the time constraints and resources. (Jawawi, 2006) was
introduced the enhancement of POAD Meta model that enable explicit description for
real time behaviour of components. The two elements that have been introduced by
Jawawi
(2006)
are
1)
RealTimeBehaviour
and
2)
PatternControlInterface.
RealTimeBehaviour was added to class Meta model to show the real time elements in
each class diagram. Figure 4.2 illustrates the POAD Meta model with real time elements
proposed by Jawawi (2006).
PatternDependency 1
PatternControlInterf ace
2
Pattern
name
Interf aceBinder
PatternInterf ace
Class
Constraint
Relationship
2
2
connect
connect
1
QoS
1
PatternAssociation
Operation
Attribute
Real-Time Behav iour
Figure 4.2: Enhancement of POAD Meta model (Jawawi, 2006)
4.4
ROPES Meta model
ROPES methodology defines the systematic development process specific for
ERT system. It consists four development phases which are analysis, design, translating
and testing and each phase have own activities. However, for this project we will cover
only analysis and design phase. ROPES model covers both structural and behaviour
elements in the system. Structural and behaviour elements represent the whole system
reaction and can be represented in UML metamodel. Therefore, we must systematically
identify the artefacts produced for each development phase. This is to ensure what is the
relationship between artefacts in ROPES and UML metamodel. Table 4.3 shows the
artefacts produced in ROPES methodology based on previous implementation in Wan
Zulkifli (2008).
Table 4.3: Artefacts produced in ROPES Methodology
Phase
Artefacts
UML Meta model
Use Case, Object,
Use case, Object,
Analysis
Requirement
Messages, Actor.
System
message, actor
Subsystem,
Subsystem,
component,
statechart, component, port, interface,
activity,
interaction behaviour,
diagram.
componentRealization,
Dependency,
Relation,
Association
Object
Class
Object,
Statechart,
Interaction.
diagram,
Subsystem,
Collaboration, component, port, interface,
Activity, behaviour,
componentRealization,
Dependency,
Relation,
Association
Design
Architectural
Statemachine, Use
case,
Subsystem,
Activities, component, port, interface,
interaction,
Class behaviour,
diagram, component.
componentRealization,
Dependency,
Relation,
Association,
Resources,
Thread, Task
Mechanistic
Class diagram
Pattern,
Class
diagram
Detailed design
Class diagram
Class diagram
Table 4.3 shows the artefacts produced in ROPES development phase and
correspond with the UML Meta model. Generally, ROPES are using structure and
behaviour Meta model and combining with Real Time Meta model such as Message,
Thread and Resources. This elements show that ROPES methodology covers real time
system properties in their modelling systems. After we defined the respective UML
Meta model for each artefact, then the ROPES Meta model is constructed.
Figure 4.3: ROPES Meta model
Figure 4.3 illustrates ROPES Meta model. The Meta model covers both structure
and behaviour elements that represent ERT systems. The construction of the ROPES
metamodel is little bit difficult due to its development process. Each phase of
development process was producing different artefacts which are includes in UML 2.0
superstructure metamodel. Moreover, the transformation from ROPES model into
metamodel must explicitly transform smoothly to ensure each model element will be
putting together in ROPES metamodel.
4.5
Integrated Meta model of POAD and ROPES
POAD Meta model contains structural elements and describes on how the
patterns are composed into each software development phase. Patterns are the main
elements in POAD methodology which derives from the analysis until design phase.
Patterns are glued at high level of abstraction and systematically derived from phase to
another. ROPES Meta model describes the ERT development process which is covers
both structural and behavioural elements. Unlike POAD, ROPES does not explicitly
focus the composition of pattern at each phase. This section focuses on how both Meta
model will be integrated in order to motivate the use of pattern in ERT system
development process early in analysis phase. Initially the mapping process of the both
methodology and Meta model are conducted. Then, the new software development
processes are introduced in order to capture the integrated Meta model development
process.
4.5.1
Mapping POAD to ROPES
POAD and ROPES methodology defines the software development process.
POAD capture the structural elements of software, using pattern as a main components
and they are not domain specific. ROPES cover both structural and behavioural elements
that subject to ERT domain and did not explicitly focus on pattern. To enable smooth
integration POAD model and ROPES model, each elements of POAD metamodel must
provide necessary information in order to integrate with ROPES metamodel. There are
issues that need to be resolved: (1) how to map POAD metamodel to ROPES
metamodel? (2) how to explicitly expressed real time behaviour elements? (3) how to
map POAD process into ROPES process?
4.5.1.1 Mapping POAD Metamodel to ROPES Metamodel
Mapping POAD metamodel to ROPES metamodel is essential process probably
to discover the similarity of POAD metamodel and ROPES metamodel. POAD
metamodel consists seven primary elements as mention in previous section while
ROPES metamodel contains a structural and behaviour UML metamodel elements. By
conducting the mapping process, the similarity of both metamodel can be identified and
furthermore the integrated POAD and ROPES metamodel can be achieved. Direct
migration of two methodologies is possible due to the similarity in software
development definition.
In POAD, Pattern is a set of collaborating classes that solves a specific design
problem and cannot inherit internal parts from other patterns. In contrary, Pattern is not
Package or Subsystem. Package is a collection of ModelElements and can be parents or
children in an inheritance tree. Hence, Package can import or export its internal
elements to other Package. However, in POAD, Package is used in modelling the
patterns with some limitation and constraint. The limitation is relationship and
interfaces. The relationship between patterns in POAD is dependency relationship that is
semantically a uses relationship and is not import or export relationship. Thus, interfaces
between patterns could be the classes itself or operations on interfaces classes. Then,
subsystem is generalization of Package and cannot be considered as patterns.
In POAD, there are three types of interfaces which are PatternInterface,
PatternControlInterface and InterfaceBinder. All these elements are defined specifically
for Pattern metamodel. Its have own definition and purposes. Then, its definition is
different from interface elements in ROPES. Interface in ROPES defines the set of
operation or classes that how two subsystem components interfaces each other. Thus,
subsystem and component is physical view of the system rather than logical view. Then,
the definition of POAD interfaces is has different semantics meaning from ROPES
interface definition.
However, both metamodel consists of similar elements which are Relationship,
Constraint and Real-time behaviour. Relationship defines the association or dependency
between classes or objects in the software modelling. Constraint is about non-functional
properties of systems and related to QoS which captured the fault tolerance,
performance, scheduling and task. Real-time behaviour has four categories which are
passive, active, event and implementation independence class (Jawawi, 2006). A passive
class that does not has its own thread of control. An active is a class that has its own
thread. An Event class is an active class where behaviour is triggered by event.
Implementation independent class is a class whose real-time behaviour can only
specified during the implementation phase. Both POAD and ROPES have real time
behaviour. In POAD, real time behaviour is placed in class classifier while in ROPES,
real time behaviour is placed under Task elements. This is because ROPES has Resource
elements in its metamodel that manages all task and real time behaviour of the system.
Table 4.4 shows the mapping metamodel of POAD and ROPES.
Table 4.4: Mapping POAD to ROPES Metamodel
UML Metamodel
POAD
ROPES
Relationship
Relationship
Same
defines the association or
dependency
between
classes or objects in the
software modelling
Constraint
Constraint is about
non-functional
Same
properties
of systems and related to
QoS which captured the
fault
tolerance,
performance,
scheduling
and task
Real-time Behaviour
Consists
passive,
event
active,
Same
and
implementation
independent class
Pattern
a
set
of
Same
collaborating classes that
solves a specific design
problem
Package
Pattern is grouped
Package
is
as Package but requires collection
a
of
additional stereotyping to ModelElements and can be
reflect the pattern type and represented
relationship
in
domain
between analysis or subsystem.
patterns.
Subsystem
NA
subsystem
is
generalization of Package
and
represent
the
subsystem of the system.
Component
POAD
component
defines
as
components
Component
design ROPES
which
is
in
physical
is packages used to model
composed a set of classes source code or physical
at the design phase.
Class
database.
A specification for
Same
a set of objects and exist at
design time.
PatternInterface
A set of classes and
NA
operations that define how
the pattern interfaces with
the other patterns
PatternControlInterfa
NA
ce
InterfaceBinder
It used to connect
PatternInterface
with
NA
its
internal classes
PatternAssociation
It
shows
relationship
the
NA
between
pattern interfaces
PatternDependency
It
relationship
shows
the
NA
between
patterns
interface
NA
the set of operation
or classes that how two
subsystem
components
interfaces each other
Table 4.4 illustrates the metamodel mapping between POAD and ROPES
methodology. From the table, there are five UML metamodels which are having same
semantic description for both methodologies. The five UML metamodels are
Relationship, Constraint, Real-time Behaviour, Pattern and Class. These elements are
used in constructing a software model in POAD and ROPES methodology. However,
there is two UML metamodels that have different definition between two models which
are Package and Component.
Package is general purposes UML modelling for grouping elements into groups.
They provide a hierarchical view and visibility mechanism to control the visibility of the
elements of the package. In POAD, packages are used in modelling patterns. Pattern is a
collection of collaborating class that solves a specific problem. Using packages to model
patterns requires additional stereotyping and different definition of relationship and
interfaces. However, in ROPES, packages are used to represent the domain analysis of
the system and each package is usually a part of another domain. Meaning that, the
integrated ROPES and POAD metamodel allows the Package to be represented in two
ways which are 1) Patterns and 2) Subsystem. Each Package delivers different purposes
depend on it uses.
Component represents a modular, deployable and replaceable part of a system
that encapsulates implementation and exposes a set of interfaces (UML 2002). In
ROPES, a component is used to represents physical packages that used to model source
code and physical database. Thus, physical packaging is used to define implementation
deliverables. Unlike ROPES, in POAD patterns are visualized as logical packaging and
as well as Component and used to organize a set of collaborating classes.
From the metamodel view, the integrated metamodel of POAD and ROPES can
be constructed by plug in POAD metamodel into ROPES metamodel at the respective
level as figured in figure 4.4.
From POAD
From
POAD
Figure 4.4: ROPES + POAD Metamodel
Figure 4.4 illustrates the integrated POAD and ROPES metamodel. From the
figure, ROPES is used as main methodology. Then, all the POAD UML metamodels
were added into ROPES metamodel. Pattern metamodel in ROPES is replaced by
POAD metamodel. Afterthat, Class metamodel is transformed under the Pattern classes
to show that every class construction in enhancement of ROPES will be illustrated as a
pattern. Then, real time behaviour in POAD is integrated with POAD.
The main issue in the integrated POAD and ROPES metamodel is the definition
of Package and Component. After the integration of both metamodel, the definition of
Package and Component in POAD and ROPES still does not change. Using packages to
illustrate pattern and domain analysis is needed but they have different semantics and
purposes. Furthermore, pattern cannot be modelled using UML component because they
are conceptually different encapsulation. Hence, it is semantically incorrect to model
pattern using component diagram. Because of this restriction, an enhancement of
ROPES methodology will use component as logical (pattern) and physical views. To
conclude, in the integrated ROPES and POAD metamodel, Package is used to visualize
the patterns and subsystems. Hence, Component is used to visualize physical views of
the system as well as patterns.
4.5.1.2 Validation of The Integrated ROPES and POAD Metamodel
The integrated ROPES and POAD metamodel have been developed in the
previous chapter to enable the uses of pattern in ROPES methodology. In order to
validate whether the integrated metamodel is well defined or not, the validation process
will used MOF (OMG, 2007) profiles from OMG.
MOF provides a metadata management and a set of metadata services to enable
the development of model and metadata driven systems. MOF also defines a metamodel
required for composing and validating the model development including UML. In
general, each proposed metamodel that has been developed must be undergoing
validation process towards MOF. This is to ensure the correctness of the proposed
metamodel. Therefore, the integrated ROPES and POAD metamodel were verified using
MOF. The verification process includes each proposed metamodel elements is an
instance of MOF and conforms to rule of MOF. Before that, the proposed metamodel
and MOF elements must be transformed into graph theory in order to develop the
mathematical equation between MOF and proposed metamodel. Figure 4.5 shows the
graph theory for MOF.
Model element
TypedElement
Namespace
Feature
Generalized
Element
Package
Behavioural
Feature
Structural
Feature
Operation
Attribute
Classifier
Class
Association
Figure 4.5: MOF Graph
Figure 4.5 illustrates the MOF graph. The graph was constructed based on MOF
metamodel and contains a node and arc. A node represents an element in MOF and arc
represents the relationship between elements. Figure 4.6 demonstrates the graph for
proposed metamodel.
Interaction
Syste
m
Statemachine
Activity
Node
Relationship
Behaviour
Attribute
Use Case
Class
Pattern
Package
Operation
Real-time
behaviour
Subsystem
Dependency
PatternDependenc
y
PatternInterface
Component
Interface
PatternControlInterfac
e
Port
PatternAssociation
MessageEvent
MessageQueue
Communication
MessageProtocol
Figure 4.6: Graph for The integrated ROPES and POAD metamodel
Both graphs will be used to develop a simple mathematical equation that shows
the relationship between MOF and proposed metamodel. The mathematical equation
must show each proposed metamodel nodes is an instance of MOF nodes and conforms
to rule of MOF. MOF graph can be viewed as:
The integrated ROPES and POAD metamodel graph can be viewed as:
MOF becomes a guardian to check the consistency of proposed metamodel
graph. To check the consistency, all nodes of the proposed metamodel must be mapped
onto MOF nodes. The equation to check the consistency as follows:
……………………… (1)
…………………….. (2)
……….
(3)
…………………… (4)
…………….. (5)
The equation (1), (2) and (5) shows the function of IMGraph to MOF. Each node
in both graphs must subset with the defined function. Then, each node in IMGraph must
be subset in MOF nodes. In order to prove the consistency of IMGraph, the function
from IMGraph to MOF is defined as follows:
All arcs in IMGraph are mapped on the MOF nodes. The equation (3) and (4)
shows if there an arc in two nodes in IMGraph, and then there should be an arc for two
nodes in MOF as shown in Figure 4.7.
IMGraph
MOF
Model element
Class (Classifier)
Pattern (Namespace)
Namespace
PatternDependency
(Model element)
Generalized
Element
PatternControlInterface
(Classifier)
Package
Classifier
Figure 4.7: Equation (3) and (4) Mapping
This results shows that all IMGraph is kind of ModelElement that exist in MOF.
Therefore, the integrated ROPES and POAD metamodel was validated by using the
graph theory of MOF and it is proved that the proposed metamodel fulfil all of the MOF
specification.
4.5.1.3 Mapping ROPES Process to POAD Process
ROPES and POAD have a similarity in development phase. Both methodology
have analysis and design phase which consists of initial finding on system requirements.
However, they have different contents or activities for each development phase. In order
to integrate both metamodel, we must mapping ROPES development phase to POAD.
By conducting the mapping process, we can identify the relationship both development
phase. Table 4.5 illustrates the mapping of development phase for both methodologies.
Table 4.5: ROPES and POAD Development Phase Mapping
Develop
ROPES
POAD
ment phase
Analysis Requirements
Pattern Selection
System engineering
Object Domain
Design
Architectural
Pattern
Level
diagram
Pattern
Level
diagram with interface
Mechanistic
Detailed
internal
pattern
Detailed Design
Table 4.5 shows the mapping process of POAD and ROPES development phase.
In analysis phase, ROPES define details description of analysis system requirements and
covers both structural and behaviour elements while POAD define the patterns selection
based on system requirement analysis. In design phase, ROPES have three level of
design while in POAD, system design only covers the pattern diagram, pattern diagram
with interface and detailed patterns internal classes.
Generally, this project aims in to enhance the ROPES methodology by
promoting the use of pattern from the early phase. Thus, ROPES methodology was
chosen as a main components and combining with the POAD process. In the ROPES
analysis phase, each activity must explicitly address the whole system requirements
including software and hardware, object relationship and system behaviour elements.
After those activities are conducted, the massive and concrete requirements are
produced. Then, POAD analysis process is adapted. We use concrete requirements that
are produced in ROPES as an input into the POAD analysis. Furthermore, POAD
analysis will analyse the inputs and select the suitable patterns in pattern library. Patterns
that are selected then will be used as the main components to the design phase.
In the design phase, ROPES consists of three levels of designing the software
which are architectural, mechanistic and detailed design. Architectural design consists of
domain analysis, subsystem, safety, and task concurrency and resources. Safety and task
activities are real time behaviour. Subsystem consists of a set of components interact
each other to represent the subsystem structure and behaviour. From the analysis phase,
a set of patterns are selected and will be used in the design phase. However, this process
is an iterative process and if there any addition or correction of patterns, it will reverse
back into analysis until the concrete patterns are achieved.
4.5.1.4 Initial Result of POAD + ROPES Development Process
ROPES development process can be enhanced by integrating with POAD
process. POAD are focusing on using patterns from analysis until design phase. Thus,
ROPES and POAD both software development methodology and have a similarity in
term on development process. The only differences between both methodologies are
POAD is not domain specific and using pattern as main component while ROPES is
specific for ERT domain and did not explicitly address the uses of pattern. Moreover,
combining POAD into ROPES can motivate the use of pattern from analysis until design
phase. Figure 4.8 shows the POAD + ROPES development process.
ROPES
POAD
Requirements
System
engineering
Analysis
Pattern Selection
Object
Analysis
Validate
pattern
Need improvement
Yes
Architectural
Design
Validate
pattern
Need improvement
Design
Pattern Level Diagram
Pattern Level Diagram
with interfaces
Design Refinement
Detailed Pattern
Internal
Yes
Mechanistic
Detailed
design
Figure 4.8: ROPES + POAD Development Process
Figure 4.8 shows the ROPES + POAD development process. The combination
POAD and ROPES development process can be done by mapping both development
processes together for each phase. The new development process goals are to promote
the use of patterns from analysis to design phase and subject to ERT domain. From the
figure, the ROPES and POAD development phase is complement each other. The dash
boxes represent the ROPES process and complete boxes represent POAD process. Then,
the dash arrow represents the ROPES realization process to POAD process.
In ROPES, system engineering and object analysis process will conduct the
intensive analysis of the whole system and each object structural and behaviour
elements. During the process, every input will be reflecting into the POAD process
which is pattern selection. Pattern selection process is responsible to make analysis input
from ROPES and retrieve suitable patterns from pattern library. By doing this, system
engineering and object analysis in ROPES will produce a set of pattern that will be used
in design phase. However, before conducting design phase, analysis stage must validate
the selected pattern whether it meets system requirements or not. If not, reverse back to
analysis phase, otherwise proceed to design phase.
In ROPES, design phase consists of architectural, mechanistic and detail design.
Architectural design defines the system architecture from subsystem, component,
domain, concurrency, task and resource view. Here again, the patterns that have been
selected in analysis phase will be used to defines the output artefacts in architectural
design. The pattern level diagram and pattern level with interfaces will be decided and
regularly check with the architectural design requirements. If there any conflicts with
selected pattern, the process will reverse back to analysis phase, otherwise it will
proceed to mechanistic design.
In mechanistic design, each pattern will elaborate its internal classes. Pattern
internal classes will represent the detailed logical implementation of the system and
reflects with the mechanistic design. After finishing this phase, it will go through into
detailed design.
From this explanation, the ROPES + POAD development process will use
pattern as main features. This process can be done by realize of each output in ROPES
analysis into pattern selection process in POAD. Then, the patterns that have been
selected in analysis phase will be used in design phase. By doing this, a set of patterns
are produced and will be represent as logical implementation of the ERT system.
4.5.2
Summary
This chapter presents the integrated metamodel of POAD and ROPES
methodology. The integrated metamodel aims to motivate the use of patterns at software
development process that subject to ERT system. ERT system is the crucial software due
to structural and behavioural elements. In addition, ERT system highly dependent on
time constraint, task distribution and concurrency resource sharing (Crnkovic, 2003 ).
Therefore, the ERT system development process is complex because of the complexity
of real time properties. This result was inspiring the patterns to play the main roles to
increase the software quality as well as decrease the software development cost and
time.
There are two important elements in this chapter need to be considered. The
elements are 1) POAD and ROPES metamodel and 2) POAD and ROPES metamodel
integration. The UML metamodel is used as a modelling languages to defines the metamodels for both methodology. POAD enables the semantic description in their
metamodel by defining the Pattern name, PatternInterface, PatternDependency, Class,
Constraint,
Relationship,
InterfaceBinder,
PatternAssociation
and
PatternControlInterface. All of these elements will be used to construct POAD
metamodel. The POAD metamodel have been enhanced (Jawawi, 2006) from the
original metamodel in order to capture real time behaviour requirements. ROPES define
the semantic description in their metamodel by using UML metamodel for structural,
behaviour, real-time properties and Core profiles. By identifying the ROPES metamodel,
then we construct the ROPES metamodel.
The reasons of creating metamodel for both methodologies are to identify
the semantic description of both models. By doing this, the integrated metamodel of
POAD and ROPES can be achieved. However, before both metamodel will be
integrated, the mapping process and metamodel for both POAD and ROPES need to be
considered. In addition, the mapping process can ensure what or where level need to be
integrated as shown in Figure 4.7. Then, the integrated metamodel of POAD and
ROPES can be obtained.
After the integrated ROPES and POAD metamodel was developed, there is some
mechanism to validate the proposed metamodel. The validation that has been used is
MOF and graph theory. The MOF and proposed metamodel was developed in graph
theory to discover what is the relationship between two graphs by considering the
elements and functions. The elements represent a node and the relationship represents an
arc. This is to ensure that all proposes metamodel nodes are an instance of MOF nodes.
To ensure the proposed metamodel graph has conforms the rules of MOF, the arc has
been used as a function. The results shows that the proposed metamodel was well
defined regarding on MOF.
The effectiveness of this integrated metamodel are to motivate the use of pattern
early at analysis phase and systematically derived until design phase that subject to ERT
system. ROPES are a methodology that covers both structural and behavioural elements
as well as real-time properties. The use of pattern for the whole development process can
ensure the high software reuse, software quality and decreasing of software development
time and cost.
CHAPTER 5
THE INTEGRATED POAD AND ROPES SOFTWARE PROCESS
5.1
Introduction
This chapter describes the software process for integrated ROPES and POAD
metamodel explicitly based on ROPES and POAD integrated metamodel that has been
constructed in Chapter 4. Software Process Engineering Meta model (SPEM) 2.0 is used
to specify the process model.
5.2
Software Process Engineering Model (SPEM)
Software Process Engineering Model (SPEM) is process engineering meta-model
which can provide valuable concepts for modelling, documenting, organizing and
enacting software development process and contents. SPEM metamodel is based on
UML specification and the early version of SPEM is SPEM 1.x that based on UML 1.4
and hence, is extended to SPEM 2.0 based on UML 2.0 Infrastructure specification. A
SPEM 2.0 main aim is used to describe the concrete software development process.
SPEM 2.0 is solely to enable the systematic software development explicitly
from the development teams, process and contents. Development teams can easily
access the necessary information when they need and exchange the necessary
information across team members. The information of software development
systematically separated from its process and contents and purposely to standardize the
property format of documentation of which they need to refer. To realize these needs,
SPEM 2.0 is constructing the metamodel based on UML 2.0 specification.
SPEM 2.0 embodies of seven metamodel which are Core, Process Structure,
Process Behaviour, Method Content, Managed Content, Process with Methods and
Method Plug In. These metamodel is used to defines the SPEM 2.0 metamodel and its
structure will enabling the software development teams to choose the generic behaviour
modelling approach and gives specifics structures to enhance the behaviour models that
are describing development models. To realize the implementation of integrated ROPES
and POAD software process, we use Magic Draw 16.5 tool with SPEM profile.
5.3
The Process Model
Process model is the process that embodies a few processes that have the same
nature. Process model also occurring at the type level which means the process that has
been identified can be used repeatedly for the other software development activities.
Thus, process model is important to explicitly tracking the occurrence of the whole
process, defines the specific process that what it’s should be performed and provides the
necessary information of the process. Therefore, the process model for integrated
metamodel of ROPES and POAD is defined to explicitly describing the concrete
software development and at the same time to show the existence the uses of patterns.
Based on Figure 4.5, the integrated of ROPES and POAD metamodel has the new
software development process which is enabling the uses of patterns in ROPES
methodology.
The process model for integrated of ROPES and POAD metamodel is defined by
using SPEM 2.0 profile. Based on SPEM 2.0 profile, the process model is divided into
two categories which are Method Content and Process Content. Figure 5.1 shows the
whole framework of process model for integrated of ROPES and POAD metamodel.
Figure 5.1: Process Model Framework
Figure 5.1 shows process model framework for the integrated ROPES and POAD
metamodel. This framework consists of the structure of method framework. Method
framework structure consists of Method Content and Process Content. Both contents
will be directed or guided by the Guidance at the intersection in order to provide
background for Method Content and process. Method Content is a metamodel package
that primarily defines the resources of the software development such as users and
groups to build up the development knowledge base. Knowledge base is the collection
of software development resource descriptions and independent of any process related
and projects. The knowledge bases for ROPES+POAD process model framework are
Roles, Work Product, Task and Guideline definition.
Process Content is a process which related to project that specific to any type of
development level. It uses the Method Content elements to detail up the specific process
of development. The Process Content elements for the integrated ROPES and POAD
software process framework are Analysis Process and Design Process. Furthermore,
both contents were connected to Method Plugin. In details, Method Plugin is a Package
that represents a physical container for Method Content and Process Content. It defines a
granularity level for the modularization and organization of for Method Content and
Process Content. A Method Plug embodies in the Process Based Library which contains
all the core elements of SPEM 2.0. Figure 5.2 shows the details of Process Content and
Method Content elements.
Figure 5.2: Details of Process Content and Method Content Elements
5.3.1 Method Content
Method Content contains a few main elements in software development process.
The integrated ROPES and POAD software process have four elements which are Roles,
Work Product, Task and Guidance definition. This element provides step-by-step
explanation by describing how specific fine-granular processes are achieved by which
roles and resources. Some other process might reuse the Method Content elements for
different purposes. Thus, user does not need to specify the fine-structured process of the
development because Method Content only provides the knowledge base that can be
reused for another processes.
5.3.1.1 Role Definition
Role definition defines a set of responsibilities, skills and expertise of an
individual or a set of individual. Roles definition is not a person but rather to the
definition of responsibilities. When the Role definition has been defined, project
manager will responsible to map between individual to Role. Role definitions are used
by Task definition to identify whose perform the task and responsible to the Work
Product. Figure 5.3 shows the Role definition that has been defined in the integrated
ROPES and POAD software process.
Figure 5.3: Roles Definition for ROPES+POAD Process Model
Figure 5.3 shows the Role definition for ROPES+POAD process model. Each
Role compositions have been attached to the CompositeRole that grouping the entire
Role. There are four Roles which are System Architecture, System Analyst, System
Designer and Use Case Specifier. Each Role represents the skills and responsibilities
that should be performed to the set of Task definition.
5.3.1.2 Work Product Definition
Work Product definition is representing as input and output of the process. It is
used, modified and produced by Task. Role may use Work Product to perform a Task
and produce Work Product as a Task process output. For the integrated ROPES and
POAD software process, there are two major packages which are Work Product
definition for Analysis and Design. Figure 5.4 shows the Analysis Work Product
definition for the integrated ROPES and POAD software process.
Figure 5.4: Analysis Work Product Definition for ROPES+POAD Process
Model
Figure 5.4 shows the Analysis Work Product definition for the integrated ROPES
and POAD software process. They compromise three major Work Product definitions
which are Requirement Analysis, System Analysis and Object Analysis. This Work
Product represents the Analysis process in ROPES methodology. Analysis process in
ROPES consists of Requirement, System and Objects analysis process and resemble to
Work Product definition. Analysis Work Product definition is important to provide
subtle information which will be used by Task. Requirement analysis Work Product
contains a set of related Work Product that represent in Artefact notation. The most
important element that has been produced here is a Set of Pattern Work Product
definition. The Set of Pattern has been derived early at analysis phase to ensure that a
Set of Pattern was produced in early stage so that System Designer will use this pattern
to design the system. System Analysis Work Product embodies a Hardware, Software,
Architecture and Executable Work Product definition. Object Analysis Work Product
consists of Object Structural and Object Behavioural Work Product. Moreover, Figure
5.5 shows the Design Work Product definition for ROPES+POAD process model.
Figure 5.5: Design Work Product Definition for ROPES+POAD Process
Model
Figure 5.5 shows the Design Work Product definition for the integrated ROPES
and POAD software process. They compromise three major Work Product definitions
which are Architectural, Mechanistic and Detailed Design. This Work Product
represents the design process in ROPES methodology. Architectural Design Work
Product contains Architectural design model that are composed with the Pattern Level
Diagram and Pattern Level Diagram with Interface Work Product definition. This Work
Product definition provides a critical output by Task because they are all compromise
the overall system design. Then, Mechanistic Design Work Product will provide
Detailed Pattern Internal Work Product definition. This artefact will provide the details
of system class diagram based on design patterns.
5.3.1.3 Task Definition
Task definition is a set of work in the software development process and it is
used as an element of defining a process. Each Task definition is assigned to the specific
Role definition and using Work Product definition as input and output. Task definition
main principles are to define the process of works and sometimes if it is too complex,
Task definition will use Step to describe the process. Figure 5.6 shows the Task
definition for the integrated ROPES and POAD software process.
Figure 5.6: Task Definition for ROPES+POAD Process Model
Figure 5.6 shows the Task definition for the integrated ROPES and POAD
software process. From the diagram, there are special notations that represent the class
which are Category, Discipline and Guideline. Category is used to categorize the process
content based on user criteria. Discipline defines the group of Task definition and
Guideline defines the additional information that might help to accelerate the process.
Iteration category was defined to represent what kind of software development
was conducted that exists in Software Engineering methodology based on user criteria.
Iteration was selected in order to adapt the suitability of integrated ROPES and POAD
software process. This is to enable pattern discovery process more systematic and able to
produce firm a set of patterns. Iteration category contains two Disciplines which are
System Analysis and System Design. System Analysis Discipline embodies a three Task
definition which are Requirement, System Analysis and Object Analysis. These Tasks
also have been categorized by a Use Case Development category and a user might
provide a Guideline (Use case template) to this category. System Design discipline
contains three Tasks which are Architectural, Mechanistic and Detailed design. These
Tasks have been categorized by a Software Pattern category that has Pattern Library
Template and Pattern Level with Interface.
5.3.2 Process Content
Process Content defines a software development process with a special structured
that refers the project development activities. Process Contents contain a set of process
that represents the project process architecture such as Process Structure, Process
Behaviour and Process with Method. Process Structure contains the basic structural
elements for defining development processes which are describing in well-formed
structure from its lifecycle until resources hence, how the projects shall be executed.
Besides that, Process Behaviour feeds the implementers to design the generic modelling
approach that fits their needs. However, ROPES+POAD process model is using Process
with Method approaches to define its process. It is because SPEM 2.0 has a
characteristic that separate between method and process. This approach can fully utilize
the separation of Method Content from processes and consequently the reusability of
Method Contents and processes can be achieved.
ROPES+POAD process model consists of two activities which are Analysis
Process and Design Process. Both activities were attached to the Process Pattern
elements. Process Patterns are reusable building blocks of process and ROPES+POAD
process patterns can be reused for another projects. Moreover, before the details of
Analysis and Design process to be described, the overall flow of process of the
integrated ROPES and POAD software process must be identified. The flow of
integrated ROPES and POAD software process was able to show how the integrated
process will be executed on which phase to which process. Figure 5.7 shows the flow of
process for the integrated ROPES and POAD software process.
Figure 5.7: Process of Flow of the Integrated ROPES and POAD Software
Process
Figure 5.7 demonstrates the flow of process for the integrated ROPES and
POAD software process. The flow consists of two phase which are Analysis and Design
includes with Task definition. Each phase execute specific task definition which already
declared in Method Content. The flow of integrated ROPES and POAD software process
is using ROPES process and merged with POAD process in order to enable pattern
oriented development. The arrows are representing the flow of process between task
definitions.
5.3.2.1 Analysis Process
Analysis Process defines the process of collecting the system requirements from
the higher level until the low level of the system. Analysis Process explicitly derived
from the ROPES analysis process. The realization of ROPES analysis process into
process model is important to provide a concrete explanation of its development. Figure
5.8 shows the Analysis Process activity.
Figure 5.8: Analysis Process for ROPES+POAD Process Model
Figure 5.8 shows the Analysis Process activity in ROPES+POAD process model.
Analysis Process defines the system analysis in depth based on ROPES methodology
process. These processes are divided into two activities which are Understand
Stakeholder Needs and Define the System. The first activity was performed by System
Architecture whereby they define the overall system architecture including system’s
vision and mission. In addition, Define the System Activity is a predecessor of first
activity and was performed after the first activity was completed. Define the System
activity was performed by System Analyst and System Analyst will perform the Task
Definition realization called Task Use.
Task Use has three tasks which are Requirement Analysis, System Analysis and
Object Analysis. Requirement Analysis is a Task definition that was defined in Method
Content package and then was realized to specific Task Use. Requirements analysis has
complex process and will be described in Step meta-class. Before that, Requirement
analysis will produce subtle Work Product Use named Use Case Model. Work Product
Use for Use Case Model is the realization from Work Product Definition in Method
Content package. Thus, Work Product Use for Use Case Model will be traced and
mapped to the Set of Design Pattern (Work Product Definition). Figure 5.9 shows the
Requirement Analysis Task Use Step.
Figure 5.9: Requirement Analysis Task Use Step
Figure 5.9 shows the Requirement Analysis Task Use Step. This Step is the
process flow obtained from ROPES methodology. The process that was derived from
POAD analysis process was represented in dash box notation which is “Pattern
Selection: Pattern Selection Process”. This process then will be directed to another Step
process as shown in Figure 5.10.
Figure 5.10: Pattern Selection: Pattern Selection Process Step
Figure 5.10 shows the “Pattern Selection: Pattern Selection Process” step that
was originally derived from POAD analysis process. This process tends to find and
select the suitable design patterns of the system. After that, System Analysis Task Use
takes part as the next phase.
System Analysis Task Use is composed several step and has complex process. It
originally derived form Task Definition in Method Content package. Figure 5.11
illustrates
the
System
Analysis
Task
Use
Step.
Figure 5.11: System Analysis Task Use Step
Figure 5.11 shows the process step in System Analysis Task Use. This process
was derived from ROPES process and intended to produce a set of hardware and
hardware specification and architectural model as well. After this process was
completed, Object Analysis Task Use will be implemented to discover the objects and
system classes.
Object Analysis Task Use is originally from ROPES process and will link up
with the POAD analysis process. The POAD analysis process will be reused again in
this process in order to produce a firm set of patterns. The firm set of pattern is crucial to
be produced here in order to get well-formed system design architecture that will be
used in Design Process. Figure 5.12 shows the Object Analysis Task Use Step.
Figure 5.12: Object Analysis Task Use Step
Figure 5.12 shows the Object Analysis Task Use Step The dash box represent the
“: Pattern Selection Process” as shown in Figure 5.8 in order to find and select design
patterns. It is clearly shows that Analysis Process activity is originally from ROPES
process and was merged with POAD process to find and create a set of patterns. The
merging process of ROPES and POAD is important to support the new development
process of integrated ROPES and POAD metamodel.
5.3.2.2 Design Process
Design Process is the second phase of software development. Design process is
the process of designing the system based on its requirement. Figure 5.13 shows the
Design Process activity.
Figure 5.13: Design Process for ROPES+POAD Process Model
Figure 5.13 shows the Design Process for ROPES+POAD process model. It
contains two activities which are Define the System and Define System Design. Then,
Define the System activity is from preceding activities in Analysis Process and becomes
predecessor to Define System Design activity. Furthermore, Define System Design
activity will be performed by Method Content elements. For the Define System Design
activity, System Designer will responsible to perform a set of Task Use that the
realization from Task Definition. The Tasks Use items are Architectural, Mechanistic
and Detailed Design.
Architectural Design task use is a set of complex process that needs to be
executed step-by-step. The execution process will use Step elements to shows the whole
flow of process. In addition, Architectural Design task use has one mandatory input
which is a Set of Design Pattern. This Work Product use is essential because it contains
necessary information for designing a system. Then, the mandatory output for this task
use is Architectural design model (Work Product use) that has an important content
tracing. Content trace for Architectural design model (Work Product use) is Pattern
level diagram and Pattern level diagram with interface. Both items are Work Product
definition in Method Content elements. Then, Architectural Design task use itself has
Step process as shown in Figure 5.14.
Figure 5.14: Architectural Design Task Use Step
Figure 5.14 shows the Architectural Design Task Use Step that follows step-bystep flow from ROPES process. Dash box step represents the thread for the “Design
Pattern Modification” process that originally from POAD design phase. POAD design
phase was embedded to this process in order to initiate design pattern modification.
Figure 5.15 illustrates Design Pattern Modification Process Flow.
Figure 5.15: Design Pattern Modification Process Flow
Figure 5.15 was originally derived from POAD early design phase to define
Pattern level diagram and Pattern level diagram with interface diagram. This process is
crucial since it must briefly define the information of patterns.
Mechanistic Design Task Use is the process of defining the structure and
behaviour model. Before that, this task use has one mandatory input which is Pattern
level diagram with interface (Work Product definition) and produce one subtle output;
Detailed Pattern Internal Work Product Use. Figure 5.16 shows the Step process of
Mechanistic Design.
Figure 5.16: Mechanistic Design Task Use Step Process
Figure 5.16 was originally derived from ROPES design phase and was
embedding with POAD design detailed phase that represented with dash box diagram.
This step is to identify the detailed internal class of the patterns. Figure 5.17 shows the
POAD design detailed phase flow process.
Figure 5.17: Design Pattern Internal Class Process Flow
Detailed Design Task Use is the final tasks that need to be executed after
previous task is completed. This task use own one mandatory output which is Design
detailed model (Work Product Use). Figure 5.18 shows the Detailed Design task use
Step process that originally derived form ROPES design phase.
Figure 5.18: Detailed Design Task Use Step Process
From the Design Process diagram, it shows that all the elements are originally
derived from Method Content elements such as Roles, Task and Work Product
definition. The Method Use is the realization of Method Content elements and each task
use represent a set of complex process. The complex process then represent in Step
elements.
5.4
Discussion On The Proposed Software Process
The integrated ROPES and POAD software process consists of two phase 1)
Analysis and 2) Design. These new process was introduced explicitly to enable the uses
of patterns in early phase and systematically. In seeking to demonstrate the efficacy of
the integrated ROPES and POAD software process, the most compelling form of
analysis and design would be to quantitatively show how adopting ROPES and POAD
methodology could bring some improvement of the new process to a standard set of
software development. The discussion of this chapter is twofold. Firstly, what is the
integration point of two processes of methodology need to be done and how to
implement it in order to gain a smooth integrated process? Secondly, there has been a
reviewing on the new process in context of its applicability. This shortcoming is
identified by examining the impact on the new process of adopting the uses of pattern in
ROPES and consequently will answer all the project objectives and motivations that
have been identified in Chapter 1.
The integration of ROPES and POAD is essential to present exactly the uses of
pattern in software development. In ROPES, Analysis phase contains of three processes
which are Requirement, System and Object analysis. To seek the appropriate level of
adopting POAD analysis process in ROPES, the integration will be executed at
Requirement and Object analysis process. Both processes describe the structural and
behaviour information of the system which will be subtle information to select suitable
patterns. After the integration points have been identified, POAD analysis process will
be implemented after system behaviour has been identified. It is important because the
system behaviour tells the whole story how the system should be execute and from there,
the suitable patterns can be selected. Furthermore, in Design phase, POAD design
process will be adapted to the Architectural and Mechanistic design in ROPES. In
Architectural design, POAD design processes which are Pattern Level Diagram and
Pattern Level Diagram with interface will defined because Architectural design define
the package and subsystem of the system. Thus, Detailed Pattern Internal Class will be
defined in Mechanistic design because this process responsible for class diagrams
construction.
After the integrated ROPES and POAD software process was designed, it clearly
shown that the new process was offering the big enhancements in ROPES. The uses of
patterns in ROPES methodology will start in early phase were systematically derived
until design phase. Thus, the complexity of system design will decreased because the
patterns feed the defined class diagrams in completing the design of the system class
diagrams.
The use of patterns in the integrated ROPES and POAD software process is at an
early phase of development, and yet the widespread acceptance of the concepts of a
pattern implies that patterns have a significant future in software development
methodology. Probably, the most important outstanding achievement for the integrated
ROPES and POAD software process is the applicability of pattern oriented development
in the integrated process.
5.5
Comparative Evaluation of Pattern Oriented Development
The integrated ROPES and POAD software process was introduced to enable
pattern oriented development in ROPES. Even though ROPES methodology already
using pattern in its software lifecycle, the process only occurs in design phase. To enable
the using of patterns systematically and furthermore, beginning in early phase, ROPES
was combined with POAD methodology. The results demonstrates, the integrated
ROPES and POAD software process enable the uses of patterns starting in analysis
phase and systematically derived until design phase.
In order to validate the usefulness of integrated ROPES and POAD software
process, the comparative evaluation of pattern oriented development was conducted.
(Simba and Jawawi, 2008) was introduced the integrated POAD and PECOS software
process. The comparative evaluation gives the background information needed to
establish the context of evaluation being conducted. It normally includes the pattern
criteria on which level of patterns are used and how the integration of two
methodologies was established. Table 5.1 shows the comparative evaluation of pattern
oriented development methodology.
Table 5.1: Comparative Evaluation on Pattern Oriented Development
Methodology
Criteria
POAD + PECOS
POAD + ROPES
Structural
Yes
Yes
N/A
Yes
Pattern Selection
Analysis
Analysis
Pattern
Analysis
Architectural
Features
Behaviour
Features
Level
Diagram
Pattern
Design
Level
Early Design
Diagram with Interface
Detailed
Pattern
Design
Design
Internal
Methodology
Integration Level
Architectural
Mechanistic
Design
Integration
Combination
Pattern Selection
Sequential
Iteration
Lifecycle
Table 5.1 demonstrates the comparative evaluation of pattern oriented
development between POAD+PECOS (Simba and Jawawi, 2008) and POAD+ROPES.
The comparison has been made to prove the applicability of POAD+ROPES towards
POAD+PECOS in term of pattern uses. There are some essential criteria have been
identified to compare both works which are system features, patterns, integration and
patterns selection lifecycle. The system features includes structural and behaviour that
represent the nature of the system. POAD+PECOS software process using POAD as
main methodology and PECOS as a supported methodology that enabling component
based development. This integrated software process describes the structural of the
system but not considering of system behaviour because of POAD constraints. In
contrary, POAD+ROPES were enabling the structural and behaviour of the system. In
addition, both integrated software process defined the pattern selection in analysis phase
and systematically derived until design phase.
For the integration level, POAD+PECOS are using integration approaches. This
means, the integration between POAD and PECOS occurs at intersection between them.
The pattern selection and pattern design mainly from POAD but the internal classes of
pattern using component notation that available in PECOS. In contrary, POAD+ROPES
are using combination approaches. This approach enables the whole POAD process to
be merged with the ROPES. This will enable the smooth process transactions between
POAD and ROPES phase. Thus, the traceability, requirement propagation and
trustworthy of the process can be firmed in term of software process quality.
Drawing these insights together, it is possible to define a canonical view of a
system. Both integrated software process express the composition of patterns in analysis
phase and connected together along the software development process until design
phase.
CHAPTER 6
ANALYSIS AND DESIGN OF FEEDBACK CONTROL SYSTEM
6.1
Introduction
This chapter describes the implementation of the Feedback Control System by
applying the integrated ROPES and POAD software process as described in Chapter 5.
The scopes of the implementation strictly on analysis and design phase. Thus, behaviour
of the system will be showed in simulation views by using Rhapsody I-Logix 6.0 tool.
6.2
Analysis Phase
An initial analysis of the system is essential to discover the functionality of the
system in users and stakeholders view. The functionality of the system can be thought as
functional and non-functional requirements. The functional requirements usually will be
viewed as black-box as a System Analyst investigate how the users interact with the
system in high level view. Hence, non-functional requirements specify the performance,
reliability and safety of the functional requirements.
In the integrated ROPES and POAD software process, Analysis Phase consists of
three analysis processes which are Requirement, System and Object analysis.
Requirement analysis is the process how to identify the system users and functionality.
System analysis is to identify the composition of the system such as subsystem. Object
analysis was divided into two categories which are Object Structural and Behaviour
analysis. Object Structural analysis is the process of identifying the objects in the system
and Object Behaviour analysis is the process to identify the behaviour of the objects
against the system.
The other kind of analysis is the pattern selection analysis which originally from
POAD methodology. Pattern selection analysis was combined into Requirement and
Object analysis in order to identify the suitable candidate of design pattern that will be
used in system design. Pattern selection process in early phase in ROPES is very
important to enable the consistency and systematic system development in order to
decrease the complexity of the system development.
6.2.1 Requirement Analysis
Requirements are essential in order to identify the system requirements.
In this case, Feedback Control System requirements are extracted by the System Analyst
so that they can be analysed and refined. In practical, the main tool that will use by
System Analyst to view the system requirements is Use Case. Use Case describes the
behaviour of the system in high level views by ignoring how the system was constructed
in details. This enables the visible views of the system by referring the information that
was given by the users and stakeholders.
6.2.1.1 Main Use Case
Feedback Control System (FCS) is the system that is used into the other system
in order to identify the error feedback of the system. The Use Case of the FCS was
constructed as shown in Figure 6.1.
Feedback Control System
Control
Configure
User
Acuator
Calculate Error
Monitor
Collect data
Sensor
Figure 6.1: FCS Use Case
Figure 6.1 shows the FCS Use Case. FCS Use Case consist three users called
Actor. The Actor of the system is User, Actuator and Sensor. In this case, User was
enabling to configure the system by setting the static indicator input that need to be
compared with the error data. Then, Actuator was responsible to control the Plant
operation and Sensor was responsible to monitor all the measured input taken from the
Plant. All the actors were associated with the respective system functionality that
represented in Use Case form.
Further analysis need to be done in order to discover the suitable patterns to
implement the functionalities of the system. To succeed this purpose, the Use Case
behaviour must be identified to capture how the system operate and to realize that,
System Analyst must develop Use Case Text, Sequence Diagram and State chart of each
identified Use Case.
6.2.1.2 Use Case Behaviour
Use cases defining the functional of the system. Use cases usually are text stories
and used to discover and record requirements. Furthermore, use case described the
action of an actor using the system to meet the goal. In order to visualize how each Use
cases meet the goal, Use Case Text was constructed and furthermore, sequence diagram
and state chart as well.
6.2.1.3 Use Case Text
The Use Case Text is more like text stories and describes how the system
operates by investigate how the Actor communicates with the system. Use Case Text do
not concern in details of the system because Use Case model only visible to the high
level view of the system (black-box). There are five Use Cases which are Configure,
Calculate Error, Collect Data, Control and Monitor. Figure 6.2 illustrates Use Case Text
for Configure Use Case.
UC-00: Configure
Scope
: FCS
Level
: System Goal
Primary Actor
: User
Include Use Case
: Error Calculation
Preconditions
: System was ready
Postconditions
: System was ready to be launched
Basic Flow
:
1. User examines all parts of devices to inspect the hardware.
2. User installs BIOS for main board of System.
3. System shows BIOS ready to execute.
4. User install Operating System (OS) into the System
5. System shows initial status to User.
6. User installs software and firmware for System communication.
7. System ready to execute the process.
Special Requirements
:

Central Processing Unit (CPU)

Monitor

Logic Machine
Frequency of
: Once
Occurrence
Figure 6.2: UC-00
Figure 6.2 shows the Use Case Text for Configure Use Case. Use Case Text
consists of items that specifically mention about system Use Case. They consists of
scope, level, primary actor, include use case, precondition, post condition, flow of
message, special requirements and frequency of occurrence. These items are responsible
to describe the behaviour of Use Case.
In details, Use Case Text for Configure describes the behaviour of its operation
itself. Configure Use Case scope only focusing on the implementation of FCS which is
system goal level. By referring the Use Case diagram, the Actor involves to execute the
Configure Use Case is User and includes with Error Calculation Use Case after the FCS
successful configured. Before the FCS will be configured by an Actor, they must fulfil
certain precondition which is the system itself must be ready to run. After the
configuration works, the expected post-condition is system was ready to be launched. In
general, all of this flow will be described in basic flow of the Configure use case to
describe how this use case should be executed. Apart from that, there are special
requirements included to ensure the successful of the Configure use case. The special
requirements needed are CPU, monitor and logic machine. The occurrence of Configure
use case behaviour only once. For conclusion, Use Case Text is the way to describe the
behaviour of the Use Case. Refer Appendix A for the rest of Use Case Text.
In general, many actions require relatively specific stories to perform. This may
be initiated by an introduction of system sequence diagram that may help the System
Analyst to have clear views how the messages between system and actor may exchange.
By observing the Use Case Text, sequence diagram and state chart of the Use Case will
be constructed.
6.2.1.4 Sequence Diagram
In this section, the sequence diagram of each use cases was developed based on
Use Case Text in the preceding sections. Sequence diagram show the sequence of
message between object and class. However, in requirement analysis, the message
exchange between system and actor. Figure 6.3 shows the sequence diagram of
Configure Use Case.
Configure Use Case Scenario
:User
System:FCS
installB IOS ()
statusBIOS()
InstallOS()
statusOS ()
configureSystem()
systemstatus()
Figure 6.3: Configure Use Case Sequence Diagram
Figure 6.3 shows the sequence diagram for Configure use case. The sequence
diagram was constructed based on Configure Use Case Text in order to shoe the
exchange messages between User and System. The User will send sequence of messages
to the System to initiate BIOS and Operating System (OS) installation. Then, System
will reply the messages to give permission to User to execute those tasks. After those
tasks are successful, User begin Configure the System and the System reply the
messages to User after all the operations are successful. Configure sequence diagram
exactly refer to Configure use case text regarding on its flow. Refer Appendix A for the
Monitor and Control Use Case.
Note that only three use case in FCS use case model was realized into sequence
diagram to show the behaviour of each use cases. Some of the messages are internal to
the system. Those three use cases are directly performs by Actor and again, sequence
diagram in requirement analysis only shows the exchange message between Actor and
System. This is to capture what are the messages between Actor and system. The other
two use cases which are Error Calculation and Collect Data will be realized in statechart
diagram.
6.2.1.5 Statechart
For the FCS Use Case model, there are two use cases which are using statechart
to describe the use case behaviour. The use cases are Error Collection and Collect Data.
Error Collection use case contains the most completes behaviour and may compose into
a few subsystems because of its complexity. However, the Error Calculation is an
autonomous behaviour so that, its behaviour will be shown in statechart diagram as
shown in Figure 6.4.
Cal cul ate Error Use Case Statechart
wai t for feedback data
dataReady
Read feedback data
Queing Data
Enqueue feedback data
update error data i nto database
Data Ready
Retri eve i nput data
Updating Data
Terminate
Process
Process data
Terminate
Process
Process data
produce error data
Produce feedback data
Process data
forward to feedforward subsystem
Updating Data
cal cul ate error data
Figure 6.4: Error Calculation Statechart
Figure 6.4 shows the statechart for Error Calculation use case. They statechart
consists a transition and state. The transition describes what are the operations,
parameters or action need to be transferred to another state. The state may represents the
current state of the operation by the given or specific time. It also influence whether the
states are active or passive.
On the other hand, Figure 6.5 shows the Collect Data statechart. Note that Data
Collection statechart contains two active states which are Store and Retrieve state. Store
state responsible for restoring the incoming data from the subsystem and Retrieve state
responsible for response for the request data if there any possible request from the other
subsystem.
Collect Data Use Case Statechart
wait for data request
dataRequest
Read request data
dataStore
dataRetrieve
sendData
store
retrieve
DataReady
DataReady
Looking for request data
Save data in database
DataFound
Figure 6.5: Collect Data Statechart
6.2.1.6 Pattern Selection
Pattern selection analysis is originally from POAD methodology. However, the
integrated ROPES and POAD software process was enabling the pattern selection
analysis could be made in requirement analysis in ROPES. This is the ultimate objective
of the integrated methodology and the patterns were enabling to be selected in early
phase. In order to do so, each use case text, sequence diagram and statechart was
investigated to capture which part that suitable for patterns implementation. Table 6.1
shows the suitable patterns that possible to be used in system design after deep
understanding of the use case behaviour items.
Table 6.1: Pattern Selection Analysis
Use
Case
Diagra
State
Purpos
m
Error
Calculation
es
Use
Read
rn
Observ
 feedback data
Case
Patte
Statechart
Obser
e the measured ver
data from Plant
Produc
e
Apply
feedback strategy
data
Strate
to gy
produce
feedback data
Calcula
te error data
Observ
Obser
e feedback data ver
to be compared
with input data
Forwar
d
Data
Collection
Use
Case
Statechart
Apply
to strategy
feedforward
Plant
subsystem
error data
Store
 and Retrieve
to gy
with
Manipu
lates
Strate
Black
multiple board
types of data
Table 6.1 illustrates the pattern selection analysis result. The result was obtained
from the comprehensive analysis on use case behaviour diagram. Statechart diagram for
Error Calculation use case compose two types of patterns which are Observer and
Strategy. Observer pattern purposes are to receive any incoming data, processes it and
update the data. These patterns are suitable to be implemented to the feedback and error
calculation state since they both have received potential incoming data. Then, Strategy
pattern implements control strategy to the targeted subsystem with some algorithm
hence; it’s suitable for feedforward and feedback state. In addition, Blackboard pattern
absolutely suitable for store and retrieve state because they contains multiple types of
data that the system needs.
In pattern selection analysis, an early pattern was selected based on use case
behaviour and more precisely, the behaviour of the system. By identifying the suitable
patterns, a set of pattern candidate then was selected that will be used in system design
phase.
6.2.2 System Analysis
The next stage of analysis in ROPES is system analysis. System analysis is the
investigation onto the system without knowing the details architecture of the system.
System analysis may discover the complexity of the system and if possible, the system
may composed into several subsystem depends on its functional. Each subsystem will
implement specific roles or tasks of the system in order to meet system goals. Based on
FCS Use Case model, the FCS can be composed into five types of subsystem as shown
in Figure 6.6.
Feedback Control System
<<System>>
«Subsystem»
«Subsystem»
Monitoring
ErrorCalculation
1
1
1
1
1
controlPlant
1
1
1
«Subsystem»
«Subsystem»
Database
Display
1
1
Figure 6.6: FCS Subsystem Composition
Figure 6.6 shows the subsystem of FCS. The composition of the system has been
made by investigating the functional of the system based on FCS use case model. Note
that each subsystem has specific tasks that responsible to implement the system
functionality. Table 6.2 shows the responsible of each subsystem.
Table 6.2: Subsystem Tasks
Subsystem
Tasks
ErrorCalcula
Responsible to determine the input data, observe
tion
measured data from Plant, produce feedback data, calculate error
data based on feedback data, apply strategy to Plant with error
data.
Monitoring
Responsible to collect measurement data from sensor.
Display
Responsible for display purposes for end user.
controlPlant
Responsible to handle the Plant operation.
Database
Responsible to store all types of data and handle data
manipulation process.
6.2.3 Object Analysis
Object analysis is the process of discover the possible objects that exist in the
domain or subsystem. In this case, the objects will be discovered in each system. In
addition, Object analysis contains two parts which are Structural and Behaviour.
Structural analysis is the process to identify essential objects that appear in subsystem,
propose suitable classes, their relationship and identify essential attributes and
operations. Then, Behaviour analysis is the process to determine the behaviour of each
object that appears in subsystem.
6.2.3.1 Object Structural
In the later section, the FCS subsystem has been identified by undergoing
comprehensive analysis on use cases behaviour. Then, each subsystem may have
possible objects that build up the subsystem structure. In order to identify subsystem
structure, Object structural analysis will be implemented. Object structural analysis main
principles to capture essential objects that appear in subsystem, propose possible class
and identify their relationship. However, build up subsystem structure, the possible
objects that exist in the system must be identified as shown in Table 6.3.
Table 6.3: FCS Transaction Objects
Object 1
Object
2
Primary
Associ
ation
Record
Transaction
Object
Tracks
Sensor
Subject
Tracking Time
Tracking Date
Secondary
Record
Tracks
Sensor
Subject
Tracking Time
Tracking Date
Plant
Controller
Actuato
r
Screen
Message
Contain
Request for action
Owns
Set Data
s
Icon
Menu
Database
Control
FB Data
s
Error
Get Data
Data
Measur
ed Data
Measured
FB
Observ
Request
for
subject
Strategy
FB subject
es
Error
measured data
Notify
Observer
Error
Observer
for
feedback data
FF
Strategy
Request
Update
s
Request for error
data
Table 6.3 shows the FCS transaction objects. The objects were identified by
observing the system behaviour and its relationship with each subsystem. Note that, each
subsystem implements their own function by the group of objects. From Table 6.3, the
association of the two objects was identified following the transaction objects. From this
analysis, the list of objects then will be grouped to the subsystem as shown in Table 6.4.
Table 6.4: Subsystem Objects
Subsystem
Objects
Error
FB Strategy
Calculation
FF Strategy
Measured Subject
FB Subject
Error Observer
Monitoring
Primary Sensor
Secondary Sensor
Record
Display
Screen
Icon
Menu
controlPlan
Plant Controller
Database
Error data
t
FB Data
Measured Data
After all the subsystem objects have been identified, the subsystem object model
diagram was constructed by using Rhapsody I-Logix 6.0 to realize the implementation
of the system. Figure 6.7 shows the FCS subsystem view diagram.
Feedback Control S ystem
<<System >>
ErrorCal cul ati on
1
1
i tsFFS trategy
M oni tori ng
1
1
1
1
i tsFB Strategy
i tsM easuredSubj ect
1
1
1
i tsP ri m aryS ensor
i tsS econdarySensor
1
1
1
1
1
1
i tsRecord
1
1
1
1
1
i tsE rrorObserver
1
1
1
control Pl ant
i tsFB Subj ect
1
1
1
i tsP l antControl l er
1
1
1
1
1
Di spl ay
Database
1
i tsE rrorData
1
1
i tsFB Data
i tsM easuredData
1
1
i tsS creen
1
1
1
i tsIcon
1
i tsM enu
1
Figure 6.7: Subsystem Diagram
6.2.3.2 Object Behaviour
Object behaviour analysis refers to the way what the object does. The objects of
each subsystem have their own behaviour that implements specific tasks to contribute
the operation the whole system. The behaviour of each object will be represented in
Statechart diagram in order to show the clear view how the state change and what are the
exchange messages involve. Figure 6.8 shows the statechart for FFStrategy Object.
idle
DataReady
Apply strategy
Feed data to plant
Figure 6.8: FFStrategy Object Statechart
Figure 6.8 demonstrates the FFStrategy Object statechart diagrams. This diagram
intended to explain the behaviour of the object. The FFStrategy Object was placed in
ErrorCalculation
subsystemand this object responsible to executed the specific
algorithm to Plant. There are four states which are idle, DataReady, Apply strategy and
Feed data to plant which connected with transition arrow. Idle state means the object is
in position to receive incoming data. Then, after the data was received, it goes to the
DataReady states which show the data was available. Then, Apply strategy state begins
to initiate the strategy to be applied into the Feed data to plant state. This behaviour
main purpose is to show how FFStrategy object behaviour will react when the system
start to be executed. Refer Appendix A for the rest of subsystem object statechart.
6.2.4 Analysis Result Summary
Analysis phase in ROPES consist three main processes which are Requirement,
System and Object analysis. Each process have specific purposes that to be done in order
to produce clear views on system requirements. Thus, regarding the integrated ROPES
and POAD software process, POAD analysis process will be combined with the ROPES
analysis process at the critical process. In ROPES, Requirement and Object analysis
process was essential because these processes describe the behaviour of the system.
Since the behaviour of the system was identified, the suitable patterns can be selected.
Therefore, POAD analysis process which is Pattern Selection process was combined into
Requirement and Object analysis process.
To select suitable patterns in software development is the main concerns of the
integrated ROPES and POAD software process. The Requirement and Object analysis
process feed the subtle information about how the correct patterns were selected. Those
processes includes the behaviour features which becoming the major factors of pattern
selection process. Similarly, the pattern selection process relied heavily on the system
behaviour. The Requirement and Object analysis have elaborated the FCS to encompass
a number of different kinds of behaviour diagram, making the behavioural modelling
more complete. This is where the pattern selection process in POAD takes part to
execute the process of selecting suitable patterns of the FCS. In general, Requirement
and Object analysis process deals with the very broad scope strategic decision such as
system structural and behavioural and patterns selection process.
6.3
Design Phase
In the previous section, analysis phase was implemented comprehensively in
order to collect and gather all the system requirements. The use case model, subsystem
view, objects and system behaviours were briefly described. In addition, based on
integrated ROPES and POAD software process, a set of pattern was selected in analysis
phase in order to enable smooth system design by using the selected patterns. In design
phase, there are three processes which responsible to implement FCS design. The three
processes are Architectural, Mechanistic and Detailed design. Then, those processes
were embedded with the POAD design processes which define the Pattern Level
Diagram, Pattern Level with Interface Diagram and Pattern Internal Classes.
6.3.1
Architectural Design
An architectural design main concern is to enable broad level view of the FCS
system. The large-scale design of FCS was constructed by involving the relationship of
UML management notation such as components, packages, subsystem and processors.
In further details, architectural was divided into two processes which are Deployment
View and Component View.
6.3.1.1 Component View
A component is the software items that can be reused to another purpose.
Components occur at run-time and often used for embedded and real-time system. For
FCS, there are three components that libraries and executable types. Figure 6.9 shows
Component View of FCS.
«Executable»
GUI
«Usage»
«Library»
«Executable»
GUIlib
FCS_Library
«Usage»
Figure 6.9: Component View in FCS
Figure 6.9 shows the FCS components. There are three components that
responsible for the systems which are GUIlib, GUI and FCS_Library. GUIlib component
is the Library type which contains a set of objects and function that provide services to
executable component. Thus, all graphical user interface of FCS was placed in GUIlib
component to be linked with FCS_Libarary and GUI components. Then, GUI
component is stand-alone program that execute the entire system display base. A
FCS_Library component is the most important component that execute all the FCS
function. Those three components are declared explicitly to enable the run-time
executable of the FCS.
6.3.1.2 Deployment View
In the previous section, we discussed about the Component view in FCS.
Components exist at the run-time that provides necessary information. However, how
can those components interact with the devices or processors in FCS? Deployment view
can provide the physical view of the system and illustrates how each component
communicates with system hardware. Figure 6.10 shows the Deployment view of FCS.
«Proc ess or»
«Display»
User_Interface
LCD
«Proc ess or»
Error_Calculation
«Proc ess or»
«Proc ess or»
Input_Controller
Output_Controller
«Disk»
Database
«flow»
«Sensor»
«M otor»
position_sensor
Stepper
«flow»
«Sensor»
«M otor»
position_sensor
Stepper
Figure 6.10: Deployment View of FCS
6.3.1.3 Pattern Level Diagram
In the Architectural design, the low-level view of the system has been identified
such as components, deployments and so on. Then, regarding on the integrated ROPES
and POAD software process, the development of Pattern Level Diagram will be
constructed at this level. After a set of pattern has been produced in Requirement
analysis stage as shown in Table 6.1, there is a process to construct the pattern Package.
Before that, Table 6.5 shows the transformation a set of pattern that has been identified
in Table 6.1 into patterns Package.
Table 6.5: Patterns Package
State
Purpose
Pattern
s
Read
feedback data
Package
Observe
the
Patterns
Observer
measured
FB_Obse
rver
data from Plant
Produce
feedback data
Apply
strategy
Strategy
to
FB_Strat
egy
produce
feedback data
Calculate
error data
Observe
Observer
feedback data to
be
ER_Obs
erver
compared
with input data
Forward
to feedforward
Apply
Strategy
strategy to Plant
FF_Strat
egy
with error data
Store
and Retrieve
Manipul
ates
multiple rd
types of data
Blackboa
DT_Blac
kboard
Table 6.5 shows the patterns package of the FCS. Each patterns package was
assigned to the respective purposes based on current state at FCS statechart. Apart from
that, each patterns package was derived originally from core patterns which are
Observer, Strategy and Blacboard. In details, each patterns package was having certain
purposes where it would facilitate process of building FCS class diagram. Figure 6.11
shows how patterns package related to each other and how the flows of data will occur.
P lant
«<<Pattern>>»
«flo w»
«<<Pattern>>»
FF_ Stra tegy
FB _Obsever
«flo w»
«flo w»
«<<Pattern>>»
«<<Pattern>>»
FB _S trateg y
E R_Ob server
«flo w»
«flo w»
«<<Pattern>>»
DT_B lackboard
«flo w»
«flo w»
Figure 6.11: Pattern Level Diagram in ErrorCalculation Subsystem
Figure 6.11 shows the Pattern level diagram for ErrorCalculation Subsystem.
Note that there are five pattern packages that have been constructed based on Table 6.5.
Strategy pattern has been applied to the feedforward and feedback process. Then
Observer pattern will be used on error calculation and the process of producing feedback
data. This entire pattern is in Error Calculation subsystem. In addition, Blackboard
pattern has been constructed into Database subsystem in order to group the types of data.
After the pattern level diagram has been constructed, those patterns must have a special
interface to enable communication between patterns.
6.3.1.4 Pattern Level With Interface Diagram
In the previous section, pattern level diagram for FCS was constructed based on
the requirement analysis and subsystem in FCS. In order to enable the communication
between patterns, each pattern package must have an interface. An interface will act as a
proxy so that all the parameter or transaction of objects can be done here. Figure 6.12
shows the pattern level diagram with interface for FCS.
«<<Pattern>>»
«<<Pattern>>»
FF_S trategy
FB _Ob sever
«Interfac e»
Co ntroller
Feedb ackObserver
1
«<<Pattern>>»
ER_Observer
«<<Pattern>>»
FB _Strateg y
1
«Interfac e»
Error_Observer
«Interfac e»
1
FB
«<<Pattern>>»
DT _Bl ackboard
1
«Interfac e»
Da ta_Cont roller
1
Figure 6.12: Pattern Level Diagram with Interface for ErrorCalculation
Subsystem
Figure 6.12 shows the pattern level diagram with interface for FCS. Each pattern
package contains an interface that responsible to be as proxy of pattern communication.
This process originally from POAD designs process and the construction of pattern
package will enable each pattern exchanging messages through interface.
6.3.2
Mechanistic Design
Mechanistic design deals with the class diagram construction and what its
relationship. The class diagram of FCS will be constructed based on a set of objects in
subsystem. As mention in Section 6.2.3, Object analysis is responsible to discover
possible objects in subsystem. Then, based on those objects, the respective class diagram
will be constructed. Based on subsystem object, the possible candidate class has been
identified based on a set of pattern that has been selected in requirement analysis.
Furthermore, in Architectural design, Pattern level diagram and pattern level diagram
with interface have been identified. So that, in Mechanistic design, the pattern internal
class will be constructed to build up the system. By doing this, the behaviour of the FCS
also can be achieved by constructing sequence and statechart diagram based on defined
class diagram.
6.3.2.1 Design Pattern Internal Class
Based on the basic process in Mechanistic design in ROPES, class diagram for
the system will be constructed to build up the system design. Furthermore, each class
diagram has their own behaviour that will be shows in statechart diagram. However, in
the integrated ROPES and POAD metamodel, the class diagram construction for the
system design must base on pattern shape. In the other words, class diagram for FCS is
constructed by applying the collaboration with patterns package. Before that, the
patterns package internal class must be defined. Table 6.6 illustrates the pattern internal
classes for each patterns package.
Table 6.6: Pattern Internal Classes
Patterns package
Class Diagram
FB_Observer
Subject
Observer
MeasuredSubject
FeedbackObserver
FB_Strategy
FB
FBStrategyA
FBStrategyB
FBController
FF_Strategy
FF_Strategy
ConcreteStrategyA
ConcreteStrategyB
Controller
ER_Observer
ErrorSubject
FeedbackSubject
Error_Observer
AbstractObserver
DT_Blackboard
Data_Controller
DataType
Err_Data
FB_Data
Measured-Data
Table 6.6 shows the pattern internal class diagrams. Internal class diagrams for
patterns package were originally derived from pattern library that already has been
defined by the pattern’s creator. In FCS system, some of the classes may have not
required because of the system requirements. For the initial FCS class diagram, all
patterns package that are shown in Appendix A was connected together via interface
and with the other subsystem class diagrams. Figure 6.13 shows the FCS class diagrams.
plant
1
MeasuredSubject
1
FB_ObserverPattern
FF_Strategy Pattern
«Interface»
1
1
FF_Strategy
Observer
Controller
Subject
1
1
«Interface»
ConcreteStrategyB
ConcreteStrategyA
MeasuredSubject
FeedbackObserver
RecordManager
ER_Observer Pattern
FB_Strategy Pattern
AbsractObserver
«Interface»
1
1
1
FB
«Interface»
ErrorSubject
FBController
1
1
FeedbackSubject
Error_Observer
FBStrategyA
FBStrategyB
DT _Blackboard Pattern
1
1
«Interface»
1
Data_Controller
1
Err_Data
1
1
DataT ype
FB_Data
1
VisualElement
Measured_Data
Figure 6.13: FCS Class Diagram with Patterns
Figure 6.13 shows the FCS class diagrams with patterns. FCS class diagrams
were constructed by the set of patterns and the other subsystem classes. Each patterns
package communicate through class interface which responsible for data or objects
transaction. Apart from that, the other class like Plant, VisualElement and
RecordManager also included together as a part of system design. Note that, the FCS
class diagram above fulfil the integrated ROPES and POAD metamodel requirements
as most of the class diagrams were constructed from the pattern internal classes.
However, the FCS class diagrams that has been developed has not complete yet.
By referring the integrated ROPES and POAD software process, the Mechanistic
design in ROPES is combined with the design phase in POAD. As such circumstances,
after the FCS class diagram was constructed, its must be refined again in order to
decrease the complexity of the class diagrams. This process is to facilitate the
developer so that they will get the appropriate class diagrams. Thus, the sufficient class
diagrams are important to maintain the stability of the system design.
6.3.2.2 Refined Class Diagram
After the FCS class diagrams was constructed as shown in Figure 6.29, it shows
that some other class diagrams can be merged together in order to decrease the
complexity of the system design. This process known as refined class diagrams and the
main principles of this process is to minimize the complexity of the FCS class diagrams.
Based on the FCS class diagrams, there are five patterns package included and each one
contains the original class diagrams. By referring Table 6.1, only three patterns was
included which are Observer, Strategy and Blackboard. Observer patterns were used to
produce feedback and error data. Strategy patterns were used to apply the specific
algorithm to feedback and feedforward purposes and Blackboard pattern is used to
categorize a data. By observing this information and FCS class diagrams, the existed
class diagrams can be refined by minimizing the pattern internal classes. Table 6.7
shows the summary of refined FCS class diagrams.
Table 6.7: Refined FCS Class Diagrams Summary
Pattern
s package
Class
Diagram
FB_Obs
erver
Patter
n
Refined
Diagrams
Subject
AbstractSubject
Observer
AbstractObserver
MeasuredS
FBSubjectObserv
ubject
Obser
FeedbackO
er
ver
ErrorObserver
bserver
ER_Obs
erver
Class
MeasurementSubj
ect
ErrorSubjec
t
FeedbackSu
bject
Error_Obse
rver
AbstractOb
server
FF_Stra
tegy
FF_Strateg
AbstractController
y
Controller
ConcreteStr
FBStrategyA
ategyA
Strateg
ConcreteStr
ategyB
Controller
FB_Stra
FB
tegy
FBStrategy
A
FBStrategy
B
FBControll
er
y
ConcreteStrategy
A
DT_Bla
ckboard
Data_Contr
oller
Blackb
No Change
oard
DataType
Err_Data
FB_Data
Measured_
Data
Table 6.7 shows the summary of FCS class diagrams that has been refined by
combining with the same patterns. Note that, they have five patterns package and each
one of them have their own internal classes. Both FF_Observer and ER_Observer have
the same pattern which is Observer. Observer patterns have two core class diagrams
which are AbstractSubject and AbstractObserver. Both classes already exist in
FF_Observer and ER_Observer patterns package. Furthermore, AbstractSubject
responsible to identify the subject involves in the system. In this case, AbstractSubject is
responsible to handle feedback and measured subject. Furthermore, AbstractObserver is
required to observers any incoming data and feedback and error observer will be placed
inside this class.
The other patterns package that will be grouped together is FF_Strategy and
FB_Strategy. Both patterns package are responsible to execute the specific algorithm in
order to produce some output. As such conditions, FBStrategyA and ConcreteStrategyA
class will be generalized inside AbstractController. Figure 6.14 shows the FCS refined
class diagrams.
Pattern::Strategy ::AbstractController
Pattern::Strategy ::Controller
1
1
1
Plant
1
1
Pattern::Strategy ::ConcreteStrategy A
Pattern::Strategy ::FBStrategy A
1
Pattern::Observ er::AbstractObserv er
Pattern::Observ er::AbstractSubject
MeasurementSubject
1
1
Pattern::Observ er::ErrorObserver
RecordManager
Pattern::Observ er::FBSubjectObserver
1
1
1
VisualElement
Pattern::Blacboard::DataController
1
1
1
1
Pattern::Blacboard::DataHolder
1
Pattern::Blacboard::ErrorData
Pattern::Blacboard::FBData
Pattern::Blacboard::MeasuredData
Figure 6.14: FCS Refined Class Diagram
6.3.2.3 Sequence Diagram
After FCS class diagram was refined and already exist in minimized form, it is
important to stress that analysing the FCS behaviour is very creative process. Thus, the
process of exchanging messages between classes is essential since it may contain some
information parameters or objects that need to travel across class diagrams. In order to
show this process, FCS will use sequence diagram. A sequence diagram is the tool that
shows the sequence of messages between classes or objects. Thus, sequence diagrams
capable to show the timing properties that may exist while messages are exchange. For
FCS system, there are four main sequence diagrams which illustrate how the whole
system will operate. Figure 6.15 shows the sequence diagram for error calculation.
ENV
:Abstract
Observer
:ErrorObserver
:Controller
:DataController
update(changedSubject)
update(changedSubject)
setDataController(aDataController)
setData(newData)
setController(aController)
setInputData(newInputData)
control(feedbackData)
setStrategy(aStrategy)
Figure 6.15: Error Calculation Sequence Diagram
6.3.2.4 Statechart Diagram
Statechart diagram main principles is to shows the behaviour of the objects or
classes. For this reason, they are appropriate to the class diagrams. In FCS class
diagrams, the operations and attributes have been defined. Thus, the selected class
diagrams will show how the process of FCS. By referring to the requirement analysis,
FCS main purposes are to produce error data by observing the measured data from plant
and compared with the defined input. The behaviour of these processes lies in the
important class diagrams. Table 6.8 shows the statechart of the selected class diagrams.
Table 6.8: Statechart Diagram
Class Diagram
Purposes
Plant
The
process
of
producing measured data.
Pattern::Observer::Abstract
Subject
The
process
of
producing feedback data
by observing the measured
data from plant with some
special algorithm.
Pattern::Observer::ErrorOb
server
The
process
of
producing error data by
observing
the
feedback
data.
Pattern::Strategy::Controll
er
The
process
of
applying special algorithm
to plant with error data.
Table 6.8 shows the statechart of respective class diagrams in FCS refined class
diagrams. Each class diagrams have important tasks of describing the whole FCS
process. The process of FCS includes the operations of each class and reflecting the
system design overall. Figure 6.16 shows the statechart for Plant class diagram.
idle
[speed=15]
SetCurrentSpeed
tm(1000)[currentSpeed]
startOperation
tm(1000)[speedUp]
PlantingProcess
tm(1000)
Figure 6.16: Plant Class Statechart
Figure 6.16 shows the statechart for Plant class diagram. The statechart intended
to illustrate the behaviour of the Plant class which enable the specific view on how the
Plant class will executed. The Plant class statechart consists of four states which each
state represent the system behaviour. Idle state means the Plant in the idle state and
available to receive any new command. Before that, the static parameter which is speed
was setup by the User. The static speed was setup because to give the specific
measurement of the plant speed should operate. Then, SetCurrentSpeed state was setting
up the current speed of the Plant. After that, The Plant start the operation based on the
binding parameter which is currentSpeed. Then, the startOperation state will start the
planting process. Each time the currentSpeed value is more or less than speed, the
system will automatically adjust the currentSpeed value until it same as speed value.
Then, the PlantingProcess state will precede the Plant regulated process until the certain
time is met. Refer Appendix A for the other statechart diagram for each class diagram in
Table 6.8. Furthermore, each statechart will undergo some simulation process in order to
show how the FCS behaviour will be executed. Figure 6.17 shows the result of FCS
simulation for the Plant class diagrams.
Figure 6.17: Plant Statechart Simulation Result
Figure 6.17 demonstrates the Plant statechart simulation. Note that the initial current
speed is 5 and the static speed is 15. Each time current speed is lower than static speed,
the system automatically increase the current speed value by one until the current speed
equal with speed value. After that, Plant will start to regulate in order to produce
measured data. Refer Appendix A for simulation result for each class diagram
statechart.
6.3.3
Detailed Design
After the FCS class diagram was constructed and already refined, the final
process of system design in the integrated ROPES and POAD software process is
detailed design. Detailed design is more concern of detailing the attributes and
operations in the FCS class diagrams such as storage format, data format, range used for
attributes and so on. However, in this project we do not put so much stress in detailed
design because of time constraints. Please refer in Appendix A to view FCS refined
class diagrams with attributes and operations.
6.3.4
Design Result Summary
Design phase in ROPES put stress on how the system was designed. There are
three main design processes in ROPES which are Architectural, Mechanistic and
Detailed design. These processes are responsible to construct system design from the
above view until the details view. Apart from that, system was designed supporting with
structural and behaviour diagrams. Structural diagrams such as class, subsystem,
package, objects and behaviour diagrams likes statechart, sequence diagram and task
diagram. All this diagrams are working together to enrich the system designed up to
higher level.
Naturally, in the integrated ROPES and POAD software process enable the
pattern construction up to class designs. Pattern level diagram process is originally from
POAD and was merged with the Architectural design in ROPES. This will enable the
pattern level diagram construction based on patterns that have been selected in
requirement analysis. Furthermore, in Mechanistic design, FCS class diagram was
constructed with collaborating patterns package. Then, each patterns package will reveal
its pattern internal classes that finally build up the complete FCS class diagram. The
process of connecting each patterns package is originally from POAD and known as
pattern level diagram with interface. In the other words, each patterns package
communicating each other through interface. After that, the behaviour of the FCS will be
showed by using statechart and sequence diagrams. The statechart diagrams also
conducting the simulation of FCS in order to show the how FCS run.
After design phase is completed, it shows that the set of patterns that have been
selected in Requirement analysis is consistently used in design phase. The pattern level
diagram and pattern level diagram with interface was merged with the Architectural and
Mechanistic process.
6.4
Summary and Discussion
To demonstrate the applicability of the integrated ROPES and POAD software
process, the selected case study has been selected to conduct the system analysis and
design. FCS system is the small-scale embedded real time system that enables to
produce feedback response to the system based on Plant data. After the FCS analysis and
design was conducted, it show that the integrated ROPES and POAD software process
capable to use patterns systematically from analysis until design phase. Apart from that,
the complexity of the software development was decreased because the uses of patterns.
The integrated ROPES and POAD software process also shows that the implementation
of FCS in analysis and design phase capable to reduced the complexity of embedded real
time system and systematically using patterns from early phase.
The integrated ROPES and POAD software process main concerns are to enable
the uses of patterns from early phase and systematically derived until design phase. The
analysis and design of FCS demonstrates how the POAD process fit in ROPES process.
The POAD process was embedded into ROPES process only in analysis and design
phase. In addition, in order to successful merges POAD process into ROPES, the system
behaviour must specifically describe. The system behaviour plays main roles on how a
set of patterns was selected and how the selected patterns fit into the FCS design.
However, the process of embedding POAD into ROPES only involves the small
scale of system design without affecting the whole process of ROPES. As mention
before, ROPES methodology provides the systematic software development for
embedded real time system in term of analysis and design. Therefore, the company or
individual who are adopted the ROPES methodology for a long time does not having
any problems to use the integrated ROPES and POAD software process for their works.
This is because the use of patterns is the matter of system design without affecting the
notations or semantics in ROPES. The patterns development still using traditional class
diagram, package and interface that available in ROPES metamodel. Because of this, ILogix Rhapsody tool can be adapted into the integrated ROPES and POAD
methodology.
CHAPTER 7
DISCUSSION AND FUTURE WORK
7.1
Introduction
This chapter discussed about Project summary and contribution as well as future
works for further study of this project. The Project summary covers from Chapter 4 to 6
and the knowledge contribution is critically defined. Then, the potential future works for
the further study will be discussed as well.
7.2
Summary
Designing and building ERTS software is difficult in order to fulfil the quality
and performance of the system. Indeed, a wide range of the software development
methodologies have been devised to minimize the complexity of the ERT software
development. Each successive development claims can decrease the complexity of
software development into another level. In this project, the integrated ROPES and
POAD methodology has been built to prove that the uses of software patterns will
enable the systematic and efficient software development especially as solutions for ever
more demanding ERT softwares are required.
In seeking to demonstrate the efficiency of the integrated ROPES and POAD
methodology, the integrated metamodel and software process were developed as
described in Chapter 4 and Chapter 5. In addition, to prove the applicability of the
defined metamodel and software process, the selected case study has been chosen to be
applied by using I-Logix Rhapsody tool. The integrated ROPES and POAD metamodel
has proven to provide the ERT system modelling guidance with the correct notations and
semantics. Furthermore, the integrated ROPES and POAD software process will act as a
standard form to the software analyst and designer to built ERT software by applying
pattern oriented development. After those two processes have been applied, the proven
solution is demonstrated by applying analysis and design strategy into the FCS system
by using I-Logix Rhapsody tool in order to prove the applicability of the defined
software process.
7.3
Project Contribution
Having highlighted the potential benefits of software patterns in software
development, this section pinpoints some of the advantages of building embedded real
time system using software patterns. The following sets of contributions are directly
attributable to the characteristics of pattern oriented development. Naturally, since the
reliable of the integrated ROPES and POAD metamodel as well as software process
have been built, designers have found means of develop the ERT system by following
pattern oriented approaches. This Project main purpose is to enable the pattern oriented
development in ROPES by integrating it with POAD methodology. In particular, the
ongoing process of enabling pattern oriented development in the integrated ROPES and
POAD methodology have shown the formalism of metamodel and software process
developed for specifying, designing and verifying software development using patterns.
By recognising these critical points, there are certain project knowledge contributions
which seem common to pattern oriented development. The project contributions as
follows:
i.
The development of the integrated ROPES and POAD metamodel.
ii.
The development of the integrated ROPES and POAD software process.
iii.
The proven solution of the applicability of the integrated ROPES and
POAD metamodel and software process into the selected case study by
using I-Logix Rhapsody 6.0 tool.
Note that those contributions have highlighted in Chapter 1 which is the Project
objectives and scope. The integrated ROPES and POAD methodology is now having the
new metamodel and software process that enable the uses of patterns. In addition, these
contributions have emphatically indicate that pattern oriented development is not any
more complex than more traditional software development approaches. The ERT system
can be built more systematically and the complexity of the ERT software development
can be decreased by applying patterns. Hence, correct metamodel and systematic
software process can promote systematic and high degree of software patterns reuse. As
conclusion, the integrated ROPES and POAD methodology was offered the new way of
analysing and designing the ERT software. The patterns enable the high degree of
design reuse and consequently, the complexity of ERT software development can be
decreased.
7.4
Future Work
The integrated ROPES and POAD methodology for software patterns are at an
early stage of software development, and yet systematically derived until the design
stage. The widespread acceptance of the concept of software patterns implies that
software patterns have a significant future in the software development paradigm.
Probably, the most important issues for the pattern uses in the integrated ROPES and
POAD methodology are:
i.
An understanding of the situations in which software patterns will be
applied.
ii.
Principle of the development process for pattern oriented development.
iii.
Which software patterns are suitable for the certain domains and in this
case, ERT domain.
Naturally, the integrated ROPES and POAD software process main principles are
to enable the uses of patterns systematically in ROPES. However, there some issues
arise that made the system design little bit harder. The issues are how to ensure that the
patterns that have been selected in analysis phase is appropriate when in design phase.
Then, there must be a standard framework of pattern adaptation after a set of patterns
that have been selected in analysis phase. Other than that, because of the complexity of
embedded real time requirements, the patterns may have been reviewed again in design
phase in order to meet the system functional and non functional requirements especially
for safety critical ERT system. Furthermore, the standard tools to support pattern
oriented development especially for ERT software can be developed. All of these issues
maybe can be solved in the future by observing in depth how the integration of ROPES
and POAD will be conducted. To conclude, the future works of this project as follows:
i.
Patterns selection process.
ii.
Pattern adaptation framework in software design.
iii.
Patterns testing based on generated test cases in software design.
iv.
Metamodel validation and verification using formal method and graph
theory.
REFERENCES
Angelov, C., Sierszecki, K., & Marian, N. (2008). Component-Based Design of
Embedded Software: An Analysis of Design Issues. In Lecture Notes in Computer
Science (pp. 1-11). Berlin: Springer Berlin / Heidelberg.
Baelen, S. V., Gorinsik, J., & Wills, A. (2001). The DESS Methodology. Deliverable
D.1 Version 01 - Public .
Buschman, F., Meunier, R., Rohnert, H., & Sommerlab, P. (1996). Pattern Oriented
Software Architecture:A System of Patterns. John Wiley and Sons.
Bunse, C., Gross, H. G., & Peper, C. (2008). Embedded System Construction –
Evaluation of Model-Driven and Component-Based Development Approaches.
MODELS`08 Workshop ESMDE .
Clements, P. (1996). A Survey of Architecture Description Languages. In Proceedings
of the Eighth International Workshop on Software Specification and Design (pp. 1625). Paderborn, Germany: ACM.
Coad, P. (1997). Object Models:Strategies, Patterns and Applications. Yourdon Press.
Crankovic, I. (2003). Component based Software Engineering- New Challenges in
Software Development. 25th International Conference on Information Technology
Interfaces, (pp. 9-18).
Crnkovic, I. (2005). Component-based Software Engineering for Embedded Systems.
ICSE’05 ACM .
Crnkovic, I., Stig, L., & Michel, C. (2005). Component Based Development Process and
Component Lifecycle. Journal of Computing and Information technology , 321-327.
Demicheil, L., Yalcinalp, L., & Krishnan, S. (2001). Enterprise JavaBeans Specification
Version 2.0.
Domiczi, E., Farfarakis, R., & Jürgen, Z. (2000). Octopus/UML Artifact Reference
Version 1.3.
Domiczi, E., Rallis, F., & Jürgen, Z. (2000). Release of Octopus/UML. Nokia Research
Center .
Dong, J., Alencar, P. S., & Cowan, D. D. (2004). A behavioral analysis and verification
approach to pattern-based design composition. Software and Systems Modeling ,
262-272.
Douglass, B. P. (1999). Doing Hard Time : Developing Real-Time System Using UML
Objects, Framework and Patterns. Addison-Wesley.
Felix, L., & Narashima, B. (2003). Object-Oriented Analysis using Patterns: A Review
and Research Opportunities.
Fernandez, E. B., & Yuan, X. (2000). Semantic Analysis Patterns.
Fernando, L. C. (2005). A New Component Based Life Cycle Model. Journal of
Computer science , 76-82.
Finkelstein, A. (2000). The Future of Software Engineering. Proceedings of 22nd
International Conference on Software Engineering , ACM Press.
Fowler, M. (1997). Analysis Patterns, Reusable Object Models. Addison Wesley.
Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design Patterns, Elements of
Reusable Object Oriented Software. Addison-Wesley.
Garlan, D., & Shaw, M. (1996). Software Architecture: Perspectives on an Emerging
Discipline. Prentice Hall.
Gomaa, H. (2001). Designing Concurrent, Distributed and Real Time Applications with
UML. Addison-Wesley.
Harb, D., Bouhours, C., & Leblanc, H. (2009). Using an Ontology to Suggest Software
Design Patterns Integration. In MODELS 2008 Workshops, LNCS 5421 (pp. 318331). Berlin: Springer-Verlag Berlin Heidelberg.
Heinenam, G., & Councill, W. (2001). Component Based Software Engineering.
Addison-Wesley.
Jawawi, D. (2006). A Framework for Component-Based Reuse for Autonomous Mobile
Robot Software. PhD Thesis: Universiti Teknologi Malaysia.
Jawawi, D. (2003). Embedded Real Time System:Technical Report. Universiti Teknologi
Malaysia.
Jawawi, D., Mohamad, R., Deris, S., & Mamat, R. (2005). Transforming PatternOriented Models into Component-Based Models for Embedded Real Time Software
Development. MySEC'05 .
Jerry, O. (2007). Pattern Oriented Analysis and Design Theory.
Konrad, S., & Cheng, B. H. (2005). Real-time Specification Patterns. Proceedings of the
27th International Conference of Software Engineering (ICSE05) .
Kotonya, G., & Hutchinson, J. (2005). Pattern and Component Oriented System
Development. Proceeding of the 2005 31st EUROMICRO Conference on Software
Engineering and Advanced Applications .
Lau, K. K., & Wang, Z. (2005). A Taxonomy of Software Component Models.
Proceeding of the 2005 31st EUROMICRO Conference on Software Engineering
and Advanced Applications .
Luigi, L., & Bianco, V. d. (2000). Software Development Process for Real-Time
Embedded Software Systems (DESS). Deliverable D5.2/D5.3/D5.4 DESS process
modeling:methodology and support .
Meyer, B. (2003). The grand Challenge of Trusted Components. Proceedings ICSE 2003
IEEE , 660-667.
Natale, M. D. (2008). Design and Development of Component-Based Embedded
Systems for Automotive Applications. In Lecture Notes in Computer Science,
Reliable Software Technologies – Ada-Europe 2008 (pp. 15-29). Berlin: Springer
Berlin / Heidelberg.
Nicola, J., Mayfield, M., & Abney, M. (2001). Streamlined Object Modelling: Patterns,
Rules and Implementation. Upper Saddle River, N.J: Prentice Hall.
Nierstrasz, O., Grenssler, T., & Schonhage, B. (2002). Components for Embedded
Software. The PECOS Approach CASES .
OMG. (2007). UML Superstructure Specification. http://www.omg.org.
Rajasree, M. S., Jithendra, P., Reddy, K., & Janakiram, D. (2001). Pattern Oriented
Software Development: Moving Seamlessly from Requirements to Architecture.
Riehle, D., & Zullighoven, H. (1996). Understanding and Using Patterns in Software
Development. Theory and Practice of Object System , Vol, 2(1) 13-33.
Sesera, L. (2000). Analysis Pattern. SOFSEM'2000 Lecture Notes in Computer Science
Series
Sesera, L. (2001). Hierarchical Patterns:A Way to Organize Analysis Patterns.
SYSTEMATICS, CYBERNATICS AND INFORMATICS , Volume 3.
Sommerville, L. (2004). Software Engineering 7th Edition. Addison-Wesley.
Staines, A. S. (2007). A Comparison of Software Analysis and Design Methods for Real
Time Systems. Proceedings of World Academy of Science, Engineering and
Technology, (p. Volume 21).
Szyperski, C. (2002). Component Software: Beyong Object Oriented Programming.
Addison-Wesley.
Tichy, M. (2006). Pattern-Based Synthesis of Fault-Tolerance Embedded Systems.
SIGSOFT’06/FSE14 ACM .
Wan Zulkifeli, W. R. (2008). Kajian Penggunaan Corak Rekabentuk Masa Nyata
Dalam Pembangunan Sistem Masa Nyata Berasaskan Metodologi Pattern Oriented
Analysis and Design (POAD) dan Rapid Object Process for Embedded System
(ROPES). Malaysia.
Yacoub, S. M., Xue, H., & Ammar, H. H. (2000). Automating the Development of
Pattern Oriented Designs for Application Specific Software Systems. Proceeding
IEEE .
Yacoub, S., & Ammar, H. H. (2004). Pattern Oriented Analysis and Design:Composing
Patterns to Design Software System. Addison Wesley.
Yau, S., & Dong, N. (2000). Integration in Component based Software Development
Using Design Pattern. Proceeding IEEE .
Zhang, J. Z., & Yunsheng. (2007). Component-oriented Modeling and Design of
Hierarchical Hybrid Control System. IEEE International Conference on Control
and Automation Guangzhou, CHINA .
Appendix A
Analysis and Design of Feedback Control System
UC-01: Monitor
Scope
: Plant and FCS
Level
: System Goal
Primary Actor
: Sensor
Include Use Case
: -
Preconditions
: System was produced measured data
Postconditions
: System was ready to collect measured data
Basic Flow
:
1. Sensor request for Plant status.
2. Plant replies the current state.
3. Sensor start request for measured data from Plant
4. Plant accepts the request and sends the measured data.
5. Sensor destroys the connection with the Plant.
6. Sensor in idle state
Special Requirements

:
Sensor
Frequency of
: Continuos
Occurrence
Figure 1: UC-01
UC-02: Control
Scope
: Plant and FCS
Level
: System Goal
Primary Actor
: Actuator
Include Use Case
: -
Preconditions
: Plant was operate properly
Postconditions
: System was controlled by Actuator
Basic Flow
:
1. Actuator request System status from the System.
2. System sends the status state.
3. Actuator request for Plant status from System
4. System sends the Plant current status.
5. Actuator starts control the Plant while time>0.
6. System sends Plant status regularly to Actuator.
7. Actuator destroy the connection with the Plant.
Special Requirements
:

Central Processing Unit (CPU)

Monitor
Frequency of
: Continuos
Occurrence
Figure 2: UC-02
UC-00: Collect Data
Scope
: FCS
Level
: System Goal
Primary Actor
: User
Include Use Case
: Monitor and Calculate Error
Preconditions
: System was produced measured data, feedback data
and error data
Postconditions
: System was ready to be stored and collected
Basic Flow
:
1. System ready for receive and send a data.
2. System start process saving data in database
3. System start to response for data request
4. System start to send a requested data
Special Requirements
:

Central Processing Unit (CPU)

Monitor

Disks
Frequency of
: Continuos
Occurrence
Figure 3: UC-03
UC-00: Error Calculation
Scope
: FCS
Level
: System Goal
Primary Actor
: User
Include Use Case
: Collect Data, Monitor, Control
Preconditions
: System was ready to run
Postconditions
: System produce error feedback data for Plant
Basic Flow
:
1. System is waiting for incoming data from Plant.
2. Plant produce measured data.
3. System collects a measured data from Plant.
4. System starts to produce feedback data.
5. System starts to calculate error data.
6. System sends error data to the subsystem.
7. System feed error data to the Plant
Repeat step 1-7 until system halted by user
Special Requirements
:

Central Processing Unit (CPU)

Monitor

Logic Machine
Frequency of
: Once
Occurrence
Figure 4: UC-04
Monitor Use Case S cenario
:Sensor
System:FCS
getSystemS tatus()
systemS tatus()
getPlantData()
plantData()
destroyConnection()
sensorIdle()
Figure 5: Monitor Use Case Sequence Diagram
Control Use Case Scenario
:Acuator
System:FCS
getSystemS tatus()
systemS tatus()
getPlantS tatus()
plantStatus()
controlPlant()
tm(time>0)
plantStatus()
destroyConnectionPlant()
Figure 6: Control Use Case Sequence Diagram
idle
DataReady
Apply strategy
Feed data to plant
Figure 7: FBStrategy Object Statechart
dataReady
tm()
Waiting for request
Sending data
Figure 8: MeasuredSubject Object Statechart
idle
set current status
Ready for receive measured data
tm(transferTime=true)
time>0
Receive measured data
Figure 9: FB Subject Object Statechart
idle
setStatus
Ready to receive feedback data
tm(operationTime=true)
update
Update current error data
Figure 10: ErrorObserver Object Statechart
Active
Waiting
Storing
evDetect
DetectingSubject
tm(operationTime)
Figure 11: Record Object Statechart
Active
RequestingControl
Destroying
evControl
Controlling
evDestroyConnection
Figure 12: Plant Controller Object Statechart
Active
Waiting
NotViewed
evnotSeen
evSeen
Viewed
tm(refreshTime)
Figure 13: Screen Object Statechart
«<<Pattern>>»
FB_Obsever
Observer
1
«Interface»
Subject
MeasuredSubject
FeedbackObserver
Figure 14: FB_Observer Pattern Package
«<<Pattern>>»
FB_Strategy
«Interface»
FB
1
FBController
1
FBStrategyA
FBStrategyB
Figure 15: FB_Strategy Pattern Package
«<<Pattern>>»
FF_Strategy
«Interface»
1
1
FF_Strategy
Controller
ConcreteStrategyA
ConcreteStrategyB
Figure 16: FF_Strategy Pattern Package
«<<Pattern>>»
ER_Observer
1
AbsractObserver
«Interface»
ErrorSubject
FeedbackSubject
Error_Observer
Figure 17: ER_Observer Pattern Package
«<<Pattern>>»
DT_Blackboard
«Interface»
1
1
DataType
Data_Controller
Err_Data
FB_Data
Measured_Data
Figure 18: DT_Blackboard Pattern Package
ENV
:Plant
:Measurement
Subject
:Abstract
Subject
:Abstract
Observer
:FBSubject
Observer
:Record
Manager
getPlantMeasurement()
setPlant(aPlant)
measurePlant()
attach(anObserver)
notifyObserver()
update(changedSubject)
setDataController(theDataController)
setFBController(aController)
setSensor()
setData(newData)
detach(anObserver)
getState()
destroySensor()
<idle>
Figure 19: Feedback Sequence Diagram
:DataController
ENV
:Controller
:AbstractController
:Plant
:DataController
setInputData(newInputData)
control(feedbackData)
apply(errorData)
setStrategy(aStrategy)
FBApply(inputData, outputData)
getPlantMeasurement()
setPlant(aPlant)
run()
control(speedUp)
setData(newData)
Figure 20: Feedforward Sequence Diagram
:User
:DataController
:DataHolder
:RecordManager
viewData()
getValue()
setDate()
setDisplay()
setDisplay()
Figure 21: Viewing Sequence Diagram
:VisualElement
wait
tm(1000)
tm(2000)
Notifying
ProducingFBData
notifyObserver();...
[measuredData]
Figure 22: AbstractSubject Class Statechart
wait
tm(1000)
retrievingFBData
setting input data
tm(1000)[FBData]
[inputData]
producing error data
tm(100)
Figure 23: ErrorObserver Class Statechart
wait
tm(2000)[ErrorData]
RetrieveErrorData
[ErrorData]/operationTime=10;
Apply feedforward strategy
tm(1000)
Planting
Figure 24: Controller Class Statechart
Figure 25: AbstractSubject Statechart Simulation Result
Figure 26: ErrorObserver Statechart Simulation Result
Figure 27: Controller Statechart Simulation Result
Pattern::Strategy ::AbstractController
Pattern::Strategy ::Controller
control(f eedbackData:DataHolder):v oid
Controller()
setInputData(newInputData:DataHolder):v oid
setStrategy (aStrategy :AbstractController):v oid
1
apply (errorData:DataHolder):v oid
FBApply (inputData:DataHolder,outputData...
Abstrac tController()
setPlant(aPlant:Plant):v oid
1
1
Plant
speed:double=60
speedUp:OMBoolean
1
1
Pattern::Strategy ::ConcreteStrategy A
control(speedUp:OMBoolean):v oid
getPlantMeasurement():v oid
run():v oid
ev Start():v oid
Pattern::Strategy ::FBStrategy A
apply (errorData:DataHolder):v oid
FBApply (inputData:DataHolder,outp...
ConcreteStrategy A()
apply (errorData:DataHolder...
FBApply (inputData:DataHol...
FBStrategy A()
1
Pattern::Observ er::Abs tractObserv er
Pattern::Observ er::Abs tractSubjec t
update(changedSubject:Abstract...
MeasurementSubject
attach(anObserv er:AbstractObs erv ...
detach(anObserv er:AbstractObserv ...
notif y Observ er():v oid
Abstrac tSubject()
getState():v oid
ev Start():v oid
1
measurePlant():v oid
setPlant(aPlant:Plant):v oid
MeasurementSubject()
getState():v oid
1
Pattern::Observ er::ErrorObs erv er
RecordManager
Pattern::Observ er::FBSubjectObserv er
update(changedSubject:Abs tract...
setDataController(aDataControlle...
setController(aController:Controll...
ErrorObserv er()
setDataController(theDataContr...
update(changedSubject:Abstrac...
FBSubjectObs erv er()
setFBController(aController:Abs...
getState():v oid
1
1
setSens or():v oid
destroy Sensor():v oid
1
Vis ualElement
Pattern::Blacboard::DataController
1
setData(newData:DataHolder):...
DataController()
v iewData():v oid
Message_4():v oid
1
1
setDis play ():v oid
setDate():v oid
1
Pattern::Blacboard::DataHolder
1
currentValue:double
getValue():v oid
DataHolder()
Pattern::Blacboard::ErrorData
Pattern::Blacboard::FBData
Pattern::Blacboard::MeasuredData
Figure 28: Detailed FCS Class Diagram