student workbook - · pdf filestudent workbook. page ii rev 6.3.1 ... applying uml and...

Object-OrientedAnalysis & Design

UsingThe Unified Modeling

Language

Student Workbook

Page ii Rev 6.3.1 © 2009 ITCourseware, LLC

Object-Oriented Analysis & Design Using UML

Object-Oriented Analysis & Design Using the Unified ModelingLanguage

Lynwood Wilson

Published by ITCourseware, LLC., 7245 South Havana Street, Suite 100, Centennial, CO 80112

Contributing Authors: John McAlister, Jamie Romero, Rick Sussenbach, and Rob Seitz.

Editors: Danielle Hopkins and Jan Waleri

Editorial Assistant: Dana Howell

Special thanks to: Many instructors whose ideas and careful review have contributed to the qualityof this workbook, offering comments, suggestions, criticisms, and insights.

Copyright © 2009 by ITCourseware, LLC. All rights reserved. No part of this book may be reproducedor utilized in any form or by any means, electronic or mechanical, including photo-copying, recording, or byan information storage retrieval system, without permission in writing from the publisher. Inquiries should beaddressed to ITCourseware, LLC., 7245 South Havana Street, Suite 100, Centennial, Colorado, 80112.(303) 302-5280.

All brand names, product names, trademarks, and registered trademarks are the property of their respectiveowners.

© 2009 ITCourseware, LLC Rev 6.3.1 Page iii


Contents

Chapter 1 - Course Introduction ............................................................................................................... 9

Course Objectives ............................................................................................................................ 10Course Overview .............................................................................................................................. 12Using the Workbook ......................................................................................................................... 13Suggested References ....................................................................................................................... 14

Chapter 2 - Introduction to Analysis and Design ...................................................................................... 19

Why is Programming Hard? .............................................................................................................. 20The Tasks of Software Development ................................................................................................. 22Modules ............................................................................................................................................ 24Models ............................................................................................................................................. 26Modeling........................................................................................................................................... 28Perspective ....................................................................................................................................... 30Objects ............................................................................................................................................. 32Change ............................................................................................................................................. 34New Paradigms ................................................................................................................................ 36Labs ................................................................................................................................................. 38

Chapter 3 - Objects ................................................................................................................................ 41

Encapsulation .................................................................................................................................... 42Abstraction ....................................................................................................................................... 44Objects ............................................................................................................................................. 46Classes ............................................................................................................................................. 48Responsibilities .................................................................................................................................. 50Attributes .......................................................................................................................................... 52Composite Classes ............................................................................................................................ 54Operations and Methods ................................................................................................................... 56Visibility ............................................................................................................................................ 58Inheritance ........................................................................................................................................ 60Inheritance Example .......................................................................................................................... 62Protected and Package Visibility ....................................................................................................... 64Scope ............................................................................................................................................... 66Class Scope ...................................................................................................................................... 68Labs ................................................................................................................................................. 70

Page iv Rev 6.3.1 © 2009 ITCourseware, LLC


Chapter 4 - Advanced Objects ............................................................................................................... 73

Constructors & Destructors .............................................................................................................. 74Instance Creation .............................................................................................................................. 76Abstract Classes ............................................................................................................................... 78Polymorphism ................................................................................................................................... 80Polymorphism Example ..................................................................................................................... 82Multiple Inheritance ........................................................................................................................... 84Solving Multiple Inheritance Problems ............................................................................................... 86Interfaces .......................................................................................................................................... 88Interfaces with Ball and Socket Notation ........................................................................................... 90Templates.......................................................................................................................................... 92Labs ................................................................................................................................................. 94

Chapter 5 - Classes and Their Relationships ............................................................................................ 97

Class Models .................................................................................................................................... 98Associations .................................................................................................................................... 100Multiplicity ...................................................................................................................................... 102Qualified Associations ..................................................................................................................... 104Roles .............................................................................................................................................. 106Association Classes......................................................................................................................... 108Composition and Aggregation.......................................................................................................... 110Dependencies ................................................................................................................................. 112Using Class Models ........................................................................................................................ 114Labs ............................................................................................................................................... 116

Chapter 6 - Sequence Diagrams............................................................................................................ 119

Sequence Diagrams......................................................................................................................... 120Interaction Frames .......................................................................................................................... 122Decisions ........................................................................................................................................ 124Loops ............................................................................................................................................. 126Creating and Destroying Objects ..................................................................................................... 128Activation........................................................................................................................................ 130Synchronous & Asynchronous......................................................................................................... 132Evaluating Sequence Diagrams ........................................................................................................ 134Using Sequence Diagrams ............................................................................................................... 136Labs ............................................................................................................................................... 138

© 2009 ITCourseware, LLC Rev 6.3.1 Page v


Chapter 7 - Communication Diagrams ................................................................................................... 141

Communication Diagrams ................................................................................................................ 142Communication and Class Diagrams ................................................................................................ 144Evaluating Communication Diagrams ............................................................................................... 146Using Communication Diagrams ...................................................................................................... 148Labs ............................................................................................................................................... 150

Chapter 8 - State Machine Diagrams .................................................................................................... 153

What is State? ................................................................................................................................. 154State Notation ................................................................................................................................. 156Transitions and Guards .................................................................................................................... 158Registers and Actions ...................................................................................................................... 160More Actions .................................................................................................................................. 162Internal Transitions .......................................................................................................................... 164Superstates and Substates ............................................................................................................... 166Concurrent States ........................................................................................................................... 168Using State Machines ...................................................................................................................... 170Implementation ................................................................................................................................ 172Labs ............................................................................................................................................... 174

Chapter 9 - Activity Diagrams ............................................................................................................... 177

Activity Notation ............................................................................................................................. 178Decisions and Merges ..................................................................................................................... 180Forks and Joins ............................................................................................................................... 182Drilling Down .................................................................................................................................. 184Iteration .......................................................................................................................................... 186Partitions ......................................................................................................................................... 188Signals ............................................................................................................................................ 190Parameters and Pins ........................................................................................................................ 192Expansion Regions .......................................................................................................................... 194Using Activity Diagrams .................................................................................................................. 196Labs ............................................................................................................................................... 198

Chapter 10 - Supplemental UML Diagrams........................................................................................... 201

Modeling Groups of Elements - Package Diagrams ......................................................................... 202Visibility and Importing .................................................................................................................... 204Structural Diagrams ......................................................................................................................... 206Components and Interfaces ............................................................................................................. 208

Page vi Rev 6.3.1 © 2009 ITCourseware, LLC


Deployment Diagram....................................................................................................................... 210Composite Structure Diagrams ........................................................................................................ 212Timing Diagrams .............................................................................................................................. 214Interaction Overview Diagrams ....................................................................................................... 216Labs ............................................................................................................................................... 218

Chapter 11 - Use Cases ........................................................................................................................ 221

Use Cases....................................................................................................................................... 222Use Case Diagram Components ..................................................................................................... 224Use Case Diagram .......................................................................................................................... 226Actor Generalizations ...................................................................................................................... 228Include ............................................................................................................................................ 230Extend ............................................................................................................................................ 232Specialize ........................................................................................................................................ 234Other Systems ................................................................................................................................ 236Narrative......................................................................................................................................... 238Template for Use Case Narrative .................................................................................................... 240Using Use Cases ............................................................................................................................. 242Labs ............................................................................................................................................... 244

Chapter 12 - Process ............................................................................................................................ 247

Process ........................................................................................................................................... 248Risk Management ........................................................................................................................... 250Test ................................................................................................................................................. 252Reviews .......................................................................................................................................... 254Refactoring...................................................................................................................................... 256History ............................................................................................................................................ 258The Unified Process ........................................................................................................................ 260Agile Processes ............................................................................................................................... 262Labs ............................................................................................................................................... 264

