50578582 Cs2353 Object Oriented Analysis and Design

ST. JOSEPH COLLEGE OF ENGINEERING Name: __________________

Object Oriented Analysis and Design http://stjoseph.ac.in/

CS2353 OBJECT ORIENTED ANALYSIS AND DESIGN OBJECTIVES: 1. To learn basic OO analysis and design skills through an elaborate case study 2. To use the UML design diagrams 3. To apply the appropriate design patterns UNIT I Introduction to OOAD – What is OOAD? – What is UML? What are the United process(UP) phases - Case study – the NextGen POS system, Inception -Use case Modeling - Relating Use cases – include, extend and generalization. UNIT II Elaboration - Domain Models - Finding conceptual classes and description classes – Associations – Attributes – Domain model refinement – Finding conceptual class hierarchies- Aggregation and Composition- UML activity diagrams and modeling UNIT III 9 System sequence diagrams - Relationship between sequence diagrams and use cases Logical architecture and UML package diagram – Logical architecture refinement – UML class diagrams - UML interaction diagrams UNIT IV GRASP: Designing objects with responsibilities – Creator – Information expert – Low Coupling –Controller – High Cohesion – Designing for visibility - Applying GoF design patterns – adapter, singleton, factory and observer patterns. UNIT V UML state diagrams and modeling - Operation contracts- Mapping design to code –UML deployment and component diagrams TEXT BOOK : 1.Craig Larman,"Applying UML and Patterns: An Introduction to object-oriented Analysis and Design and iterative development‖, Third Edition, Pearson Education, 2005 REFERENCES: 1. Mike O’Docherty, ―Object-Oriented Analysis & Design: Understanding System Development with UML 2.0‖, John Wiley & Sons, 2005. 2. James W- Cooper, Addison-Wesley, ―Java Design Patterns – A Tutorial‖, 2000. 3. Micheal Blaha, James Rambaugh, ―Object-Oriented Modeling and Design with UML‖, Second Edition, Prentice Hall of India Private Limited, 2007 4. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides,“Design patterns: Elements of Reusable object-oriented software‖, Addison-Wesley, 1995.



Unit – I PART - A 1. What is an object? An object is a combination of data and logic; the representation of some real-world entity. 2. What is the main advantage of object-oriented development?

• High level of abstraction • Seamless transition among different phases of software development • Encouragement of good programming techniques. • Promotion of reusability.

3. What is Object Oriented System development methodology?

Object oriented system development methodology is a way to develop software by building self-contained modules or objects that can be easily replaced, modified and reused.

4. Distinguish between method and message in object. Method Message

i) Methods are similar to functions, procedures or subroutines in more traditional programming languages. Message essentially are non-specific function calls. ii) Method is the implementation. Message is the instruction. iii) In an object oriented system, a method is invoked by sending an object a message. An object understands a message when it can match the message to a method that has the same name as the message.

5. What Is Analysis and Design?

Analysis emphasizes an investigation of the problem and requirements, rather than a solution. For example, if a new computerized library information system is desired, how will it be used. Design emphasizes a conceptual solution that fulfills the requirements, rather than its implementation. For example, a description of a database schema and software objects. Ultimately, designs can be implemented.

6. What Is Object-Oriented Analysis and Design?

During object-oriented analysis, there is an emphasis on finding and describing the objects—or concepts—in the problem domain. For example, in the case of the library information system, some of the concepts include Book, Library, and Patron.

During object-oriented design, there is an emphasis on defining software objects

and how they collaborate to fulfill the requirements. For example, in the library system, a Book software object may have a title attribute and a get Chap-ter method

7. What is UML?

Unified modeling language is a set of notations and conventions and diagrams to describe and model an application.



8. What are the primary goals in the design of UML? • Provide users a ready – to use expressive visual modeling language so they can develop and exchange meaningful models. • Provide extensibility and specialization mechanism to extend the core concepts. • Be independent of particular programming language and development process. • Provide a formal basis for understanding the modeling language. • Encourage the growth of the OO tools market. • Support higher – level development concepts. • Integrate best practices and methodologies.

9. Define Class Diagram.

The main static structure analysis diagram for the system, it represents the class structure of a system including the relationships between class and the inheritance structure.

10. Define Activity Diagram.

A variation or special case of a state machine in which the states are activities representing the performance of operations and the transitions are triggered by the completion of the operations.

11. What is interaction diagram? Mention the types of interaction diagram.

Interaction diagrams are diagrams that describe how groups of objects collaborate to get the job done interaction diagrams capture the behavior of the single use case, showing the pattern of interaction among objects.

There are two kinds of interaction models • Sequence Diagram • Collaboration Diagram.

12. What is Sequence Diagram?

Sequence diagram is an easy and intuitive way of describing the behaviors of a system by viewing the interaction between the system and its environment.

13. What is Collaboration Diagram?

Collaboration diagram represents a collaboration, which is a set of objects related in a particular context, and interaction, which is a set of messages exchanged among the objects with in collaboration to achieve a desired outcome.

14. Define Start chart Diagram.

Start chart diagram shows a sequence of states that an object goes through during its life in response to events. A state is represented as a round box, which may contain one or more compartments. The compartments are all optional.

15. What is meant by implementation diagram?

Implementation Diagrams show the implementation phase of systems development such as the source code structure and the run- time implementation structure. There are two types of implementation diagrams:



1. Component Diagrams 2. Development Diagrams.



16. Define Component Diagram?

A Component diagrams shows the organization and dependencies among a set of components. A component diagrams are used to model the static implementation view of a system. This involves modeling the physical things that reside on a mode, such as executable, libraries, tables, files and documents.

17. Define Deployment Diagram.

Deployment Diagram shows the configuration of run-time processing elements and the software components, processes, and objects that live in them. Deployment diagrams are used to model the static deployment view of a system. A deployment diagram is a graph of modes connected by communication association.

18. What is the UP?

A software development process describes an approach to building, deploying, and possibly maintaining software. The Unified Process has emerged as a popular iterative software development process for building object-oriented systems.

19. What is Iterations?

A key practice in both the UP and most other modern methods is iterative development. In this lifecycle approach, development is organized into a series of short, fixed-length (for example, three-week) mini-projects called iterations

20. What is Iterative and Evolutionary Development?

The iterative lifecycle is based on the successive enlargement and refinement of a system through multiple iterations, with cyclic feedback and adaptation as core drivers to converge upon a suitable system. The system grows incrementally over time, iteration by iteration, and thus this approach is also known as iterative and incremental development. Because feedback and adaptation evolve the specifications and design, it is also known as iterative and evolutionary development

21. What are the Phases of Unified Process?

The Unified Process has 4 phases: – Inception: Requirements capture and analysis – Elaboration: System and class-level design – Construction: Implementation and testing – Transition: Deployment

22. What is Inception?

Inception is the initial short step to establish a common vision and basic scope for the project. It will include analysis of perhaps 10% of the use cases, analysis of the critical non-functional requirement, creation of a business case, and preparation of the development environment.



23. Define Use case modeling? Use case modeling is a form of requirements engineering. How to create an SRS

in what we might call the ―traditional‖ way. Use case modeling is a different and complementary way of eliciting and documenting requirements.

24. Define Use case generalization?

Use case generalization is used when you have one or more use cases that are really specializations of a more general case

Unit –II PART - A

1. What is an Elaboration?

It Build the core architecture, resolve the high-risk elements, define most requirements, and estimate the overall schedule and resources

2. What is a domain model?

A domain model is a visual representation of conceptual classes or real-world objects in a domain of interest. They have also been called conceptual models, domain object models, and analysis object models

3. Define Conceptual Classes?

The domain model illustrates conceptual classes or vocabulary in the domain. Informally, a conceptual class is an idea, thing, or object. More formally, a conceptual class may be considered in terms of its symbol, intension, and extension.

4. Define Description Class?

A description class contains information that describes something else. For example, a Product Description that records the price, picture, and text description of an Item.

5. What are Three Strategies to Find Conceptual Classes?

1. Reuse or modify existing models. 2. Use a category list. 3. Identify noun phrases

6. What is an association?

An association is a relationship between classes (more precisely, instances of those classes) that indicates some meaningful and interesting connection.

7. What is an Attributes?

An attribute is a logical data value of an object. It is useful to identify those attributes of conceptual classes that are needed to satisfy the information requirements of the current scenarios under development.



8. What About Attributes in Code? The recommendation that attributes in the domain model be mainly data types

does not imply that C# or Java attributes must only be of simple, primitive data types. The domain model is a conceptual perspective, not a software one. In the Design Model, attributes may be of any type.

9. What is a Derived Attributes?

The total attribute in the Sale can be calculated or derived from the information in the SalesLineItems. When we want to communicate that 1) this is a noteworthy attribute, but 2) it is derivable, we use the UML convention: a / symbol before the attribute name.

10. When to Define New Data Type Classes?

n the NextGen POS system an itemID attribute is needed; it is probably an attribute of an Item or ProductDescription. Casually, it seems like just a number or perhaps a string. For example, itemID : Integer or itemID : String.

11. Defining Conceptual Super classes and Subclasses?

It is valuable to identify conceptual super- and subclasses, it is useful to clearly and precisely understand generalization, super classes, and subclasses in terms of class definition and class sets.

12. What is Generalization?

Generalization is the activity of identifying commonality among concepts and defining superclass (general concept) and subclass (specialized concept) relationships.

13. What is Aggregation?

Aggregation is a vague kind of association in the UML that loosely suggests whole-part relationships (as do many ordinary associations). It has no meaningful distinct semantics in the UML versus a plain association, but the term is defined in the UML.

14. What is Composition?

Composition, also known as composite aggregation, is a strong kind of whole-part aggregation and is useful to show in some models. A composition relationship implies that 1) an instance of the part belongs to only one composite instance at a time, 2) the part must always belong to a composite and 3) the composite is responsible for the creation and deletion of its parts either by itself creating/deleting the parts, or by collaborating with other objects.

15. What is UML Activity Diagrams?

A UML activity diagram shows sequential and parallel activities in a process. They are useful for modeling business processes, workflows, data flows, and complex algorithms.



16. How to Apply Activity Diagrams? A UML activity diagram offers rich notation to show a sequence of activities,

including parallel activities. It may be applied to any perspective or purpose, but is popular for visualizing business workflows and processes, and use cases.

Unit –III PART - A

1. What is a system sequence diagram?

A system sequence diagram (SSD) is a fast and easily created artifact that illustrates input and output events related to the systems under discussion. They are input to operation contracts and most importantly object design.

2. What are System Sequence Diagrams?

A system sequence diagram is a picture that shows, for one particular scenario of a use case, the events that external actors generate their order, and inter-system events. All systems are treated as a black box; the emphasis of the diagram is events that cross the system boundary from actors to systems.

3. What is the Logical Architecture?

The logical architecture is the large-scale organization of the software classes into packages (or namespaces), subsystems, and layers. It\'s called the logical architecture because there\'s no decision about how these elements are deployed across different operating system processes or across physical computers in a network.

4. What is a Layer?

A layer is a very coarse-grained grouping of classes, packages, or subsystems that has cohesive responsibility for a major aspect of the system. Also, layers are organized such that \"higher\" layers (such as the UI layer) call upon services of \"lower\" layers, but not normally vice versa.

5. What is Software Architecture?

An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization these elements and their interfaces, their collaborations, and their composition.

6. What's the Connection Between SSDs, System Operations, and Layers?

The SSDs illustrate these system operations, but hide the specific UI objects. Nevertheless, normally it will be objects in the UI layer of the system that capture these system operation requests, usually with a rich client GUI or Web page.

7. What is controller?



A controller is the first object beyond the UI layer that is responsible for receiving or handling a system operation message.

8. What is UML Class Diagrams? The UML includes class diagrams to illustrate classes, interfaces, and their

associations. They are used for static object modeling. 9. Define Classifier?

A UML classifier is \"a model element that describes behavioral and structure features\" Classifiers can also be specialized. They are a generalization of many of the elements of the UML, including classes, interfaces, use cases, and actors. In class diagrams, the two most common classifiers are regular classes and interfaces.

10. What is UML Operations?

A UML operation is a declaration, with a name, parameters, return type, exceptions list, and possibly a set of constraints of pre-and post-conditions. But, it isn\'t an implementation rather, methods are implementations.

11. What is UML Method?

A UML method is the implementation of an operation; if constraints are defined, the method must satisfy them. A method may be illustrated several ways, including:

• in interaction diagrams, by the details and sequence of messages • in class diagrams, with a UML note symbol stereotyped with «method»

12. What is UML Keyword?

A UML keyword is a textual adornment to categorize a model element. For example, the keyword to categorize that a classifier box is an interface is (shocking surprise!) «interface».

13. What are UML Properties and Property Strings?

In the UML, a property is \"a named value denoting a characteristic of an element. A property has semantic impact.\" Some properties are predefined in the UML, such as visibility a property of an operation. Others can be user-defined.

Properties of elements may be presented in many ways, but a textual approach is to use the UML property string {name1=value1, name2=value2} format, such as {abstract, visibility=public}. Some properties are shown without a value, such as {abstract}; this usually implies a boolean property, shorthand for {abstract=true}. Note that {abstract} is both an example of a constraint and a property string.

14. What is qualified association?

A qualified association has a qualifier that is used to select an object (or objects) from a larger set of related objects, based upon the qualifier key.

15. What is an association class?

An association class allows you treat an association itself as a class, and model it with attributes, operations, and other features. For example, if a Company employs many



Persons, modeled with an Employs association, you can model the association itself as the Employment class, with attributes such as startDate.

16. What is a Sequence diagram?

Sequence diagrams illustrate interactions in a kind of fence format, in which each new object is added to the right.

17. What is a Communication diagram?

Communication diagrams illustrate object interactions in a graph or network format, in which objects can be placed anywhere on the diagram

Unit –IV PART - A

1. What is GRASP? General Responsibility Assignment Software Patterns (or Principles), abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design. 2. What is Responsibility-Driven Design?

A popular way of thinking about the design of software objects and also larger scale Components 3 are in terms of responsibilities, roles, and collaborations. This is part of a larger approach called responsibility-driven design or RDD.

3. What is Responsibilities?

The UML defines a responsibility as ―a contract or obligation of a classifier‖. Responsibilities are related to the obligations or behavior of an object in terms of its role.

4. What are the two responsibilities? The responsibilities are of the following two types: doing and knowing.

Doing responsibilities of an object include: • doing something itself, such as creating an object or doing a calculation • initiating action in other objects • controlling and coordinating activities in other objects

Knowing responsibilities of an object include: • knowing about private encapsulated data • knowing about related objects • knowing about things it can derive or calculate

5. Define Pattern?

A pattern is a named problem/solution pair that can be applied in new context, with advice on how to apply it in novel situations and discussion of its trade-offs

6. What are the GRASP patterns?

They describe fundamental principles of object design and responsibility assignment. expressed as patterns.



7. How to Apply the GRASP Patterns? The following sections present the first five GRASP patterns:

. Information Expert

. Creator

. High Cohesion

. Low Coupling

. Controller 8. Define Creator?

Creation of objects is one of the most common activities in an object-oriented system. Which class is responsible for creating objects is a fundamental property of the relationship between objects of particular classes.

