Introducing UML: Object-Oriented Analysis and Design - Practices

http://www.devshed.com/c/a/Practices/Introducing-UMLObjectOriented...

Practices Tutorials
Home Practices Introducing UML: Object-Oriented Analysis and Design

Introducing UML: Object-Oriented Analysis and Design

The purpose of UML, or Uni ed Modeling Language, is communication; to be speci c, it is to provide a comprehensive notation for communicating the requirements, architecture, implementation, deployment, and states of a system. This article will o er an overview of Object Oriented Analysis and Design, focusing in on the three most important concepts it encompasses: objects, analysis, and design. It is excerpted from the book UML Applied: A .Net Perspective, by Martin Shoemaker (Apress, 2004; ISBN: 1590590872). TABLE OF CONTENTS:
Introducing UML: Object-Oriented Analysis and Design Analysis UML UML Diagrams Component Diagrams Package Diagrams Its All About Communication Summary
By: Apress Publishing Rating: / 169 July 21, 2005 print this article Share Share 6 13 Poor Best

Dev Shed Forums FREE Virtualization Tools RAD for .Net Articles Forums All Feeds

Write For Us Get Paid SEARCH DEV SHED Request Media Kit Contact Us Privacy Policy Support

ShareThis

19

TOOLS YOU CAN USE

BlueHost offers professional web hosting services with 24/7 US Based Tech Support. Sign up now and receive a free domain name. Plans start at just $5.95 per month with a 30-day money back guarantee. Learn more!
advertisement

See Also: TIP For those who are impatient . . . If you already understand objects, you dont need convincing that UML is a great thing, and you just want to start learning the UML notation right away, skip ahead to Chapter 2.
Design with ArgoUML Class and Object Diagrams Five-Step UML: OOAD for Short Attention Spans - Design, Repeat

IN UML, the L is for language, one of the de nitions of which is any means of communicating, according to the Merriam-Webster Dictionary. That is the single overriding purpose of UML, or the Uni ed Modeling Language: to provide a comprehensive notation for communicating the requirements, architecture, implementation, deployment, and states of a system.

1 of 5

10/2/2011 7:18 PM

Introducing UML: Object-Oriented Analysis and Design - Practices

http://www.devshed.com/c/a/Practices/Introducing-UMLObjectOriented...

UML communicates these aspects from the particular perspective of Object Orientation (OO), in which everything is described in terms of objects: the actions that objects take, the relationships between the objects, the deployment of the objects, and the way the states of the objects change in response to external events. The starting point in this chapter will be an overview of Object-Oriented Analysis and Design (OOAD), focusing in on the three most important concepts it encompassesobjects, analysis, designbecause to understand UML, you rst must understand these broader concepts. If youve programmed with any OO language, then youre probably already familiar with a lot of these ideas, so Ill keep this discussion brief. Besides, a full discussion of OOAD is beyond the scope of this book. If you want to explore OOAD further, you should read Boochs ObjectOriented Analysis and Design with Applications.1 Next, Ill discuss the results of the OOAD process, namely, a model. Ill take a bit of a diversion to discuss the nature of models, how you use them, and why theyre important. For the rest of the chapter, Ill be focusing on UML, looking at what it is, and perhaps more importantlywhat it isnt. But before I get started into the nitty gritty of all the di erent UML elements and diagrams and what the notation looks like (Ill save that for the next chapter!), Ill be showing you some UML diagrams from the case study that Ill be developing in detail in the next part of the book. Now these diagrams arent there to scare you o : quite the contrary. When you start to look at some real-world UML, youll see how intuitive it is, and how you can understand much of it without any formal teaching. Objects Many modern programming languages depend largely or exclusively on the concept of objects: a close syntactic binding of data to the operations that can be performed upon that data. In these Object-Oriented languagesC++, C#, Java, Ei el, Smalltalk, Visual Basic .NET, Perl, and many othersprogrammers create classes, each of which de nes the behavior and structure of a number of similar objects. Then they write code that creates and manipulates objects that are instances of those classes. One reason why objects are a powerful programming techniquethe reason most often touted in the early literature on Object-Oriented Programming is that programmatic objects map naturally to real-world objects. Suppose, for example, that your company has to deal with orders. These orders would probably have an ID number and contain information on products. You could create Order objects, which would map to these real-world objects, and which would have properties such as ID and ProductList. Youd probably want to be able to add a product to the order and to submit the order, so you could write AddProduct and SubmitOrder methods. This mapping between objects in the real world and more abstract code objects encourages programmers to think in the problem domain, rather than in computer science terms. This bene t has perhaps been overstated, however; unless youre building a simulator of a real-world process, such surrogate real-world objects form just the surface of your system. The complexity of your design lies underneath that surface, in code that re ects business rules, resource allocation, algorithms, and other computer science concerns. If you only use objects to re ect the real world, you leave yourself with a lot of work. A more important bene t of classes and objects is that they form a nice syntactic mechanism for achieving some classic aspects of well-designed code:2 Encapsulation. The goal of encapsulation is to expose only enough of a module or subsystem to allow other modules to make use of it. Object-Oriented Programming allows you to specify the degree of visibility of elements of your code, so that client code is restricted in what it can access. Thus, you can syntactically seal o implementation details, leading to more exibility and maintainability in your system. Loose coupling. Coupling refers to the ways in which and degrees to which one part of the system relies on the details of another part. The tighter the coupling, the more changes in one part of the system will ripple throughout the system. With loose coupling, the interfaces between subsystems are well de ned and restricted. What lies beyond those interfaces can change without any changes needed in the client sub systems. Object-Oriented Programming supports loose coupling by allowing you to de ne and publish a classs methods without publishing how those methods are carried out. This principle goes even further in OO languages that support interfaces (described later in this section). Strong cohesion. Cohesion refers to the degree in which elements within a subsystem form a single, uni ed concept, with no excess elements. Where there is high cohesion, there is easier comprehension and thus more reliable code. Object-Oriented Programming supports strong cohesion by allowing you to design classes in which the data and the functions that operate on them are tightly bound together. Does OO force you to have these quality attributes in your code? I wish! No matter the language, you can write shoddy code with no encapsulation, pathological coupling, and no cohesion. Furthermore, some OO languages are less rigid than others in how much they require you to design around objects. But OO languages certainly support these quality attributes if you take the time to pursue them. The key concepts in Object-Oriented Programming are these:
E-Commerce Hosting Linux Web Hosting Managed Hosting Small Business Hosting VPS Hosting Forums Sitemap Site Map

