Smalltalk and Object Orientation: an Introduction - Free
Smalltalk and Object Orientation: an Introduction - Free
Smalltalk and Object Orientation: an Introduction - Free
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
16. <strong>Object</strong> Oriented Analysis <strong><strong>an</strong>d</strong> Design<br />
16.1 <strong>Introduction</strong><br />
This chapter provides <strong>an</strong> introduction to <strong>Object</strong> Oriented Analysis <strong><strong>an</strong>d</strong> Design. It will survey the most<br />
signific<strong>an</strong>t methods to emerge since the late 1980's. This me<strong>an</strong>s that we will concentrate primarily on<br />
OOA [Coad <strong><strong>an</strong>d</strong> Yourdon 1991], Booch [B ooch 1991, 1994], OMT [Rumbaugh et al 1991], <strong>Object</strong>ory<br />
[Jacobson 1992] <strong><strong>an</strong>d</strong> Fusion [Colem<strong>an</strong> et al 1994]. We will also introduce the Unified Modeling<br />
L<strong>an</strong>guage (or UML) [Booch et al 1996; Booch <strong><strong>an</strong>d</strong> Rumbaugh 1995].<br />
The aim in this chapter is not to be compreh ensive either with regard to the r<strong>an</strong>ge of methods<br />
available, nor with the fine details of each approach. Rather it is to provide <strong>an</strong> overview of the design<br />
process, strengths <strong><strong>an</strong>d</strong> weaknesses of some of the import<strong>an</strong>t <strong><strong>an</strong>d</strong> reasonably representative methods.<br />
In the remainder of this chapter we briefly introduce the Unified Modeling L<strong>an</strong>guage, <strong>Object</strong><br />
Oriented Design (OOD) <strong><strong>an</strong>d</strong> then summarize a number of OOD methods.<br />
16.2 The Unified Modeling L<strong>an</strong>guage<br />
The Unified Modeling L<strong>an</strong>guage (or UML as it is known) is <strong>an</strong> attempt by Grady Booch, Ivar Jacobson<br />
<strong><strong>an</strong>d</strong> James Rumbaugh to build on the experiences of the Booch, OMT <strong><strong>an</strong>d</strong> <strong>Object</strong>ory methods [Booch et<br />
al 1996; Booch <strong><strong>an</strong>d</strong> Rumbaugh 1995]. Their aim is to produce a sing le, common, <strong><strong>an</strong>d</strong> widely usable<br />
modeling l<strong>an</strong>guage for these methods <strong><strong>an</strong>d</strong>, working with other methodologists, for other methods as<br />
well. This me<strong>an</strong>s that the UML focuses on a st<strong><strong>an</strong>d</strong>ard l<strong>an</strong>guage <strong><strong>an</strong>d</strong> not a st<strong><strong>an</strong>d</strong>ard process. This<br />
reflects what actually happens in reality: a particular notation is adopted as the me<strong>an</strong>s of<br />
communication on a specific project <strong><strong>an</strong>d</strong> between projects. However, between projects (<strong><strong>an</strong>d</strong> sometimes<br />
within projects) different design methods are adopted as appropriate. For example, a design met hod<br />
intended for the domain of real -time avionics systems may or may not be suitable for designing a small<br />
payroll system. The result is that the UML is <strong>an</strong> attempt to develop a common metamodel (which<br />
unifies sem<strong>an</strong>tics) from which a common notation c<strong>an</strong> be built. We will discuss the UML in greater<br />
detail in a later chapter.<br />
16.3 <strong>Object</strong> oriented design methods<br />
The object oriented design methods (OOD methods) we shall be considering are all architecture -driven,<br />
incremental <strong><strong>an</strong>d</strong> iterative. That is, they do not adopt the more traditional waterfall software<br />
development model adopting instead <strong>an</strong> approach which is more akin to the spiral model of Boehm<br />
[Boehm 1988]. This reflects developers' experiences when creating object oriented system s - the object<br />
oriented development process is more incremental th<strong>an</strong> that for procedural systems with far less distinct<br />
barriers between <strong>an</strong>alysis, design <strong><strong>an</strong>d</strong> implementation. Indeed some org<strong>an</strong>izations take this process to<br />
the extreme <strong><strong>an</strong>d</strong> have adopted <strong>an</strong> Evolutionary Development approach. That is a system which is<br />
developed around the concept of evolutionary delivery. This me<strong>an</strong>s that system functions are delivered<br />
to users in very small steps with project pl<strong>an</strong>s being revised in light of experience <strong><strong>an</strong>d</strong> user feed-back.<br />
This has proved to be very successful for those org<strong>an</strong>izations who have fully embraced this philosophy<br />
<strong><strong>an</strong>d</strong> has led to much earlier business benefits <strong><strong>an</strong>d</strong> successful end -products from large development<br />
projects.
Change language