Chapter 13 - The Project ...................................................................................................................... 267

Inception ......................................................................................................................................... 268Elaboration...................................................................................................................................... 270Elaboration II .................................................................................................................................. 272Construction Iterations .................................................................................................................... 274Construction Iterations — The Other Stuff ...................................................................................... 276Labs ............................................................................................................................................... 278

© 2009 ITCourseware, LLC Rev 6.3.1 Page vii


Chapter 14 - Domain Analysis ............................................................................................................... 281

Chapter Note .................................................................................................................................. 282Top View — The Domain Perspective ............................................................................................ 284Data Dictionary ............................................................................................................................... 286Finding the Objects ......................................................................................................................... 288Responsibilities, Collaborators, and Attributes ................................................................................. 290CRC Cards .................................................................................................................................... 292Class Models .................................................................................................................................. 294Use Case Models ........................................................................................................................... 296Other Models ................................................................................................................................. 298Judging the Domain Model .............................................................................................................. 300Labs ............................................................................................................................................... 302Trial Schedule Sheet ........................................................................................................................ 305Course Catalog ............................................................................................................................... 306Course Roster ................................................................................................................................. 308

Chapter 15 - Requirements and Specification ........................................................................................ 311

The Goals ....................................................................................................................................... 312Understand the Problem .................................................................................................................. 314Specify a Solution ........................................................................................................................... 316Prototyping ..................................................................................................................................... 318The Complex User .......................................................................................................................... 320Other Models ................................................................................................................................ 322Judging the Requirements Model ..................................................................................................... 324Labs ............................................................................................................................................... 326

Chapter 16 - Design of Objects ............................................................................................................ 329

Design ............................................................................................................................................. 330Factoring......................................................................................................................................... 332Design of Software Objects ............................................................................................................ 334Features .......................................................................................................................................... 336Methods ......................................................................................................................................... 338Cohesion of Objects ....................................................................................................................... 340Coupling Between Objects .............................................................................................................. 342Coupling and Visibility ..................................................................................................................... 344Inheritance ...................................................................................................................................... 346Labs ............................................................................................................................................... 348

Page viii Rev 6.3.1 © 2009 ITCourseware, LLC


Chapter 17 - System Design ................................................................................................................. 351

Design ............................................................................................................................................. 352A Few Rules ................................................................................................................................... 354Object Creation .............................................................................................................................. 356Class Models .................................................................................................................................. 358Interaction Diagrams ....................................................................................................................... 360Printing the Catalog ......................................................................................................................... 362Printing the Catalog II ..................................................................................................................... 364Printing the Catalog III .................................................................................................................... 366Object Links ................................................................................................................................... 368Associations .................................................................................................................................... 370Labs ............................................................................................................................................... 372

Chapter 18 - Refactoring....................................................................................................................... 375

Refactoring...................................................................................................................................... 376Clues and Cues ............................................................................................................................... 378How to Refactor ............................................................................................................................. 380A Few Refactoring Patterns ............................................................................................................. 382

Appendix A - UML Syntax ................................................................................................................... 385

Appendix B - Design by Contract ......................................................................................................... 393

Contracts ........................................................................................................................................ 394Enforcing Contracts ......................................................................................................................... 396Inheritance and Contracts ................................................................................................................ 398

Appendix C - University Summary ........................................................................................................ 401

Appendix D - Implementations - C++, Java, and C#............................................................................. 407

Registering for a Course .................................................................................................................. 410C++ Implementation ....................................................................................................................... 411Java Implementation ........................................................................................................................ 428C# Implementation .......................................................................................................................... 443

Solutions ............................................................................................................................................... 459

Index..................................................................................................................................................... 493

Course Introduction

© 2009 ITCourseware, LLC Rev 6.3.1

Chapter 1

Chapter 1 - Course Introduction


Rev 6.3.1 © 2009 ITCourseware, LLC

Apply the principals and practices of Object-Oriented Programming.

Use modeling in analysis and design, particularly in visual modeling.

Use the Unified Modeling Language to create visual models of businessproblems and software solutions.

Design programs with objects.

Create more flexible and more maintainable software systems at lower costs.

Course Objectives

Course Introduction


Chapter 1



Audience: Programmers, analysts and software designers.

Prerequisites: Some exposure to the problems of analysis and design.Experience with structured analysis and design, as well as object-orientedprogramming, would be helpful.

Note: This course is based on UML Version 2.0, and occasionally mentionsfeatures from previous versions.

Course Overview

Course Introduction


Chapter 1

Using the Workbook

Chapter 2 Servlet Basics

© 2002 ITCourseware, LLC Rev 2.0.0 Page 17

Add an init() method to your Today servlet that initializes a bornOn date, then print the bornOn date

along with the current date:

Today.java

...

public class Today extends GenericServlet {

private Date bornOn;

public void service(ServletRequest request,

ServletResponse response) throws ServletException, IOException

{

...

// Write the document

out.println("This servlet was born on " + bornOn.toString());

out.println("It is now " + today.toString());

}

public void init() {

bornOn = new Date();

}

}

Hands On:

The init() method is

called when the servlet is

loaded into the container.

This workbook design is based on a page-pair, consisting of a Topic page and a Support page. When youlay the workbook open flat, the Topic page is on the left and the Support page is on the right. The Topicpage contains the points to be discussed in class. The Support page has code examples, diagrams, screenshots and additional information. Hands On sections provide opportunities for practical application of keyconcepts. Try It and Investigate sections help direct individual discovery.

In addition, there is an index for quick look-up. Printed lab solutions are in the back of the book as well asonline if you need a little help.

Java Servlets

Page 16 Rev 2.0.0 © 2002 ITCourseware, LLC

� The servlet container controls the life cycle of the servlet.

� When the first request is received, the container loads the servlet class

and calls the init() method.

� For every request, the container uses a separate thread to call

the service() method.

� When the servlet is unloaded, the container calls the destroy()

method.

� As with Java’s finalize() method, don’t count on this being

called.

� Override one of the init() methods for one-time initializations, instead of

using a constructor.

� The simplest form takes no parameters.

public void init() {...}

� If you need to know container-specific configuration information, use

the other version.