9. What is Controller?

The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event.

10. Define Low Coupling?

Low Coupling is an evaluative pattern, which dictates how to assign responsibilities to support:

• low dependency between classes; • low impact in a class of changes in other classes; • high reuse potential;

11. Define High Cohesion?

High Cohesion is an evaluative pattern that attempts to keep objects appropriately focused, manageable and understandable. High cohesion is generally used in support of Low Coupling. High cohesion means that the responsibilities of a given element are strongly related and highly focused. Breaking programs into classes and subsystems is an example of activities that increase the cohesive properties of a system.

12. What is Information Expert?

Information Expert is a principle used to determine where to delegate responsibilities. These responsibilities include methods, computed fields and so on. Using the principle of Information Expert a general approach to assigning responsibilities is to look at a given responsibility, determine the information needed to fulfill it, and then determine where that information is stored. Information Expert will lead to placing the responsibility on the class with the most information required to fulfill it

13. What is singleton pattern?

The singleton pattern is a design pattern used to implement the mathematical concept of a singleton, by restricting the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system.



14. What is adapter pattern? The adapter pattern is a design pattern that translates one interface for a class into

a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter is also responsible for transforming data into appropriate forms.

15. What is Facade Pattern?

A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can:

• make a software library easier to use, understand and test, since the facade has convenient methods for common tasks;

• make code that uses the library more readable, for the same reason; • reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system; • Wrap a poorly-designed collection of APIs with a single well-designed API (as per task needs).

16. What is Observer pattern?

The observer pattern (a subset of the publish/subscribe pattern) is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.

Unit –V PART - A

1. What is UML State machine Diagram? A UML state machine diagram, illustrates the interesting events and states of an

object, and the behavior of an object in reaction to an event. 2. Definitions: Events with example?

An event is a significant or noteworthy occurrence. For example: • A telephone receiver is taken off the hook.

3. Definitions: States with an example?

A state is the condition of an object at a moment in time the time between events. For example: • A telephone is in the state of being \"idle\" after the receiver is placed on the hook and until it is taken off the hook.

4. Definitions: States with an example?

A transition is a relationship between two states that indicates that when an event occurs, the object moves from the prior state to the subsequent state. For example:



• When the event \"off hook\" occurs, transition the telephone from the \"idle\" to \"active\" state.

5. What is State-Independent and State-Dependent Objects? If an object always responds the same way to an event, then it is considered state-

independent (or modeless) with respect to that event. If for all events of interest, an object always reacts the same way, it is a state-

independent object. By contrast, state-dependent objects react differently to events depending on their state or mode.

6. What is Deployment diagram?

A deployment diagram shows the assignment of concrete software artifacts (such as executable files) to computational nodes (something with processing services). It shows the deployment of software elements to the physical architecture and the communication (usually on a network) between physical elements.

7. What is Component Diagrams?

The Component Diagram helps to model the physical aspect of an Object-Oriented software system. It illustrates the architectures of the software components and the dependencies between them. Those software components including run-time components, executable components also the source code components.

8. What is Operation Contract?

An operation Contract describes the change in the state of the system when a system operation is invoked.

9. What is meant by an axiom? List the two design axioms of object oriented design.

An axiom is a fundamental truth that always is observed to be valid and for which there is no counter example or exception. Two design axioms: Axiom 1: The independence axiom Axiom 2: The information axiom.

10. Write the attribute presentation suggested by UML?

OCL can be used during the design phase to define the class attributes .The following is the attribute presentation suggested by UML. Visibility name: type –expression-initial-value where visibility is

+ public visibility # protected visibility - private visibility

Type – expression is language dependent specification .Initial – value is language dependent expression for the initial value of a newly created object.



11. What are the 3 relationships that can be shown in UML diagram? Define them. 1. Association how are objects associated? This information will guide us in designing classes. 2. Super-Sub Structure How are objects organized into super classes and sub classes? This information provides us the direction of inheritance. 3. Aggregation and a part of Structure what is the composition of complex classes? This information guides as in defining mechanisms that properly manage object within object.

12. What do you mean by layered architecture?

Layered architecture is an approach to software development that allows us to create objects that represents tangible elements of the business independent of how they are represented to the user through an interface or physically stored in a database.

13. Define Database Models And explain the categories.

A database model is a collection of logical constructs representing the data structure and data relationship within the database.

Database models is of two categories 1. Conceptual model

2. Implementation model Conceptual Model: Focuses on logical nature of data. It deals with what is represented in the database.

Implementation Model: is concerned with how it is represented.



Unit –I PART - B

1. Explain Types of UML Diagrams with example? 2. Explain Unified Phase and their types with an example? 3. Explain CASE STUDY: THE NEXTGEN POS SYSTEM? 4. Explain Use Case Modeling With example?

Unit –II PART - B

1. Explain Domain Models with an example? 2. Explain Conceptual Classes with an example and what are Three Strategies to Find Conceptual Classes? 3. Explain Descriptions with the Airline Domain example? 4. Explain Associations with Applying UML? 5. Explain Attribute with Applying UML? 6. What are Suitable Attribute Types? Explain Focus on Data Type Attributes in the Domain Model. 7. Explain Conceptual Superclasses and Subclasses with an example? 8. Explain Aggregation and Composition? 9. Explain UML Activity Diagrams and Modeling?

Unit –III PART - B

1. Explain System sequence diagrams with an Example? 2. Explain logical architecture and UML package diagrams? 3. What\'s the Connection Between SSDs, System Operations, and Layers? 4. Explain Logical architecture refinement? 5. Explain UML class diagrams? 6. Explain Inter-Layer and Inter-Package Interaction? 7. Explain UML Interaction Diagrams? 8. Explain Operations and Methods with an example? 9. What are the Strengths and Weaknesses of Sequence vs. Communication Diagrams?

Unit –IV PART - B

1. Explain GRASP: Designing objects with responsibilities 2. Explain GoF DESIGN PATTERNS 3. Explain Creator and Information Expert with an Example? 4. Explain Low Coupling and Controller with an Example? 5. Explain adapter and singleton with an example? 6. Explain factory and observer patterns.

Unit –V PART - B

1. Explain UML state diagrams with an example? 2. Explain Operation contracts with an example? 3. Explain Mapping design to code with an Example? 4. Explain UML deployment diagrams with an example? 5. Explain UML component diagrams with an example?



Object-Orientation and the UML

The prevalence of programming languages such as Java, C++, Object Pascal, C#, and Visual Basic make it incredibly clear that object-oriented technology has become the approach of choice for new development projects. Although procedural languages such as COBOL and PL/1 will likely be with us for decades it is clear that most organizations now consider these environments as legacy technologies that must be maintained and ideally retired at some point. Progress marches on. My experience is that agile software developers, be they application developers or Agile DBAs, must minimally have an understanding of object orientation if they are to be effective. This includes understanding basic concepts such as inheritance, polymorphism, and object persistence. Furthermore, all developers should have a basic understanding of the industry-standard Unified Modeling Language (UML). A good starting point is to understand what I consider to be the core UML diagrams – use case diagrams, sequence diagrams, and class diagrams – although as I argued in An Introduction to Agile Modeling and Agile Documentation you must be willing to learn more models over time.

One of the advantages of working closely with other IT professionals is that you learn new skills from them, and the most effective object developers will learn and adapt fundamental concepts from other disciplines. An example is class normalization, the object-oriented version of data normalization, a collection of simple rules for reducing coupling and increasing cohesion within your object designs.

This article overviews the fundamental concepts and techniques that application developers use on a daily basis when working with object technology. This article is aimed at Agile DBAs that want to gain a basic understanding of the object paradigm, allowing them to understand where application developers are coming from. The primary goal of this article is to provide Agile DBAs with enough of an understanding of objects so that they have a basis from which to communicate with application developers. Similarly, other articles overview fundamental data concepts, such as relational database technology and data modeling, that application developers need to learn so that they understand where Agile DBAs are coming from.

1. Object-Oriented Concepts Agile software developers, including Agile DBAs, need to be familiar with the basic concepts of object-orientation. The object-oriented (OO) paradigm is a development strategy based on the concept that systems should be built from a collection of reusable components called objects. Instead of separating data and functionality as is done in the structured paradigm, objects encompass both. While the object-oriented paradigm sounds similar to the structured paradigm, as you will see at this site it is actually quite different. A common mistake that many experienced developers make is to assume that they have been ―doing objects‖ all along just because they have been applying similar software-engineering principles. To succeed you must recognize that the OO approach is different than the structured approach.

To understand OO you need to understand common object terminology. The critical terms to understand are summarized in Table 1. I present a much more detailed explanation of these terms in The Object Primer 3/e. Some of these concepts you will have seen before, and some of them you haven’t. Many OO concepts, such as encapsulation, coupling, and cohesion come from software engineering. These concepts are important because they underpin good OO design. The main point to be made here is that you do not want to deceive yourself – just because you have seen some of these concepts before, it don’t mean you were doing OO, it just means you were doing good design. While good design is a big part of object-orientation, there is still a lot more to it than that.

http://www.agiledata.org/essays/roles.html#DataDevelopers

http://www.agilemodeling.com/essays/umlDiagrams.htm

http://www.agiledata.org/essays/agileModeling.html

http://www.agiledata.org/essays/relationalDatabases.html

http://www.agiledata.org/essays/dataModeling101.html

http://www.ambysoft.com/books/theObjectPrimer.html



Table 1. A summary of common object-oriented terms.

Term Description

Abstract class A class that does not have objects instantiated from it

Abstraction The identification of the essential characteristics of an item

Aggregation Represents ―is part of‖ or ―contains‖ relationships between two classes or components

Aggregation hierarchy

A set of classes that are related through aggregation

Association Objects are related (associated) to other objects

Attribute Something that a class knows (data/information)

Class A software abstraction of similar objects, a template from which objects are created

Cohesion The degree of relatedness of an encapsulated unit (such as a component or a class)

Collaboration Classes work together (collaborate) to fulfill their responsibilities

Composition A strong form of aggregation in which the ―whole‖ is completely responsible for its parts and each ―part‖ object is only associated to the one ―whole‖ object

Concrete class A class that has objects instantiated from it

Coupling The degree of dependence between two items

Encapsulation The grouping of related concepts into one item, such as a class or component

Information hiding The restriction of external access to attributes

Inheritance Represents ―is a‖, ―is like‖, and ―is kind of‖ relationships. When class ―B‖ inherits from class ―A‖ it automatically has all of the attributes and operations that ―A‖ implements (or inherits from other classes)

Inheritance hierarchy

A set of classes that are related through inheritance

Instance An object is an instance of a class

Instantiate We instantiate (create) objects from classes

Interface The definition of a collection of one or more operation signatures that defines a cohesive set of behaviors

Message A message is either a request for information or a request to perform an action



Messaging In order to collaborate, classes send messages to each other

Multiple inheritance When a class directly inherits from more than one class

Multiplicity A UML concept combining the data modeling concepts of cardinality (how many) and optionality.

Object A person, place, thing, event, concept, screen, or report

Object space Main memory + all available storage space on the network, including persistent storage such as a relational database

Operation Something a class does (similar to a function in structured programming)

Override Sometimes you need to override (redefine) attributes and/or methods in subclasses

Pattern A reusable solution to a common problem taking relevant forces into account

Persistence The issue of how objects are permanently stored

Persistent object An object that is saved to permanent storage

Polymorphism Different objects can respond to the same message in different ways, enable objects to interact with one another without knowing their exact type

Single inheritance When a class directly inherits from only one class

Stereotype Denotes a common usage of a modeling element

Subclass If class ―B‖ inherits from class ―A,‖ we say that ―B‖ is a subclass of ―A‖

Superclass If class ―B‖ inherits from class ―A,‖ we say that ―A‖ is a superclass of ―B‖

Transient object An object that is not saved to permanent storage

It is important for Agile DBAs to understand the terms presented above because the application developers that you work with will use these terms, and many others, on a regular basis. To communicate effectively with application developers you must understand their vocabulary, and they must understand yours. Another important aspect of learning the basics of object orientation is to understand each of the diagrams of the Unified Modeling Language (UML) – you don’t need to become a UML expert, but you do need to learn the basics.

2. An Overview of The Unified Modeling Language

The goal of this section is to provide you with a basic overview of the UML, it is not to teach you the details of each individual technique. Much of the descriptiv material in this section is modified from The Elements of UML Style, a pocket-sized book that describes proven guidelines for developing high-quality and readable UML diagrams, and the examples from The Object Primer 3/e. A good starting point for learning the UML is UML Distilled as it is well written and concise. If you want a more thorough look at the UML, as well as other important models that the UML does not include, then you’ll find The Object Primer 3/e to be a better option.

It is also important to understand that you don’t need to learn all of the UML notation available to you, and believe me there’s a lot, but only the notation that you’ll use in practice. The examples presented in this section, there is one



for each UML diagram, use the core UML. As you learn each diagram focus on learning the core notation first, you can learn the rest of the notation over time as you need to.

2.1 Core UML Diagrams

Let’s begin with what I consider to be the three core UML diagrams for developing business software: UML use case diagrams, UML sequence diagrams, and UML class diagrams. These are the diagrams that you will see used the most in practice – use case diagrams to overview usage requirements, sequence diagrams to analyze the use cases and map to your classes, and class diagrams to explore the structure of your object-oriented software (what I like to refer to as your object schema). These three diagrams will cover 80% of your object modeling needs when building a business application using object technology.

2.1.1 UML Use Case Diagrams

According to the UML specification a use case diagram is ―a diagram that shows the relationships among actors and use cases within a system.‖ Use case diagrams are often used to:

Provide an overview of all or part of the usage requirements for a system or organization in the form of an essential (Constantine and Lockwood 1999) model or a business model (Rational Corporation 2001)

Communicate the scope of a development project Model the analysis of your usage requirements in the form of a system use case model (Cockburn 2001a)

Figure 1 depicts a simple use case diagram. This diagram depicts several use cases, actors, their associations, and optional system boundary boxes. A use case describes a sequence of actions that provide a measurable value to an actor and is drawn as a horizontal ellipse. An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures. Associations between actors and classes are indicated in use-case diagrams, a relationship exists whenever an actor is involved with an interaction described by a use case. Associations between actors and use cases are modeled as lines connecting them to one another, with an optional arrowhead on one end of the line indicating the direction of the initial invocation of the relationship.

Figure 1. A UML use case diagram.

Associations also exist between use cases in system use case models and are depicted using dashed lines with the UML stereotypes of <<extend>> or <<include>>, as you see in Figure 2. It is also possible to model inheritance between use cases, something that is not shown in the diagram. The rectangle around the use cases is called the system boundary box and as the name suggests it delimits the scope of your system – the use cases inside the rectangle represent the functionality that you intend to implement.



Figure 2. Associations between use cases.

Figure 3 depicts an example of a use case diagram for a university information system. This is the level of detail that you would commonly see with use case diagrams in practice. A good reference is UML use case diagram style guidelines.

Figure 3. A use case diagram for university application.

2.1.2 UML Sequence Diagrams

UML sequence diagrams are a dynamic modeling technique, as are collaboration diagrams and activity diagrams described below. UML sequence diagrams are typically used to:

