Essentials of Visual Modeling w UML 2.0 - Instructor Notes

(1)

3 - 1

(2)

(3)

3 - 3

(4)

Instructor Notes:

An objectis an entity that has a well-defined boundary. That is, the purpose of the object should be clear.

An object has two key components: attributes and operations. Attributes and relationships represent an object’s state. Operations represent the behavior of the object.

Object behavior and state are discussed in the next few slides.

All objects have state and behavior.

Emphasize that state,

identity and behavior are the key characteristics of an object.

Take a moment to explain the graphic on this slide. Attributesare documented on the inside of the

doughnut. Operationsare documented on the borders, which become clearer to the student as you discuss topics like encapsulation.

(5)

3 - 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM. Module 3 - Concepts of Object Orientation

The state of an object is one of the possible conditions in which an object may exist. State normally changes over time. The state of an object is usually implemented by a set of properties called attributes, along with the values of the

properties and the links the object may have with other objects. State is not defined by a “state” attribute or set of attributes. Instead, state is defined by the total of an object’s attributes and links. For example, if Professor Clark’s status changed from Tenured to Retired, the state of the Professor Clark object would change.

Attributes change value from object to object of the

same class.

Explain the concept of state to the students.

Provide some supplemental state exercises to ensure that the class understands the concept of state. For example an online order (Pending, Approved, Shipped, BackOrdered, Cancelled, etc.) or a car’s Cruise Control (Engaged, Disengaged, On,

(6)

Instructor Notes:

The second characteristic of an object is that it has behavior. Objects are intended to mirror the concepts that they are modeled after, including behavior.

Behavior determines how an object acts and reacts to requests from other objects.

Object behavior is represented by the operations that the object can perform. For example, Professor Clark can choose to take a sabbatical once every five years. The Professor Clark object represents this behavior through the TakeSabbatical() operation.

Explain the concept of behavior to the students.

Objects “do” some interesting things. This is where the work in an OO system is done.

The melding of data and behavior is what makes OO such a powerful

(7)

3 - 7

In the real world, two people can share the same

characteristics: name, birth date, job description. Yet, there is no doubt that they are two individuals with a unique identity. The same concept holds true for objects. Although two objects may share the same state (attributes and relationships), they are separate, independent objects with their own unique identity.

All objects have a unique identity.

Explain the concept of

identity to the students.

(8)

Instructor Notes:

An object is represented with a rectangle and the name of the class.

The name of the object is always underlined. To name an object, place its name before the colon.

An object can be either named or anonymous. To remain anonymous, do not include a name.

Demonstrate how an object is modeled in UML.

(9)

3 - 9

There are four basic principles of object orientation: • Abstraction

• Encapsulation • Modularity • Hierarchy

(10)

Instructor Notes:

Encapsulationcan be defined as:

The physical localization of features (for example, properties, behaviors) into a single blackbox abstraction that hides their implementation (and associated design decisions) behind a public interface. (Dictionary of Object Technology, Firesmith, Eykholt, 1995.)

• Encapsulation is often referred to as “information hiding,” making it possible for the clients to operate without knowing how the implementation implements the interface.

• Encapsulation eliminates direct dependencies on the implementation (clients depend on/use the interface). Thus, it’s possible to change the implementation without updating the clients as long as the interface is unchanged.

• Clients are not affected by changes in implementation, thus reducing the “ripple effect,” where a correction to one operation forces the corresponding correction in a client operation and so on. As a result of encapsulation, maintenance is easier and less expensive.

• Encapsulation offers two kinds of protection. It protects an object’s internal state from being corrupted by its clients and • Define the concept of

encapsulation to the students.

• Encapsulation is putting the “data bits” and operations that

manipulate them in the same place.

• Encapsulation does NOT allow direct manipulation of things that have been encapsulated without using the supplied interface.

(11)

3 - 11

Modularitycan be defined as:

The logical and physical decomposition of things (for example, responsibilities and software) into small, simple groupings (for example, requirements and classes,

respectively), which increase the achievements of software-engineering goals. (Dictionary of Object Technology, Firesmith, Eykholt, 1995.)

• Another way to manage complexity is to break something that is large and complex into a set of smaller, more manageable pieces. These pieces can then be

independently developed as long as their interactions are well understood.

• Packages (described later in the course) support the definition of modular components.

(12)

Instructor Notes:

A Packagecan be defined as:

A general purpose mechanism for organizing elements into groups. (The Unified Modeling Language User Guide, Booch, 1999.)

• Models can contain hundreds and even thousands of model elements. The sheer number of these elements can quickly become overwhelming. Therefore, it’s critical to group model elements into logical collections to maintain and easily read the model (application of modularity and hierarchy).

• Packages are a general grouping mechanism for grouping elements into semantically related groups. A package contains classes that are needed by a number of different packages, but are treated as a “behavioral unit.”

• A package is simply a grouping mechanism. No semantics are defined for its instances. Thus, packages do not

necessarily have a representation in implementation, except maybe to represent a directory.

• In the UML, a package is represented as a tabbed folder.

Introduce the term package to the students.

(13)

3 - 13

The Greek term polymorphosmeans “having many forms.” Every implementation of the interface must include at least the interface. In some cases, the implementation can include more than the interface.

For example, a remote control can be used to monitor/support any type of television that relates to a specific interface (the specific interface the remote was designed to be used with).

Objects that are polymorphic may have the same

operation names but the operations perform

differently

Define the term polymorphism for the students.

(14)

Instructor Notes:

Interfaces are not abstract classes, as abstract classes allow you to provide default behavior for some/all of their methods. Interfaces provide no default behavior.

Interfaces are the key to the “plug-and-play” ability of an

architecture: Any classifiers (for example, classes, subsystems, components) that realize the same interfaces may be

substituted for one another in the system, thereby supporting the changing of implementations without affecting clients. Interfaces formalize polymorphism.They allow us to define polymorphism in a declarative way, unrelated to

implementation. Two elements are polymorphic with respect to a set of behaviors if they realize the same interfaces. In other words, if two objects use the same behaviors to get different, but similar results, they are considered to be polymorphic. A cube and a pyramid can both be drawn, moved, scaled, and rotated, but they look very different.

(15)

3 - 15

A roleis a constituent element of a structured class that represents the appearance of an instance (or, possibly, set of instances) within the context defined by the structured class. The concept of capsules in

(16)

(17)

3 - 17

A structured class clearly defines the class boundary

via an encapsulation shell.

A structured class can play multiple roles that vary

on the objects that interact with it.

(18)

Instructor Notes:

A structured class brings public interfaces into the

class via ports.

(19)

3 - 19

Since the port is a structural element, it’s created and destroyed along with its structured class.

(20)

Instructor Notes:

Multiplicitycan be defined as:

The number of instances of one class that relate to one instance of another class.

• For each role, you can specify the multiplicity of its class and how many objects of the class can be associated with one object of the other class.

• Multiplicity is indicated by a text expression on the role. The expression is a comma-separated list of integer ranges.

• It is important to remember that multiplicity is referring to instances of classes (objects) and their relationships. In this example, a Course Offering object can have either zero or one Professor object related to it. Conversely, a Professor object can have zero or more Course Offering objects related to it.

(21)

3 - 21

• Multiplicity is indicated by a text expression on the role. • The expression is a comma-separated list of integer ranges. • A range is indicated by an integer (the lower value), two dots,

followed by another integer (the upper value).

• A single integer is a valid range, and the symbol “*” indicates "many.” That is, an asterisk “*” indicates an unlimited number of objects.

• The symbol “*” by itself is equivalent to “0..*” That is, it represents any number, including none. This is the default value.

• An optional scalar role has the multiplicity 0..1.

• It’s possible to tell if the relationship is mandatory

or optional.

• It’s possible to tell how many links one object can

maintain with objects of another type.

The use of “N” instead of “*” is from Booch, not UML. For example, the use of “0..N” and “N” is not UML.

(22)

(23)

3 - 23

The software systems that you develop today are more complex than the human mind can comprehend. This is why you model systems. Your model selection profoundly

influences how you attack the problem and shape the solution. No single model is sufficient. Every complex system is best approached through a small set of nearly independent models. Therefore, to increase comprehension, a common language like the Unified Modeling Language (UML) is used to express models.

A modeling language is a language whose vocabulary and rules focus on the conceptual and physical representation of a system. A modeling language like the UML is a standard language for software blueprints.

Introduce the UML. Remember many of your students have no idea what the UML really is.

The next four slides explain how the UML is a language for visualizing, specifying, constructing and

(24)

Instructor Notes:

(25)

3 - 25

An iterative approach allows users to be involved in a meaningful way throughout the project life cycle. Since each iteration produces an executable release, users can observe the partially executing system and provide meaningful feedback to their level of satisfaction. This ensures that the final system delivered to users is acceptable.

Continuous testing and integrationensures that, at every iteration, the pieces all fit together and that the system-level requirements (for example, performance and capacity) are being met.

The short-term focus of an iterationis an objective measure of “doneness.” Either a class is included in the build or it’s not. It can’t be 90 percent done. Either a test is executed

successfully or it’s not. There is very little room for subjective estimates.

In spite of the best efforts of the development team, not all system features may be complete on the original delivery date. With a waterfall approach, this would usually mean that nothing was ready to be delivered (everything is 90 percent done). With an iterative approach, most of the system is already fully tested and operational. In many cases, there is value in delivering the partial system on the promised date with the remaining features incorporated at a later time. This can be important when a user has a critical need for some of the new functionality provided by the system or it may help the training and installation process to proceed on schedule. An iterative approach can avoid inconvenient planning and

re-assignment of resources.

Design the system in small digestible pieces. UML diagrams can enable one to design in an iterative fashion.

(26)

(27)

3 - 26

According to Booch in The Unified Modeling Language User Guide, modeling achieves four aims:

1. Models help you to visualizea system, as you want it to be.

A model helps the software team communicate the vision for the system being developed.It is difficult for a software team to have a unified vision of a system that is described only in specification and requirement documents. Models bring about understanding of the system.

2. Models permit you to specifythe structure of behavior of a system. A model allows how to document system behavior and structure before coding the system.

3. Models give a template that guide you in constructing a system. A model is an invaluable tool during construction. It serves as a road map for a developer. Have you experienced a situation where a developer coded incorrect behavior because he or she was confused over the wording in a requirements document? Modeling helps alleviate that situation.

4. Models document the decisions you’ve made. Models are valuable tools in the long term because they give “hard” information on design decisions. You don’t need to rely on someone’s memory.

Sell the students on the value of visual modeling.

Clarify that you are

(28)

(29)

3 - 28

Review the Rational Unified Process Framework and the relationship of the Analysis and Design Discipline to the other disciplines in the Framework.

The Rational Unified Process Framework was introduced in the Requirements Module. Highlight what part of the overall process we are concentrating on (analysis and design activities in an early elaboration iteration).

The purposes of Analysis and Design are to:

• Transform the requirements into a system design.

• Evolve a robust architecture for the system.

• Adapt the design to match the implementation environment, designing it for performance.

The Analysis and Design Discipline is related to other process disciplines.

• The Business Modeling Discipline provides an organizational context for the system.

• The Requirements Discipline provides the primary input for Analysis and Design.

• The Test Discipline tests the system designed during Analysis and Design.

• The Environment Discipline develops and maintains the supporting artifacts that are used during Analysis and Design.

(30)

Instructor Notes:

Use cases are one recommended method for organizing your requirements. Instead of a bulleted list of requirements, you organize them in a way that tells how someone may use the system. By doing so, you make a requirement more complete and consistent. You can also better understand the importance of a requirement from a user’s perspective.

It is often difficult to tell how a system does what it is supposed to do from a traditional object-oriented system model. This stems from the lack of a common thread through the system when it performs certain tasks. Use cases are that thread, because they define the behavior performed by a system. Use cases are not part of "traditional" object orientation, but their importance has become more and more apparent, further emphasizing the fact that use cases are part of the UML. This slide first appeared in

(31)

3 - 30

An instructor once said: “Analysis vs. Design is

important because of the mind-set. If you tried to manage all of the Analysis and Design issues in one go, your brain would explode on all but the most trivial developments. It’s just too much to take in,

comprehend, and model in one go. So I mentally switch ‘OK, Analysis — problem domain — don’t care about memory, persistence, databases, language, etc’. Right now it’s Design and I do care about all those things — but now I can stop trying to understand the business domain. It’s about managing the 7+/-2 things I can think about in one go. It also separates the skills (a bit).” Another instructor once said: “Analysis is the study of and eventual comprehension of ‘some thing’ [the problem space]. But to understand it, we must invent some entities to hold onto the thing that we have just grasped — this inventive process is Design. That is, human cognitive thinking is actually interwoven Analysis/Design and any attempt to separate them is really only an idealization. Therefore, if I try to apply two separate ‘steps’ in the production of, say, a class diagram [and call those steps A and then D], I will introduce ambiguity into my process because cognitive process forces one to ‘produce a solution’ in order to ‘understand a problem’ - that D is necessary to have any results from A.” Think of Analysis as an

idealized design step — where we ignore several complicating issues. This can turn into a religious debate.

The differences between Analysis and Design are ones of focus and emphasis. The above slide lists the things that you focus on in Analysis versus Design.

The goal in Analysis is to understand the problem and to begin to develop a visual model of what you are trying to build, independent of implementation and technology concerns.

Analysis focuses on translating the functional

requirements into software concepts. The idea is to get a rough cut at the objects that comprise our system, but focusing on behavior (and therefore encapsulation). We then move very quickly, nearly seamlessly, into “Design” and the other

concerns.

A goal of Design is to refine the model with the intention of developing a Design Model that will allow a seamless transition to the coding phase. In design, we adapt to the implementation and the deployment environment. The implementation

environment is the “developer” environment, which is a software superset and a hardware subset of the deployment environment

In modeling, we start with a model that closely resembles the real world (Analysis), and then find more abstract (but more fundamental) solutions to a more generalized problem

(32)

(33)

3 - 32

In Architectural Analysis — prior to the use-case

realizations, you define what flow of events (and therefore what use-case realizations), you are going to work on during the current iteration. The iteration planning is part of the Project Management discipline, performed by the project manager, but Architectural Analysis is where the actual use-case realization gets created.

Purpose:

• To define a candidate architecture for the system based on experience gained from similar systems or in similar problem domains.

• To define the architectural patterns, key mechanisms, and modeling conventions for the system.

• To define the reuse strategy.

• To provide input to the planning process.

Input Artifacts: • Use-Case Model

• Supplementary Specifications • Glossary

• Design Model

• Reference Architecture • Vision Document

• Project Specific Guidelines • Software Architecture Document

Resulting Artifacts:

• Software Architecture Document • Design Model

(34)

Instructor Notes:

Requirements and Business Modeling activities usually uncover key concepts that the system must be able to handle. These concepts manifest themselves as key design

abstractions. Because of the work already done, there is no need to repeat the identification work again during Use-Case Analysis. To take advantage of existing knowledge, we identify preliminary entity analysis classes to represent these key abstractions on the basis of general knowledge of the system.

Sources include the

Requirements

, the

Glossary

, and in particular, the

Domain

Model

, or the

Business Object Model

, if you

have one.

These key abstractions are

the “essence of the system,” and identifying them now is meant to provide a starting point for Use-Case Analysis. By identifying and modeling these key abstractions before Use-Case Analysis, you improve the consistency across the Use-Case Analysis activities for the different use cases. You reduce the possibility that different terms will model the same

abstractions when the classes are being identified for the different use cases. This is especially important if separate use-case teams will be working on the use cases, as it gives everyone a common starting point. You need more than just the Glossary, because the Glossary should not

(35)

3 - 34

This should be a review of the 4+1 views. They were initially described in the Analysis and Design Overview module.

The above diagram describes the model Rational uses to describe the software architecture. This is the recommended way to represent a software architecture. There may be other “precursor” architectures that are not in this format. The goal is to mature those architectural representations into the 4+1 view representation.

In Architectural Analysis,you will concentrate on the Logical View. The other views will be addressed in later architecture modules:

• The Logical View will be refined in the Identify Design Mechanisms, Identify Design modules.

• The Process View will be discussed in the Describe Run-time Architecture module.

• The Deployment View will be discussed in the Describe Distribution module.

• The Implementation View is developed during

Implementation and is thus considered out of scope for this Analysis and Design course.

• The Implementation view is the physical

realization of the system

(36)

Instructor Notes:

In Architectural Analysis, it is important to recognize that cycles are bad and should be avoided when possible. However, resolving circular dependencies should really be focussed on in Incorporate Existing Design Elements.

It is desirable that the package hierarchy be acyclic. This means that the following situation should be avoided (if possible):

• Package A uses package B, which uses package A.

If a circular dependency exists between Package A and Package B, if you change Package A it might cause a change in Package B, which might cause a change in Package A, etc. A circular dependency between packages A and B means that they will effectively have to be treated as a single package. Circles wider than two packages must also be avoided. For example, package A uses package B, which uses package C, which uses package A.

(37)

3 - 36

Emphasize that analysis mechanisms allow the designer to “build in” standard abstractions and conventions for the

nonfunctional requirements right into the architecture. Analysis mechanisms can be considered a shorthand representation for complex behavior.

The architecture should be simple, but not simplistic. It should provide standard behavior through standard abstractions and mechanisms. Thus, a key aspect in designing a software architecture is the definition and the selection of the

mechanisms that designers use to give "life" to their objects. In Architectural Analysis, it is important to identify the

analysis mechanisms for the software system being developed. Analysis mechanisms focus on and address the nonfunctional requirements of the system (that is, the need for persistence, reliability, and performance), and builds support for such non-functional requirements directly into the architecture.

Analysis mechanisms are used during analysis to reduce the complexity of analysis, and to improve its consistency by providing designers with a shorthand representation for complex behavior. Mechanisms allow the analysis effort to focus on translating the functional requirements into software abstractions without becoming bogged down in the

(38)

Instructor Notes:

Be sure to tell the students that the architect is the one who decides what use cases are realized in which iteration.

A use-case realization is the expression of a particular use case within the Design Model. It describes the use case in terms of collaborating objects. A use-case realization ties together the use cases from the Use-Case Model with the classes and relationships of the Design Model. A use-case realization specifies what classes must be built to implement each use case.

In the UML, use-case realizations are stereotyped collaborations. The symbol for a collaboration is an oval containing the name of the collaboration. The symbol for a use-case realization is a “dotted line” version of the collaboration symbol.

A use-case realization in the Design Model can be traced to a use case in the Use-Case Model. A realization relationship is drawn from the use-case realization to the use case it realizes. Within the UML, a use-case realization can be represented using a set of diagrams that model the context of the

(39)

3 - 38

Use cases form the central focus of most of the early analysis and design work. To enable the transition between

requirements-centric activities and design-centric activities, the use-case realization serves as a bridge, providing a way to trace behavior in the Design Model back to the Use-Case Model, as well as organizing collaborations in the Design Model around the use-case concept.

(40)

(41)

3 - 40

Some of the work done in analysis is thrown away. This isn’t bad, since you need to play with the ideas to see what works and what doesn’t, but expect that much of the work done during analysis is a kind of “structured doodling.” The biggest mistakes happen when people assign too much value to the early results of analysis.

The need to define analysis classes in UML terms creates a sense that they are more formal than they are. An instructor once referred to analysis classes as “CRC-like cards, on which you can scribble anything you want in the margins.”

This course concentrates on the development of a Design Model. Maintaining a separate Analysis Model would require some modifications to the presented activities, the discussion of which is out of the scope of this course.

Finding a candidate set of roles is the first step in the

transformation of the system from a mere statement of required behavior to a description of how the system will work.

The analysis classes, taken together, represent an early conceptual model of the system. This conceptual model evolves quickly and remains fluid for some time as different representations and their implications are explored. Formal documentation can impede this process, so be careful how much energy you expend on maintaining this “mode”’ in a formal sense; you can waste a lot of time polishing a model that is largely expendable. Analysis classes rarely survive into the design unchanged. Many of them represent whole

collaborations of objects, often encapsulated by subsystems. Analysis classes are “proto-classes,” which are essentially "clumps of behavior." These analysis classes are early conjectures of the composition of the system; they rarely survive intact into Implementation. Many of the analysis classes morph into something else later (subsystems,

(42)

Instructor Notes:

One technique for capturing this additional detail if Word is used to document the use cases is to add the detail in the form of comments in the Word document. That way the detail can be “turned on or off,” depending on the audience.

The description of each use case is not always sufficient for finding analysis classes and their objects. The customer generally finds information about what happens inside the system uninteresting, so the use-case descriptions may leave such information out. In these cases, the use-case description reads like a “black-box” description, in which internal details on what the system does in response to an actor’s actions is either missing or very summarily described. To find the objects that perform the use case, you need to have the “white box” description of what the system does from an internal perspective.

For example, in the case of the Course Registration System, the student might prefer to say ”the system displays a list of course offerings.” While this might be sufficient for the student, it gives us no real idea of what really happens inside the system. In order to form an internal picture of how the system really works, at a sufficient level of detail to identify objects, we might need additional information.

(43)

3 - 42

Sources of possible attributes: • Domain knowledge

• Requirements • Glossary • Domain Model • Business Model

Attributes are used instead of classes where:

• Only the value of the information, not it's location, is important

• The information is uniquely "owned" by the object to which it belongs; no other objects refer to the

information.

• The information is accessed by operations that only get, set, or perform simple transformations on the information; the information has no "real" behavior other than providing its value.

If, on the other hand, the information has complex behavior, or is shared by two or more objects, the information should be modeled as a separate class.

Attributes are domain-dependent. (An object model for a system includes those characteristics that are relevant for the problem domain being modeled.)

(44)

Instructor Notes:

(45)

3 - 43

At this point, we have a pretty good understanding of the analysis classes, their responsibilities, the analysis

mechanisms they need to implement, and the collaborations required to support the functionality described in the use cases. Now we must review our work and make sure that it is as complete and as consistent as possible before moving on to the architecture activities.

(46)

Instructor Notes:

A boundary class is used to model interaction between the system's surroundings and its inner workings. Such interaction involves transforming and translating events and noting

changes in the system presentation (such as the interface). Boundary classes model the parts of the system that depend on its surroundings. They make it easier to understand the system because they clarify the system's boundaries and aid design by providing a good point of departure for identifying related services. For example, if you identify a printer interface early in the design, you will realize that you must also model the formatting of printouts.

Because boundary classes are used between actors and the working of the internal system (actors can only communicate with boundary classes), they insulate external forces from internal mechanisms and vice versa. Thus, changing the GUI or communication protocol should mean changing only the boundary classes, not the entity and control classes.

(47)

3 - 45

Entity classes represent stores of information in the system. They are typically used to represent the key concepts that the system manages. Entity objects (instances of entity classes) are used to hold and update information about some phenomenon, such as an event, a person, or a real-life object. They are usually persistent, having attributes and relationships needed for a long period, sometimes for the lifetime of the system.

The main responsibilities of entity classes are to store and manage information in the system.

An entity object is usually not specific to one Use-Case

(48)

Instructor Notes:

A control class is a class used to model control behavior

specific to one or more use cases. Control objects (instances of control classes) often control other objects, so their behavior is of the coordinating type. Control classes encapsulate use-case-specific behavior.

The behavior of a control object is closely related to the

realization of a specific use case. In many scenarios, you might even say that the control objects "run" the Use-Case

Realizations. However, some control objects can participate in more than one Use-Case Realization if the use-case tasks are strongly related. Furthermore, several control objects of

(49)

3 - 47

(50)

Instructor Notes:

Note: This course concentrates on the development of a Design Model. The maintenance of a separate Analysis Model would require modifications to the described process and is really out of the scope of this course. Thus, the analysis classes are not maintained — they are refined into design elements.

Emphasize that the mapping does not have to be 1-to-1. One analysis class can be realized as multiple design classes and/or subsystems. “Superman” analysis classes (that jump small buildings in a single bound) may end up as subsystems in the design. We will be discussing additional guidelines for selecting subsystems on later slides.

Identify Design Elementsis where the analysis classes identified during Use-Case Analysis are refined into design elements (for example, classes or subsystems). Analysis classes handle primarily functional requirements, and model objects from the "problem" domain; design elements handle nonfunctional requirements, and model objects from the "solution" domain.

It is in Identify Design Elementsthat you decide which analysis “classes” are really classes, which are subsystems (which must be further decomposed), and which are existing components and do not need to be “designed” at all.

Once the design classes and subsystems have been created, each must be given a name and a short description. The responsibilities of the original analysis classes should be transferred to the newly created subsystems. In addition, the identified design mechanisms should be linked to design elements.

(51)

3 - 49

(52)

Instructor Notes:

This slide was originally discussed in Architectural Analysis.

Frameworks enable scalability of development: the ability to develop and deliver systems as quickly as the market requires by using a leveraged solution.

An analogy in bridge-building may help clarify this.

Examples of frameworks are suspension bridge, piling-and-trestle bridge, and cantilever bridge. Examples of design patterns are rivet fastener, bolt, and weld. In building a bridge, each is substitutable in some cases, and each is uniquely superior in other cases. (Both a weld and a bolt can be used to join two materials; the weld can be stronger if done correctly, but cannot be undone, repaired, or replaced as the bolt can.)

Taking the analogy a bit further, a suspension bridge can be a footbridge or the Golden Gate bridge. Both represent the same basic design approach and principles, so that one could readily say “that is a

suspension bridge,” but the extensions and localizations cause the end result to be quite different.

A patterncodifies specific knowledge collected from

experience. Patterns provide examples of how good modeling solves real problems, whether you come up with the patterns yourself or you reuse someone else’s. Design patterns are discussed in more detail on the next slide.

Frameworksdiffer from analysis and design patterns in their scale and scope. Frameworks describe a skeletal solution to a particular problem that may lack many of the details. These details can be filled in by applying various analysis and design patterns.

A framework is a micro-architecture that provides an

incomplete template for applications within a specific domain. Architectural frameworks provide the context in which the components run. They provide the infrastructure (plumbing, if you will) that allows the components to co-exist and perform in predictable ways. These frameworks can provide

(53)

3 - 51

(54)

Instructor Notes:

As we discussed in module 5, analysis mechanisms

represent a pattern that constitutes a common solution to a common problem. They can show patterns of structure, patterns of behavior, or both.

These mechanisms might show patterns of structure, patterns of behavior, or both. They are used during analysis to reduce the complexity of analysis, and to improve its consistency by providing designers with a shorthand representation for complex behavior. By using mechanisms as “placeholders”in the architecture, the architecting effort is less likely to become distracted by the details of mechanism behavior.

(55)

3 - 53

(56)

Instructor Notes:

A messagecan be defined as:

The specification of a communication among objects that conveys information with the expectation that activity will ensue. (The Unified Modeling Language User Guide, Booch, 1999.)

• When you pass a message, the action that results is an executable statement that forms an abstraction of a computational procedure. An action may result in a change of state. (

Any time a message is received;

there may be a change of state

)

• Messages are the mechanism that permits objects to interact with each other. A message is often implemented by a simple activity. For example, one object calls an operation in

another. When the activity has been executed, the control is returned to the caller along with a return value.

Explain how objects “talk” to each other when they collaborate.

Messages are used by objects in the same way that messages are used by people.

(57)

3 - 55

A sequence diagramdescribes a pattern of interaction among objects, arranged in a chronological order. It shows the objects participating in the interaction by their "lifelines" and the

messages that they send to each other.

In most cases, we use a sequence diagram to illustrate use-case realizations. That is, realizations show how objects

interact to perform the behavior of all or part of a use case. One or more sequence diagrams may illustrate the object

interactions that enact a use case. A typical organization is to have one sequence diagram for the main flow of events and one sequence diagram for each independent sub-flow of the use case.

Sequence diagrams are particularly important to designers because they clarify the roles of objects in a flow and provide basic information for determining class responsibilities and interfaces.

(58)

Instructor Notes:

You can have objects and actor instances in sequence diagrams, together with messages describing how they interact. The diagram describes what takes place in the participating objects, in terms of activations, and how the objects communicate by sending messages to one another. You can make a sequence diagram for each variant of a use case's flow of events.

The above example shows the object interactions to support the Register for Courses’use case, Create a Schedule sub-flow. Note the following responsibility allocation rationale.

•The RegisterForCoursesForm knows what data it needs to display and how to display it. It does not know where to go to get it. That is one of the RegistrationController’s

responsibilities.

•Only the RegisterForCoursesForm interacts with the Student actor.

•The RegistrationController understands how Students and Schedules are related.

(59)

3 - 57

The interaction occurrence is a reference to an interaction within the definition of another interaction.

An interaction occurrence is shown in a sequence diagram as a rectangle with the tag ref(for reference). The rectangle covers the lifelines that are included in the referenced

interaction. The name of the referenced interaction is placed in the rectangle.

In a sequence diagram, each interaction on the

diagram maps to the transition on a state diagram.

Explain interaction

(60)

Instructor Notes:

A communication diagramshows how objects interact to perform the behavior of a particular use case or a part of a use case.

Like sequence diagrams, communication diagrams are used by designers to define and clarify the roles of the objects that perform a particular flow of events of a use case. They are the primary source of information used to determine class responsibilities and interfaces.

Because of the communication diagram’s format, they tend to be better suited for analysis activities. Specifically, they tend to be better suited to depict simpler interactions of a smaller number of objects.

As the number of objects and messages grows, the diagram becomes increasingly hard to read. It is also difficult to show additional descriptive information like timing, decision points, or other unstructured information that can be easily added to the notes in a sequence diagram.

Unlike sequence diagrams, communication diagrams emphasize the organization of the objects.

(61)

3 - 59

Because they both derive the same information from the UML’s metamodel; sequence diagrams and communication diagrams are semantically equivalent. As a result, you can take a

diagram in one form and convert it to the other without any loss of information.

During Use Case Analysis, there is no magic number

of interaction diagrams (sequence or communication)

to be drawn. The number of interaction diagrams

should be just enough to ensure that all

responsibilities of participating classes are identified

and that most of the flows of events are examined.

Show the students the

similarities between sequence and

(62)

Instructor Notes:

• Sequence and communication diagrams express similar information, but show it in different ways.

• Communication diagrams emphasize the structural communication of a society of objects and show a clearer picture of the pattern of relationships and control that exist among the objects participating in a use case.

• Communication diagrams also show more structural information, such as the relationships among objects.

• Communication diagrams are better for understanding all the effects of a given object and for procedural design.

• Sequence diagrams show the explicit sequence of messages and are better for real-time specifications and complex

scenarios.

• A sequence diagram includes chronological sequences but does not include object relationships.

• Sequence numbers are often omitted in sequence diagrams, in which the physical location of the arrow shows the relative

Show the students the differences between the two diagrams.

The use of sequence versus communication diagrams is a personal choice. This course does not recommend one over the other, but describes the advantages of each. For brainstorming, some find the communication diagram easier, a closer visual representation of CRC cards.

(63)

3 - 61