2 of 5

10/2/2011 7:18 PM

Introducing UML: Object-Oriented Analysis and Design - Practices

http://www.devshed.com/c/a/Practices/Introducing-UMLObjectOriented...

Classes. A class is the de nition of the behavior and properties of one or more objects within your system. A class binds the data (attributes) of an object to the behavior (operations) that it can perform. Attributes. An attribute is a data value or state that describes an object and helps you to tell one object from another of the same class. It seems that every new OO language author feels the need to distinguish their language by coming up with new terminology. In some OO languages, these data values are called properties or member variables or member data; but in UML, the proper term is attributes. Operations. An operation is a behavior or function that an object can perform. Depending on the OO language, these might be called methods or member functions or even messages. The last term, messages, comes from Smalltalk, one of the earliest OO languages, in which all objects communicated by sending messages to each other. Youll see a similar use of the term message when we study Sequence Diagrams. Objects. An object is an instance or speci c example of a class. If Dog is the class, then Betsy, Ladi, Patches, Jake, Radar, and Frosty are speci c instances of the class found in my house. The attributes of the class have speci c values within an object of that class; and the operations of a class operate on the attributes of individual objects. Inheritance. This concept indicates that one class (the superclass) provides some common or general behavior inherited by one or more speci c classes (the subclasses). The subclasses then provide more or di erent behavior beyond that de ned in the superclass. For example, besides the Dogs, I have Cat objects and Horse objects that live on my property. Each class has unique behaviors: Dogs must be walked, Cats use the litter box, and Horses drop manure that must be scooped up and thrown in the manure pile. Yet all classes have some common behavior: they must be fed, and they must have vet visits. So I can de ne a superclass, Pet, and have my subclasses, Dog, Cat, and Horse, derive their shared behavior from the Pet class. In UML, this concept is known under the slightly di erent term of generalization, in which a superclass provides the generalized behavior of the subclasses. Its really the same concept, but just looking at it the other way up. Components. A component is a collection of related classes that together provide a larger set of services. Components in your system might include applications, libraries, ActiveX controls, JavaBeans, daemons, and services. In the .NET environment, most of your projects will require component development. Interfaces. An interface is a de nition of a set of services provided by a component or by a class. This allows further encapsulation: the author of a component can publish just the interfaces to the component, completely hiding any implementation details. Each of these concepts will be explored in more detail as I discuss the UML diagrams that represent them.

Next: Analysis >>

>>> More Practices Articles

>>> More By Apress Publishing

Like

1 person liked this. Login

Add New Comment

Showing 7 comments

Thank you, It's really good information

ok! but not for the beginners.................

3 of 5

10/2/2011 7:18 PM

Introducing UML: Object-Oriented Analysis and Design - Practices

http://www.devshed.com/c/a/Practices/Introducing-UMLObjectOriented...

i'm from electronics background, so its di cult for me to understand something from this article. . .

As a rst read, it gives you a universal lead to what UML is in relation to OOA and helps put things in perspective for old geysers like me who grew up in the DFD and ERD world - very well written and an easy read

good one

Really helpful information, particularly diagramatic explanations.

real nice and helpful article, Thank You

M Subscribe by email S RSS Trackback URL

blog comments powered by DISQUS

PRACTICES ARTICLES More Techniques for Finding Things Finding Things Finishing the System`s Outlines The System in So Many Words Basic Data Types and Calculations What`s the Address? Pointers Design with ArgoUML Pragmatic Guidelines: Diagrams That Work Five-Step UML: OOAD for Short Attention Span... Five-Step UML: OOAD for Short Attention Span... Introducing UML: Object-Oriented Analysis an... Class and Object Diagrams Class Relationships Classes Basic Ideas Find More Practices Articles

2003-2011 by Developer Shed. All rights reserved. DS Cluster 12 - Follow our Sitemap Dev Shed Tutorial Topics: MySQL Tutorials Perl Help PHP Tutorials Oracle Tutorials Administration Flash Java & J2EE Javascript Python Reviews

4 of 5

10/2/2011 7:18 PM

Introducing UML: Object-Oriented Analysis and Design - Practices

http://www.devshed.com/c/a/Practices/Introducing-UMLObjectOriented...

Apache Ajax DHTML

Security Smartphone Dev Web Services XML

5 of 5

10/2/2011 7:18 PM