Validate and flesh out the logic of a usage scenario. A usage scenario is exactly what its name indicates – the description of a potential way that your system is used. The logic of a usage scenario may be part of a use case, perhaps an alternate course; one entire pass through a use case, such as the logic described by the basic course of action or a portion of the basic course of action plus one or more alternate scenarios; or a pass through the logic contained in several use cases, for example a student enrolls in the university then immediately enrolls in three seminars.

Explore your design because they provide a way for you to visually step through invocation of the operations defined by your classes.



To detect bottlenecks within an object-oriented design. By looking at what messages are being sent to an object, and by looking at roughly how long it takes to run the invoked method, you quickly get an understanding of where you need to change your design to distribute the load within your system. In fact some CASE tools even enable you to simulate this aspect of your software.

Give you a feel for which classes in your application are going to be complex, which in turn is an indication that you may need to draw state chart diagrams for those classes.

For example Figure 4 models a portion of the basic course of action for the "Enroll in Seminar" use case. The boxes across the top of the diagram represent classifiers or their instances, typically use cases, objects, classes, or actors. Because you can send messages to both objects and classes, objects respond to messages through the invocation of an operation and classes do so through the invocation of static operations, it makes sense to include both on sequence diagrams. Because actors initiate and take an active part in usage scenarios they are also included in sequence diagrams. Objects have labels in the standard UML format ―name: ClassName‖ where ―name‖ is optional (objects that have not been given a name on the diagram are called anonymous objects). Classes have labels in the format "ClassName," and actors have names in the format "Actor Name" – both common naming conventions.

Figure 4. A UML sequence diagram.

I have a tendency to hand draw sequence diagrams on whiteboards. Two such examples are show in Figure 5 and Figure 6. Figure 5 depicts a UML sequence diagram for the Enroll in University use case, taking a system-level approach where the interactions between the actors and the system are show. Figure 6 depicts a sequence diagram for the detailed logic of a service to determine if an applicant is already a student at the university.

Figure 5. Enrolling in University.



Figure 6. Searching for student records.

UML sequence diagramming is described in detail here, and a good style reference is UML sequence diagram style guidelines.

2.1.3 UML Class Diagrams

UML class diagrams show the classes of the system, their inter-relationships, and the operations and attributes of the classes. Class diagrams are typically used, although not all at once, to:

Explore domain concepts in the form of a domain model Analyze requirements in the form of a conceptual/analysis model Depict the detailed design of object-oriented or object-based software

A class model is comprised of one or more class diagrams and the supporting specifications that describe model elements including classes, relationships between classes, and interfaces. Figure 3 depicts an example of an analysis UML class diagram. Classes are shown as boxes with three sections – the top for the name of the class, the middle for the attributes, and the bottom for the operations. Associations between classes are depicted as lines between classes. Associations should include multiplicity indicators at each end, for example 0..1 representing ―zero or one‖ and 1..* representing ―one or more‖. Associations may have roles indicated, for example the mentors association, a recursive relation that professor objects have with other professor objects, indicates the roles of advisor and associate. A design class model would show greater detail. For example it is common to see the visibility and type of attributes depicted on design class diagrams as well as full operation signatures.



Figure 7. A UML class diagram.

A detailed description of class diagramming is provided here, and a good style reference at UML class diagram style guidelines.

2.2 Different Goals, Different Core Diagrams

What happens if you're not developing business application development, are their different core diagrams? Yes. For real-time or embedded systems the core diagrams are typically UML state machine diagrams, UML communication diagrams (or UML sequence diagrams depending on your team's preference), and UML class diagrams. For architecture efforts the core diagrams are often UML deployment and UML component diagrams. All of these diagrams are valuable, in the right situations. Every agile software developer should learn how to work with these diagrams at some point in their careers, but they likely aren’t the first model types that you are likely to learn.

INTRODUCTION TO THE DIAGRAMS OF UML 2.0

Understanding the thirteen diagrams of UML 2.x is an important part of understanding OO development. Although there is far more to modeling than just the UML the reality is the UML defines the standard modeling artifacts when it comes to object technology.

There are three classifications of UML diagrams:

Behavior diagrams. A type of diagram that depicts behavioral features of a system or business process. This includes activity, state machine, and use case diagrams as well as the four interaction diagrams.

Interaction diagrams. A subset of behavior diagrams which emphasize object interactions. This includes communication, interaction overview, sequence, and timing diagrams.

Structure diagrams. A type of diagram that depicts the elements of a specification that are irrespective of time. This includes class, composite structure, component, deployment, object, and package diagrams.

Table 1 summarizes the thirteen, up from nine in UML 1.x, diagram types of UML 2.x. In the diagram column the links will take you to description pages for the artifact. The learning priority column indicates how important it is for a business application developer to learn the artifact (IMHO).

Table 1. The diagrams of UML 2.



Diagram Description

Activity Diagram Depicts high-level business processes, including data flow, or to model the logic of complex logic within a system. See UML Activity diagram guidelines.

Class Diagram Shows a collection of static model elements such as classes and types, their contents, and their relationships. See UML Class diagram guidelines.

Communication Diagram

Shows instances of classes, their interrelationships, and the message flow between them. Communication diagrams typically focus on the structural organization of objects that send and receive messages. Formerly called a Collaboration Diagram. See UML Collaboration diagram guidelines.

Component Diagram

Depicts the components that compose an application, system, or enterprise. The components, their interrelationships, interactions, and their public interfaces are depicted. See UML Component diagram guidelines.

Composite Structure Diagram

Depicts the internal structure of a classifier (such as a class, component, or use case), including the interaction points of the classifier to other parts of the system.

Deployment Diagram

Shows the execution architecture of systems. This includes nodes, either hardware or software execution environments, as well as the middleware connecting them. See UML Deployment diagram guidelines.

Interaction Overview Diagram

A variant of an activity diagram which overviews the control flow within a system or business process. Each node/activity within the diagram can represent another interaction diagram.

Object Diagram Depicts objects and their relationships at a point in time, typically a special case of either a class diagram or a communication diagram.

Package Diagram Shows how model elements are organized into packages as well as the dependencies between packages. See Package diagram guidelines.

Sequence Diagram Models the sequential logic, in effect the time ordering of messages between classifiers. See UML Sequence diagram guidelines.

State Machine Diagram

Describes the states an object or interaction may be in, as well as the transitions between states. Formerly referred to as a state diagram, state chart diagram, or a state-transition diagram. See UML State chart diagram guidelines.

Timing Diagram Depicts the change in state or condition of a classifier instance or role over time. Typically used to show the change in state of an object over time in response to external events.

Use Case Diagram Shows use cases, actors, and their interrelationships. See UML Use case diagram guidelines.

UML 2 ACTIVITY DIAGRAMS



UML 2 activity diagrams are typically used for business process modeling, for modeling the logic captured by a single use case or usage scenario, or for modeling the detailed logic of a business rule. Although UML activity diagrams could potentially model the internal logic of a complex operation it would be far better to simply rewrite the operation so that it is simple enough that you don’t require an activity diagram. In many ways UML activity diagrams are the object-oriented equivalent of flow charts and data flow diagrams (DFDs) from structured development.

Let’s start by describing the basic notation (there’s more) that I’ve used in Figures 1 and 2:

Initial node. The filled in circle is the starting point of the diagram. An initial node isn’t required although it does make it significantly easier to read the diagram.

Activity final node. The filled circle with a border is the ending point. An activity diagram can have zero or more activity final nodes.

Activity. The rounded rectangles represent activities that occur. An activity may be physical, such as Inspect Forms, or electronic, such as Display Create Student Screen.

Flow/edge. The arrows on the diagram. Although there is a subtle difference between flows and edges I have never seen a practical purpose for the difference although I have no doubt one exists. I’ll use the term flow.

Fork. A black bar with one flow going into it and several leaving it. This denotes the beginning of parallel activity.

Join. A black bar with several flows entering it and one leaving it. All flows going into the join must reach it before processing may continue. This denotes the end of parallel processing.

Condition. Text such as [Incorrect Form] on a flow, defining a guard which must evaluate to true in order to traverse the node.

Decision. A diamond with one flow entering and several leaving. The flows leaving include conditions although some modelers will not indicate the conditions if it is obvious.

Merge. A diamond with several flows entering and one leaving. The implication is that one or more incoming flows must reach this point until processing continues, based on any guards on the outgoing flow.

Partition. Figure 2 is organized into three partitions, also called swimlanes, indicating who/what is performing the activities (either the Applicant, Registrar, or System).

Sub-activity indicator. The rake in the bottom corner of an activity, such as in the Apply to University activity, indicates that the activity is described by a more finely detailed activity diagram. In Figure 2 the Enroll In Seminar activity includes this symbol.

Flow final. The circle with the X through it. This indicates that the process stops at this point. Note. Figure 2 includes a standard UML note to indicate that the merges does not require all three flows

to arrive before processing can continue. An alternative way to model this would have been with an OR constraint between the no match and applicant not on match list flows. I prefer notes because stakeholders find them easier to understand.

Use case. In Figure 1 I indicated that the Enroll in Seminar use case is invoked as one of the activities. This is a visual cheat that I use to indicate that an included use case is being invoked. To tell you the truth I’m not sure if this is official allowed by the UML but clearly it should be. Another way to depict this is shown in Figure 2 via the use of a normal activity although I don’t think this is as obvious as using a use case.

The activity diagram of Figure 1 depicts one way to model the logic of the Enroll in University use case, a very common use of activity diagrams because they enable you to depict both the basic course of action as well as the alternate courses. Activity diagrams can also be drawn that cross several use cases, or that address just a small portion of a use case. You can also use activity diagrams without use cases being involved at all, for example a pair of eXtreme Programming (XP) developers (Beck 2000) could draw activity diagrams with their customer (the XP term for stakeholder) to analyze a user story or a larger business process that a user story supports.



Figure 1. UML activity diagram for the Enroll in University use case.

Figure 1 is notable for several things:

1. It depicts the notation that you’re likely to use 90% of the time (I’ll discuss the more esoteric notation later).

2. It is incorrect. You can enter the join but never get out of it. When you look at the logic, you see that you'll either Create a Student Record and then enter the join, or you could enter the join directly from Display List of Potential Matches when the applicant is on the list. One but not both of these things will happen, but both are required for you to exit the join. I really should have used a merge (a diamond) instead of a join bar. Should I update the diagram? No, because agile models are just barely good enough to get the job done (this one is, IMHO) and because agile modelers follow the practice update only when it hurts, and there isn't enough motivation to update this diagram (chances are very good that once you implemented the logic contained within it that you'd simply erase it anyway).

3. The use of diamonds for decisions and merges is visually wordy but unfortunately all too common. In Figure 2 I address this issue by placing conditions on flows leaving activities instead of introducing additional diamonds to represent decision points.

4. It uses a fork to indicate parallel processing, in this case we’ve decided that we can perform some of the checks on the applicant in parallel, something that wasn’t easy to indicate using flow charts.

5. It shows how activity diagrams can get large very quickly. Even though it models the logic of a single use case I was forced to have it wind around the whiteboard because I ran out of space. Ideally the diagram should be wider, with the logic going from left-to-right across the board. Better yet, it would be nice to have more whiteboard space.

6. It includes a common mistake. At the very end I applied a decision just before the Process Payment and Print Receipt processes to indicate that they can be done in parallel. I should have used a fork, not a decision, for that. I should also use a balancing join, instead of a merge, although either one would be allowed. The join or merge is required because both processes need to finish before the overall process ends, without doing this a race condition effectively exists where the first process to finish would end things.

Figure 2 depicts the Enroll in University use case but takes a different approach than Figure 1. As noted above it avoids the use of decision points. It also uses the concept of partitions, also called swim lanes, to indicate who/what is performing the activity. In this diagram I simply labeled the partitions with the text Applicant, Registrar, and System although it is also common to put actor symbols (stick figures) to make it very clear that an actor is performing some activities. Partitions are useful because they provide more information, but they also elongate the diagram – I ran out of room and was forced to finish the diagram on another whiteboard (not



shown), using a connector (the circle with the letter A in it), to help show how the physical separate portions fit together. A common use of connectors is to avoid a line going from one side of a diagram to another. Instead you show a flow entering a connector and a second flow leaving a similarly labeled connector, e.g. both connectors have the letter B in them, going into the target activity. Figure 2 also depicts how to apply a flow final, the circle with the X through it, as well as a note to indicate a constraint on a merge, as noted above.

Figure 2. UML activity diagram with partitions based on actors.

The style of partitions in Figure 2 is often referred to as ―swim lanes‖ because the partitions look like the lanes in a swimming pool. Figure 3 takes a different approach, I guess you could call the partitions ―swim areas‖. As you can see swim areas take up less room than swim lanes. It’s also interesting to note that the partitioning strategies between the two diagrams are different – Figure 2 is partition by actor whereas Figure 3 is partitioned by courses of action within a use case. As always, my advice is to use the strategy best suited for your situation.

Figure 3. UML activity diagram with partitions based on alternate courses.



Figure 3 uses a notation that we haven’t seen before, the five-sided Possible Security Risk signal. This symbol indicates that an event has occurred, that we’ve determined that there is a possible security risk, and therefore the Perform Security Check use case may need to be triggered.

Figure 4 depicts a UML activity diagram for the Distribute Schedules use case, this time I’ve used a drawing tool so you can see a clean example of the notation. The activity starts when the Schedule Printed signal is received, this signal would be sent from one or more other activity diagrams, and it’s April 1st (or later). The hour-glass symbol represents time, and because all of the flows going into a join must occur before processing can continue the way that you would read this is that the schedules must be printed and it has to be at least April 1st. In fact, I’ve chosen to indicate this with a join specification, basically a constraint associated to a join in the format {joinSpec = …}. In this case the join specification is completely redundant so there isn’t any value in indicating it other than the fact that I wanted to show you an example. The only time that I indicate join specifications is when there is a constraint that isn’t obvious from the incoming flows. For example, if the schedules needed to be distributed before April 21st then I would likely indicate this with a join specification.

Figure 4. Distributing schedules.

The square on the side of the Determine Mailing List activity in Figure 4 is called a pin, and the one on the side of the Print Mailing Label activity is a parameter. The circle on the flow indicates a transformation, in this case the people on the mailing list are sorted by zip code (the post office charges less for bulk mailings that are sorted in this manner) and then each individual is listed so that a mailing label can then be printed for each individual.

The Labeled Schedule box is an example of an object being passed between activities. I rarely show objects in this manner as I feel this notation is a little bit goofy. You can usually read between the lines and determine what is flowing between activities, for example it is clear that labels are being passed from the Print Mailing Label activity to the Attach Labels to Schedules activity.

UML 2 CLASS DIAGRAMS

UML 2 class diagrams are the mainstay of object-oriented analysis and design. UML 2 class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation, and association), and



the operations and attributes of the classes. Class diagrams are used for a wide variety of purposes, including both conceptual/domain modeling and detailed design modeling. Although I prefer to create class diagrams on whiteboards because simple tools are more inclusive most of the diagrams that I’ll show in this article are drawn using a software-based drawing tool so you may see the exact notation.

