 |
|
Analysis of Large Systems in UML
An Architectural and Process Approach |
|
|
|
Daniel Duffy
Datasim Education BV
Available 2nd quarter 2002 |
|
|
|
| Summary of Objectives |
This book will be
written in order to improve the awareness and productivity of
software developers. In particular, we show how to improve UML
by paying more attention to system decomposition in the early
stages of the software development lifecycle and by improving
the road to use cases. |
|
In particular, we show how to improve
UML by paying more attention to system decomposition in the early
stages of the software development lifecycle and by improving
the road to use cases. |
|
|
|
| rationale |
| We wish to improve
awareness and productivity of software developers. In particular,
we show how to improve UML by paying more attention to system
decomposition in the early stages of the software development
lifecycle. The book is a step-by-step account of how to analyse
medium and large systems using object technology and UML. |
|
The goal of the
book is to develop a process for system analysis using UML syntax
as a standard communication language. |
|
|
|
| Market and Target Groups |
| This book is aimed at experienced
analysts, designers and architects. It will be of use to those
software professionals who have used object-oriented technology
and UML to solve real-life problems. The book is also for structured
analysts who do not necessarily have UML experience. The added
value of this boom to these readers is that it deals with the
analysis of large systems in various application domains. In
this way we hope to 'bond' to these readers by dealing with
interesting and pertinent examples and test cases from previous
and current projects. |
|
Furthermore, we do not inundate
readers with pages of irrelevant syntax details (that is done
in the UML specification). Instead, we use just enough syntax
to describe the current problem. This book could also be of
use to senior engineering and computer science students. I suggest
giving exercises at the end of each chapter and providing answers
in a separate booklet. It could then be used by other trainers
throughout the world. |
|
|
|
| Executive Overview |
| The structure of this book is
based on the Datasim Development Process (DDP) as applied to
the analysis phase of the software lifecycle (see section 4.3
of the White Paper) where the process is described. This process
has been revised, optimized and improved during the last 10
years and we use it in our courses, Datasim software development
projects and on customer projects. Thus, we are confident that
the book will do justice to this process since each part in
the book describes all the syntax and steps that are needed
to help readers understand the material and to apply it in their
own work (see below for past projects and customers who use
DDP). |
|
In general, the artifacts from
each Part will be used as input to the next Part. In this way
we achieve a traceable path in the process (similar to Minsky's
'chaining of ideas' as discussed in his Society of Minds) The
main parts and their summary descriptions are: |
|
|
| back to top |
|
| Part I: |
| deals with defining how to
scope a system and decompose it into loosely coupled subsystems.
In particular, we show how business goals and business processes
are discovered and how processes are documented using UML activity
diagrams. To this end, we use the Rummler/Brache approach to
find the activity diagrams (this is where activity graphs originated
from in the first place! (personal communication, Jim Odell)).
Having defined a stable and extensible domain architecture allows
us to apply and integrate the other (lower-level) UML techniques,
such as the Boundary, Entity and Control analysis classes. |
|
We conclude Part I with a discussion
of the essential dimensions of a generic system. The deliverables
for this phase will be used in later parts of the book. UML
2.0 will introduce processes into the standard. We have already
integrated this with UML. |
|
|
| back to top |
|
| Part II: |
| deals with describing and discovering
customer and stakeholder requirements. We depart from the well-accepted
Use Case approach. This works for small systems but breaks down
when we move to large and enterprise system development. To
this end, we introduce the concepts of stakeholder categories
and their corresponding viewpoints (these will be part of UML
2.0). Each stakeholder has an associated set of viewpoints and
each viewpoint will be realized by a number of requirements.
Finally, each requirement is realized by several use cases.
|
|
This process is well-developed
in this book. In this way we resolve some major weaknesses and
shortcomings with use cases. See the UML meta-model for the
specific relationships in the White Paper, section 4.2, figure
5. Part II concludes by integrating the deliverables of Part
I and Part II. In particular, our aim is that each requirement
can be mapped in a 1:1 manner to a (sub)system.
|
|
|
| back
to top |
|
| Part III:
|
| Deals with 'intermediate-level
'class architecture (this is where many UML books begin, that
is at class-level!). To this end, we introduce the Presentation-Abstraction-Control
(PAC) that the author sees as the next generation alternative
to the more intuitive Boundary-Entity-Control approach in UML.
PAC can be applied to large systems and it represents a stable
infrastructure for much of UML, for example aggregation, association
and generalization relationships between classes. |
|
The author has applied PAC to
numerous applications and Domain Categories and in many cases
it is possible to 'predict' which classes come where in the
early stages of the software development process (this speeds
up developer productivity). Part III contains major chunks of
UML syntax that is applied in an appropriate way to create stable
and maintainable class models and class diagrams. Examples are
taken from real applications.
|
|
|
| back to top |
|
| Part
IV: |
| deals with how functionality
is realised in UML. To this end, we discuss interaction diagrams
in general and sequence/collaboration diagrams in particular.
These diagrams are standard in UML and we integrate them with
the static PAC entities from Part III. Part IV deals with all
the syntax elements in UML as well as developing a strategy
for interaction diagram construction based on use cases thereby
improving the quality of interaction diagrams (validation) |
|
Finally, we devote a chapter
to standardizing messages and protocols. This will improve understandability
among the team members and it lays the foundation for Harel
statecharts in Part V. |
|
|
| back
to top |
|
| Part V:
|
| deals with the Harel statechart
technique. This is a powerful mechanism for documenting the
lifecycle of active objects in UML applications. We define a
process for creating statecharts based on the deliverables from
Part IV. We discuss all UML syntax concerning statecharts and
we apply this syntax to several interesting and non-trivial
problems. |
|
In particular, we integrate
a number of 'loose-ends' that cannot be documented in sequence
diagrams. Statecharts are an essential element of the UML-RT
technology (Rumbaugh/Selic). This will be discussed in Appendix
C in some detail.
|
|
|
| back to top |
|
| Part VI: |
| Both Part IV and Part V are
very important because they allows the developer achieve high
productivity levels (my feeling is that they achieve CMM level
3 (defined) and in some cases CMM level 4). Part IV deals with
the author's findings in the area of reusable domain architectures
(we call them Domain Categories). I have been working on these
since 1992 but it was only since 1998 that the results crystallized.
A domain category is a family of applications having similar
structure and behaviour. We document each category using UML
notation and each category can be used as a framework or generator
for specific applications. This will promote developer productivity.
|
|
The author owes his gratitude
to Michael Jackson who developed the Problem Frame concept and
which sparked the idea to discover Domain Categories. This section
produces standard generic artifacts that can be specialized
in 'instance' applications:
-Standard context diagram
-Standard use cases
-Standard class diagrams
-Standard sequence diagrams and protocols
These can be used by developers to 'bootstrap' their own specific
applications |
|
|
| back
to top |
| Part VII:
|
deals with specific applications
(instances of Domain Categories). The full weight of UML comes
to bear as we document each application using a standard approach:
Core processes and system decomposition
PAC model
Standard use case template
Sequence diagrams
Statecharts
Deliverables
|
|
The added value of this approach
is that readers can modify the applications to suit their own
needs. For example, the Order Processing Systems in chapter
34 is so generic and clear that developers can adapt it to their
own needs |
|
|
| back to top |
|
| Appendices:
|
| deal with a discussion of a number
of topics that are relevant to the current book. Furthermore,
they discuss a number of emerging technologies (such as Component
Oriented Analysis and UML-RT). |
|
An important appendix deals
with a critique of the object-oriented paradigm |
|
|
|
| back
to top |
| UML Topics
that are covered |
| Activity diagrams Class modelling
diagrams (aggregation, association etc.) Statecharts (from A
to Z) Use cases Sequence and collaboration diagrams UML-RT capsule
and protocol diagrams |
|
Other necessary and standard
additions:
Goals and core processes (Rummler/Brache)
Context diagram
Problem frames (Jackson)
Domain categories (Duffy)
Viewpoints and requirements (Sommerville et al)
Disovering and documenting knowledge from and about real applications
|
|
|
|
| back
to top |
| Table of contents |
|
|
|
Part I: Domain Architectures
and Structural Decomposition
Chapter 1: Goals and Business Processes
Chapter 2: System Discovery and System Decomposition
Chapter 3: Canonical Description of Systems
|
Part II: Viewpoint and Requirements Analysis
Chapter 4: Stakeholders and Actors
Chapter 5: Stakeholder Viewpoint Theory
Chapter 6: Requirements Discovery
Chapter 7: Moving to Use Cases
|
Part III: Class Architecture in UML
Chapter 8: Architectural Infrastructure: the PAC Model
Chapter 9: Classes and Class Relationships
Chapter 10: Advanced Structural Modelling
Chapter 11: Discovering and Documenting Classes
|
Part IV: Object Interaction Modelling
Chapter 12: Use Case Details
Chapter 13: Introduction to Sequence Diagrams
Chapter 14: Advanced Sequence Diagrams
Chapter 15: Validation Issues and Exit Criteria
Chapter 16: Optimisation and Deliverables
|
Part V: Object Lifetime Modelling
Chapter 17: An Introduction to Statecharts
Chapter 18: Advanced Statechart Theory
Chapter 19: Defined Processes for Statechart Construction
Chapter 20: Use Statecharts to discover new Requirements
Chapter 21: Integration and Deliverables from the Analysis Phase
|
Part VI: Reusable Domain Categories
Chapter 22: An Introduction to Domain Categories
Chapter 23 Management Information Systems (MIS)
Chapter 24: Access Control Systems (ACS)
Chapter 25: Resource Allocation and Tracking Systems (RAT)
Chapter 26: Manufacturing Systems (MAN)
Chapter 27: Process Control Systems (PCS)
Chapter 28: Lifecycle Models (LCM)
|
Part VII: Applications and Examples
Chapter 29: Manpower Control System (MIS)
Chapter 30: Home Heating System (PCS)
Chapter 31: Financial Portfolio Trading System (MIS)
Chapter 32: Drink Vending Machine (ACS)
Chapter 33: Graphics Compiler System (MAN)
Chapter 34: Order Processing System (LCM)
|
Appendices
A. Comparison with other Methodologies
B. A Critique of the Object-Oriented Paradigm
C. An Introduction to Component-Oriented Analysis™ and UML-RT Extensions
D. Summary of DDP Process
E. Glossary of Terms
|
|
|
|
| back
to top |
