OOAD with UML Object Oriented Analysis and Design Using the UML 2 UML Applied - Object Oriented Analysis and Design using the UML 3 UML Applied - Object Oriented Analysis and Design using the UML Contents AN INTRODUCTION TO THE UML 7 What is the UML? 7 A Common Language 7 Summary 9 THE UML WITHIN A DEVELOPMENT PROCESS 10 The UML as a Notation 10 The Waterfall Model 10 The Spiral Model 12 Iterative, Incremental Frameworks 13 Inception 13 Elaboration 14 Construction 14 Transition 15 How Many Iterations? How Long Should They Be? 15 Time Boxing 16 Typical Project Timings 16 The Rational Unified Process 17 Summary 18 OBJECT ORIENTATION 19 Structured Programming 19 The Object Orientated Approach 22 Encapsulation 23 Objects 23 Terminology 24 The Object Oriented Strategy 24 Summary 25 AN OVERVIEW OF THE UML 26 The Use Case Diagram 27 The Class Diagram 28 Collaboration Diagrams 29 Sequence Diagram 30 State Diagrams 31 Package Diagrams 32 Component Diagrams 33 Deployment Diagrams 34 Summary 34 THE INCEPTION PHASE 35 4 UML Applied - Object Oriented Analysis and Design using the UML THE ELABORATION PHASE 37 Deliverables 37 Summary 38 USE CASE MODELLING 39 Actors 39 The Purpose of Use Cases 40 Use Case Granularity 41 Use Case Descriptions 43 Use Cases at the Elaboration Phase 43 Finding Use Cases 44 Joint Requirements Planning Workshops (JRP) 44 Brainstorming Advice 45 Summary 45 CONCEPTUAL MODELLING 46 Finding Concepts 47 Extracting Concepts From Requirements 47 The Conceptual Model in the UML 48 Finding Attributes 49 Guidelines for Finding Attributes 50 Associations 50 Possible Cardinalities 51 Building the Complete Model 51 Summary 53 RANKING USE CASES 54 Summary 55 THE CONSTRUCTION PHASE 56 Construction 56 Summary 57 THE CONSTRUCTION PHASE : ANALYSIS 58 Back to the Use Cases 58 1. Main Flow 59 Alternate Flows 60 Exception Flows 60 The Complete Use Case 61 The UML Sequence Diagram 61 Summary 63 5 UML Applied - Object Oriented Analysis and Design using the UML THE CONSTRUCTION PHASE : DESIGN 64 Design - Introduction 64 Collaboration of Objects in Real Life 65 Collaboration Diagrams 66 Collaboration Syntax : The Basics 66 Collaboration Diagrams : Looping 68 Collaboration Diagrams : Creating new objects 68 Message Numbering 68 Collaboration Diagrams : Worked Example 69 Some Guidelines For Collaboration Diagrams 72 Chapter Summary 73 DESIGN CLASS DIAGRAMS 74 Crediting and Debiting Accounts 74 Step 1 : Add Operations 75 Step 2 : Add Navigability 75 Step 3 : Enhance Attributes 75 Step 4 : Determine Visibility 76 Aggregation 76 Composition 77 Finding Aggregation and Composition 77 Summary 77 RESPONSIBILITY ASSIGNMENT PATTERNS 78 The GRASP Patterns 78 What is a pattern? 78 Grasp 1 : Expert 78 Grasp 2 : Creator 80 Grasp 3 : High Cohesion 81 Grasp 4 : Low Coupling 83 Grasp 5 : Controller 86 Summary 87 INHERITANCE 88 Inheritance – the basics 88 Inheritance is White Box Reuse 90 The 100% Rule 91 Substitutability 91 The Is-A-Kind-Of Rule 92 Example - Reusing queues through inheritance 92 Problems With Inheritance 94 Visibility of Attributes 95 Polymorphism 96 Abstract Classes 97 The Power of Polymorphism 98 Summary 99 6 UML Applied - Object Oriented Analysis and Design using the UML SYSTEM ARCHITECTURE - LARGE AND COMPLEX SYSTEMS 100 The UML Package Diagram 100 Elements Inside a Package 101 Why Packaging? 101 Some Packaging Heuristics 102 Expert 102 High Cohesion 102 Loose Coupling 102 Handling Cross Package Communication 102 The Facade Pattern 104 Architecture-Centric Development 105 Example 105 Handling Large Use Cases 106 The Construction Phase 107 Summary 107 MODELLING STATES 108 Example Statechart 108 State Diagram Syntax 109 Substates 110 Entry/Exit Events 111 Send Events 111 Guards 111 History States 112 Other Uses for State Diagrams 112 Summary 113 TRANSITION TO CODE 114 Synchronising Artifacts 114 Mapping Designs to Code 115 Defining the Methods 117 Step 1 118 Step 2 118 Step 3 119 Step 4 119 Mapping Packages into Code 119 In Java 119 In C++ 120 The UML Component Model 120 Ada Components 121 Summary 121 BIBLIOGRAPHY 123 7 UML Applied - Object Oriented Analysis and Design using the UML Chapter 1 An Introduction to the UML What is the UML? The Unified Modelling Language, or the UML, is a graphical modelling language that provides us with a syntax for describing the major elements (called artifacts in the UML) of software systems. In this course, we will explore the main aspects of the UML, and describe how the UML can be applied to software development projects. Through to its core, UML leans towards object oriented software development, so in this course, we will also explore some of the important principles of object orientation.
In this short chapter, we’ll look at the origins of the UML, and we’ll discuss the need for a common language in the software industry. Then we will start to look at how to exploit the UML on a software project. A Common Language Other industries have languages and notations, which are understood by every member of that particular field. Figure 1 - A Mathematical Integral Although the picture above is a fairly simple drawing (a stylised "S" figure), mathematicians the world over recognise instantly that I am representing an integral.
Although this notation is simple, it masks a very deep and complicated topic (though perhaps not as deep as the concept represented by the figure of eight on its side!) So the notation is simple, but the payoff is that mathematicians all around the world can clearly and unambiguously communicate their ideas using this, and a small collection 8 UML Applied - Object Oriented Analysis and Design using the UML of other symbols. Mathematicians have a common language. So do musicians, electronic engineers, and many other disciplines and professions. To date, Software Engineering has lacked such a notation.
Between 1989 and 1994, a period referred to as the “method wars”, more than 50 software modelling languages were in common use – each of them carrying their own notations! Each language contained syntax peculiar to itself, whilst at the same time, each language had elements which bore striking similarities to the other languages. To add to the confusion, no one language was complete, in the sense that very few software practitioners found complete satisfaction from a single language! In the mid 1990’s, three methods emerged as the strongest. These three methods had begun to converge, with each containing elements of the other two. Each method had its own particular strengths: • Booch was excellent for design and implementation.
Grady Booch had worked extensively with the Ada language, and had been a major player in the development of Object Oriented techniques for the language. Although the Booch method was strong, the notation was less well received (lots of cloud shapes dominated his models - not very pretty!) • OMT (Object Modelling Technique) was best for analysis and data-intensive information systems. • OOSE (Object Oriented Software Engineering) featured a model known as Use Cases. Use Cases are a powerful technique for understanding the behaviour of an entire system (an area where OO has traditionally been weak).
In 1994, Jim Rumbaugh, the creator of OMT, stunned the software world when he left General Electric and joined Grady Booch at Rational Corp. The aim of the partnership was to merge their ideas into a single, unified method (the working title for the method was indeed the "Unified Method"). By 1995, the creator of OOSE, Ivar Jacobson, had also joined Rational, and his ideas (particularly the concept of "Use Cases") were fed into the new Unified Method - now called the Unified Modelling Language1. The team of Rumbaugh, Booch and Jacobson are affectionately known as the "Three Amigos".
Despite some initial wars and arguments, the new method began to find favour amongst the software industry, and a UML consortium was formed. Heavyweight corporations were part of the consortium, including Hewlett-Packard, Microsoft and Oracle. The UML was adopted by the OMG2 in 1997, and since then the OMG have owned and maintained the language. Therefore, the UML is effectively a public, non- proprietary language.
1 Officially, the spelling is "modeling", but I favour the English spelling 2 The OMG are the Object Management Group, an industry wide, non profit making standards body.org for full details. 9 UML Applied - Object Oriented Analysis and Design using the UML Summary The UML is a graphical language for capturing the artifacts of software developments. The language provides us with the notations to produce models. The UML is gaining adoption as a single, industry wide language.
The UML was originally designed by the Three Amigos at Rational Corp. The language is very rich, and carries with it many aspects of Software Engineering best practice. 10 UML Applied - Object Oriented Analysis and Design using the UML Chapter 2 The UML within a Development Process The UML as a Notation The Three Amigos, when developing the UML, made a very clear decision to remove any process based issues from the language. This was because processes are very contentious - what works for company A might be a disaster for company B.
A defence company requires much more documentation, quality and testing than (say) an e-commerce company. So the UML is a generic, broad language enabling the key aspects of a software development to be captured on "paper". In other words, the UML is simply a language, a notation, a syntax, whatever you want to call it. Crucially, it does not tell you how to develop software.
To learn how to use the UML effectively, however, we will follow a simple process on this course, and try to understand how the UML helps at each stage. To start with, let's have a look at some common software processes. The Waterfall Model Figure 2 - The traditional “Waterfall” model 11 UML Applied - Object Oriented Analysis and Design using the UML The waterfall model prescribes that each stage must be complete before the next stage can commence. This simplistic (and easy to manage) process begins to break down as the complexity and size of the project increases.
The main problems are: • Even large systems must be fully understood and analysed before progress can be made to the design stage. The complexity increases, and becomes overwhelming for the developers. • Risk is pushed forward. Major problems often emerge at the latter stages of the process – especially during system integration.
Ironically, the cost to rectify errors increase exponentially as time progresses. • On large projects, each stage will run for extremely long periods. A two-year long testing stage is not necessarily a good recipe for staff retention! Figure 3 –Over time on the waterfall, both the risks and the cost to rectify errors increase Also, as the analysis phase is performed in a short burst at the outset of the project, we run a serious risk of failing to understand the customer’s requirements. Even if we follow a rigid requirements management procedure and sign off requirements with the customer, the chances are that by the end of Design, Coding, Integration and Testing, the final product will not necessarily be what the customer wanted.
Having said all the above, there is nothing wrong with a waterfall model, providing the project is small enough. The definition of "small enough" is subjective, but essentially, if the project can be tackled by a small team of people, with each person able to understand every aspect of the system, and if the lifecycle is short (a few 12 UML Applied - Object Oriented Analysis and Design using the UML months), then the waterfall is a valuable process. It is much better than chaotic hacking! In summary, the waterfall model is easy to understand and simple to manage. But the advantages of the model begin to break down once the complexity of the project increases.
The Spiral Model An alternative approach is the spiral model.