1. Conceptual Class Diagrams

Figure 1 depicts a start at a simple UML class diagram for the conceptual model for a university. Classes are depicted as boxes with three sections, the top one indicates the name of the class, the middle one lists the attributes of the class, and the third one lists the methods. By including both an attribute and a method box in the class I’m arguably making design decisions in my model, something I shouldn’t be doing if my goal is conceptual modeling. Another approach would be to have two sections, one for the name and one listing responsibilities. This would be closer to a CRC model (so if I wanted to take this sort of approach I’d use CRC cards instead of a UML class diagram). I could also use class boxes that show just the name of the class, enabling me to focus on just the classes and their relationships. However, if that was my goal I’d be more likely to create an ORM diagram instead. In short, I prefer to follow AM’s Apply the Right Artifact(s) practice and use each modeling technique for what it’s best at.

Figure 1. Sketch of a conceptual class diagram.

Enrollment is an associative class, also called a link class, which is used to model associations that have methods and attributes. Associative classes are typically modeled during analysis and then refactored into what I show in Figure 2 during design (Figure 2 is still a conceptual diagram, albeit one with a design flavor to it). To date, at least to my knowledge, no mainstream programming language exists that supports the notion of associations that have responsibilities. Because you can directly build your software in this manner, I have a tendency to stay away from using association classes and instead resolve them during my analysis efforts. This is not a purist way to model, but it is pragmatic because the other members on the team, including project stakeholders, don’t need to learn the notation and concepts behind associative classes.

Figure 2 depicts a reworked version of Figure 1, the associative class has been resolved. I could have added an attribute in the Seminar class called Waiting List but, instead, chose to model it as an association because that is what it actually represents: that seminar objects maintain a waiting list of zero or more student objects.



Attributes and associations are both properties in the UML 2.0 so they’re treated as basically the same sort of thing. I also showed associations are implemented as a combination of attributes and operations – I prefer to keep my models simple and assume that the attributes and operations exist to implement the associations. Furthermore that would be a detailed design issue anyway, something that isn’t appropriate on a conceptual model.

Figure 2. Initial conceptual class diagram.

The on waiting list association is unidirectional because there isn’t yet a need for collaboration in both directions. Follow the AM practice of Create Simple Content and don’t over model – you don’t need a bi-directional association right now so don’t model it. The enrolled in association between the Student and Enrollment classes is also uni-directional for similar reasons. For this association it appears student objects know what enrollment records they are involved with, recording the seminars they have taken in the past, as well as the seminars in which they are currently involved. This association would be traversed to calculate their student object’s average mark and to provide information about seminars taken. There is also an enrolled in association between Enrollment and Seminar to support the capability for student objects to produce a list of seminars taken. The instructs association between the Professor class and the Seminar class is bidirectional because professor objects know what seminars they instruct and seminar objects know who instruct them.

When I’m conceptual modeling my style is to name attributes and methods using the formats Attribute Name and Method Name, respectively. Following a consistent and sensible naming convention helps to make your diagrams readable, an important benefit of AM’s Apply Modeling Standards practice. Also notice in Figure 2 how I haven’t modeled the visibility of the attributes and methods to any great extent. Visibility is an important issue during design but, for now, it can be ignored. Also notice I haven’t defined the full method signatures for the classes. This is another task I typically leave to design.

I was able to determine with certainty, based on this information, the multiplicities for all but one association and for that one I marked it with a note so I know to discuss it further with my stakeholders. Notice my use of question marks in the note. My style is to mark unknown information on my diagrams this way to remind myself that I need to look into it.

In Figure 2 I modeled a UML constraint, in this case {ordered FIFO} on the association between Seminar and Student. The basic idea is that students are put on the waiting list on a first-come, first-served/out (FIFO) basis.



In other words, the students are put on the waiting list in order. UML constraints are used to model complex and/or important information accurately in your UML diagrams. UML constraints are modeled using the format ―{constraint description}‖ format, where the constraint description may be in any format, including predicate calculus. My preference is to use UML notes with English comments, instead of formal constraints, because they’re easier to read.

3. How to Create Class Diagrams

To create and evolve a conceptual class diagram, you need to iteratively model:

Classes Responsibilities Associations Inheritance relationships Composition associations Vocabularies

To create and evolve a design class diagram, you need to iteratively model:

Classes Responsibilities Associations Inheritance relationships Composition associations Interfaces

3.1 Classes

An object is any person, place, thing, concept, event, screen, or report applicable to your system. Objects both know things (they have attributes) and they do things (they have methods). A class is a representation of an object and, in many ways, it is simply a template from which objects are created. Classes form the main building blocks of an object-oriented application. Although thousands of students attend the university, you would only model one class, called Student, which would represent the entire collection of students.

3.2 Responsibilities

Classes are typically modeled as rectangles with three sections: the top section for the name of the class, the middle section for the attributes of the class, and the bottom section for the methods of the class. The initial classes of your model can be identified in the same manner as they are when you are CRC modeling, as will the initial responsibilities (its attributes and methods). Attributes are the information stored about an object (or at least information temporarily maintained about an object), while methods are the things an object or class do. For example, students have student numbers, names, addresses, and phone numbers. Those are all examples of the attributes of a student. Students also enroll in courses, drop courses, and request transcripts. Those are all examples of the things a student does, which get implemented (coded) as methods. You should think of methods as the object-oriented equivalent of functions and procedures.

An important consideration the appropriate level of detail. Consider the Student class modeled in Figure 2 which has an attribute called Address. When you stop and think about it, addresses are complicated things. They have complex data, containing street and city information for example, and they potentially have behavior. An arguably better way to model this is depicted in Figure 4. Notice how the Address class has been modeled to



include an attribute for each piece of data it comprises and two methods have been added: one to verify it is a valid address and one to output it as a label (perhaps for an envelope). By introducing the Address class, the Student class has become more cohesive. It no longer contains logic (such as validation) that is pertinent to addresses. The Address class could now be reused in other places, such as the Professor class, reducing your overall development costs. Furthermore, if school term, a student may live in a different location than his permanent mailing address, such as a

addresses should make the addition of this behavior easier to implement.

Figure 4. Student and address (Conceptual class diagram).

An interesting feature of the Student class is its Is Eligible to Enroll responsibility. The underline indicates that this is a class-level responsibility, not an instance-level responsibility (for example Provide Seminars Taken). A good indication that a responsibility belongs at the class level is one that makes sense that it belongs to the class but that doesn’t apply to an individual object of that class. In this case this operation implements BR129 Determine Eligibility to Enroll called out in the Enroll in Seminar system use case.

The Seminar class of Figure 2 is refactored into the classes depicted in Figure 5. Refactoring such as this is called class normalization (Ambler 2004), a process in which you refactor the behavior of classes to increase their cohesion and/or to reduce the coupling between classes. A seminar is an offering of a course, for example, there could be five seminar offerings of the course "CSC 148 Introduction to Computer Science." The attributes name and fees where moved to the Course class and courseNumber was introduced. The getFullName() method concatenates the course number, "CSC 148" and the course name "Introduction to Computer Science" to give the full name of the course. This is called a getter method, an operation that returns a data value pertinent to an object. Although getter methods, and the corresponding setter methods, need to be developed for a class they are typically assumed to exist and are therefore not modeled (particularly on conceptual class diagrams) to not clutter your models.

Figure 5. Seminar normalized (Conceptual class diagram).



Figure 6 depicts Course from Figure 5 as it would appear with its getter and setter methods modeled. Getters and setters are details that are not appropriate for conceptual models and in my experience aren’t even appropriate for detailed design diagrams – instead I would set a coding guideline that all properties will have getter and setter methods and leave it at that. Some people do choose to model getters and setters but I consider them visual noise that clutter your diagrams without adding value.

Figure 6. Course with accessor methods (Inching towards a design class diagram).

3.3 Associations

Objects are often associated with, or related to, other objects. For example, as you see in Figure 2 several associations exist: Students are ON WAITING LIST for seminars, professors INSTRUCT seminars, seminars are an OFFERING OF courses, a professor LIVES AT an address, and so on. Associations are modeled as lines connecting the two classes whose instances (objects) are involved in the relationship.

When you model associations in UML class diagrams, you show them as a thin line connecting two classes, as you see in Figure 6. Associations can become quite complex; consequently, you can depict some things about them on your diagrams. The label, which is optional, although highly recommended, is typically one or two words describing the association. For example, professors instruct seminars.

Figure 6. Notation for associations.

It is not enough simply to know professors instruct seminars. How many seminars do professors instruct? None, one, or several? Furthermore, associations are often two-way streets: not only do professors instruct seminars, but also seminars are instructed by professors. This leads to questions like: how many professors can instruct any given seminar and is it possible to have a seminar with no one instructing it? The implication is you also need to identify the multiplicity of an association. The multiplicity of the association is labeled on either end of the line,



one multiplicity indicator for each direction (Table 1 summarizes the potential multiplicity indicators you can use).

Table 1. Multiplicity Indicators.

Indicator Meaning

0..1 Zero or one

1 One only

0..* Zero or more

1..* One or more

n Only n (where n > 1)

0..n Zero to n (where n > 1)

1..n One to n (where n > 1)

Another option for associations is to indicate the direction in which the label should be read. This is depicted using a filled triangle, called a direction indicator, an example of which is shown on the offering of association between the Seminar and Course classes of Figure 5. This symbol indicates the association should be read ―a seminar is an offering of a course,‖ instead of ―a course is an offering of a seminar.‖ Direction indicators should be used whenever it isn’t clear which way a label should be read. My advice, however, is if your label is not clear, then you should consider rewording it.

The arrowheads on the end of the line indicate the directionality of the association. A line with one arrowhead is uni-directional whereas a line with either zero or two arrowheads is bidirectional. Officially you should include both arrowheads for bi-directional assocations, however, common practice is to drop them (as you can see, I prefer to drop them).

At each end of the association, the role, the context an object takes within the association, may also be indicated. My style is to model the role only when the information adds value, for example, knowing the role of the Student class is enrolled student in the enrolled in association doesn’t add anything to the model. I follow the AM practice Depict Models Simply and indicate roles when it isn’t clear from the association label what the roles are, if there is a recursive association, or if there are several associations between two classes.

3.4 Inheritance Relationships

Similarities often exist between different classes. Very often two or more classes will share the same attributes and/or the same methods. Because you don’t want to have to write the same code repeatedly, you want a mechanism that takes advantage of these similarities. Inheritance is that mechanism. Inheritance models ―is a‖ and ―is like‖ relationships, enabling you to reuse existing data and code easily. When A inherits from B, we say A is the subclass of B and B is the superclass of A. Furthermore, we say we have ―pure inheritance‖ when A inherits all the attributes and methods of B. The UML modeling notation for inheritance is a line with a closed arrowhead pointing from the subclass to the superclass.

Many similarities occur between the Student and Professor classes of Figure 2. Not only do they have similar attributes, but they also have similar methods. To take advantage of these similarities, I created a new class



called Person and had both Student and Professor inherit from it, as you see in Figure 7. This structure would be called the Person inheritance hierarchy because Person is its root class. The Person class is abstract: objects are not created directly from it, and it captures the similarities between the students and professors. Abstract classes are modeled with their names in italics, as opposed to concrete classes, classes from which objects are instantiated, whose names are in normal text. Both classes had a name, e-mail address, and phone number, so these attributes were moved into Person. The Purchase Parking Pass method is also common between the two classes, something we discovered after Figure 2 was drawn, so that was also moved into the parent class. By introducing this inheritance relationship to the model, I reduced the amount of work to be performed. Instead of implementing these responsibilities twice, they are implemented once, in the Person class, and reused by Student and Professor.

Figure 7. Inheritance hierarchy.

3.5 Composition Associations

Sometimes an object is made up of other objects. For example, an airplane is made up of a fuselage, wings, engines, landing gear, flaps, and so on. Figure 8 presents an example using composition, modeling the fact that a building is composed of one or more rooms, and then, in turn, that a room may be composed of several subrooms (you can have recursive composition). In UML 2, aggregation would be shown with an open diamond.

Figure 8. Modeling composition.

I'm a firm believer in the "part of" sentence rule -- if it makes sense to say that something is part of something else then there's a good chance that composition makes sense. For example it makes sense to say that a room is part of a building, it doesn't make sense to say that an address is part of a person. Another good indication that composition makes sense is when the lifecycle of the part is managed by the whole -- for example a plane manages the activities of an engine. When deciding whether to use composition over association, Craig Larman (2002) says it best: If in doubt, leave it out. Unfortunately many modelers will agonize over when to use composition when the reality is little difference exists among association and composition at the coding level.



3.6 Vocabularies

In Agile Database Techniques (Ambler 2004) I discussed the importance of vocabularies when it comes to modeling XML data structures. A vocabulary defines the semantics of entity types and their responsibilities, the taxonomical relationships between entity types, and the ontological relationships between entity types. Semantics is simply a fancy word for meaning – when we’re defining the semantics of something we’re defining it’s meaning. Taxonomies are classifications of entity types into hierarchies, an example of which is presented for persons Figure 9. Ontology goes beyond taxonomy. Where taxonomy addresses classification hierarchies ontology will represent and communicate knowledge about a topic as well as a set of relationships and properties that hold for the entities included within that topic.

Figure 9. A taxonomy for people within the university.

The semantics of your conceptual model are best captured in a glossary. There are several interesting aspects of Figure 9:

It takes a ―single section‖ approach to classes, instead of the three section approach that we’ve seen in previous diagrams, because we’re exploring relationships between entity types but not their responsibilities.

It uses UML 2.0’s generalization set concept, basically just an inheritance arrowhead with a label representing the name of the set. In UML 1.x this label was called a discriminator. There are three generalization sets for Person: Nationality, Role, and Gender.

These generalization sets overlap – a person can be classified via each of these roles (e.g. someone can be a male foreign student). This is called multiple classification.

You can indicate ―sub generalization‖ sets, for example Student within the Role generalization set.

Some generalization sets are mutually exclusive from others, not shown in the example, where an entity type may only be in one set. This is referred to as single classification and would be modeled using an XOR (exclusive OR) constraint between the two (or more) discriminators.

UML 2 COMMUNICATION DIAGRAMS

A fundamental concept of the Unified Modeling Language (UML) is that you use different diagrams for different purposes. Class diagrams are used to model the static nature of your system, sequence diagrams are used to model sequential logic, and state machine diagrams are used to model the behavior of complex classes.



But what happens when you need to show the behavior of several objects collaborating together to fulfill a common purpose? This is what UML 2 communication diagrams, formerly known as collaboration diagrams in UML 1.x, can be used for because they provide a birds-eye view of a collection of collaborating objects.

UML 2 communication diagrams show the message flow between objects in an OO application and also imply the basic associations (relationships) between classes. Figure 1 presents a simplified collaboration diagram for displaying a seminar details screen or page. The rectangles represent the various objects involved that make up the application. The lines between the classes represent the relationships (associations, composition, dependencies, or inheritance) between them. The same notation for classes and objects used on UML sequence diagrams are used on UML communication diagrams, another example of the consistency of the UML. The details of your associations, such as their multiplicities, are not modeled because this information is contained on your UML class diagrams: remember, each UML diagram has its own specific purpose and no single diagram is sufficient on its own. Messages are depicted as a labeled arrow that indicates the direction of the message, using a notation similar to that used on sequence diagrams.