public void init(ServletConfig config) {...

� Whenever you use the ServletConfig approach, always call the

superclass method, which performs additional initializations.

super.init(config);

The Servlet Life Cycle

The Topic page providesthe main topics for

classroom discussion.

The Support page hasadditional information,

examples and suggestions.

Code examples are in afixed font and shaded. Theon-line file name is listedabove the shaded area.

Screen shots showexamples of what youshould see in class.

Topics are organized intofirst ( ), second ( ) and

third ( ) level points.

Pages are numberedsequentially throughout

the book, making lookupeasy.

Callout boxes point outimportant parts of the

example code.



Ambler, Scott W. 2002. Agile Modeling: Effective Practices for Extreme Programming and theUnified Process. John Wiley & Sons, New York, NY. ISBN 0471202827.

Beck, Kent and Cynthia Andres. 2004. Extreme Programming Explained: Embrace Change.Addison-Wesley, Reading, MA. ISBN 0321278658.

Bellin, David and Susan Simone. 1997. The CRC Card Book. Addison-Wesley, Reading, MA.ISBN 0201895358.

Bentley, Jon. 1999. Programming Pearls. Addison-Wesley, Reading, MA. ISBN 0201657880.

Booch, Grady, James Rumbaugh and Ivar Jacobson. 2005. The Unified Modeling Language UserGuide, Second Edition. Addison-Wesley, Reading, MA. ISBN 0321267974.

Buschmann, Frank, et al. 1996. Pattern-Oriented Software Architecture, Volume 1: A System ofPatterns. John Wiley & Sons, New York, NY. ISBN 0471958697.

Coad, Peter and Edward Yourdon. 1990. Object-Oriented Analysis, Second Edition. Yourdon Press/Prentice Hall, Englewood Cliffs, NJ. ISBN 0136299814.

Coad, Peter and Edward Yourdon. 1991. Object-Oriented Design. Yourdon Press/Prentice Hall,Englewood Cliffs, NJ. ISBN 0136300707.

Cockburn, Alistair. 2001. Agile Software Development. Addison-Wesley, Reading, MA.ISBN 0201699699.

Cockburn, Alistair. 2000. Writing Effective Use Cases. Addison-Wesley, Reading, MA. ISBN 0201702258.

Demarco, Tom and P. J. Plauger. 1979. Structured Analysis and System Specification. Prentice Hall,Englewood Cliffs, NJ. ISBN 0138543801.

Fowler, Martin, et al. 1999. Refactoring: Improving the Design of Existing Code. Addison-Wesley,Reading, MA. ISBN 0201485672.

Fowler, Martin. 2003. UML Distilled: A Brief Guide to the Standard Object Modeling Language,Third Edition. Addison-Wesley, Reading, MA. ISBN 0321193687.

Freedman, Daniel P. and Gerald M. Weinberg. 1990. Handbook of Walkthroughs, Inspections, andTechnical Reviews: Evaluating Programs, Projects, and Products. Dorset House PublishingCompany, New York, NY. ISBN 0932633196.

Suggested References

Course Introduction


Chapter 1

Gamma, Erich, et al. 1995. Design Patterns: Elements of Reusable Object-Oriented Software.Addison-Wesley, Reading, MA. ISBN 0201633612.

Highsmith III, James A. 1999. Adaptive Software Development: A Collaborative Approach toManaging Complex Systems. Dorset House, New York, NY. ISBN 0932633404.

Hunt, Andrew and David Thomas. 1999. The Pragmatic Programmer: From Journeyman to Master.Addison-Wesley, Reading, MA. ISBN 020161622X.

Jacobson, Ivar, Grady Booch and James Rumbaugh. 1999. The Unified Software DevelopmentProcess. Addison-Wesley, Reading, MA. ISBN 0201571692.

Jones, T. Capers. 1994. Assessment and Control of Software Risks. Prentice Hall PTR, EnglewoodCliffs, NJ. ISBN 0137414064.

Kernighan, Brian W. and Rob Pike. 1999. The Practice of Programming. Addison-Wesley, Reading,MA. ISBN 020161586X.

Kruchten, Philippe. 2003. The Rational Unified Process: An Introduction, Third Edition. Addison-Wesley, Reading, MA. ISBN 0321197704.

Larman, Craig. 2004. Applying UML and Patterns : An Introduction to Object-Oriented Analysisand Design and Iterative Development, Third Edition. Prentice-Hall, Englewood Cliffs, NJ.ISBN 0131489062.

McConnell, Steve. 2004. Code Complete: A Practical Handbook of Software Construction, SecondEdition. Microsoft Press, Redmond, WA. ISBN 0735619670.

McConnell, Steve. 1997. Software Project Survival Guide. Microsoft Press, Redmond, WA. ISBN 1572316217.

McLaughlin, Brett D., Gary Pollice and David West. 2006. Head First Object Oriented Analysis andDesign. O'Reilly Media. Sebastopol, CA. ISBN 0596008678.

Meyer, Bertrand. 2000. Object-Oriented Software Construction, Second Edition. Prentice-Hall,Englewood Cliffs, NJ. ISBN 0136291554.

Miles, Russell and Kim Hamilton. 2006. Learning UML 2.0. O'Reilly Media, Sebastopol, CA.ISBN 0596009828.

Page-Jones, Meilir. 1988. The Practical Guide to Structured System Design, Second Edition.Prentice Hall PTR, Englewood Cliffs, NJ. ISBN 0136907695.



Page-Jones, Meilir. 1999. Fundamentals of Object-Oriented Design in UML. Addison-Wesley,Reading, MA. ISBN 020169946X.

Pilone, Dan and Neil Pitman. 2005. UML 2.0 in a Nutshell. O'Reilly Media, Sebastopol, CA.ISBN 0596007957.

Rumbaugh, James, Ivar Jacobson and Grady Booch. 2004. The Unified Modeling LanguageReference Manual, Second Edition. Addison-Wesley, Reading, MA. ISBN 0321245628.

Shlaer, Sally and Stephen J. Mellor. 1991. Object Lifecycles: Modeling the World in States. YourdonPress/Prentice Hall, Englewood Cliffs, NJ. ISBN 0136299407.

Shlaer, Sally and Stephen J. Mellor. 1988. Object-Oriented Systems Analysis: Modeling the World inData. Yourdon Press/Prentice Hall, Englewood Cliffs, NJ. ISBN 013629023X.

Wirfs-Brock, Rebecca, Brian Wilkerson and Lauren Wiener. 1990. Designing Object-OrientedSoftware. Prentice Hall, Englewood Cliffs, NJ. ISBN 0136298257.

http://alistair.cockburn.us/index.php/Resources_for_writing_use_caseshttp://www.agilealliance.orghttp://www.junit.orghttp://www.rational.com

Suggested References (cont'd)

Course Introduction


Chapter 1

Chapter 2 Introduction to Analysis and Design


Chapter 2 - Introduction to Analysis andDesign

Objectives

Identify essential problems and tasks ofsoftware development.

Describe basic concepts of modularity andabstraction.

Outline the concepts of Objects and Object-Oriented Programming.



It's complicated.

Computer programs are among the most complex things people build.

Most people can only think of 7 ± 2 things at a time.

It gets more complicated as the system gets bigger.

Why is the curve of effort vs. size exponential?

More communication links among programmers, designers,analysts, clients, etc.More communication links among modules in the system.

The most efficient software project is a single programmer working on aprogram no one else will use. There's no communication.

Modularity helps to flatten this curve.

With good design and abstraction you can work on a module — a part ofthe program — as though it were a single small program, and thus staytoward the left end of the above graph.

This works even when it's a high-level module that uses several low-levelmodules, if you properly define and constrain the interfaces.

Why is Programming Hard?

size of system

effort

to

complete



Miller, G. A., "The magical number seven, plus or minus two: Some limits on our capacity for processinginformation." Psychological Review, Vol. 63, March 1956, pp. 81 - 97. Miller's research showed thatmost people can only hold seven plus or minus two things in working memory at a time. Think about it whenyou are designing menus. Most of our models and drawings should contain no more than nine different top-level artifacts.

Blaise Pascal, they say, once closed a letter by saying, "I'm sorry this letter is so long. I didn't have time tomake it shorter." Most of what we create will benefit from taking the time to make it shorter. Text, models,and code alike are clearer and communicate better if we take the time to make them concise, precise, andelegant. Take the time.

You have a client even if you aren't a consultant or a contractor. Your client is the person who manages thegroup that needs the system you are working on. Often the client is the person who asked for the work, orthe person who pays for it or whose division pays for it. Usually the client is the person who knows bestwhat the top-level requirements are. The users are important, and your system must satisfy them, but theyoften do not know all the needs of the business.



Figure out what problem to solve or what system to build.

Analysis

Build the system to solve the problem.

Design

Implementation / Programming

Analysis is harder.

Most of the problem is communication: communication with the computerand communication with people. The computer is easier, in spite of (orperhaps because of) being so literal and requiring perfection in each detail.

What tools do we use to manage complexity and help with communication?(Not just in software, but everywhere.)

Modules — Break a job into simpler components such that if we completethe components the job will be done.

Models — Represent the problem, the solution, and their component partsin such a way as to enable us to work with the important aspects (for aparticular task) and ignore the rest.

Formal Process — Organize the work so that we do everything importantwith a minimum of non-productive effort.

The Tasks of Software Development



We divide the analysis into two parts: Domain Analysis, and Requirements or Specification Analysis.

Domain Analysis is finding out about the business and its processes. Building a common vocabulary withthe domain people, users, clients. Understanding the context within which our proposed system mustoperate. And if there is an existing system that ours is to replace, we should understand that as well.

Requirements or Specification Analysis describes the system that will solve the client's problems,characterizing it in such a way and to such a depth that if we meet the specification we satisfy the client.

It's not possible to perform either of these perfectly or completely. This is one reason we must deal withchange throughout the process, as we discover missing, incomplete, inconsistent, or erroneousspecifications.



ModulesA module is a part of a program or model that can be considered as an entityseparate from the rest.

A module has a purpose.

A module has a specified interface through which it interacts with the restof the system.

A module is abstract. It hides its implementation, the details of itsoperation, from the rest of the system.

A module should have high cohesion.

It should do one thing, have a single responsibility, at its level ofabstraction.

A module should have low coupling.

It should be a black box. The modules that use it need not understand itsinternal operation.

Its external interface should be simple, narrow, and elegant.

The kind of module we will be most interested in during this course is the object.

We will also see higher-level modules that contain multiple objects.

Objects contain attributes (data) and methods (functions), and these aremodules, too.



ModelsThe kind of model we will talk about most is an abstraction made up of modulesand relationships between them.

Abstraction is ignoring those aspects of something that do not contributeto your task in order to focus on those aspects that do.A model displays a few aspects and hides all the others.We try to use between nine and five important modules in each model.These modules are all at about the same level of abstraction.The parts we choose contribute to some particular understanding of thething modeled.

For example, the mathematics operations in our programs are abstractions.When we add two simple integers in a program we don't know (or care) what'sgoing on at the level of the memory and the CPU registers. Instead, we are freeto concentrate on the logic of the program and on the way this addition willcontribute to some result.

If we had to deal with addition at the byte level every time we added twointegers it would add considerable complexity to our task and divert ourattention from the higher-level logic.

This abstraction allows us to focus on just a few things at a time, and alsoallows us to work at a constant level.

People seem to perform better if they can work at a fairly constant level ofabstraction. This seems particularly valuable in communication.And don't forget the magic number 7 ± 2.

One of the most important attributes of a model, regardless of its perspective,level, or purpose, is that it is clear, and can be easily read and understood.

This is as important as accuracy. If you cannot understand it you willnever know if it is accurate.Part of this is the artistic quality that we call "elegance." Spend a littleextra effort to make it clear and clean and pretty and simple. Elegant.



When Ford proposes to build a new car, they first build models of it. In the old days they'd build a woodenframe, cover it with clay, and carve it into the shape of the proposed body. First in miniature, later full size.They'd probably model several variations. Finally they would paint the final version and photograph it withpretty people standing around it. Was this a car? Of course not. What was it? An abstract representation ofa single aspect of a car: the appearance. In other words, a model. Today most of this is done withcomputers, but the ideas are the same.

This isn't the only model of a new car, although it often seems like the most important one. (As withcomputer programs the visual impression is crucial.) Ford will also build a computer model of thesuspension with all its parts and characteristics. This will be a working model (although today it's a computersimulation with variables for spring rates and pivot locations). Then they can exercise it by subjecting it tovarious simulated bumps at various simulated speeds. They can calculate the forces on the parts to see ifthey are strong enough, and the forces on the rest of the car to see if the passengers will like it. Perhapsthere will also be wind tunnel models, and coupled with the mathematical models of the proposed enginethey can calculate the performance and fuel mileage. Thus Ford can find out a lot about their design and canmake certain kinds of decisions fairly cheaply, before making a commitment to metal and tooling.

Note that each of these models has a purpose and each is an abstraction, each represents only one part ofthe car.

Some models become central to your project and will be maintained and used forever. Others will be builtonly to solve an immediate problem and subsequently discarded. Maintaining a model can be moreexpensive than building it (like a program). Don't maintain it unless you make a profit on the effort. If youchoose not to maintain it, get rid of it immediately. The model is often less valuable than the thought andplanning that goes into it.

The ultimate model of software is the code. In the beginning we design and model with diagrams and text.Then we write code. We find problems and shortcuts, test and debug, find better ways to do things, and doa lot of low-level design as we go. The result does not exactly follow our models. Whether we update ourmodels, they are never exactly like the code. The code rules.



ModelingOur choice of models to build is driven by our perception of the problem asmuch as it drives our understanding of the problem.

One of our many challenges will be to understand what the models aretelling us and change our ideas as we go forward.We have to start somewhere, guided by our best guesses based on ourexperience, but then we must leave them behind and follow our models.As we learn, we find it easier to decide what we need to model, which ofour existing models may no longer be relevant, and what we need to donext.

Determine the purpose of the model before building it.

Not the purpose of the thing modeled, but the purpose of this particularmodel in the development process.Put in the model only that which contributes to the purpose of the model.Don't try to tell everything you know in a single model.Don't try to model everything.

For each model we must choose the level of abstraction.

This too will drive our understanding and be driven by it.This too will become easier, more apparent, as we proceed.

It's useful for our models to be well grounded in reality.

Models derived from the domain communicate better with our clients,users, and domain experts.Modules derived from the real world are more likely to be reusable.Models and modules derived from the domain have a characteristic kindof unity and integrity and reality that is hard to create from scratch. Theymodel something that exists and works rather than something we imaginemight work if we could build it.

The UML is not complete. Explore other kinds of models: Data Flow Diagrams,Entity Relationship Diagrams, etc.



What Makes a Model: Text and GraphicsIn our world there are many kinds of models, although we hardly ever build wooden forms and cover themwith clay. Most of our models are text or graphic representations. Sometimes we build a software model ofan algorithm or a process to test its speed or storage requirements. Sometimes we model a user interface toget the user's opinion. But mostly we stick to text and graphics. Some prefer one, some the other. Mostlearn best with both: text with plenty of illustrations.

Static vs. DynamicSome of the things we model will be static and others dynamic. A static model can represent a static thing.It can also represent a dynamic thing, but incompletely. A static model of a dynamic thing is a snapshot,change frozen at a particular moment, a particular state. A dynamic model can represent a dynamic thingmore completely.

Analysis vs. SynthesisAnalysis is describing something that exists and synthesis (design) is predicting something in theprocess of creation. See Herbert Simon's Sciences of the Artificial for a fascinating discussion of thedifference between synthesis and analysis, the difference between understanding something natural andcreating something artificial.

IterationThe first model you build may be perfect. It may not. Don't just build a model and go on. Test your models,consider other possible ways to do things, try modeling the subject in another form, see if someone elsethinks of it in a different way. As your experience with the problem grows, the chance of an insight thatyields a better model grows too. However, beware of analysis paralysis.

FeedbackGet as much feedback as you can, soon and often. Usually this will be from the users and the client. If youare working without it you are kidding somebody. The classic mistake here is to build what we think theyneed. That trick never works.



PerspectiveIn software engineering we view our work and build our models from threedifferent perspectives.

Domain perspective (also called Conceptual or Essential perspective) isconcerned with the domain, the context of the problem.

The existing business, its organization and operation.

An existing system that our proposed system is to replace (if any).

Specification or Requirements perspective is about what the proposed systemshould do.

The proposed system as seen from outside, by the users and the client.

The requirements.

Design or Implementation perspective describes the internal organization andoperation of the system we propose to build.

The modules that will make up our proposed system and the way they willwork together to accomplish the tasks.

Record the perspective of your diagrams and models.

It may be obvious to you now, but not to someone else later (and youmay be that someone else on a later project).



ObjectsObjects are better modules.

Objects give us more abstraction, better modularity, more flexibility.

Now it's modularity of both function and data.

We can encapsulate more in a module and enforce the encapsulation inways that we could not before.

The modules are even further from the machine, closer to human thinking.

The modules can represent artifacts from the problem and the problemdomain, from the world of the people rather than the world of thecomputer.

Before OOP we thought first of the operation: What's it do?

After we worked that part out, sometimes a long time later, we thoughtabout the data: What's it do it to?

In OOP the data gets at least equal attention.

Each of these advances in abstraction, modeling, and modularity gave us thepower to build larger systems with less effort by managing communicationproblems.

Objects help us to program the way we actually work in the real world instead ofthe way we worked in school.



Much of this jargon comes from the Smalltalk world, once the center of OO. A Smalltalk programmer says"Object A sends message foo to object C" when a C++ programmer would say "Object A calls function fooon object C". They both mean the same thing. What a Smalltalk programmer would call a method a C++programmer calls a member function. Physically they are functions, so physically some code in one objectcalls a function that belongs to another object, no matter how you say it.

Anthropomorphism in designing OO models and programs is encouraged. In fact, it's one of the advantagesof objects. We all know that our programs don't have tiny people inside doing the work, but it's often usefulto think of modules as having desires, responsibilities, mental state similar to that of a human.

Up until now we've talked mostly about software objects. It turns out that objects are also quite useful asmodules in models for all the same reasons. One important difference, however, is that in software objectswe enforce rules about information hiding and abstraction, whereas in objects used in models of businessesand such we don't try so hard to enforce these rules. It's the difference between analysis and synthesis. Insoftware design we want to build something good. In analysis we want to model something that exists, be itgood or bad. Sometimes this results in objects you wouldn't want to use in a program, but they are just rightfor modeling a business.



Specifications change.

This can cause poor communication between us and them.They don't know what they need until we give them what they say theywant.Specifications change as we (and they) learn more.Specifications change as the business domain changes.The later we change, the more it costs.

The solid line above is the classical curve of effort to change the system vs. thepoint in the development cycle at which we begin. (The same graph describesthe cost of fixing a bug vs. the length of time it went undiscovered.)

The solid graph is based on data from before OOP.If we design and build good objects and maintain the structure of thesystem every time we touch it we can flatten this curve into somethingmore like the dashed line.It will always cost more to make a change as time passes, but we can keepthe curve from getting so steep.

OOP and OOD help us to do a better job in the real world, working with changeinstead of fighting it or pretending we can control it.

Change

analysis

effort

to

make

change

design coding maintenance



We have to handle vague and changing requirements. We cannot force our clients to work or think the waywe want them to. And if we could it still wouldn't be the right thing for their businesses or ours. The world isvague and constantly changing, and the rate of change is increasing.

OO helps. If you do a good job at the object level, it's much easier to change the program later when youknow more. We want to flatten that curve.



New ParadigmsAdopting new technology such as OOP is difficult, confusing, expensive, andcan frustrate both managers and programmers. Ignoring new technology is evenmore expensive.

Training — More projects have foundered from too little training than from toomuch.

Mentoring

Some shops that have a training organization often send a teacher out asmentor to a team about to begin working with objects.Smaller organizations may find one or two developers who have theexperience, the knowledge, and the teaching ability to season a team justgetting started. Be very good to them — you don't want to lose them.If there's no one available in your organization who can take the mentorrole, you might consider bringing in a consultant from outside: full time, ifthe project is big enough, or part time to sit in on reviews and offer ideas.A good mentor can make the difference between success and failure.There are insights that seem to come only from experience. And it's timewell spent to look for just the right person: someone with both theknowledge and the ability to communicate it.

Learn something new with each project, even if there is a cost. (There's always acost.)

It should pay off later.Sometimes what you learn is that a particular thing won't pay off later, andthat is valuable too.Sometimes you are better off to let someone else make that discovery andtell you about it, but it's hard to see that ahead of time.Read the literature, the books and the magazines and the websites. You arecrippled if you don't keep up.



Have you ever participated in a software project that failed? What caused it?

Some gurus and their books consider models and requirements documents to be deliverableproducts of the development process. What do you think?

Labs

Chapter 9 Activity Diagrams


Chapter 9 - Activity Diagrams

Objectives

Model activities, such as complicatedalgorithms and multi-branched user interfaces.

Model parallelism.



Activity NotationActivity diagrams are similar to flow charts.

The notation of activity diagrams is much the same as that of state diagrams.

The main difference is that most of the nodes in a state model are states(although some may represent activities) while most of the nodes in anactivity model represent activities (although some of them may representstates).

You can add details for the activity inside a rounded rectangle.

Partly because most nodes are activities, most transitions are triggerless. Whenthe activity of the node is finished, the transition occurs.

There can be guard conditions like those in state charts.

Activity diagrams, like state charts, usually flow from left-to-right or from top-to-bottom.

write a

program

[no bugs]

debug the

program

[few

bugs]

[many

bugs]

writecode

write a

program



The guard conditions should not allow ambiguity about what will happen in any situation.

A guard condition else will be true if all other guards for transitions from the activity are false.

Transitions may have actions on them (/action) like transitions in state diagrams, but it is unusual.

An activity takes up time; a transition (even if it has an action) is atomic and takes no time.

Activities have no internal transitions, or entry or exit actions.



Decisions and Merges

If you believe the program needs to be checked again after debugging (whateverare you thinking?) you can run the path back around through another diamond,called a merge.

If it's got one in and more than one out, it's a decision and it'll have guardconditions on the transitions from it.If it's got one out and more than one in, it's a merge and it won't haveguard conditions on the transition from it.

[no bugs]

debug the

program

[few

bugs]

[many

bugs]

writecode

[many

bugs][few

bugs]

[no bugs]

write

code

debug the

program

test

You can express testing of a program using a decision diamond.



Forks and JoinsOne of the strengths of activity diagrams is their ability to model parallelprocesses.

When a single transition encounters a fork (heavy vertical or horizontal line) itcontinues along the paths on the other side in parallel and asynchronously.

This used to be called a synchronization bar.

Parallel paths may be traversed any way at all.

In the example on the facing page, you can first reach for a cup with yourright hand and then start pouring coffee into the filter with your left whileyou set the cup on the counter and reach for the water. Or you cancomplete the paths one at a time from left-to-right. Or right-to-left.

Three of you can work on it at the same time.

The only restriction (in the first parallel section) is that you'd better put thecoffee in the filter before you put the filter in the machine.

A join (multiple in, single out) means that all the incoming transitions mustarrive before the outgoing transition may leave. It synchronizes the process.

Don't turn on the machine before putting both the coffee filter (withcoffee) and the water in it.

A join and fork can be combined and have multiple arrows arriving on one side,and multiple arrows leaving on the other. All the incoming transitions must arrivebefore any of the outgoing transitions may leave.



Note the action associated with one transition. This diagram was adapted from the UML standard, V1.4,sec. 3.84.3.

[no coffee]

[coffee]

put water in

reservoirget cups

put filter in

machine

turn on

machine

brew coffee

/coffeePot.on

pour coffee drink

get cans

of cola

[no cola]

[cola]

look for

coffee

put coffee

in filter



Drilling DownThe activity model on the previous page is on the complicated side of our magicnumber rule, but activity diagrams are usually easier to understand than, say,communication diagrams with the same number of nodes.

If we want to add detail to a section of this model we would probably do it onanother diagram, both to avoid making this one more complicated, and to avoidadding material at a different level of abstraction. This is called drilling down.

We expanded the put coffee in filter node to create this new model with moredetail and mark it with a rake.

We could expand any of these nodes if we needed to. Finding the canopener, for example, could turn into an adventure.

We probably should make notes on both of these diagrams that tie themtogether. The CASE tools can help organize them for us.

[else]

[canunopened]

findfilter

getcoffee

put coffeein filter

find canopener

open can



Here the else is quite useful, as the alternative to an unopened can could be an open can, an open bag,a closed jar with a lid, or a heap of coffee lying out on the counter. The else covers all of these possibilitiesand anything we didn't think of.

This model fits in place of the previous put coffee in filter node. The entry and exit of that nodecorrespond to the start and endpoints of this model that expands and explains it.

A lot of business and software processes could be much more parallel than they are. Often this is becausewe couldn't represent the parallelism, and things that were represented sequentially became sequential.Now that we can represent it, we should be on the lookout for places to go parallel. Many user interfaces,for example, force the user to do things in a particular order, no matter that another might be moreconvenient. Activity diagrams are very good for modeling the back and forth of a user interface.

Investigate:Why did we need the merge here? Couldn't we go down from open can to the join?



IterationWe can model iteration on an activity diagram as we do on other dynamicmodels.

Note that the decisions and branches of control are clearer than they werein sequence and communication models.

In the diagram on the facing page, the activity add item to order is done foreach item.

UML 2.0 provides a notation for modeling looping in activity diagrams.

A typical loop has three parts: the setup, the body, and the test.

You can remodel the previous diagram using activity partitions in a singlenode.

Setup

Body

TestCondition

Setup Body[false]

[true]

Test

Condition



Get FirstItem

Add Item

to Order

Get Next

Item

[more items]

[no more items]

Process

Payment

Put Items

In Box[yes]

[no]

Cancel

Order

Ship Order

Payment

Authorization



PartitionsThis activity model illustrates partitions (also known as swimlanes). The labeledvertical bands show who is responsible for each of the activities.

Use partitions when you need the activity model to show complicatedflow of control and who does what.



Process

Payment

Put Items

In Box[yes]

[no]

Cancel

Order

Ship Order

Get First

Item

Add Item

to Order

Get Next

Item

orderClerk finance warehouse shipping

Payment

Authorization

[no more]

[more]



SignalsA simple activity diagram has clearly-defined starting and ending points thatdetermine that program's runtime. Some applications need to respond to signalsgenerated externally from the application.

UML 2.0 provides for three types of signals: time signals, input signals, andoutput signals.

Time signals specify an interval of time before a signal is produced.

Input signals come from an outside source or process.

Output signals are signals sent from your system to some outside system.

The following diagram depicts a system that sends a signal to authorize apayment and then waits 30 minutes for a reply. If a reply is not received, then theauthorization will assume to be declined.

Create

Authorization

Process

Payment

Wait

30 minutes

Reverse

Purchase

Send

Authorization

Authorization

Confirmed



Parameters and PinsYou can specify input into an activity and output from an activity usingparameter nodes.

Parameter nodes are rectangular boxes on the edges of an activity.The input parameter node must have an edge to the first action and theoutput parameter node must have an edge from the final action.

Pins are a notation in activity diagrams to depict input and output parameters.

In the following diagram, the activity Ship Order requires an order object fromCreate Order.

If the output of an activity is an exception, then flag that pin with a small arrownear the pin.

Create

OrderShip

Order

order order

Create

Order

Ship

Orderorder order

Order

CancellationOrderProblem

Exception

Total Item

Cost

Calculate

Tax

Calculate

ShippingOrder Total

Cost



UML 2.0 provides an alternate notation for exception handles using a "zig-zag" or "lightning bolt" instead ofmarking a pin with a triangle:

CreateOrder

ShipOrder

order order

CancelOrder



Expansion RegionsYou can use expansion regions to show that an action or series of actions occuron a collection of items.

The following diagram depicts an activity that produces a collection of coursesthat need to be processed.

Sometimes when processing a collection of items, one of the items may not beable to be processed. In the previous example, one of the courses chosen mayhave been closed. Just because some of the courses are closed does not meanthe student should not be registered for the rest.

Flow finals indicate that one of the items in the collection may terminate, but therest should be processed.

ChooseCourses

AddStudent

to Roster

CreateCourse

Schedule

GetCourse

[open]

[closed]

ChooseCourses

RegisterStudent

in Course

CreateCourse

Schedule



Using Activity DiagramsActivity diagrams are mostly about the flow of control. The activity model isparticularly good at showing complicated branching and parallelism in control,but there isn't much information moving here.

Activity diagrams are good for modeling the operation of an existing papersystem that you intend to replace, if it is more about control than information.

If the information flow and manipulation is the main thing, try data flowdiagrams.

Activity models are useful for modeling user interfaces.

Activity models are often used to illustrate branching in the operation of usecases.

You can model complex algorithms you are going to use in the code for yourmethods.

Activity models are at home in all three perspectives: domain, requirements, anddesign.



Create an activity diagram for the user interface to a simple Automatic Teller Machineperforming the withdrawal operation. Include as much parallelism as possible.

Labs

Chapter 14 Domain Analysis


Chapter 14 - Domain Analysis

Objectives

Begin detailed communication with theclient, the domain experts, and the users.

Develop a common vocabulary.

Find the primary objects in the domain.

Model some of the relationships betweendomain objects.

Model the existing business, as it affectsthe problem.

Model any existing system that we intendto replace.



Chapter NoteThis chapter will cover domain analysis of the university and its existing system as asingle operation. In the real world, we would probably be working on a number ofthings in parallel, but that's hard to do in a classroom situation. Other than that, this isas much like we do it in a real project as we can make it, except that we don't have theusers and the client here. (Which makes sense, of course, because our university isfictitious.)

In the university registration project there is an existing system. We will model it as partof the domain. We don't want to copy it completely, because it does not work wellenough. We will retain some of its features to make our system easier to adopt. We willcopy some of its terminology and metaphors.

If you've been working in the domain for a while, you may have domain objects fromother projects you can use on this one. These models will break all the rules fordesigning software. Businesses are not designed like software, and they don't work likesoftware. Model what's there. Your analysis may show you ways in which you feel youcould improve the organization of the client's business. They may not want to hearyour thoughts about that.



Top View — The Domain PerspectiveMost domain modeling (also called conceptual or essential modeling) occursduring inception and elaboration. After that, while iterating on analysis, design,and construction, you often find it useful to go back and take another look at thedomain, driven by some specific question you've uncovered.

This phase is mostly about communication with the client, domain experts, andusers. We attempt to:

Establish a common vocabulary.Understand the business, business rules, etc.Understand the environment within which the business operates.Understand the existing system to be replaced (if any).Ask: What's wrong? What needs improvement? Why? Where's thepayoff?Use our experience in the domain if we have any - this makes it all easier.

The most important model here is usually the class diagram.

Describe objects in the domain.Assign attributes and responsibilities to them.Model the important static relationships between them.

We often build simple top-level use case models to identify the main use cases.

Some of these model an existing system, documenting its functionality.Others document the top-level function we'll need from the new system.(These aren't strictly domain models; they're more from the specificationperspective.)

Sequence models can show us the dynamic interactions between the objects inthe domain, if we need them.

Activity models can explain complicated use cases or algorithms, if we needthem.



MEMO

To: IS DepartmentFrom: Melissa WardRE: Paper-Based Registration System

The following is a description of how the current paper-based registration system is structured.

In order for a student to register for courses, they must first be enrolled in the university. Upon enrollment, astudent is given an id and personal information, such as address and phone number, are recorded.

Before registering, the student typically meets with an advisor and puts together a preliminary schedule on aTrial Schedule Sheet. This document is for student and advisor use only. We don't use it in the Registrar'soffice to add a student to a course.

In order for the student and advisor to determine what courses to register for, they consult the CourseCatalog and the Course Schedule. The Course Catalog contains detailed descriptions of courses, as wellas prerequisite information. The Course Schedule contains the current listing of which courses are availablethis semester, as well as the times, locations and teachers for each course. There are also other paperdocuments, such as the Academic Calendar, that don't apply directly to the course registration process thatstudents use to determine their schedule.

Upon completion of a Trial Schedule Sheet and on the date the student is eligible to register, the studentvisits the appropriate department in which their course is being offered and talks to the departmentsecretary. The department secretary checks the Course Roster for the course the student is trying to sign upfor, to determine availability. If there is space available and the student meets the appropriate prerequisites,then the department secretary will add the student's name and id to the Course Roster. If for any reason, thestudent can not be added to the requested course, then they would have to revise their schedule, perhapswith their advisor, and try to register for another course.

At the end of each business day, every department secretary faxes in each Course Roster to the Registrar'sOffice. The office secretary updates the university records each day with the new data for each course.This involves opening the appropriate filing cabinet drawer for the department, and then taking each newCourse Roster and placing it into a folder that contains the name of the course on it and disposing of any oldRosters.

I've enclosed a page from each of these documents for your informational purposes.

Sincerely,

Melissa WardRegistrar, Denver State UniversityEnclosures



Data DictionaryNow is also a good time to start a data dictionary to catch the suggestions thatturn out to be too simple to be objects.

It can help find details about your objects, too. For example, time is anhour (integer) and a minute (integer) and a second (integer or float or dowe handle hundredths of seconds as another integer?). Does an hour havethe range 0 - 12 or 0 - 24? These are things you need to think about, andthe data dictionary is a good tool to trigger the questions and record thediscoveries.

The data dictionary will contain simple data objects, as well as structureddata and may contain classes, but we will be documenting the classes inother ways, so it's not necessary to do it here.

Start out simple, similar to a glossary, and add detail as you go along.

By the time you get to detailed design you should have your low-level datapretty well defined, including such things as datatype, range, allowedvalues, relationship to each other, and any applicable business rules.

By this time it will be fairly formal, with complete and unambiguousdescriptions.

UML has no syntax for this formal description. Some teams use Backus-Naur Form (BNF).



Tom DeMarco has a good section on the data dictionary, including his enhancements to the Backus-NaurForm (BNF) notation, in Structured Analysis and System Specification.



Finding the ObjectsBrainstorm

Get the team together and start listing possible objects on the board.

Nouns from the domain.

Verbs too — some objects come from actions instead of the other wayaround. But think of them as things. (A transaction is an action, but wecan name it with a noun and make it an object.)

Don't criticize, just write everything down. Try to make everyone feel safeto make mistakes.

Aim for high-level stuff, leave details (e.g., Date objects) for later.

Solicit suggestions from the users and domain experts.

Try to keep the programmers fairly quiet so the domain folks aren'toverwhelmed. The programmers want software objects instead ofdomain objects anyway.

Get as many as possible and discard the extras later.

Restrict the area of interest to a level or an area of the domain so asto keep it manageable.

Think of the objects as parts, components of the domain, things that areout there, and ignore what they do or contain.

These objects will be the foundation of your work from now on.

Eventually some of them will find their way into your program.



This is called factoring, breaking a system down into its component objects, its factors.

Discovering the objects is one of the best reasons for domain modeling. Even if you don't need to build anyother domain models, you might consider mining the domain for objects to use in the rest of the project.The objects you get from the domain will not be directly usable in your software design, but they make agood start. Objects derived from real things have a quality of functionality, rooted in reality, that's hard to putinto an object you create from scratch. This helps in communication, and makes your programs work bettertoo.

Try It:Brainstorm a list of the top-level objects for the university problem. Do it as one group, list them on a boardwhere we can keep them for a while.



Responsibilities, Collaborators, andAttributesEach object should have at least one responsibility. (Verbs from the domain canindicate responsibilities.)

This will be the main thing the object does or knows.Objects from the domain may not be as cohesive as later objects inprograms. They may have several unrelated responsibilities.A responsibility may be something to do or something to know.Knowing a date is a perfectly good responsibility for an object.

This usually implies maintaining the data in legal form and allowingread and write access.Sometimes just knowing where to find the data is enough.

Some responsibilities will be too big for a single object to handle.

The object with the primary responsibility can have collaborators.A collaborator often takes only part of the responsibility.

Shipping has the responsibility to ship an order.Its collaborator, warehouse, has the responsibility to pull the itemsand get them to shipping.

Part of it is point of view.A customer thinks of the order clerk as having the responsibility tofill an order.The company thinks of the order clerk's responsibility as taking theorder and passing it on to shipping.

Responsibilities imply attributes, and vice versa.

An object whose responsibility is to hold a date will have to represent insome fashion a day, a month, and a year.In domain modeling, we can represent an attribute with a name, but nodatatype. The attribute won't necessarily correspond to just a single type— we just haven't thought about the type yet.Attributes should make sense for the object: Does this information belonghere? Is this the most reasonable place for it? Where will others look forit?



You are modeling the way the business works in the minds of the domain experts and the users. There maybe disagreement, there may be several different views. We're dealing with some sort of reality here - thebusiness does work - but there will be differences in the way people think of it. You may have to try a fewmodels before you find one that pleases everybody. Or displeases everyone equally.



CRC CardsClass – Responsibility – Collaboration (CRC) cards are a good way to documentyour objects in the early stages.

Class is primary, Responsibility is secondary, Collaborators tertiary.

Add responsibilities to the CRC cards.

Start with the main responsibility, the one that characterizes the object.

Add collaborators and we can start thinking of class models with multipleclasses.

Collaborations imply relationships between classes.These are operational relationships rather than structural (static)relationships.These are more like sequence or communication models than classmodels really, but they still rely on class diagrams for the structure thatsupports the communications.Select collaborators based on their responsibilities.

Some people write attributes on the back of the cards.

But don't go to the details too early, a common and troublesome tendencyto which programmers are peculiarly susceptible.It's usually better to let the responsibilities imply the attributes andformalize the attributes later, during design. Then write them on the backsof the cards.

Don't worry about inheritance until later, unless something's really obvious or thedomain people force it on you.

"Well, a teacher is just like any other employee except . . ."

Some teams throw away cards that have no responsibilities. Others keep them incase they'll need them later.



The CRC Card Book by Bellin and Simone has a lot of useful material, especially in the area of group/teaminteractions. CRC cards can help with people problems, as well as technical ones.

Class name at the top, responsibilities on the left, collaborators (if any) to the right of the responsibility.Some people put in inheritance and attributes.

Try It:As a group, create a CRC card for each object on the board. Assign responsibilities and collaborators.What is the perspective of this exercise?

ytisrevinU

tnemtrapedetaerc

golatacesruoctnirp esruoc,tnemtraped



Class ModelsIt is usually worth while to build a top-level class model for the domain, or thepart of it that affects our work. There are several reasons:

Establish a common vocabulary with the users and domain experts. Byassigning data and responsibilities to the objects, we see how they aredistributed among the artifacts of the business. We see what the domainpeople mean when they say "department" — what it contains, what itdoes.

Help us learn from the domain folks the static structure of their domain.

Discover objects and relationships which we will use all through theproject. Many of these objects will be in the code.

This diagram should model the most important objects in the university, and thestatic relationships between them, all based on the real world.

The classes in this model will probably show very few of their attributesor operations, possibly none at all. We are most interested in the objectsand their relationships.

We may also start modeling the individual classes, and these models will showthe attributes and operations as we need or discover them.

In the beginning, they will have only responsibilities. Some may never getanything more. This is a domain model and doesn't need full detail.



Use Case ModelsWe might build some domain-perspective use case models for the university.

What was the perspective of the use case models we built duringelaboration? What were we modeling then?

We are modeling existing processes which we intend to replace, and new usecases that the existing system does not handle. Not every possible use case, justa few interesting ones. We can do more later if we need to.

We are most interested in the user's experience.

Use include and extend where they help you avoid duplication in yourmodels.

We will need a text narrative to define pre- and post-conditions, invariants,exceptions, and multiple paths. The narrative need not be extremely detailed.

You may find that an activity diagram is a great help with a use case that hasmultiple branches in its flow.

Sometimes it's interesting to go back to the class diagrams and the CRC cards,and see how the use cases play out. Who has primary responsibility for a usecase? Collaborators? Data? Are the links in the class diagram adequate for thenecessary communication?

This is much more important in a design model. It doesn't matter as muchif your domain models aren't complete and functional. They just need tohelp you communicate.



Other ModelsWe may build state models of any objects that that have complex state.

If we model some use cases from the existing system, we can look for an objectto take the initial responsibility for each use case, along with collaborators tohandle any parts the primary object cannot.

We might get out the CRC cards again.

Note that a collaborator often takes only part of the responsibility.

It all changes with point of view.

A customer thinks of the order clerk as having the responsibility to fill anorder: "That's who I deal with to get it done."

The Order Clerk is also primary in terms of sequence.

The company thinks of the order clerk's responsibility as taking the orderand passing it on to shipping.

You may also find a need for:

Activity models of complex processes and algorithms.

Sequence or communication models to show interactions betweenobjects, if we need to show how the objects work together to performsome task.

Data Flow Diagrams (DFD) are very useful in domain modeling.

Business Rules could be considered requirements, but can also be part of thedomain.

Remember the Date object and the rules about leap years and the lengthsof the months?



Judging the Domain ModelWe're doing this for the communication. The main criterion is how well we (theanalysts and developers) are communicating with them (the client, the domainexperts, and the users). Are we getting the information we need?

How well do you understand the existing business, the problems, theparts that work well? How well do you understand the context, itsconstraints and imperatives? That is how you judge the domain models.

Domain models need not follow our rules (coupling, cohesion, etc.) for design.If the domain expert describes a dread mess, you grin and nod your head andmodel a dread mess. Your current goal is to understand, not to improve, what'sthere.

Build only the models you need.

Throw away models that are not important enough to maintain.

Often the modeling is more important than the model. When you'velearned what you needed to learn you may no longer need the model.

Maintaining models is costly, but models that are not maintained are aliability.

When you throw away a model, it's sometimes useful to save a text noteon any decisions that were driven by that model, particularly decisionsthat surprised you. Sometimes you find yourself looking back andthinking, "I wonder why we didn't to it this other way, it seems like itwould work better. I know that we had a good reason at the time. I wish Icould remember what it was." Some shops (and people) keep a logbookfor things like that.



Build a top-level domain perspective class diagram for the university system. It should haveabout seven plus or minus two classes. Make any simplifying assumptions you like. For example,each course is taught just once (no sections), and all classrooms hold 30 students.

Build a top-level use case diagram for the university registration process from the domainperspective. Use the domain memos as input for this exercise. How does it differ from thespecification use case diagram?

Write a narrative for the Enroll Student in Course Use Case.

Labs



MEMO

To: IS DepartmentFrom: Melissa WardRE: Answers about Paper-Based Registration System

Thanks for your questions about our current system. Here is the information that you requested.

Any teacher can be an advisor and can advise many students.A student can only have one advisor.Each student can register for a maximum of five classes at a time.Each teacher can teach up to three courses at a time.We do keep information about a teacher, such as name, address, phone number, salary. As a matter offact, the name, address and phone number form is identical for both the students and the teachers.Each teacher's records are kept by the department they teach for.

Let me know if I can answer any other questions for you,

Melissa WardRegistrar, Denver State University



Trial Schedule Sheet

.tpeD esruoC srHtiderC

1

2

3

4

5

��

��

��

��

��

��

��

��

��

� ��

��

��

��

��

��

��

Note: This form is for student and advisor use only.



Course CatalogComputer Science Courses

Department of Computer Science

CS100 (3 credits) Introduction to ComputingHardware and software concepts, word processing, spreadsheets and operating system commands.

CS150 (3 credits) Introduction to Programming - JavaObject oriented programming using the Java language. Classes, exceptions, basic data structures.

CS151 (3 credits) Introduction to Programming - C++Object-oriented programming using the C++ language. Classes, basic data structures, problem solving.

CS160 (4 credits) Algorithms and Data StructuresPrerequisite: CS 150 or CS 151Data structures, sorting, searching, hashing, and complexity analysis.

. . .



Denver State UniversitySpring Schedule

#esruoC emaNesruoC stiderC syaDgtM emiTgtM rotcurtsnI mooR

001SC gnitupmoCotnoitcudortnI 3 FWM 05:9-00:9 sllaW 004GNE

051SC avaJ-gnimmargorPotnoitcudortnI 3 FWM 05:11-00:11 gninroC 523GNE

061SC serutcurtSataDdnasmhtiroglA 4 hT/T 02:3-05:1 gninroC 013GNE

002SC segaugnaLretupmoC 4 FWM 05:9-00:9 ABT 523GNE

052SC noitazinagrOretupmoC 4 FWM 00:1-01:21 sllaW ABT

003SC ecneicSretupmoCfoslatnemadnuF 4 FWM 00:4-01:3 tnarG 213GNE

013SC gnireenignEerawtfoSotnoitcudortnI 4 HT/T 04:9-00:8 retraC 704GNE

053SC smetsySgnitarepO 4 HT/T 04:1-00:21 eleetS 111GNE

063SC scihparGretupmoC 4 FWM 05:8-00:8 nworB 004GNE

073SC srelipmoC 4 FWM 05:8-00:8 retraC 213GNE

083SC ngiseDdnasisylanAdetneirO-tcejbO 4 FWM 05:11-00:11 tnarG 004GNE



Department of Computer ScienceCS100 - Introduction to Computing

MWF 9:00-9:50Instructor: Walls

Course Roster

DItnedutS emaNtnedutS setoN1 71432 slleWhpesoJ2 51327 smailliWvrI3 13459 zedlaVainoS rojaMecneicSretupmoC4 72139 retsillAcMeiluJ5 87123 nworBsamohT6789011121314151617181910212223242526272829203



Denver State University (DSU)Spring 2006 Academic Calendar

yraunaJ

20 deW yadilohytisrevinU;s'raeYweN .

60 irF .6002gnirpSrofeudseefdetaicossadnanoitiuT

01 seuT .stnedutsUSDweNrofnoitatneirO

.6002gnirpSrofretsigerotyadtsaL

.6002gnirpSrofdnuferllufahtiwwardhtiwotyadtsaL

11 deW .nigebsessalcgnirpS

61 noM .yadilohytisrevinU;yaDgniKrehtuLnitraM

52 deW .esruocapord/ddaotyadtsaL

72 irF .etadsihtyberotskoobUSDehthguorhtsnwog&spacredrO

yraurbeF

02 noM .yadilohytisrevinU,yaDs'tnediserP

hcraM

80 deW .etadsihtretfadettimreplawardhtiwesruocoN

62-02 .kaerBgnirpS

72 noM .emusersessalC

lirpA

41 irF .setaudargyaMrofeudstnemyaplanifllA

82-71 .noitartsiger-erpllaF

yaM

5 irF .dnesessalC

21 irF .stnedutsgnitaudargrofeudsedarggnirpS

91 irF .stnedutsrehtollarofeudsedarggnirpS

12 nuS .yaDtnemecnemmoC

student workbook - · pdf filestudent workbook. page ii rev 6.3.1 ... applying uml and...

Documents