Figure 1. Example communication diagram.

Figure 2 summarizes the basic notation for modeling messages on communication diagrams. Optionally, you may indicate the sequence number in which the message is sent, indicate an optional return value, and indicate the method name and the parameters (if any) passed to it. Sequence numbers should be in the format A.B.C.D to indicate the order in which the messages where sent. In Figure 1 message 1 is sent to the Seminar object which in turn sends messages 1.1 and then 1.2 to the Course object. Message 5 is sent to the Seminar object, which sends message 5.1 to enrollment, which in turn sends message 5.1.1 to student, and it finally sends message 5.1.1.1 to itself. Notice how a recursive connection, or a self connection, is required so that student can do this.

Although Figure 1 applies sequence numbers to the messages, my experience is if you feel the need to use sequence numbers on communication diagrams this is a good indication you should be using sequence diagrams instead. The main difference between communication diagrams and sequence diagrams is that sequence diagrams are good at showing sequential logic but not that good at giving you a ―big picture view‖ whereas communication diagrams are the exact opposite.

Figure 2. Message notation.



[sequenceNumber:] methodName(parameters) [: returnValue]

In Figure 1 you see the Seminar Details user interface object collaborates with the seminar object to obtain the information needed to display its information. It first invokes the getter method to obtain the name of the seminar. To fulfill this responsibility, the seminar object then collaborates with the course object that describes it to obtain the name of the course. In this example I showed return values for some messages but not others to provide examples of how to do it. I’ll either indicate the type of the return value, for example string, or the result, such as seminarName. Normally I wouldn’t show return values on this diagram because the messages are named well – my heuristic is to only model return values when it isn’t clear what the message returns. Better yet I try to find a new name for the message (remember, messages map to operations implemented by your classes).

Another trick I often use is to consolidate trivial messages such as getter invocations. In Figure 1 I modeled the series of getter method invocations to obtain the information needed to display the list of students enrolled in a seminar as the single message getInfo. I also added a note to the diagram to make it clear what I was doing, but I typically don’t do that. Why is this important? Because agile developers will only do things that add value, and defining an exact list of getter invocations wouldn’t have added value.

You draw communication diagrams in the same way as you draw sequence diagrams, the only real difference is that you lay out the notation in a different manner. To tell you the truth I rarely find the need to create communication diagrams although I have found them useful in situations where we didn’t have use cases as the primary requirements artifact. Sequence diagrams and use cases seem to go hand in hand because of how easy it is to model the sequential logic of a use case using a sequence diagram. Communication diagrams seem to be preferred by people with a ―structure bent‖, people that focus on UML class diagrams or class responsibility collaborator (CRC) cards, because of the similarity of communication diagrams with those types of artifacts. As always, follow the AM practice Apply the Right Artifact(s) and use the most appropriate technique for your situation.

UML 2 Component Diagrams

Component-based development (CBD) and object-oriented development go hand-in-hand, and it is generally recognized that object technology is the preferred foundation from which to build components. I typically use UML 2 component diagrams as an architecture-level artifact, either to model the business software architecture, the technical software architecture, or more often than not both of these architectural aspects. Physical architecture issues, in particular hardware issues, are better addressed via UML deployment diagrams or network diagrams. In fact I'll often iterate back and forth between these diagrams.

Component diagrams are particularly useful with larger teams. Your initial architectural modeling efforts during cycle 0 should focus on identifying the initial architectural landscape for your system. UML component diagrams are great for doing this as they enable you to model the high-level software components, and more importantly the interfaces to those components. Once the interfaces are defined, and agreed to by your team, it makes it much easier to organize the development effort between subteams. You will discover the need to evolve the interfaces to reflect new requirements or changes to your design as your project progresses, changes that need to be negotiated between the subteams and then implemented appropriately.

Figure 1 presents an example component model, using the UML 2 notation, for the university system. Figure 2 depicts the same diagram using UML 1.x notation. As you can see, there are several notational differences. UML



2 components are modeled as simple rectangles, whereas in UML 1.x there were depicted as rectangles with two smaller rectangles jutting out from the left-hand side. As you can see UML 2 uses this symbol as a visual stereotype within the rectangle to indicate that the rectangle represents a component although the textual stereotype of component is also acceptable (as you see with the Schedule component). Both diagrams model dependencies, either between components or between components and interfaces. You can also see that both diagrams use the lollipop symbol to indicate an implemented interface although the UML 2 version introduces the socket symbol to indicate a required interface. As far as I’m concerned the socket symbol is effectively a visual stereotype applied to a dependency, the equivalent textual stereotype is shown on the dependency between the Persistence component and the JDBC interface.

Figure 1. UML 2.x component diagram.

Figure 2. UML 1.x component diagram.

Diagrams such as Figure 1 are often referred to as ―wiring diagrams‖ because they show how the various software components are ―wired together‖ to build your overall application. The lines between components are often referred to as connectors, the implication being that some sort of messaging will occur across the connectors.

I usually draw component diagrams on whiteboards although for both of the examples I’ve used a drawing tool to depict the notation accurately. You can use component diagrams for both logical and physical modeling although I prefer to use them for physical modeling of the software architecture of a system. Figure 1 shows the large-scale domain components for the system we’re building, including two user interface components which map to two



different applications which we’re building as part of the overall system. This diagram includes both business and technical architecture aspects – the components with the infrastructure and database stereotypes are clearly technical in nature – and that’s perfectly fine. The important thing is that we’re considering both business and technical aspects in our architecture, not just technical issues, and for whatever reason we’ve chosen to create a single diagram which includes both views.

Interfaces and Ports

Components may both provide and require interfaces. An interface is the definition of a collection of one or more methods, and zero or more attributes, ideally one that defines a cohesive set of behaviors. A provided interface is modeled using the lollipop notation and a required interface is modeled using the socket notation. A port is a feature of a classifier that specifies a distinct interaction point between the classifier and its environment. Ports are depicted as small squares on the sides of classifiers.

For example, Figure 3 shows a detailed component diagram which contains three components. There are several interesting features to note about this diagram:

1. Ports can be named, such as the Security and Data ports on the Student component. 2. Ports can support unidirectional communication or bi-directional communication. The Student

component implements three ports, two unidirectional ports and one bi-directional ports. The left-most port is an input port, the Security port is an output port, and the Data port is a bi-directional port.

3. The StudentAdministration and StudentSchedule interfaces are application specific and may include overlapping method signatures. I’ve found this approach to be more understandable to the clients of the component as each application team is provided their own specific interface which isn’t encumbered with methods they don’t need.

4. The diagram isn’t ―wired‖ together yet – I haven’t connected the Student component to the two security components yet.

5. You don’t need to use all of the provided interfaces of a component. My team has decided to use the X-Security component for access control and the MegaEncrypter component for encryption. Both of these fictional components are commercial off the shelf packages (COTS) which we’ve purchased. Although X-Security implements both security interfaces required by Student the other component implements the Encryption interface much more efficiently so we’ve decided to use both security components.

Figure 3. Modeling interfaces and ports.

Implementing a Component



So how do you actually build a component? Although there are various strategies to do so, there are several basic principles that you can follow. Figure 4 depicts a design for the Student component, depicting it as a UML frame. It’s also common to use "composite structure", e.g. a rectangle with the component stereotype in the top-right corner, instead of a frame because a component really is a structure composed of smaller elements. Whether you call it a frame, a composite structure, or something else, the diagram is pretty much the same. Interesting points about this diagram are:

1. I simplified the ports to either provide or require a single interface. This enables me to easily and explicitly model the relationships between the ports and the internals of the component.

2. I’ve modeled relationships between ports and internal classes in three different ways: as a stereotyped delegates relationship, as a delegates relationship, and as a realizes relationship. A delegates relationship is a line with an open arrowhead on it and a realizes relationship is a dashed arrow with a closed arrowhead. Because the delegates notation is exactly the same notation that is used for unidirectional associations there is an opportunity for confusion – as a result I recommend indicating the stereotype on the relationship to make it clear what you mean. The realizes notation, for example AdministrationFacade realizes the port containing the StudentAdministration interface, used to be my preferred approach because in my mind ports are logical modeling constructs that are realized by physical constructs such as classes. However, the delegates association has the advantage that it indicates the flow of communication and as a result seems to be easier to understand.

3. The Data and Security classes use the same names as the corresponding ports. 4. Classes such as AdministrationFacade, ScheduleFacade, StudentData, Data, and Security implement the

Façade design pattern (Gamma et. al. 1995). The basic idea is that they implement the public operations required by the interfaces, operations that typically just delegate messages to the appropriate classes. Together the AdministrationFacade, ScheduleFacade, and StudentData classes implement the public interface of the Student component. StudentData, Data, and Security wrap access to external components so that the internal classes are not directly coupled to other physical components.

5. Expect to adapt incoming/outgoing interactions back and forth between data-oriented and object-oriented messages. An incoming message may be implemented as a web service which takes XML as a parameter and returns XML as the result. The internal objects within the component, on the other hand, need messages sent to them with either objects or data as parameters and return values. The implication is that you need to marshal the data and objects back and forth between each other, something addressed by the Adapter design pattern (Gamma et al., 1995).

6. Another way to implement the public interface would have been to implement a single façade class called StudentComponent which implements the required public interfaces and delegates appropriately.

7. When designing the StudentData class the team realized that it needed to work with our existing XMLProcessor component, therefore we added the connection to this component.

Figure 4. Designing a component.



Figure 3 makes it obvious that building components is costly. Creating the Student component as shown in Figure 3 doesn’t make much sense – I’ve added five new classes to support two domain classes, a clear case of overbuilding. This approach would make sense if there was twenty classes, and would make a lot of sense for fifty domain classes, because the additional five classes reduce the coupling within your system while at the same time implement a large-scale, reusable domain component. The point is that you should only take a component-based approach when the benefit of doing so outweighs the additional cost.

Creating Component Diagrams

There are two fundamental strategies for developing a component model, either top down or bottom up. Given the choice I prefer the top-down approach because it provides a good mechanism for identifying the ―software landscape‖ early in the project, something that is particularly important for teams comprised of several subteams because you want to work towards the same vision. Unfortunately a top-down approach suffers from the tendency to promote over-architecting, and hence over-building, of your system. For example Figure 1 calls out Security and Persistence components but you might not yet need anything even remotely that complicated. It would be a serious mistake to focus on building these two components instead of implementing actual business functionality that your stakeholders actually need.

A second way to develop component models is from the bottom up. I’ll do this when we have an existing collection of classes that have been developed and we decide to componentize our design. Componentizing is often done to rescue reusable functionality out of an existing application or to split an application up so it can be easily dispersed between subteams. When I’m componentizing an existing object design I’ll often iterate through the following steps:

1. Keep components cohesive. A component should implement a single, related set of functionality. This may be the user interface logic for a single user application, business classes comprising a large-scale domain concept, or technical classes representing a common infrastructure concept.

2. Assign user interface classes to application components. User interface classes, those that implement screens, pages, or reports, as well as those that implement ―glue logic‖ such as identifying which screen/page/… to display should be placed in components with the application stereotype. In Java these types of classes would include Java Server Pages (JSPs), servlets, and screen classes implemented via user interface class libraries such as Swing.

3. Assign technical classes to infrastructure components. Technical classes, such as those that implement system-level services such as security, persistence, or middleware should be assigned to components which have the infrastructure stereotype.

4. Define class contracts. A class contract is any method that directly responds to a message sent from other objects. For example, the contracts of the Seminar class likely include operations such as enrollStudent() and dropStudent(). For the purpose of identifying components, you can ignore all the operations that aren’t class contracts because they don’t contribute to communication between objects distributed in different components.

5. Assign hierarchies to the same component. 99.9% of the time I find that it makes sense to assign all of the classes of a hierarchy, either an inheritance hierarchy or a composition hierarchy, to the same component.

6. Identify domain components. A domain component is a set of classes that collaborate among themselves to support a cohesive set of contracts. The basic idea is that classes, and even other domain components, are able to send messages to domain components either to request information or to request an action be performed. On the outside, domain components appear simple, actually they appear like any other type of object but, on the inside, they are often quite complex because they encapsulate the behavior of several classes. A key goal is you want to organize your design into several components in such a way as to reduce the amount of information flowing between them. Any information passed between components, either in the form of messages or the objects that are returned as the result of a message send, represents potential traffic on your network (if the components are deployed to different nodes).



Because you want to minimize network traffic to reduce the response time of your application, you want to design your domain components in such a way that most of the information flow occurs within the components and not between them.

7. Identify the “collaboration type” of business classes. To determine which domain component a business class belongs to you need to analyze the collaborations it is involved with to determine its distribution type. A server class is one that receives messages, but doesn’t send them. A client class is one that sends messages, but doesn’t receive them. A client/server class is one that both sends and receives messages. Once you have identified the distribution type of each class, you are in a position to start identifying potential domain components.

8. Server classes belong in their own component. Pure server classes belong in a domain component and often form their own domain components because they are the ―last stop‖ for message flow within an application.

9. Merge a component into its only client. If you have a domain component that is a server to only one other domain component, you may decide to combine the two components.

10. Pure client classes don’t belong in domain components. Client classes don’t belong in a domain component because they only generate messages, they don’t receive them, whereas the purpose of a domain component is to respond to messages. Therefore, client classes have nothing to add to the functionality offered by a domain component and very likely belong in an application component instead.

11. Highly coupled classes belong in the same component. When two classes collaborate frequently, this is an indication they should be in the same domain component to reduce the network traffic between the two classes. This is especially true when that interaction involves large objects, either passed as parameters or received as return values. By including them in the same domain component you reduce the potential network traffic between them. The basic idea is that highly coupled classes belong together.

12. Minimize the size of the message flow between components. Client/server classes belong in a domain component, but there may be a choice as to which domain component they belong to. This is where you need to consider issues such as the information flow going into and out of the class. Communication within a component will often be simple message sends between objects in memory, communication between components may require an expensive marshalling effort in which a message and its parameters are converted to data, transmitted, and then converted back into a message again.

13. Define component contracts. Each component will offer services to its clients, each such service is a component contract.

Table 1 summarizes several design principles presented in Agile Software Development (Martin, Newkirk, Koss 2003) for improving the quality of packages or components. I present them here because I find them of greatest value when it comes to component modeling.

Table 1. Component design principles.

Principle Description

Acyclic Dependencies Allow no cycles in the dependencies graph between components. For example

Common Closure The classes of a component should be closed together against the same kinds of changes. A change that affects a class within a component should not affect classes outside that component. In other words your components should be cohesive in that sweeping changes across several components are not required.

Common Reuse The classes in a component are reused together. If you reuse one class in a component you reuse them all. This is another principle addressing cohesion.

Dependency Inversion Abstractions should not depend on details, instead details should depend on



abstractions.

Open-Closed Software elements should be open for extension but closed for modification.

Release-Reuse Equivalency

The granule of reuse is the granule of release. In other words you should not reuse only part of a released software element.

Stable Abstractions A component should be as abstract as it is stable. A component should be sufficiently abstract so that it can be extended without affecting its stability.

Stable Dependencies Depend on the direction of stability – If component A depends on component B, then B should be more stable (e.g. less likely to change) than A.

Remaining Agile

My most successful use of component models was with a team where we drew a diagram similar to Figure 1, albeit a much larger one with over twenty components, on a whiteboard. This whiteboard was situated in the team work area where everyone could see the board. We developed the diagram early in the project and updated it as required throughout the project. We kept it on the board because it provided a high-level map of the architecture of our software, a map that we used from time to time as we worked and more importantly engendered many interesting conversations regarding the overall system design.

There are several advantages to components that promote agility. First, components are reusable building blocks from which you can build software, increasing your productivity as a developer. Second, components can improve your testing productivity because they can be treated as elements which you can black-box unit and integration test. Testing is discussed in detail in Full Lifecycle Object-Oriented Testing (FLOOT).

UML 2 Composite Structure Diagram

UML 2 composite structure diagrams are used to explore run-time instances of interconnected instances collaborating over communications links. Figure 1 depicts a composite structure diagram for enrolling in a seminar. The dashed oval, Enroll in Seminar, models a collaboration. A collaboration enables you to model the relevant aspects of a cooperation between instances, indicating the objects and the roles that they take within the collaboration. The rectangles model instances of any type of classifier, including classes, objects, or interfaces. The properties used in the collaboration, such as the prerequisite seminars that a student has taken in the past, are optionally indicated with the classifier boxes.

Figure 1. Composite structure diagram for enrolling in a seminar.



An alternative form of this diagram is shown in Figure 2, something I refer to as a collaboration-style composite structure diagram. I’d really like to refer to this as a collaboration diagram, but my fear is that this name would be confusing for anyone familiar with UML 1.x’s collaboration diagrams which are now called communication diagrams. In this diagram the collaboration symbol contains a detailed composite structure diagram, showing how the composite structure diagrams can effectively be nested within one another.

Figure 2. Collaboration diagram for the enrolling in a seminar.

It is interesting to note that UML composite structure diagrams are very similar to object role model (ORM) diagrams in notation. Although the two diagrams explore similar issues, structure, they do so in different ways. ORM diagrams are very good for explored detailed relationships between entities whereas the focus of composite structure diagrams is on exploring collaborations between entities.

To be honest I don’t find composite structure diagrams to be of much use. I would much rather use UML sequence diagrams for exploring a collaboration because the notation is much more robust and because far more developers understand the notation.

UML 2 Deployment Diagrams

A UML 2 deployment diagram depicts a static view of the run-time configuration of processing nodes and the components that run on those nodes. In other words, deployment diagrams show the hardware for your system,



the software that is installed on that hardware, and the middleware used to connect the disparate machines to one another. You want to create a deployment diagram for applications that are deployed to several machines, for example a point-of-sales application running on a thin-client network computer which interacts with several internal servers behind your corporate firewall or a customer service system deployed using a web services architecture such as Microsoft’s .NET. Deployment diagrams can also be created to explore the architecture of embedded systems, showing how the hardware and software components work together. In short, you may want to consider creating a deployment diagram for all but the most trivial of systems.

Figure 1 presents an example of a fully rendered UML 2 deployment diagram for the student administration application. The three-dimensional boxes represent nodes, either software or hardware. Physical nodes should be labeled with the stereotype device, to indicate that it’s a physical device such as a computer or switch. As you can see I didn’t indicate that WebServer is a device – it will at least be some sort of software artifact and very well may be one or more physical devices as well but my team hasn’t made that decision yet. Remember, models evolve over time. Connections between nodes are represented with simple lines, and are assigned stereotypes such as RMI and message bus to indicate the type of connection.

Nodes can contain other nodes or software artifacts. The ApplicationServer node contains EJBContainer (a software node) which in turn contains three software components, a deployment specification, and a software artifact. The software components use the same notation as component diagrams (I could have annotated them with their interfaces although that wouldn’t have added any value in my opinion). Deployment specifications are basically configuration files, such as an EJB deployment descriptor, which define how a node should operate. They are depicted as two-sectioned rectangles with the stereotype deployment spec, the top box indicates the name and the bottom box lists the deployment properties (if any) for the node. In my opinion the deployment properties is superfluous as this is the type of information that is contained in the actual deployment specification file at run time. Software artifacts are shown with the visual stereotype of a page with a folded corner or with the textual stereotype artifact (or both sometimes, which I also believe is superfluous). In this case the software artifact is a fictional persistence framework purchased from AmbySoft (the vendor is indicated with a UML property string).

Figure 1. UML 2 deployment diagram for the university information system.

http://www.ambysoft.com/persistenceLayer.html



When you stop and think about it, the stereotypes that I’ve applied to the connections aren’t correct. In reality the software on the web server is communicating via the RMI protocol over the connection to the software on the application server. The physical connection between the physical hardware nodes is at a lower level, perhaps an Ethernet connection, so in reality I really should have modeled a connection between the hardware nodes with Ethernet as a stereotype and a second connection between software elements with the RMI stereotype. I’d also need to model a dependency relationship between the software connection and the hardware connection, perhaps with the stereotype of over. Although this would be more accurate it would be a lot of work that I likely wouldn’t get much benefit from. Remember, agile models don’t need to be perfect, they need to be just barely good enough.

I never draw deployment diagrams following the style show in Figure 1, except when I’m writing about deployment modeling, because in my opinion this notation is visually wasteful. A better example is shown in Figure 2. Software elements are now simply listed by their physical filenames, information that developers are very likely to be interested in, and thus a more compact diagram is possible. I’ve also used a drum as a visual stereotype for the University DB database, making it easier to distinguish on the diagram. Another difference is that the concise version shows less details, not as many tagged values are shown as this information can be captured in either supporting documentation, configuration files, or source code. Deployment diagrams tend to become very large very quickly because they reflect the physical complexities of your system, therefore a concise notation becomes critical to your success.

Figure 2. Concise UML 2 deployment diagram.



How agile are deployment diagrams? As always, it depends on your goals. Very often less-detailed network diagrams, which are arguably deployment diagrams with extensive use of visual stereotypes, are a better option. This is particularly true when you are modeling an environment consisting of a many interconnected machines. Sometimes a high-level free-form diagram is a better option because the notation is much more flexible. The information contained in Figure 2 can just as readily be captured in either a network diagram or a free-form diagram in combination with installation scripts. When you think about it installation scripts are effectively ―deployment source code‖.

To determine whether you need to create a deployment model, ask yourself this: if you knew nothing about the system and someone asked you to install it and/or maintain and support it, would you want a description of how the parts of the system fit together? When I ask this question of the project teams I work with, we almost always decide to develop some form of deployment model. More important, practice has shown that deployment modeling is well worth it. Deployment models force you to think about important deployment issues long before you must deliver the actual system.

When determining how to model the deployment architecture for a system, regardless of the artifacts chosen, I will typically:

1. Identify the scope of the model. Does the diagram address how to deploy a version of a single application or does it depict the deployment of all systems within your organization?

2. Consider fundamental technical issues. What existing systems will yours need to interact/integrate with? How robust does your system need to be (will there be redundant hardware to failover to)? What/who will need to connect to and/or interact with your system and how will they do it (via the Internet, exchanging data files, and so forth)? What middleware, including the operating system and communications approaches/protocols, will your system use? What hardware and/or software will your users directly interact with (PCs, network computers, browsers, and so forth)? How do you intend to monitor the system once it has been deployed? How secure does the system need to be (do you need a firewall, do you need to physically secure hardware, and so forth)?

3. Identify the distribution architecture. Do you intend to take a fat-client approach where the business logic is contained in a desktop application or a thin-client approach where business logic is deployed to an application server? Will your application have two tiers, three tiers, or more? Your distribution architecture strategy will often be predetermined for your application, particularly if you are deploying your system to an existing technical environment.

http://www.agilemodeling.com/artifacts/networkDiagram.htm

http://www.agilemodeling.com/artifacts/networkDiagram.htm

http://www.agilemodeling.com/artifacts/freeForm.htm



4. Identify the nodes and their connections. Your distribution strategy will define the general type of nodes you will have, but not the exact details. You need to make platform decisions, such as the hardware and operating systems to be deployed, including how the various nodes will be connected (perhaps via RMI and a message bus as in Figure 2).

5. Distribute software to nodes. Both versions of the deployment diagrams indicate the software that is deployed on each node, critical information for anyone involved in development, installation, or operation of the system.

UML 2 Interaction Overview Diagrams

UML 2 interaction overview diagrams are variants on UML activity diagrams which overview control flow. Figure 1 depicts an interaction overview diagram for enrolling in a seminar. The nodes within the diagram are frames instead of the normal activities which you would see on an activity diagram. There are two types of frame shown: interaction frames which depict any type of UML interaction diagram (sequence diagram, communication diagram, timing diagram, interaction overview diagram) or interaction occurrence frames which indicate an activity or operation to invoke. There are two interaction frames in the diagram, one which depicts a sequence diagram for determining whether a student is eligible to enroll in a seminar and a communication diagram to determine if a seat is available in a seminar. These frames indicate the type of diagram (sd for sequence diagrams, cd for communication diagrams, td for timing diagrams, and iod for interaction overview diagrams) and optionally the name of the diagram. The interaction occurrence frames are of type ref and typically are anonymous as the name of the activity or operation to be invoked should make it clear what is happening (otherwise you need to rethink your naming strategy).

Figure 1. Enrolling in a seminar.



The other notation used on the diagram should be familiar to you. Decision points are shown as diamonds, exactly on UML activity diagrams. There should be guards on all of the exiting flows although as you can see I’ll forgo labeling some guards when it is obvious what is meant. Remember, agile models don’t need to be perfect, they need to be just barely good enough. Duration constraints, such as {0..7 msec}, are shown using the same notation as on other types of interaction diagrams. The start and end points use the same notation as initial and end states on UML state machine diagrams and UML activity diagrams.

Although interaction overview diagrams are an interesting concept I doubt that they’ll be used in practice. Interaction frames are virtually useless due to a lack of space – the diagrams that you can depict within the frames will be too small to be of value. My suspicion is that interaction overview diagrams will be abandoned within the marketplace in favor of UML activity diagrams because they don’t work well on whiteboards and the CASE tool vendors can simply allow you to use other diagrams to describe the details of activities. Perhaps I’m wrong about this, time will tell.

UML 2 Object Diagrams

UML 2 object diagrams, sometimes referred to as instance diagrams, are useful for exploring ―real world‖ examples of objects and the relationships between them. Although UML class diagrams are very good at describing this very information some people find them too abstract – a UML object diagram can be a good option for explaining complex relationships between classes.

For example, the object diagram of Figure 1 explores the concepts that a student can attend a seminar, be wait listed for a seminar, or can be a teaching assistant within a seminar. The diagram explores an example where John Smith and Sally Jones are both students in CSC 100a whereas Sarah McGrath is the teaching assistant for it. Sarah is also the teaching assistant in CSC 100b, Scott Ambler is an enrolled student, and Ed Maloney is wait listed. The diagram also shows that the two seminars are both sections of the Introduction to Computer Science



course. This diagram makes the three relationships between students and seminars, as well as the relationship between seminars and courses, much more explicit.

Figure 1. Object diagram.

The notation used on UML object diagrams is very simple – they show objects and the connections between them. When you depict an object you need to include enough information so that it is a recognizable instance. As a result I will use one of two formats: a single box named instance such as Sarah McGrath: Student or a double box instance listing one or more identifying attribute values in the format attribute = value such as name = “Intro to Computer Science”. Connections between objects are shown as lines with roles, such as Teaching Assistant, optionally indicated.

As you can see UML object diagrams are effectively notational subsets of UML communication diagrams, although object diagrams are used to explore structure whereas communication diagrams explore behavior. It is common for object diagrams to evolve into communication diagrams simply by adding messages to the diagram.

Remaining Agile

I will typically draw object diagrams on white boards in order to explore the relationships between objects. Once we’ve explored said relationships we’ll use whatever we’ve learned to update our class models or source code as appropriate then erase the diagram (e.g. Discard Temporary Models). Remember, the value is often in the act of modeling and not in the model itself. I have seen object diagrams retained as part of the description of a complex business rule but this is pretty rare in my experience

UML 2 Package Diagrams

Packages are UML constructs that enable you to organize model elements into groups, making your UML diagrams simpler and easier to understand. Packages are depicted as file folders and can be used on any of the



UML diagrams, although they are most common on use-case diagrams and class diagrams because these models have a tendency to grow.

Although a UML 2 package diagram can be used to organize any type of UML classifier, I typically create package diagrams to organize either classes, data entities, or use cases. All three styles are effectively business architecture diagrams in my mind.

Class Package Diagrams

When it comes to ―class package diagrams‖ I apply several rules of thumb. First, classes in the same inheritance hierarchy typically belong in the same package. Second, classes related to one another via composition often

Figure 1 depicts the start at a class package diagram for the university. It shows several packages and the dependencies between them. Notice how the Contact Point package has the ―flap‖ drawn on the right hand side instead of the left – remember the AM principle that Content is More Important Than Representation.

Figure 1. Package diagram organizing the university class model.

I have applied several UML stereotypes on Figure 1. The application stereotype is applied to the Seminar Registration package, indicating that this package contains user interface (UI) classes and application-specific business classes for registering students in seminars. Similarly the technical stereotype is applied to the Java Infrastructure package indicating that it contains technical classes, perhaps a user interface framework such as Apache Struts or a persistence framework such as Prevayler. Both the application and technical stereotypes are my own convention, albeit very common ones. The import stereotype, a UML standard, is applied to several dependencies indicating that the Java Infrastructure package is imported into the other packages on this diagram

Each package in Figure 1 would lead to a more detailed diagram, perhaps another package diagram for a very complicated system or more likely to a UML class diagram. Figure 2 depicts a UML frame which is used to depict the contents of the Schedule Package, in this case a high-level conceptual class diagram. Frames can be



used to show the detailed contents of any type of UML model, such as packages, components, classes, or operations. The heading is depicted with a name tag, the rectangle with the cut off bottom-right corner, in the format [<kind>]Name[<parameters>]. Had the frame represented a component the heading would have read Component Schedule and had it been for an operation it may have read something like Operation EnrollStudent(Student).

Figure 2. The contents of the Schedule package.

Data Package Diagrams

Because you can use the UML to model data it makes sense that you can also have ―data model package diagrams‖. In this case packages are used to organize data entities into large scale business domains. If you were to remove the Seminar Registration and Java Infrastructure packages from Figure 1 you would have such a diagram, the only difference being that the packages would lead to UML data models instead of UML class models.

Use Case Package Diagrams

Figure 3 depicts a UML use case diagram which has had its use cases organized into packages (the actors are still indicated on the diagram, although they could have been moved into packages as well). Is this really a use case diagram now or is it really a UML package diagram? The important thing is that the diagram somehow adds value to your efforts – how you categorize the diagram is of little real consequence.

When I’m creating a use case package diagram I’ll follow two rules of thumb. First, included and extending use cases belong in the same package as the base/parent use case. This heuristic works well because these use cases typically were introduced by ―pulling out‖ their logic from the base/parent use case to start. Second, I then analyze the use cases with which my main actors are involved. What I typically find is that each actor will interact with the system to fulfill a few main goals, for example, students interact with the university to enroll in it, to manage their schedules, to pay fees, and to manage their loans and grants. Because these four sets of goals are each reasonably cohesive it suggests the need for four separate packages.

Figure 3. Use case package diagram.



Packaging Strategies

Figure 3 is interesting because it shows my typical reason to use packages – to organize a large diagram into several smaller ones. A good rule of thumb is that a diagram should have 7 +/- 2 bubbles on it, a bubble being a use case or class. When a diagram has more bubbles than this it starts to become unwieldy and therefore difficult to understand.

Packages should be cohesive. Anything you put into the package should make sense when considered with the rest of the contents of the package. To determine whether a package is cohesive, a good test is you should be able to give your package a short, descriptive name. If you can’t, then you may have put several unrelated things into the package.

UML 2 Sequence Diagrams

UML sequence diagrams model the flow of logic within your system in a visual manner, enabling you both to document and validate your logic, and are commonly used for both analysis and design purposes. Sequence diagrams are the most popular UML artifact for dynamic modeling, which focuses on identifying the behavior within your system. Other dynamic modeling techniques include activity diagramming, communication diagramming, timing diagramming, and interaction overview diagramming. Sequence diagrams, along with class diagrams and physical data models are in my opinion the most important design-level models for modern business application development.

Sequence diagrams are typically used to model:

1. Usage scenarios. A usage scenario is a description of a potential way your system is used. The logic of a usage scenario may be part of a use case, perhaps an alternate course. It may also be one entire pass through a use case, such as the logic described by the basic course of action or a portion of the basic course of action, plus one or more alternate scenarios. The logic of a usage scenario may also be a pass through the logic contained in several use cases. For example, a student enrolls in the university, and then immediately enrolls in three seminars.

2. The logic of methods. Sequence diagrams can be used to explore the logic of a complex operation, function, or procedure. One way to think of sequence diagrams, particularly highly detailed diagrams, is as visual object code.

3. The logic of services. A service is effectively a high-level method, often one that can be invoked by a wide variety of clients. This includes web-services as well as business transactions implemented by a variety of technologies such as CICS/COBOL or CORBA-compliant object request brokers (ORBs).

Let’s start with three simple examples. Figure 1 depicts a UML sequence diagram for the Enroll in University use



case, taking a system-level approach where the interactions between the actors and the system are show. Figure 2 depicts a sequence diagram for the detailed logic of a service to determine if an applicant is already a student at the university. Figure 3 shows the logic for how to enroll in a seminar. I will often develop a system-level sequence diagram with my stakeholders to help to both visualize and validate the logic of a usage scenario. It also helps me to identify significant methods/services, such as checking to see if the applicant already exists as a student, which my system must support.

Figure 1. System-level sequence diagram.

The reason why they’re called sequence diagrams should be obvious: the sequential nature of the logic is shown via the ordering of the messages (the horizontal arrows). The first message starts in the top left corner, the next message appears just below that one, and so on.

Figure 2. Service-level sequence diagram.

The boxes across the top of the diagram represent classifiers or their instances, typically use cases, objects, classes,



or actors. Because you can send messages to both objects and classes, objects respond to messages through the invocation of an operation and classes do so through the invocation of static operations, it makes sense to include both on sequence diagrams. Because actors initiate and take an active part in usage scenarios, they can also be included in sequence diagrams. Objects have labels in the standard UML format name: ClassName, where ―name‖ is optional (objects that haven’t been given a name on the diagram are called anonymous objects). Classes have labels in the format ClassName, and actors have names in the format Actor Name. Notice how object labels are underlined, classes and actors are not. For example, in Figure 3, you see the Student object has the name aStudent, this is called a named object, whereas the instance of Seminar is an anonymous object. The instance of Student was given a name because it is used in several places as a parameter in messages, whereas the instance of the Seminar didn’t need to be referenced anywhere else in the diagram and thus could be anonymous. In Figure 2 the Student class sends messages to the PersistenceFramework class (which could have been given the stereotype <<infrastructure>> but wasn’t to keep the diagram simple). Any message sent to a class is implemented as a static method, more on this later.

Figure 3. Enrolling in a seminar (method).

The dashed lines hanging from the boxes are called object lifelines, representing the life span of the object during the scenario being modeled. The long, thin boxes on the lifelines are activation boxes, also called method-invocation boxes, which indicate processing is being performed by the target object/class to fulfill a message. I will only draw activation boxes when I’m using a tool that natively supports them, such as a sophisticated CASE tool, and when I want to explore performance issues. Activation boxes are too awkward to draw on whiteboards or with simple drawing tools such that don’t easily support them.

The X at the bottom of an activation box, an example of which is presented in Figure 4, is a UML convention to indicate an object has been removed from memory. In languages such as C++ where you need to manage memory yourself you need to invoke an object’s destructor, typically modeled a message with the stereotype of <<destroy>>. In languages such as Java or C# where memory is managed for you and objects that are no longer needed are automatically removed from memory, something often referred to as garbage collection, you do not need to model the message. I generally don’t bother with modeling object destruction at all and will instead trust that the programmers, often myself, will implement low-level details such as this appropriately.

Figure 4 presents a complex UML sequence diagram for the basic course of action for the Enroll in Seminar use



case. This is an alternative way for modeling the logic of a usage scenario, instead of doing it at the system-level such as Figure 1 you simply dive straight into modeling the detailed logic at the object-level. I’ll take this approach when I’m working with developers who are experienced sequence diagrammers and I have a large working space (either a huge whiteboard or a CASE tool installed on a workstation with a very large screen and good graphic card). Most of the time I’ll draw system-level diagrams first and then create small diagrams also the lines of what is shown in Figures 2 and 3.

Figure 4. Basic course of action for the Enroll in Seminar use case.

Messages are indicated on UML sequence diagrams as labeled arrows, when the source and target of a message is an object or class the label is the signature of the method invoked in response to the message. However, if either the source or target is a human actor, then the message is labeled with brief text describing the information being communicated. For example, in Figure 4 the EnrollInSeminar object sends the message isEligibleToEnroll(theStudent) to the instance of Seminar. Notice how I include both the method’s name and the name of the parameters, if any, passed into it. The Student actor provides information to the SecurityLogon object via the messages labeled name and student number (these really aren’t messages, they are actually user interactions).

Return values are optionally indicated using a dashed arrow with a label indicating the return value. For example, the return value theStudent is indicated coming back from the Student class as the result of invoking a message, whereas no return value is indicated as the result of sending the message isEligibleToEnroll(theStudent) to Seminar. My style is not to indicate the return values when it’s obvious what is being returned, so I don’t clutter my sequence diagrams (as you can see, sequence diagrams get complicated fairly quickly). Figure 5 shows an alternate way to indicate return values using the format message: returnValue for messages, as you with



isEligibleToEnroll(theStudent): false.

Notice the use of stereotypes throughout the diagram. For the boxes, I applied the stereotypes <<actor>>, <<controller>>, and <<UI>> indicating they represent an actor, a controller class, or a user interface (UI) class, respectively. I’ve also used visual stereotypes on some diagrams – a stick figure for actors; the robustness diagram visual stereotypes for controller, interface, and entity objects; and a drum for the database. Stereotypes are also used on messages. Common practice on UML diagrams is to indicate creation and destruction messages with the stereotypes of <<create>> and <<destroy>>, respectively. For example, you see the SecurityLogon object is created in this manner (actually, this message would likely be sent to the class that would then result in a return value of the created object, so I cheated a bit). This object later destroys itself in a similar manner, presumably when the window is closed.

I used a UML note in Figure 4; notes are basically free-form text that can be placed on any UML diagram, to provide a header for the diagram ,indicating its title and identifier (as you may have noticed, I give unique identifiers to all artifacts that I intend to keep). Notes are depicted as a piece of paper with the top-right corner folded over. I also used a note to indicate future work that needs to be done, either during analysis or design, in

qualifications() message likely represents a series of messages sent to the student object. Common UML practice is to anchor a note to another model element with a dashed line when appropriate, in this case the note is attached to the message.

Although Figure 4 models the logic of the basic course of action for the Enroll in Seminar use case how would you go about modeling alternate courses? The easiest way to do so is to create a single sequence diagram for each alternate course, as you see depicted in Figure 5. This diagram models only the logic of the alternate course, as you can tell by the numbering of the steps on the left-hand side of the diagram, and the header note for the diagram indicates it is an alternate course of action. Also notice how the ID of this diagram includes that this is alternate course C, yet another modeling rule of thumb I have found useful over the years.

Figure 5. An alternate course of action for the Enroll in Seminar use case.

Let’s consider other sequence diagramming notation. Figure 5 includes an initial message, Student chooses seminar, which is indicated by the filled in circle. This could easily have been indicated via a method invocation, perhaps enrollIn(seminar). Figure 6 shows another way to indicate object creation – sending the new message to a class. We’ve actually seen three ways to achieve this, the other two being to send a message with the <<create>>



stereotype and/or to send a message into the side of the classifier symbol (for example in Figure 4 the message going into the side of EnrollInSeminar or in Figure 6 the message going into the side of StudentInfoPage. My advice is to choose one style and stick to it.

Figures 6 and 7 each depict a way to indicate looping logic. One way is to show a frame with the label loop and a constraint indicating what is being looped through, such as for each seminar in Figure 6. Another approach is to simply precede a message that will be invoked several times with an asterisk, as you see in Figure 7 with the inclusion of the Enroll in Seminar use case.

Figure 6. Outputting transcripts.

Figure 6 includes an asynchronous message, the message to the system printer which has the partial arrowhead. An asynchronous message is one where the sender doesn’t wait for the result of the message, instead it processes the result when and if it ever comes back. Up until this point all other messages have been synchronous, messages where the sender waits for the result before continuing on. It is common to send asynchronous messages to hardware devices or autonomous software services such as message buses.

The method of modeling the inclusion of use cases using in Figure 7 is something that I first proposed in The Elements of UML Style although I have no doubt that others use this approach as well. I basically show the use case as a bubble across the top of the diagram, just like any other classifier, and show a message sent to it with the <<include>> stereotype. This is consistent with both use case diagramming and sequence diagramming practices.

Figure 7. Enrolling in the University.



Figure 7 is also interesting because it shows how to model conditional logic. In this case a frame with the label alt is used along with a guard, in this case applicant on eligibility list. The frame is separated into regions separated by dashed lines. In this case there are two regions, one for each alternative, although you can have as many regions as you require (to support the visual equivalent of a case statement). Each region requires a guard.

Visual Coding With Sequence Diagrams

Earlier I stated that sequence diagrams are effectively a form of visual coding, or perhaps another way to think of it is that sequence diagrams can be used for very detailed design. When I developed the sequence diagram of Figure 4 I made several decisions that could potentially affect my other models. For example, as I modeled Step 10, I made the design decision that the fee display screen also handled the verification by the student that the fees were acceptable.

Also, as I was modeling Steps 2 and 3, I came to the realization that students should probably have passwords to get into the system. When you’re following the AM practices of Active Stakeholder Participation and Model With Others it’s easy to find out if ideas such as this make sense because all you need to do is ask. In this case I discovered I was wrong: the combination of name and student number is unique enough for our purposes and the university didn’t want the added complexity of password management. This is an interesting decision that would potentially be recorded as a business rule because it is an operating policy of the university, indicating the need to follow the practice Iterate To Another Artifact and jot down the rule if we’re interested in keeping a permanent record of it.

How to Draw Sequence Diagrams

I’ve been trying to explain to people how to draw sequence diagrams for years, and what I’ve discovered is that the people who get it are either very good at thinking in a logical manner and/or they are good at writing software code. Sequence diagramming really is visual coding, even when you are modeling a usage scenario via a system-



level sequence diagram.

When I’m creating a sequence diagram I’ll start by identifying the scope of what I’m trying to model, and because I prefer to follow the AM practice Model in Small Increments I’ll typically tackle small usage scenarios at the system level or a single method/service at the detailed object level. A diagram such as Figure 4 is too complex to be useful in my experience.

I’ll then work through the logic with at least one more person, laying out classifiers across the top as I need them. I automatically add the object lifelines but as I indicated earlier will typically not invest time adding activation boxes. The heart of the diagram is in the messages, which I add to the diagram one at a time as I work through the logic. I rarely indicate return values, instead I’ll give messages intelligent names which often make it clear what is being returned.

It is interesting to note that as you sequence diagram you will identify new responsibilities for classes and objects, and, sometimes, even new classes. The implication is that you may want to update your class model appropriately, agile modelers will follow the practice Create Several Models in Parallel, something that CASE tools will do automatically. Remember, each message sent to a class invokes a static method/operation on that class each message sent to an object invokes an operation on that object.

Regarding style issues for sequence diagramming, I prefer to draw messages going from left-to-right and return values from right-to-left, although that doesn’t always work with complex objects/classes. I justify the label on messages and return values, so they are closest to the arrowhead. I also prefer to layer the sequence diagrams: from left-to-right. I indicate the actors, then the controller class(es), and then the user interface class(es), and, finally, the business class(es). During design, you probably need to add system and persistence classes, which I usually put on the right-most side of sequence diagrams. Laying your sequence diagrams in this manner often makes them easier to read and also makes it easier to find layering logic problems, such as user interface classes directly accessing persistence classes.

Keeping it Agile

The most important things that you can do is to keep your diagrams simple, both content wise and tool wise. I will sketch sequence diagrams on whiteboards to think something through, either to verify the logic in a use case or to design a method or service. I rarely keep sequence diagrams as I find their true value is in their creation.

A common mistake is to try to create a complete set of sequence diagrams for your system. I’ve seen project teams waste months creating several sequence diagrams for each of their use cases, one for the basic course of action and one for each alternate course. My advice is to only create a sequence diagram when you have complex logic that you want to think through – if the logic is straightforward the sequence diagram won’t add any value, you had might as well go straight to code.

UML 2 State Machine Diagrams

Objects have both behavior and state or, in other words, they do things and they know things. Some objects do and know more things, or at least more complicated things, than other objects. Some objects are incredibly complicated, so complex that developers can have difficulty understanding them. To understand complex classes better, particularly those that act in different manners depending on their state, you should develop one or more UML 2 state machine diagrams, formerly called state chart diagrams in UML 1.x, describing how their instances work.



UML state machine diagrams depict the various states that an object may be in and the transitions between those states. In fact, in other modeling languages, it is common for this type of a diagram to be called a state-transition diagram or even simply a state diagram. A state represents a stage in the behavior pattern of an object, and like UML activity diagrams it is possible to have initial states and final states. An initial state, also called a creation state, is the one that an object is in when it is first created, whereas a final state is one in which no transitions lead out of. A transition is a progression from one state to another and will be triggered by an event that is either internal or external to the object.

Figure 1 presents an example state machine diagram for the Seminar class during registration. The rounded rectangles represent states: you see that instances of Seminar can be in the Proposed, Scheduled, Open For Enrollment, Full, and Closed to Enrollment states. An object starts in an initial state, represented by the closed circle, and can end up in a final state, represented by the bordered circle. This is the exact same notation used by UML activity diagrams, a perfect example of the consistency of the UML.

Figure 1. A seminar during registration.

The arrows in Figure 1 represent transitions, progressions from one state to another. For example, when a seminar is in the Scheduled state, it can either be opened for enrollment or cancelled. The notation for the labels on transitions is in the format event [guard][/method list]. It is mandatory to indicate the event which causes the transition, such as open or cancelled. Guard, conditions that must be true for the transition to be triggered, are optionally indicated. The [not seat available] guard is shown on the student enrolled transition from the Open For Enrollment to the Closed To Enrollment state. Guards can be described in any manner, including both free form text or formal language – when I’m whiteboarding I’ll use free form text to ensure that it’s readable by everyone but with a sophisticated CASE tool I would consider using either a programming language such as Java or a modeling language such as Object Constraint Language (OCL) if the tool has the ability to actually process that information into something useful (such as executable code). The invocation of methods, such as addToWaitingList() can optionally be indicated on transitions. The order in the listing implying the order in which they are invoked.

States are represented by the values of the attributes of an object. For example, a seminar is in the Open For Enrollment state when it has been flagged as open and seats are available to be filled. It is possible to indicate the invocation of methods within a state, for example, upon entry into the Closed To Enrollment state the method notifyInstructor() is invoked. The notation used within the same as that used on transitions, the only difference being that the method list is mandatory and the event is optional. For example in the Full state the operations



addToWaitingList() and considerSplit() are invoked whenever a student is enrolled. Had there been no event indicated those methods would be invoked continuously (in a loop) whenever the object is in that state. I indicate the methods to run during the state when I want to indicate a method is to be run continuously, perhaps a method that polls other objects for information or a method that implements the logic of an important business process. Methods to be invoked when the object enters the state are indicated by the keyword entry, as you see with both the Open For Enrollment and Closed To Enrollment states in Figure 1. Methods to be invoked as the object exits the state are indicated by the keyword exit. The capability to indicate method invocations when you enter and exit a state is useful because it enables you to avoid documenting the same method several times on each of the transitions that enter or exit the state, respectively.

Transitions are the result of the invocation of a method that causes an important change in state. Understanding that not all method invocations will result in transitions is important. For example, the invocation of a getter method likely wouldn’t cause a transition because it isn’t changing the state of the object (unless lazy initialization is being applied). Furthermore, Figure 1 indicates an attempt to enroll a student in a full seminar may not result in the object changing state, unless it is determined that the seminar should be split, even though the state of the object changes (another student is added to the waiting list). You can see that transitions are a reflection of your business rules. For example, you see that you can attempt to enroll a student in a course only when it is open for enrollment or full, and that a seminar may be split (presumably into two seminars) when the waiting list is long enough to justify the split. You can have recursive transitions, also called self transitions, that start and end in the same state. An example of which is the student dropped transition when the seminar is full.

For the sake of convention, we say an object is always in one and only one state, implying transitions are instantaneous. Although we know this is not completely true (every method is going to take some time to run), this makes life a lot easier for us to assume transitions take no time to complete.

Because the lifecycle of a seminar is so complex Figure 1 only depicts part of it. Figure 2 depicts the entire lifecycle, with Figure 1 shown as a substate of the Enrollment state. I could have included all of the details in Figure 2 but chose not to in order to keep the diagram simple – I prefer to follow the AM practices Depict Models Simply and Model in Small Increments. In fact, instead of creating a diagram such as Figure 2 I typically prefer something more along the lines of the high-level view of Figure 3 with detailed views such as Figure 1. This approach keeps the diagrams small and easy to understand.

Figure 2. The complete seminar lifecycle.



Figure 3. Top-level state machine diagram.

Figure 4 depicts a slightly different take on state machine diagrams, this time it is much closer to an analysis level diagram because it shows what is happening to the seminar while it is in this state from the point of view of the people involved. It is organized into two parallel swimlanes representing parallel substates – one from the point of view of the professor teaching the seminar and the other showing the actions of the teaching assistant responsible for keeping the seminar material up to date. Concurrent substates are common with hardware but very uncommon in business classes, hence the goofy example. Normally I would depict this sort of information using either a UML activity diagram or a UML timing diagram but I needed an example to show you extra notation.

Figure 4. The Being Taught state.

Figure 4 shows several ways to depict transitions. The Break Starts transition exiting from the Being Taught states is applicable to all of the substates, you know this because it exits from the superstate instead of an individual substate. The Work Submitted transition is potentially triggered by several sources, you know this because it is attached to the outside edge of the superstate, whereas the source of the Break ends transition is explicitly defined as the School Break state. The initial transition into this state is the Term Started transition, indicated through the use of an initial state symbol. I could also have modeled this state coming from an Enrollment state, either approach is fair.



The Term Started and Break Ends transitions are first merged, then they lead to a fork which in turn leads to one or the other set of concurrent substates. A history pseudo-state is shown, the circle with the H, indicating that if Seminar was previously in this state, left it, and the returns that it will go back to the substate it was originally in. The arrow leaving the history pseudo state indicates that the Deliver Course Material substate is the default the very first time that Seminar enters the Begin Taught superstate.

Drawing State Machine Diagrams

When drawing a state machine diagram the thing you want to do is to identify the creation state and whether any final states exist. After you have done this, ask yourself what other states or stages in the life of an object does it pass through? You can often find states by looking at the boundary values of your attributes. For example, when the number of students in a seminar reaches the maximum, it becomes full. Full is a valid state because different rules now apply: when a student tries to enroll, he is put on a waiting list and the seminar is a candidate to be split in two.

Once you have identified as many states as you can, start looking for transitions. For each state, ask yourself how the object can get out of it, if possible. This will give you a transition. Because all transitions lead from one state to another, ask yourself what new state the transition leads you to (don’t forget about recursive transitions that lead to the same state). You should also look at the methods you identified in your class diagram. Some of them will correspond to a transition in your state diagram.

Identifying potential error conditions while you are state machine modeling is common because you are constantly asking ―should this transition be allowed when the object is in this state?‖ When the answer is yes, you need to add the transition to your diagram. When the answer is no, you may need to document this potential issue so your programmers develop the proper error checking code, so the transition is not allowed to occur.

Although being able to inherit state diagrams would be nice, it is extremely unlikely this will happen. The definition of inheritance says that although the subclass is similar to the superclass, it is still different. The behavior of the subclass is usually different than that of the superclass. This means you need to reconsider the state diagram when you inherit from a class with one. The one good thing is many of the states and transitions are reusable. You will probably find you either add new states and transitions, or you will redefine some.

Remaining Agile

State machine modeling is a dynamic modeling technique, one that focuses on identifying the behavior within

machine diagrams when a class exhibits different behavior depending on its state. For example, the Address class is fairly simple, representing data you will display and manipulate in your system. Seminar objects, on the other hand, are fairly complex, and therefore it makes sense to create a state machine diagram for them.

In business applications it seems that a very small proportion of classes, perhaps 5% at most, are complex enough to warrant the creation of a state machine diagram. However, state machine diagrams are much more common in real-time systems (Douglass 1999).

UML 2 Timing Diagrams

Timing diagrams are one of the new artifacts added to UML 2. They are used to explore the behaviors of one or more objects throughout a given period of time. There are two basic flavors of timing diagram, the concise notation depicted in Figure 1 and the robust notation depicted in Figure 2. Timing diagrams are often used to



design embedded software, such as control software for fuel injection system in an automobile, although they occasionally have their uses for business software too.

Figure 1 depicts the lifecycle of a single seminar, showing its timeline quite clearly. The :Seminar label indicates that the lifeline being explored is that of an instance of Seminar. The critical states that the seminar exhibits – Proposed, Scheduled, Enrolling Students, Being Taught, Final Exams, Closed – are listed across the diagram. The two lines surrounding the states are called a general value lifeline. In this case I’m using them to show the value of the state of a seminar, but you could also explore the value of a single attribute of an object if you so choose. When the two lines cross one another it indicates a transition point between states. Along the bottom of the diagram timing constraints are shown, in this case indicating the period of time during which the seminar is in each state.

Figure 1. Timing diagram (concise notation).

It’s interesting to note the differences between the timing diagram of Figure 1 and the state machine diagram addressing the same issue. Several states from the state machine diagram are encompassed by the Enrolling Students state of the timing diagram. That’s perfectly fine because I’m using each diagram for its individual strengths – concise timing diagrams are good at exploring one or more objects throughout a period of time and state machine diagrams are good at exploring the detailed transitions between states as the result of events (either external or internal). Remember AM’s Apply the Right Artifact(s) practice and use the right model for the job.

Figure 2 depicts a timing diagram which explores the details of what happens while a seminar is being taught. In this jaded example the professor delivers the seminar and marks student work and the teaching assistant develops the course material just in time for it to be taught. A UML frame is being used to bound the two lifelines (that of the professor and the teaching assistant); we could very easily have modeled more lifelines simply by adding other sections to the frame. The box lines are called state timelines, in this case there are discrete transitions between states resulting in a box line although had the transitions been continuous in nature (such as the change in temperature) a curvy line would have been drawn. The states/conditions applicable to the lifeline, such as Mark Student Work and Idle, are listed along the left-hand side of the diagram. Events/stimuli, such as Holiday Break and Break Ends, are optionally labeled at transition points to indicate the reason for the change. The arrows between timelines are messages between the objects.

Several ways to indicate time are shown in Figure 2. A timing constraint, {Oct 5..Oct 10} is shown as are time observations (t=Nov 25 and t=Dec 1). Timing constraints and time observations can be applied to a variety of UML diagrams, including all forms of interaction diagrams such as sequence diagrams and communication diagrams, although I find them most useful on timing diagrams. Unique to timing diagrams are timing rulers, depicted as tick mark values along the bottom of the diagram.



Figure 2. Timing diagram (robust notation).

Remaining Agile

Both notations have their purposes, although the robust notation seems the more useful of the two particularly for objects that move back and forth between states. The more lifelines you try to model at once the harder it is to draw the diagram so two lifelines is about as complex as I like to get. I draw timing diagrams on whiteboards, I don’t know of any mainstream modeling tool oriented towards business application development that supports this kind of diagram.

In my opinion very few developers will find that they need UML timing diagrams, so I really can’t recommend that you invest the time to learn them. For the few times that you need to explore timing issues free form diagrams will very likely suffice.

UML 2 Use Case Diagram

UML 2 use case diagrams overview the usage requirements for a system. They are useful for presentations to management and/or project stakeholders, but for actual development you will find that use cases provide significantly more value because they describe "the meat" of the actual requirements. Figure 1 provides an example of a UML 2 use case diagram.

Use case diagrams depict:

Use cases. A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse.

Actors. An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures.

Associations. Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. The arrowhead is often used to indicating the direction of the initial



invocation of the relationship or to indicate the primary actor within the use case. The arrowheads are typically confused with data flow and as a result I avoid their use.

System boundary boxes (optional). You can draw a rectangle around the use cases, called the system boundary box, to indicates the scope of your system. Anything within the box represents functionality that is in scope and anything outside the box is not. System boundary boxes are rarely used, although on occasion I have used them to identify which use cases will be delivered in each major release of a system. Figure 2 shows how this could be done.

Packages (optional). Packages are UML constructs that enable you to organize model elements (such as use cases) into groups. Packages are depicted as file folders and can be used on any of the UML diagrams, including both use case diagrams and class diagrams. I use packages only when my diagrams become unwieldy, which generally implies they cannot be printed on a single page, to organize a large diagram into smaller ones. Figure 3 depicts how Figure 1 could be reorganized with packages.

In the example depicted in Figure 1 students are enrolling in courses with the potential help of registrars. Professors input the marks students earn on assignments and registrars authorize the distribution of transcripts (report cards) to students. Note how for some use cases there is more than one actor involved. Moreover, note how

case association will have a zero or one arrowhead. The association between Student and Enroll in Seminar (in the version shown in Figure 4) indicates this use case is initially invoked by a student and not by a registrar (the Registrar actor is also involved with this use case). Understanding that associations don’t represent flows of information is important; they merely indicate an actor is somehow involved with a use case. Information is flowing back and forth between the actor and the use case, for example, students would need to indicate which seminars they want to enroll in and the system would need to indicate to the students whether they have been enrolled. However, use case diagrams don’t model this sort of information. Information flow can be modeled using UML activity diagrams. The line between the Enroll in Seminar use case and the Registrar actor has no arrowhead, indicating it is not clear how the interaction between the system and registrars start. Perhaps a registrar may notice a student needs help and offers assistance, whereas other times, the student may request help from the registrar, important information that would be documented in the description of the use case. Actors are always involved with at least one use case and are always drawn on the outside edges of a use case diagram.

Figure 1. System use case diagram.

Figure 2. Using System boundary boxes to indicate releases.



Figure 3. Applying packages to simplify use case diagrams.

Creating Use Case Diagrams

I like to start by identifying as many actors as possible. You should ask how the actors interact with the system to identify an initial set of use cases. Then, on the diagram, you connect the actors with the use cases with which they are involved. If an actor supplies information, initiates the use case, or receives any information as a result of the use case, then there should be an association between them. I generally don’t include arrowheads on the association lines because my experience is that people confuse them for indications of information flow, not initial invocation. As I begin to notice similarities between use cases, or between actors, I start modeling the appropriate relationships between them (see the Reuse Opportunities section).

The preceding paragraph describes my general use case modeling style, an ―actors first‖ approach. Others like to start by identifying one actor and the use cases that they’re involved with first and then evolve the model from there. Both approaches work. The important point is that different people take different approaches so you need to be flexible when you’re following AM’s practice of Model With Others.

Reuse Opportunities

Figure 4 shows the three types of relationships between use cases -- extends, includes, and inheritance -- as well as inheritance between actors. I like to think of extend relationships as the equivalent of a "hardware interrupt"



because you don't know when or if the extending use case will be invoked (perhaps a better way to look at this is extending use cases are conditional). Include relationships as the equivalent of a procedure call. Inheritance is applied in the same way as you would on UML class diagrams -- to model specialization of use cases or actors in this case. The essay Reuse in Use Case Models describes these relationships in greater detail.

Figure 4. Use case reuse.

Remaining Agile

So how can you keep use case modeling agile? First, focus on keeping it as simple as possible. Use simple, flexible tools to model with. I’ll typically create use case diagrams on a whiteboard, as you see in Figure 5 which is an example of an initial diagram that I would draw with my project stakeholders. AM tells us that Content is More Important Than Representation so it isn’t a big issue that the diagram is hand drawn, it’s just barely good enough and that’s all that we need. It’s also perfectly okay that the diagram isn’t complete, there’s clearly more to a university than what is depicted, because we can always modify the diagram as we need to.

Figure 5. Whiteboard sketch.

In parallel to creating the sketch I would also write a very brief description of each use case, often on a whiteboard as well. The goal is to record just enough information about the use case so that we understand what it is all about. If we need more details we can always add them later either as an essential/business use case or a system use case.

50578582 Cs2353 Object Oriented Analysis and Design

Documents

Transcript of 50578582 Cs2353 Object Oriented Analysis and Design