Ooad With Uml2.0

DEV475 Mastering Object-Oriented Analysis and Design with UML 2.0Student Guide, Volume 1

IBM Rational University

DEV475 Mastering Object-Oriented Analysis and Design with UML 2.0Student Guide, Volume 1Part No.

IBM CorporationRational University DEV475 Mastering Object-Oriented Analysis and Design with UML 2.0Student Manual, Volume 1Version 2004.06.00

June 2004

Copyright © International Business Machines Corporation, 2004. All rights reserved.

This document may not be reproduced in whole or in part without the prior written permission of IBM.

The contents of this manual and the associated software are the property of Rational Software and/or its licensors, and are protected by United States copyright laws, patent laws, and various international treaties. For additional copies of this manual or software, please contact Rational Software.IBM and the IBM logo are trademarks or registered trademarks of IBM Corporation, in the United States, other countries or both.

Rational, the Rational logo, ClearQuest, ClearCase, ClearCase LT, ClearCase MultiSite, Unified Change Management, Rational Developer Network, Rational Rose, Rational XDE, Purify, PureCover-age, Rational Unified Process, ClearDDTS, and Quantify are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries or both.

Microsoft Visual Basic, Windows NT, Windows 2000, Windows 95/98, Windows XP, Microsoft Word, Windows Explorer, DOS, PowerPoint, and Visual SourceSafe, among others, are trademarks or regis-tered trademarks of Microsoft Corporation.

Java and all Java-based marks, among others, are trademarks or registered trademarks of Sun Micro-systems in the United States, other countries or both.

UNIX is a registered trademark of The Open Group in the United States, other countries or both.

Other company, product and service names may be trademarks or service marks of others.

Printed in the United States of America.

This manual prepared by:IBM Rational Software18880 Homestead RoadCupertino, CA 95014-0721USA

Contents

Module 0 About This Course Course Objectives.......................................................................................... 0-3 Prerequisites .................................................................................................. 0-6 Rational University Curriculum....................................................................... 0-7

Module 1 Best Practices of Software Engineering Practice 1: Develop Iteratively ....................................................................... 1-6 Practice 2: Manage Requirements .................................................................. 1-7 Practice 3: Use Component Architectures ...................................................... 1-8 Practice 4: Model Visually............................................................................ 1-10 Practice 5: Continuously Verify Quality ........................................................ 1-12 Practice 6: Manage Change ......................................................................... 1-14

Module 2 Concepts of Object Orientation Four Principles of Modeling ........................................................................... 2-4 Representing Classes in the UML.................................................................. 2-12 Class Relationships....................................................................................... 2-14 What is a Structured Class? .......................................................................... 2-21 What Is an Interface? ................................................................................... 2-29 What is a Port? ............................................................................................ 2-33 Review ........................................................................................................ 2-39

Module 3 Requirements Overview What Is System Behavior? .............................................................................. 3-8 Use-Case Specifications ............................................................................... 3-14 What Is an Activity Diagram? ....................................................................... 3-17 Glossary....................................................................................................... 3-21 Supplementary Specification........................................................................ 3-24 Review ........................................................................................................ 3-32

Module 4 Analysis and Design Overview Analysis Versus Design ................................................................................... 4-6 Analysis and Design Workflow ..................................................................... 4-12 Review ........................................................................................................ 4-19

Module 5 Architectural Analysis Architectural Analysis Overview ..................................................................... 5-4 Package Relationships: Dependency .............................................................. 5-8 Patterns and Frameworks ............................................................................. 5-11 What Are Stereotypes?................................................................................. 5-18 Architectural Mechanisms: Three Categories ................................................ 5-22 What Are Key Abstractions? ......................................................................... 5-30 The Value of Use-Case Realizations.............................................................. 5-35 Review ........................................................................................................ 5-39

Module 6 Use-Case Analysis Use-Case Analysis Overview .......................................................................... 6-4 Use-Case Analysis Steps ................................................................................. 6-8 Find Classes from Use-Case Behavior ........................................................... 6-12 Distribute Use-Case Behavior to Classes ....................................................... 6-27 Describe Responsibilities.............................................................................. 6-37 Association or Aggregation?.......................................................................... 6-46 What Are Roles? .......................................................................................... 6-47 Unify Analysis Classes .................................................................................. 6-57 Review ........................................................................................................ 6-62

Acknowledgments The development of this course was made possible with the help of many individuals, but I would particularly like to thank the following for their exceptional participation:

Alex Kutsick of Rational University for his course development standards, instructional design expertise, and attention to detail. Alex has contributed greatly in ensuring that there is a high-level of consistency throughout this course.

Gary Bastoky of Rational University for his graphics knowledge and support.

The students at Lockheed/Martin who participated in the beta presentation of this course: Markku Kotiaho, Michael Wells, James Lowe, Alicia Kohner, Elizabeth Grant, Huy Nguyen, Kevin Carpenter, Michael Saniei, Mark Campbell, Ron Piwetz, Eric Miller, and Nhan Do.

Last but certainly not least, DeAnna Roberts of the Rational University production team for her logistical support.

June, 2004 Michael Lang Rational University Product Manager/ OO Curriculum [email protected]

mailto:[email protected]

Works Cited The following sources were used to develop this courseware. When quoted directly, we cite the source after the quoted passage. For all other uses, we respectfully acknowledge below the authors’ contributions in the development of this courseware.

The Deadline: A Novel About Project Management, Tom DeMarco, Dorset House Publishing, 1997.

Dictionary of Object Technology: The Definitive Desk Reference, Donald G. Firesmith and Edward M. Eykholt, Prentice Hall, 1995.

Meta Fax, 09/15/97.

Object Technology: A Manager’s Guide, David A. Taylor, Addison-Wesley, 1999.

Pattern-Oriented Software Architecture: A System of Patterns, Frank Buschman et al., John Wiley & Sons, 1996.

The Rational Unified Process, An Introduction, Phillippe Kruchten, Addison-Wesley, 1999.

The UML Bible, Tom Pender, Wiley Publishing, Inc., 2003.

UML Distilled – Third Edition, Martin Fowler, Addison-Wesley, 2004.

UML Toolkit, Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David Fado, Wiley Publishing, Inc., 2004.

The Unified Modeling Language User Guide, Grady Booch, James Rumbaugh, Ivar Jacobson, Addison-Wesley, 1999.

The Unified Modeling Language Reference Manual – Second Edition, James Rumbaugh, Ivar Jacobson, Grady Booch, Addison-Wesley, 2004.

Visual Modeling with Rational Rose and UML, Terry Quatrani, Addison-Wesley, 1998.

► ► ► Module 0 About This Course

1

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 0: About This Course

Topics

Course Objectives ................................................................................................ 0-3 Prerequisites......................................................................................................... 0-6 Rational University Curriculum ............................................................................. 0-7

© Copyright IBM Corp. 2004 0 - 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

Mastering Object-Oriented Analysis and Design with UML 2.0

Introductions

2

Introductions

Your organizationYour roleYour background, experience

Object technology experienceSoftware development experienceImplementation language experience

Your expectations for this course

0 - 2 © Copyright IBM Corp. 2004


Module 0 - About This Course

Course Objectives

3

Course Objectives

Upon completion of the course, participants will be able to:

Apply an iterative, use case-driven, architecture-centric process to the development of a robust design modelUse the Unified Modeling Language (UML) to represent the design modelApply Object-Oriented (OO) concepts: abstraction, encapsulation, inheritance, hierarchy, modularity, and polymorphism to the development of a robust design model

During this course, you will be introduced to the concepts, process, and notation for developing a design model. You will be using the Rational Unified Process Analysis and Design workflow as your framework. These concepts can also be applied within any software development process.




Course Objectives (continued)

4

Course Objectives (continued)

Upon completion of the course, participants will be able to:

Describe the different views of software architecture, key mechanisms that are defined in support of that architecture, and the effect of the architecture on the produced designDefine basic design considerations, including the use of patterns

The concentration will be on those activities that are performed by the object-oriented designer. Architectural concepts will be introduced and discussed, as they drive the design, but this is not an architecture course.




Intended Audience

5

Intended Audience

Intended AudiencePractitioners who want a basic explanation of Object-Oriented Analysis and Design (OOAD) concepts, as well as hands-on practical experience in applying the techniquesAnalysts, designers, software developers, and system engineers




Prerequisites

6

Prerequisites

Some experience applying the following techniques in a software development environment

An exposure to object technology including, how to:• Read a use-case model • Add classes, objects, associations and how to create simple

interaction and class diagrams • Find classes and distribute class behavior • Distinguish between the UML Analysis class stereotypes:

boundary, control, and entityPrerequisites can be achieved through attendance in “Essentials of Visual Modeling with UML” or equivalent experience




Rational University Curriculum

7

Rational University CurriculumCurriculum Flow:Designer

Instructor-led Web-basedOptional

DEV275Essentials of Visual Modeling with UML

1 day

DEV110Principles of

Modeling

2 hours

OR

Path 1

DEV111Principles of UC Modeling

with UML

2 hours

DEV113Principles of Analysis II

2 hours

DEV112Principles of

Analysis I

2 hours

Path 2

DEV475Mastering Object

OrientedAnalysis &

Design with UML4 days

DEV160Principles of

Modeling Behavior

2 hours

The Rational University curriculum offers the courses shown here and on the next two slides. As you can see, for each major software development team role, Rational University offers a professional development course.





8

Rational University CurriculumCurriculum Flow:Enterprise Architect


Path 1

DEV111Principles of UC Modeling

with UML

2 hours

DEV113Principles of Analysis II

2 hours

DEV112Principles of

Analysis I

2 hours

Path 2OR

DEV110Principles of

Modeling

2 hours

DEV275Essentials of Visual Modeling with UML

1 day

DEV475Mastering Object

OrientedAnalysis &

Design with UML4 days





9

Rational University CurriculumCurriculum Flow:System Analyst


REQ480Management

with Use Cases

3 days

OR

REQ370Essentials of

Rational RequisitePro

1 day

REQ310Essentials of

Rational RequisitePro

5 hours

OR

DEV110Principles of

Modeling

2 hours

DEV275Essentials of

Visual Modeling with

UML

1 day




Course Materials

10

Course Materials

Student Manual, Books 1, 2, and 3Additional Information AppendixExercise WorkbookPayroll Exercise Solution

The Student Manual contains copies of the slides, as well as detailed Student Notes.The Student Manual is comprised of three books.

The Additional Information Appendix contains a collection of additional topics that are not general enough to be included in the base course, or may be considered too advanced for the introductory audience. These topics may or may not be covered by the instructor. This appendix contains the UML-To-Language Maps that show the map from the UML to implementation language constructs for the following languages: C++, Java, PowerBuilder, and Visual Basic. It also contains information on several additional Architectural Mechanisms.

The Exercise Workbook is made up of three documents or handbooks. The requirements that drive the development of the example and exercise design models are documented in the Exercise Workbook: Course Registration Requirements and Payroll Requirements, respectively.

The architectural “givens” that guide the students in the development of the exercise design model are documented in the Exercise Workbook: Payroll Architecture Handbook.

The Payroll Exercise Solution contains the hard-copy of the course exercise solutions.




Other Sources of Information

11

Other Sources of Information

Rational Unified Processhttp://www.ibm.com/developerworks/rational/products/rup

Rational Web Sitehttp://www.ibm.com/software/rational/

Rational developerWorkshttp://www.ibm.com/developerworks/

Rational Developer Domainhttp://www.ibm.com/developerworks/rational/

• The Rational Web site provides the latest information on new products, visual

modeling and development, events, customer support, documentation and training, to name just a few.

• Rational developerWorks, a customer-only site is IBM’s resource for developers.




Logistics

12

Logistics

Morning2-Fifteen-minute breaks

Lunch 1 HourAfternoon2-Fifteen-minute breaks



► ► ► Module 1 Best Practices of Software Engineering

1

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 1: Best Practices of Software Engineering

Topics

Practice 1: Develop Iteratively .............................................................................. 1-6 Practice 2: Manage Requirements ........................................................................ 1-7 Practice 3: Use Component Architectures............................................................. 1-8 Practice 4: Model Visually .................................................................................. 1-10 Practice 5: Continuously Verify Quality............................................................... 1-12 Practice 6: Manage Change................................................................................ 1-14



Mastering Object-Oriented Design and Analysis

Objectives: Best Practices

2

Objectives: Best Practices

Identify symptoms of software development problems.Explain the Best Practices.Present the Rational Unified Process (RUP) within the context of the Best Practices.

In this module, you will learn about recommended software development Best Practices and the reasons for these recommendations. Then you will see how the Rational Unified Process (RUP) is designed to help you implement the Best Practices.



Module 1 - Best Practices of Software Engineering

Symptoms of Software Development Problems

3

Symptoms of Software Development Problems

User or business needs not metRequirements not addressedModules not integratingDifficulties with maintenanceLate discovery of flawsPoor quality of end-user experiencePoor performance under loadNo coordinated team effortBuild-and-release issues




Trace Symptoms to Root Causes

4

Trace Symptoms to Root Causes

Needs not met

Requirements churn

Modules don’t fit

Hard to maintain

Late discovery

Poor quality

Poor performance

Colliding developers

Build-and-release

Insufficient requirements

Ambiguous communications

Brittle architectures

Overwhelming complexity

Undetected inconsistencies

Poor testing

Subjective assessment

Waterfall development

Uncontrolled change

Insufficient automation

Symptoms Root Causes Best Practices

Ambiguous communications

Undetected inconsistencies

Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually (UML)

Continuously Verify Quality

Manage Change



Modules do not fit

By treating these root causes, you will eliminate the symptoms. By eliminating the symptoms, you’ll be in a much better position to develop high-quality software in a repeatable and predictable fashion.

Best Practices are a set of commercially proven approaches to software development, which, when used in combination, strike at the root causes of software development problems. They are called “Best Practices,” not because we can precisely quantify their value, but because they have been observed to be commonly used in the industry by successful organizations. The Best Practices have been harvested from thousands of customers on thousands of projects and from industry experts.




Best Practices Reinforce Each Other

5

Best Practices Reinforce Each Other

Best PracticesDevelop Iteratively

Manage Requirements




Manage Change

Validates architectural decisions early on

Addresses complexity of design/implementation incrementally

Measures quality early and often

Evolves baselines incrementally

Ensures users are involved as requirements evolve

In the case of our Best Practices, the whole is much greater than the sum of the parts. Each of the Best Practices reinforces and, in some cases, enables the others. This slide shows just one example: how iterative development supports the other five Best Practices. However, each of the other five practices also enhances iterative development. For example, iterative development done without adequate requirements management can easily fail to converge on a solution. Requirements can change at will, which can cause users not to agree and the iterations to go on forever.

When requirements are managed, this is less likely to happen. Changes to requirements are visible, and the impact on the development process is assessed before the changes are accepted. Convergence on a stable set of requirements is ensured. Similarly, every Best Practices supports each of the other Best Practices. Hence, although it is possible to use one Best Practice without the others, this is not recommended, since the resulting benefits will be significantly decreased.




Practice 1: Develop Iteratively

6

Develop Iteratively

Iterative development produces an executable

1. InitialPlanning

2. Planning

3. Requirements4. Analysis & Design

5. Implementation

7. Deployment

6. Test

8. Evaluation

ManagementEnvironment

(on-going)

Each iteration results in an executable release

Developing iteratively is a technique that is used to deliver the functionality of a system in a successive series of releases of increasing completeness. Each release is developed in a specific, fixed time period called an iteration.

Each iteration is focused on defining, analyzing, designing, building, and testing a set of requirements.

The earliest iterations address the greatest risks. Each iteration includes integration and testing and produces an executable release. Iterations help:

• Resolve major risks before making large investments. • Enable early user feedback. • Make testing and integration continuous. • Define a project’s short-term objective milestone. • Make deployment of partial implementations possible. Instead of developing the whole system in lock step, an increment (for example, a subset of system functionality) is selected and developed, then another increment, and so on. The selection of the first increment to be developed is based on risk, with the highest priority risks first. To address the selected risk(s), choose a subset of use cases. Develop the minimal set of use cases that will allow objective verification (that is, through a set of executable tests) of the risks that you have chosen. Then, select the next increment to address the next-highest risk, and so on.




Practice 2: Manage Requirements

7

Managing RequirementsEnsures that you

solve the right problembuild the right system

by taking a systematic approach toeliciting organizing documenting managing

the changing requirements of a software application.

A report from the Standish Group confirms that a distinct minority of software development projects is completed on time and on budget. In their report, the success rate was only 16.2%, while challenged projects (operational, but late and over budget) accounted for 52.7%. Impaired (canceled) projects accounted for 31.1%. These failures are attributed to incorrect requirements definition from the start of the project and poor requirements management throughout the development lifecycle. (Source: Chaos Report, http://www.standishgroup.com) Aspects of requirements management:

• Analyze the problem • Understand user needs • Define the system • Manage scope • Refine the system definition • Manage changing requirements




Practice 3: Use Component Architectures

8

Use Component Architectures Software architecture needs to be:

Meets current and future requirementsImproves extensibilityEnables reuseEncapsulates system dependencies

Reuse or customize components Select from commercially available componentsEvolve existing software incrementally

ResilientComponent-based

Architecture is a part of Design. It is about making decisions on how the system will be built. But it is not all of the design. It stops at the major abstractions, or, in other words, the elements that have some pervasive and long-lasting effect on system performance and ability to evolve.

A software system’s architecture is perhaps the most important aspect that can be used to control the iterative and incremental development of a system throughout its lifecycle.

The most important property of an architecture is resilience –flexibility in the face of change. To achieve it, architects must anticipate evolution in both the problem domain and the implementation technologies to produce a design that can gracefully accommodate such changes. Key techniques are abstraction, encapsulation, and object-oriented Analysis and Design. The result is that applications are fundamentally more maintainable and extensible.

Software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost, according to the authors of Software Architecture in Practice (Len Bass, Paul Clements, and Rick Kazman [1998] Addison-Wesley). The Software Engineering Institute (SEI) has an effort underway called the Architecture Tradeoff Analysis (ATA) Initiative that focuses on software architecture, a discipline much misunderstood in the software industry. The SEI has been evaluating software architectures for some time and would like to see architecture evaluation in wider use. As a result of performing architecture evaluations, AT&T reported a 10% productivity increase (from news@sei, Vol. 1, No. 2).




Purpose of a Component-Based Architecture

9

Purpose of a Component-Based Architecture

Basis for reuseComponent reuseArchitecture reuse

Basis for project managementPlanningStaffingDelivery

Intellectual controlManage complexityMaintain integrity System-

software

Middleware

Business-specific

Application-specific

Component-based architecture with layers

Definition of a (software) component:

RUP Definition: A nontrivial, nearly independent, and replaceable part of a system that performs a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realization of a set of interfaces.

UML Definition: A physical, replaceable part of a system that packages implementation and that conforms to and provides the realization of a set of interfaces. A component represents a physical piece of the implementation of a system, including software code (source, binary, or executable) or equivalents such as scripts or command files.




Practice 4: Model Visually

10


Captures structure and behaviorShows how system elements fit togetherKeeps design and implementation consistentHides or exposes details as appropriate Promotes unambiguous communication

The UML provides one language for all practitioners.

A model is a simplification of reality that provides a complete description of a system from a particular perspective. We build models so that we can better understand the system we are building. We build models of complex systems because we cannot comprehend any such system in its entirety.

Modeling is important because it helps the development team visualize, specify, construct, and document the structure and behavior of system architecture. Using a standard modeling language such as the UML (the Unified Modeling Language), different members of the development team can communicate their decisions unambiguously to one another.

Using visual modeling tools facilitates the management of these models, letting you hide or expose details as necessary. Visual modeling also helps you maintain consistency among system artifacts: its requirements, designs, and implementations. In short, visual modeling helps improve a team’s ability to manage software complexity.




Visual Modeling with the Unified Modeling Language

11

Visual Modeling with the Unified Modeling Language

Dynamic Diagrams

Multiple viewsPrecise syntax and semantics

ActivityDiagrams

Models

Static Diagrams

SequenceDiagrams

CommunicationDiagrams

State MachineDiagrams

DeploymentDiagrams

ComponentDiagrams

ObjectDiagrams

ClassDiagramsUse-Case

Diagrams

In building a visual model of a system, many different diagrams are needed to represent different views of the system. The UML provides a rich notation for visualizing models. This includes the following key diagrams:

• Use-case diagrams to illustrate user interactions with the system • Class diagrams to illustrate logical structure • Object diagrams to illustrate objects and links • Component diagrams to illustrate physical structure of the software • Deployment diagrams to show the mapping of software to hardware

configurations • Activity diagrams to illustrate flows of events • State Machine diagrams to illustrate behavior • Interaction diagrams (that is, Communication and Sequence diagrams) to

illustrate behavior This is not all of the UML diagrams, just a representative sample.




Practice 5: Continuously Verify Quality

12


Cost

TransitionConstructionElaborationInception

Software problems are100 to 1000 times more costly

to find and repair after deployment

Cost to Repair Software

Cost of Lost Opportunities

Cost of Lost Customers

Quality, as used within the RUP, is defined as “The characteristic of having demonstrated the achievement of producing a product which meets or exceeds agreed-upon requirements, as measured by agreed-upon measures and criteria, and is produced by an agreed-upon process." Given this definition, achieving quality is not simply “meeting requirements" or producing a product that meets user needs and expectations. Quality also includes identifying the measures and criteria (to demonstrate the achievement of quality) and the implementation of a process to ensure that the resulting product has achieved the desired degree of quality (and can be repeated and managed).

This principle is driven by a fundamental and well-known property of software development: It is a lot less expensive to correct defects during development than to correct them after deployment.

Tests for key scenarios ensure that all requirements are properly implemented.

• Poor application performance hurts as much as poor reliability. • Verify software reliability by checking for memory leaks and bottlenecks. • Test every iteration by automating testing. Inception, Elaboration, Construction, and Transition are all RUP terms that will be discussed shortly.




Testing Dimensions of Quality

13

Testing Dimensions of Quality

Performance

ReliabilityTest that the application behaves consistently and predictably.

Test the online response under average and peak loading.

FunctionalityTest the accurate workings of each usage scenario.

UsabilityTest application from the perspective of convenience to the end user.

SupportabilityTest the ability to maintain and support the application under production use.

Functional testing verifies that a system executes the required use-case scenarios as intended. Functional tests may include the testing of features, usage scenarios, and security.

Usability testing evaluates the application from the user’s perspective. Usability tests focus on human factors, aesthetics, consistency in the user interface, online and context-sensitive Help, wizards and agents, user documentation, and training materials.

Reliability testing verifies that the application performs reliably and is not prone to failures during execution (crashes, hangs, and memory leaks). Effective reliability testing requires specialized tools. Reliability tests include tests of integrity, structure, stress, contention, and volume.

Performance testing checks that the target system works functionally and reliably under production load. Performance tests include benchmark tests, load tests, and performance profile tests.

Supportability testing verifies that the application can be deployed as intended. Supportability tests include installation and configuration tests.




Practice 6: Manage Change

14

WorkspaceManagement

Process Integration

Parallel Development

Build Management

Configuration Management is more than just check-in and check-out

Manage Change

To avoid confusion, have:Secure workspaces for each developerAutomated integration/build managementParallel development

Establishing a secure workspace for each developer provides isolation from changes made in other workspaces and control of all software artifacts — models, code, documents and so forth.

A key challenge to developing software-intensive systems is the need to cope with multiple developers, organized into different teams, possibly at different sites, all working together on multiple iterations, releases, products, and platforms. In the absence of disciplined control, the development process rapidly degrades into chaos. Progress can come to a stop. Three common problems that result are:

• Simultaneous update: When two or more roles separately modify the same artifact, the last one to make changes destroys the work of the others.

• Limited notification: When a problem is fixed in shared artifacts, some of the developers are not notified of the change.

• Multiple versions: With iterative development, it would not be unusual to have multiple versions of an artifact in different stages of development at the same time. For example, one release is in customer use, one is in test, and one is still in development. If a problem is identified in any one of the versions, the fix must be propagated among all of them.




Manage Change (continued)

15

Manage Change (continued)

Unified Change Management (UCM) involves:

Management across the lifecycle• System• Project management

Activity-based management• Tasks• Defects• Enhancements

Progress tracking• Charts• Reports

Unified Change Management (UCM) is “the Rational software approach” to managing change in software system development, from requirements to release. UCM spans the development lifecycle, defining how to manage change to requirements, design models, documentation, components, test cases, and source code.

One of the key aspects of the UCM model is that it unifies the activities used to plan and track project progress and the artifacts undergoing change.

You cannot stop change from being introduced into a project; however, you must control how and when changes are introduced into project artifacts, and who introduces those changes.

You must also synchronize changes across development teams and locations. Unified Change Management (UCM) is the Rational Software approach to managing change in software system development, from requirements to release.




Rational Unified Process Implements Best Practices

16

Develop Iteratively

Manage Requirements




Manage Change

Rational Unified Process Implements Best Practices

Best PracticesProcess Made Practical

Why have a process?

• It provides guidelines for efficient development of quality software • It reduces risk and increases predictability • It promotes a common vision and culture • It captures and institutionalizes Best Practices The Rational Unified Process (RUP) is a generic business process for object-oriented software engineering. It describes a family of related software-engineering processes sharing a common structure and a common process architecture. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget. The RUP captures the Best Practices in modern software development in a form that can be adapted for a wide range of projects and organizations.

The UML provides a standard for the artifacts of development (semantic models, syntactic notation, and diagrams): the things that must be controlled and exchanged. But the UML is not a standard for the development process. Despite all of the value that a common modeling language brings, you cannot achieve successful development of today’s complex systems solely by the use of the UML. Successful development also requires employing an equally robust development process, which is where the RUP comes in.




Achieving Best Practices

17

Achieving Best Practices

Iterative approachGuidance for activities and artifactsProcess focus on architectureUse cases that drive design and implementationModels that abstract the system

Examples:

• The dynamic structure (phases and iterations) of the Rational Unified Process creates the basis of iterative development.

• The Project Management discipline describes how to set up and execute a project using phases and iterations.

• Within the Requirements discipline, the Use-case model and the risk list determine what functionality you implement in an iteration.

• The workflow details of the Requirements discipline show the activities and artifacts that make requirements management possible.

• The iterative approach allows you to progressively identify components and to decide which one to develop, which one to reuse, and which one to buy.

• The Unified Modeling Language (UML) used in the process represents the basis of visual modeling and has become the de facto modeling language standard.

• The focus on software architecture allows you to articulate the structure: the components, the ways in which they integrate, and the fundamental mechanisms and patterns by which they interact.




A Team-Based Definition of Process

18

A Team-Based Definition of Process

A process defines Who is doing What, When, and How, in order to reach a certain goal.

New or changedrequirements

New or changed system

Software EngineeringProcess




Process Structure - Lifecycle Phases

19

Process Structure - Lifecycle Phases

The Rational Unified Process has four phases:Inception – Define the scope of the projectElaboration – Plan the project; specify features and baseline architecture Construction – Build the productTransition – Transition the product into the end-user community

Inception Elaboration Construction Transition

Time

During Inception, we define the scope of the project: what is included and what is not. We do this by identifying all the actors and use cases, and by drafting the most essential use cases (typically 20% of the complete model). A business plan is developed to determine whether resources should be committed to the project.

During Elaboration, we focus on two things: getting a good grasp of the requirements (80% complete) and establishing an architectural baseline. If we have a good grasp of the requirements and the architecture, we can eliminate a lot of the risks, and we will have a good idea of how much work remains to be done. We can make detailed cost and resource estimates at the end of Elaboration.

During Construction, we build the product in several iterations up to a beta release.

During Transition, we move the product to the end user and focus on end-user training, installation, and support.

The amount of time spent in each phase varies. For a complex project with many technical unknowns and unclear requirements, Elaboration may include three to five iterations. For a simple project, where requirements are known and the architecture is simple, Elaboration may include only a single iteration.




Bringing It All Together: The Iterative Approach

20

Bringing It All Together: The Iterative Approach

Disciplinesgroup activities logically.

In an iteration, you walk through all disciplines.

This slide illustrates how phases and iterations (the time dimension) relate to the development activities (the discipline dimension). The relative size of each color area in the graph indicates how much of the activity is performed in each phase or iteration. Each iteration involves activities from all disciplines. The relative amount of work related to the disciplines changes between iterations. For instance, during late Construction, the main work is related to Implementation and Test, and very little work on Requirements is done. Note that requirements are not necessarily complete by the end of Elaboration. It is acceptable to delay the analysis and design of well-understood portions of the system until Construction because they are low in risk. This is a brief summary of the RUP disciplines: Business Modeling – Encompasses all modeling techniques you can use to visually model a business. Requirements – Defines what the system should do. Analysis & Design – Shows how the system's use cases will be realized in implementation. Implementation – Implements software components that meet quality standards. Test – Integrates and tests the system. Deployment - Provides the software product to the end-user. Configuration & Change Management – Controls and tracks changes to artifacts. Project Management – Ensures tasks are scheduled, allocated and completed in accordance with project schedules, budgets and quality requirements. Environment – Defines and manages the environment in which the system is being developed.




Summary

21

Summary

Best Practices guide software engineering by addressing root causes.Best Practices reinforce each other.Process guides a team on who does what, when, and how.The Rational Unified Process is a means of achieving Best Practices.






► ► ► Module 2 Concepts of Object Orientation

1

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 2: Concepts of Object Orientation

Topics

Four Principles of Modeling.................................................................................. 2-4 Representing Classes in the UML ........................................................................ 2-12 Class Relationships ............................................................................................. 2-14 What is a Structured Class? ................................................................................. 2-21 What Is an Interface?.......................................................................................... 2-29 What is a Port? ................................................................................................... 2-33 Review............................................................................................................... 2-39




Objectives: Concepts of Object Orientation

2

Objectives: Concepts of Object Orientation

Explain the basic principles of object orientation Define the basic concepts and terms of object orientation and the associated UML notation



Module 2 - Concepts of Object Orientation

Review: Why Model?

3

Review: Why Model?

Modeling achieves four aims:Helps you to visualize a system as you want it to be.Permits you to specify the structure or behavior of a system.Gives you a template that guides you in constructing a system.Documents the decisions you have made.

You build models of complex systems because you cannot comprehend such a system in its entirety.You build models to better understand the system you are developing.

According to Booch in The Unified Modeling Language User Guide, modeling achieves four aims: 1. Models help you to visualize a 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 specify the 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.




Four Principles of Modeling

4

Four Principles of Modeling

The model you create influences how the problem is attacked.Every model may be expressed at different levels of precision.The best models are connected to reality.No single model is sufficient.

Modeling has a rich history in all the engineering disciplines.

The four basic principles of modeling are derived from this history. 1. The models you create profoundly influence how a problem is attacked and how

a solution is shaped. 2. Every model may be expressed at different levels of precision. 3. The best models are connected to reality. 4. No single model is sufficient. Every non-trivial system is best approached through

a small set of nearly independent models.




Review: Basic Principles of Object Orientation

5

Review: Basic Principles of Object Orientation

Abst

ract

ion

Hier

arch

y

Object Orientation

Enca

psul

atio

n

Mod

ular

ity

There are four basic principles of object orientation. They are:

• Abstraction • Encapsulation • Modularity • Hierarchy




Review: Example: Abstraction

6

Review: Example: Abstraction

Student Professor

Course Offering (9:00 AM, Monday-Wednesday-Friday) Course (e.g., Algebra)

The following are examples of abstraction.

• A student is a person enrolled in classes at the university. • A professor is a person teaching classes at the university. • A course is a class offered by the university. • A course offering is a specific offering for a course, including days of the week

and times.




Review: Encapsulation Illustrated

7

Review: Encapsulation Illustrated

Professor Clark needs to be able to teach four classes in the next semester.

Subm

itFina

lGra

des()

AcceptCourseOffering()

TakeSabbatical()

Professor Clark

SetMaxLoad()

Name: J ClarkEmployee ID: 567138HireDate: 07/25/1991Status: TenuredDiscipline: FinanceMaxLoad: 4SetMaxLoad(4)

• The key to encapsulation is an object’s message interface. The object interface

ensures that all communication with the object takes place through a set of predefined operations. Data inside the object is only accessible by the object’s operations. No other object can reach inside of the object and change its attribute values.

• For example, Professor Clark needs to have her maximum course load increased from three classes to four classes per semester. Another object will make a request to Professor Clark to set the maximum course load to four.The attribute, MaxLoad, is then changed by the SetMaxLoad() operation.

• Encapsulation is beneficial in this example because the requesting object does not need to know how to change the maximum course load. In the future, the number of variables that are used to define the maximum course load may be increased, but that does not affect the requesting object. The requesting object depends on the operation interface for the Professor Clark object.




Review: Example: Modularity

8

Review: Example: Modularity

For example, break complex systems into smaller modules. Billing

System

Course Registration System

Course Catalog System

Student Management System

Often, the system under development is too complex to understand. To further understanding, the system is broken into smaller blocks that are each maintained independently. Breaking down a system in this way is called modularity. It is critical for understanding a complex system.

For example, the system under development is a Course Registration system. The system itself is too large and abstract to allow an understanding of the details. Therefore, the development team broke this system into three modular systems, each independent of the others.

• The Billing System • Course Catalog System • Student Management System




Review: Example: Hierarchy

9

Review: Example: Hierarchy

Decreasing abstraction

Increasingabstraction

Asset

RealEstate

Savings

BankAccount

Checking Stock

Security

Bond

Elements at the same level of the hierarchy should be at the same level of abstraction.

Hierarchy can be defined as:

Any ranking or ordering of abstractions into a tree-like structure. Kinds: Aggregation hierarchy, class hierarchy, containment hierarchy, inheritance hierarchy, partition hierarchy, specialization hierarchy, type hierarchy. (Dictionary of Object Technology, Firesmith, Eykholt, 1995)

• Hierarchy organizes items in a particular order or rank (for example, complexity and responsibility). This organization is dependent on perspective. Using a hierarchy to describe differences or variations of a particular concept provides for more descriptive and cohesive abstractions and a better allocation of responsibility.

• In any one system, there may be multiple abstraction hierarchies (for example, a financial application may have different types of customers and accounts).

• Hierarchy is not an organizational chart or a functional decomposition. • Hierarchy is a taxonomic organization. The use of hierarchy makes it easy to

recognize similarities and differences. For example, botany organizes plants into families. Chemistry organizes elements in a periodic table.




Review: What Is an Object?

10

Review: What Is an Object?

An object is an entity with a well-defined boundary and identitythat encapsulates stateand behavior.

State is represented by attributes and relationships.Behavior is represented by operations, methods, and state machines. Object

Operations

Attributes

An object is 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.




Review: What Is a Class?

11

Review: What Is a Class?

A class is a description of a set of objects that share the same attributes, operations,relationships, and semantics.

An object is an instance of a class.A class is an abstraction in that it

Emphasizes relevant characteristics.Suppresses other characteristics.

Class

+ attribute+ operation()

A class can be defined as:

A description of a set of objects that share the same attributes, operations, relationships, and semantics. (The Unified Modeling Language User Guide, Booch, 1999)

• There are many objects identified for any domain. • Recognizing the commonalties among the objects and defining classes helps us

deal with the potential complexity. • The OO principle of abstraction helps us deal with complexity. An Attribute can be defined as:

A named property of a class that describes the range of values that instances of the property may hold. (The Unified Modeling Language User Guide, Booch, 1999.)

• A class may have any number of attributes or no attributes at all. At any time, an object of a class has specific values for every one of its class’s attributes.

An Operation can be defined as:

A service that can be requested from an object to effect behavior. An operation has a signature, which may restrict the actual parameters that are possible.

• The operations in a class describe what the class can do.




Representing Classes in the UML

12

Review: Representing Classes in the UML

A class is represented using a rectangle with compartments.

Professor J Clark

Professor- name- employeeID : UniqueID- hireDate- status- discipline- maxLoad

+ submitFinalGrade()+ acceptCourseOffering()+ setMaxLoad()+ takeSabbatical()+ teachClass()

• The UML notation for a class permits you to see an abstraction apart from any

specific programming language, which lets you emphasize the most important parts about an abstraction — its name, attributes, and operations.

• Graphically, a class is represented by a rectangle.




Review: The Relationship Between Classes and Objects

13

Review: The Relationship Between Classes and Objects

A class is an abstract definition of an object.It defines the structure and behavior of each object in the class.It serves as a template for creating objects.

Classes are not collections of objects.

Professor Meijer Professor Allen

Professor Torpie Professor

• A class is a description of a set of objects that share the same responsibilities,

relationships, operations, attributes, and semantics. • An object is defined by a class. A class defines a template for the structure and

behavior of all its objects. The objects created from a class are also called the instances of the class.

• The class is the static description; the object is a run-time instance of that class. • Since we model from real-world objects, software objects are based on the real-

world objects, but they exist only in the context of the system. • Starting with real-world objects, abstract out what you do not care about. Then,

take these abstractions and categorize, or classify them, based on what you do care about. Classes in the model are the result of this classification process.

• These classes are then used as templates within an executing software system to create software objects. These software objects represent the real-world objects we originally started with.

• Some classes/objects may be defined that do not represent real-world objects. They are there to support the design and are "software only.”




Class Relationships

14

Review: Class Relationships

“The semantic connection between classes” ~ Grady BoochClass diagrams may contain the following relationships:

AssociationAggregationCompositionGeneralizationDependencyRealization

OR

OR

OR

The next several slides will explain and define each of these relationships.




What Is Navigability?

15

What Is Navigability?

Indicates that it is possible to navigate from a associating class to the target class using the association

RegistrationController

CourseOfferingSchedule

The navigability property on a role indicates that it is possible to navigate from a associating class to the target class using the association. This may be implemented in a number of ways: by direct object references, associative arrays, hash-tables, or any other implementation technique that allows one object to reference another.

• Navigability is indicated by an open arrow placed on the target end of the association line next to the target class (the one being navigated to). The default value of the navigability property is true (associations are bi-directional by default).

• In the course registration example, the association between the Schedule and the Course Offering is navigable in both directions. That is, a Schedule must know the Course Offering assigned to the Schedule, and the Course Offering must know the Schedules it has been placed in.

• When no arrowheads are shown, the association is assumed to be navigable in both directions.

• In the case of the association between Schedule and Registration Controller, the Registration Controller must know its Schedules, but the Schedules have no knowledge of the Registration Controllers (or other classes). As a result, the navigability property of the Registration Controller end of the association is turned off.




Review: What Is an Association?

16


The semantic relationship between two or more classifiers that specifies connections among their instances

A structural relationship, specifying that objects of one thing are connected to objects of another

CourseStudent Schedule

An association can be defined as:

The semantic relationship between two or more classifiers that specifies connections among their instances. In other words, an association is a structural relationship that specifies that objects (instances of classes) are connected to other objects.

• The way that we show relationships between classes is through the use of associations. Associations are represented on class diagrams by a line connecting the associating classes. Data may flow in either direction or in both directions across a link.

• Most associations are simple. That is, they exist between exactly two classes. They are drawn as solid paths connecting pairs of class symbols. Ternary relationships are also possible.

• Sometimes, a class has an association to itself. This does not always mean that an instance of that class has an association to itself. More often, it means that one instance of the class has associations to other instances of the same class.

• This example shows that a student object is related to a schedule object. The course class demonstrates how a course object can be related to another course object.




Review: What Is Multiplicity?

17

Review: What Is Multiplicity?

Multiplicity is the number of instances one class relates to ONE instance of another class.For each association, there are two multiplicity decisions to make, one for each end of the association.

For each instance of Professor, many Course Offerings may be taught.For each instance of Course Offering, there may be either one or zero Professor as the instructor.

Professor CourseOffering0..1 0..*

+ instructor

Multiplicity can 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.

• Multiplicity must be defined on both ends of the association.




Review: Multiplicity Indicators

18

Review: Multiplicity Indicators

2..4

0..1

1..*

0..*

1

*

2, 4..6

Unspecified

Exactly One

Zero or More

Zero or One (optional scalar role)

One or More

Specified Range

Multiple, Disjoint Ranges

Zero or More

• 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.




Review: What Is Aggregation?

19


An aggregation is a special form of association that models a whole-part relationship between an aggregate (the whole) and its parts.

An aggregation is an “Is a part-of” relationship.Multiplicity is represented like other associations.

ScheduleStudent

0..11

An aggregation can be defined as:

A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts.

• Aggregation is used to model relationships between model elements. There are many examples of aggregation: a library contains books, departments are made up of employees, a computer is composed of a number of devices. To model an aggregation, the aggregate (department) has an aggregation association to the its constituent parts (employee).

• A hollow diamond is attached to the end of an association path on the side of the aggregate (the whole) to indicate aggregation.

• An aggregation relationship that has a multiplicity greater than one for the aggregate is called shared. Destroying the aggregate does not necessarily destroy the parts. By implication, a shared aggregation forms a graph or a tree with many roots. Shared aggregations are used where there is a strong relationship between two classes. Therefore, the same instance can participate in two different aggregations.




What Is Composition?

20


A composition is a stronger form of association in which the composite has sole responsibility for managing its parts – such as their allocation and deallocation.It is shown by a diamond filled adornment on the opposite end.

ScheduleStudent

0..*

1

The relationship from Student to Schedule is modeled as a composition because if you got rid of the Student, you would get rid of any Schedules for that Student. Here are some general rules for when to use composition.

Use composition when:

• Properties need independent identities • Multiple classes have the same properties • Properties have a complex structure and properties of their own • Properties have complex behavior of their own • Properties have relationships of their own Otherwise use attributes




What is a Structured Class?

21

What is a Structured Class?

A structured class contains parts or roles that form its structure and realize its behavior

Describes the internal implementation structureThe parts themselves may also be structured classes

Allows hierarchical structure to permit a clear expression of multilevel models.

A connector is used to represent an association in a particular context

Represents communications paths among parts

A role is 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.




Structured Class Notation

22

Structured Class Notation

A part or role is shown by using the symbol for a class (a rectangle) with the syntax:

rolename : Typename [ multiplicity ]All three may be omitted.

If multiplicity is omitted, it defaults to one.A reference to an external object (one not owned by the enclosing object) is shown by a dashed rectangle.

partA : CompositionPart partB : SharedPart

connector

parts




Class Diagram versus Structure Diagram

23

Class Diagram versus Structure Diagram

Schedule

Student

0..*

1

Schedule

0..*

1

Student

comp : Schedule [0..*]

shared : Schedule [0..*]

Class Diagram Structure Diagram

shared comp




Example: Structure Diagram

24

Example: Structure Diagram


: BillingSystem

: StudentManagementSystem

: CourseCatalogSystem

As the system is further decomposed, each of the parts may be a structured class which contains parts themselves. This is a very effective method to visualize the system architecture.




Review: What Is Generalization?

25

Review: What Is Generalization?

A relationship among classes where one class shares the structure and/or behavior of one or more classesDefines a hierarchy of abstractions in which a subclass inherits from one or more superclasses

Single inheritanceMultiple inheritance

Is an “is a kind of” relationship

Generalization can be defined as:

A specialization/generalization relationship in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent). (The Unified Modeling Language User Guide, Booch, 1999)

• The subclass may be used where the superclass is used, but not vice versa. • The child inherits from the parent. • Generalization is transitive. You can always test your generalization by applying

the “is a kind of” rule. You should always be able to say that your specialized class “is a kind of” the parent class.

• The terms “generalization” and “inheritance” are generally interchangeable. If you need to distinguish, generalization is the name of the relationship, while inheritance is the mechanism that the generalization relationship represents/models.

Inheritance can be defined as:

The mechanism by which more-specific elements incorporate the structure and behavior of more-general elements. (The Unified Modeling Language User Guide, Booch, 1999)

• Single inheritance: The subclass inherits from only one superclass (has only one parent).

• Multiple inheritance: The subclass inherits from more than one superclass (has multiple parents).




Relationships: Dependency

26

Relationships: Dependency

A relationship between two model elements where a change in one may cause a change in the otherNon-structural, “using” relationship

Package

Class

Dependencyrelationship

Component

Client

ClientPackage SupplierPackage

Supplier



Client SupplierThe <<use>> stereotype is implicit and does not need to be shown.

A dependency relationship is a weaker form of relationship showing a relationship between a client and a supplier where the client does not have semantic knowledge of the supplier.

A dependency relationship denotes a semantic relationship between model elements, where a change in the supplier may cause a change in the client.




Relationships: Realization

27

One classifier serves as the contract that the other classifier agrees to carry out, found between:

Interfaces and the classifiers that realize them

Use cases and the collaborations that realize them

One classifier serves as the contract that the other classifier agrees to carry out, found between:

Interfaces and the classifiers that realize them

Use cases and the collaborations that realize them

Relationships: Realization

Collaboration UseCase

Subsystem<<subsystem>>

Class

Component

<<interface>>

<<interface>>

InterfaceName<<interface>>

InterfaceName

InterfaceName

Realization is a semantic relationship between two classifiers. One classifier serves as the contract that the other classifier agrees to carry out.

The realizes relationship is a combination of a dependency and a generalization. It is not true generalization, as only the “contract” (that is to say, operation signature) is “inherited.” This “mix” is represented in its UML form, which is a combination of dependency and generalization.

The realizes relationship may be modeled as a dashed line with a hollow arrowhead pointing at the contract classifier (canonical form), or when combined with an interface, as a “ball” (elided form).

Again, from The Random House Collegiate Dictionary:

• Elide: to pass over; omit; ignore. • Canonical: authorized; recognized; accepted.




Review: What Is Polymorphism?

28


Manufacturer AManufacturer B Manufacturer C

OO Principle:Encapsulation

The ability to hide many different implementations behind a single interface

Remote Control

The Greek term polymorphos means “having many forms.” There may be one or many implementations of a given interface. Every implementation of an interface must fulfill the requirements of that interface. In some cases, the implementation can perform more than the basic interface requirements.

For example, the same remote can be used to control any type of television (implementation) that supports the specific interface that the remote was designed to be used with.




What Is an Interface?

29

What Is an Interface?

A declaration of a coherent set of public features and obligations.

A contract between providers and consumers of services. Examples of interfaces are:• Provided interface - The interfaces that the element

exposes to its environment. • Required interface - The interfaces that the element

requires from other elements in its environment in order to be able to offer its full set of provided functionality.

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.

You have probably heard that polymorphism is one of the big benefits of object orientation, but without interfaces there is no way to enforce it, verify it, or even express it except in informal or language-specific ways. Formalization of interfaces strips away the mystery of polymorphism and gives us a good way to describe, in precise terms, what polymorphism is all about. Interfaces are testable, verifiable, and precise.




Example: A Provided Interface

30

Example: A Provided Interface

Remote Sensor

Manufacturer A

RemoteSensor<<interface>>

Manufacturer B

Manufacturer C

Manufacturer A

Manufacturer B

Manufacturer C

Elided/Iconic Representation(“ball”)

Canonical (Class/Stereotype) Representation

The ball notation is best used when you only need to denote the existence of an interface. If you need to see the details of the interface (for example, the operations), then the class/stereotype representation is more appropriate.

From The Random House Collegiate Dictionary:





Example: A Required Interface

31

Example: A Required Interface

Remote Control

Remote Sensor

Remote Control Remote Sensor<<interface>>

Elided/Iconic Representation(“socket”)

Canonical (Class/Stereotype) Representation







Example: Connecting Interfaces

32

Example: Connecting Interfaces

Remote Control RemoteSensor<<interface>>

Manufacturer A

Manufacturer B

Manufacturer C

Remote Sensor

Remote Control

Manufacturer A

Manufacturer B

Manufacturer C







What is a Port?

33

What is a Port?

A port is a structural feature that encapsulates the interaction between the contents of a class and its environment.

Port behavior is specified by its provided and required interfaces

Permits the internal structure to be modified without affecting external clients

External clients have no visibility to internalsA class may have a number of ports

Each port has a set of provided and required interfaces

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

Another class connected to a port may request the provided services from the owner of the port but must also be prepared to supply the required services to the owner.




Port Notation

34

Port Notation

A port is shown as a small square with the name placed nearby.

Ports may be public, protected or private

portName




Port Types

35

Port Types

Ports can have different implementation types

Service Port - Is only used for the internal implementation of the classBehavior Port - Requests on the port are implemented directly by the classRelay Port – Requests on the port are transmitted to internal parts for implementation

The use of service ports are rare because the main purpose of ports is to encapsulate communication with the environment. These ports are located inside the class boundary.

Behavior ports are shown by a line from the port to a small state symbol (a rectangle with rounded corners). This is meant to suggest a state machine, although other forms of behavior implementation are also permitted.




Example: Structure Diagram with Ports

36

Example: Structure Diagram with Ports

Structured Class Name

partA partB

Behavior Port

Relay Port

Service Port




Review: Diagram Depiction

37

Review: Diagram Depiction

<heading>

<contents area>

Each diagram has a frame, a heading compartment in the upper left corner, and a contents area.

If the frame provides no additional value, it may be omitted and the border of the diagram area provided by the tool will be the implied frame.

A heading compartment is a string contained in a name tag (a rectangle with cutoff corner) in the upper leftmost corner with the following syntax:

[<kind>]<name>[<parameters>]

This <kind> can be:

• activity - activity diagram • package - class diagram, package diagram • communication - communication diagram • component - component diagram • class - composite structure diagram • deployment - deployment diagram • intover - interaction overview diagram • object - object diagram • state machine - state machine diagram • sd - sequence diagram • timing -timing diagram • use case - use case diagram




What Are Notes?

38

What Are Notes?

A comment that is added to include more information on the diagramMay be added to any UML elementA “dog eared” rectangle May be anchored to an element with a dashed line

MaintainScheduleFormThere can be up to one MaintainScheduleForm per user session.




Review

39

Review: Concepts of Object Orientation

What are the four basic principles of object orientation? Provide a brief description of each.What is an object and what is a class? What is the difference between the two?What is a class relationship? Give some examples.What is polymorphism? What is an interface?






► ► ► Module 3 Requirements Overview

1

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 3: Requirements Overview

Topics

What Is System Behavior?..................................................................................... 3-8 Use-Case Specifications...................................................................................... 3-14 What Is an Activity Diagram? .............................................................................. 3-17 Glossary ............................................................................................................. 3-21 Supplementary Specification .............................................................................. 3-24 Review............................................................................................................... 3-32




Objectives: Requirements Overview

2

Objectives: Requirements Overview

Describe the basic Requirements concepts and how they affect Analysis and DesignDemonstrate how to read and interpret the artifacts of Requirements that are used as a starting point for Analysis and Design

This Requirements Overview module provides an overview of the activities that immediately precede Analysis and Design. It is meant to describe the interface between the Requirements and the Analysis and Design discipline.

This Requirements Overview module will provide enough information to give you an appreciation for the Requirements discipline, and enable you to read and interpret the Requirements artifacts that serve as the starting point for the Analysis and Design activities.



Module 3 - Requirements Overview

Requirements Overview Topics

3


IntroductionKey ConceptsUse-Case ModelGlossarySupplementary SpecificationsCheckpoints

We will start with an introduction to the Requirements discipline, followed by a review of the key concepts in use-case modeling. Then we will look briefly at each of the Requirements’ artifacts and discuss how to read and interpret their contents. We will close by reviewing a series of checklists that will assist you in assessing the quality and completeness of the Requirements artifacts.




Requirements in Context

4

Requirements in Context

The purpose of Requirements is to:

• Establish and maintain agreement with the customers and other stakeholders on what the system should do.

• Give system developers a better understanding of the requirements of the system.

• Delimit the system.

• Provide a basis for planning the technical contents of the iterations.

• Provide a basis for estimating cost and time to develop the system.

• Define a user interface of the system.

The Business Modeling discipline provides organizational context for the system. This is the context in which the requirements are defined and analyzed.

The purpose of the Requirements discipline is:

• To establish and maintain agreement with the customers and other stakeholders on what the system should do.

• To provide system developers with a better understanding of the system requirements.

• To define the boundaries of (delimit) the system. • To provide a basis for planning the technical contents of iterations. • To provide a basis for estimating cost and time to develop the system. • To define a user-interface for the system, focusing on the needs and goals of the

users. The Analysis and Design discipline gets its primary input (the Use-Case Model and the Glossary) from Requirements. Flaws in the Use-Case Model can be discovered during Analysis and Design; change requests are then generated, and applied to the Use-Case Model.




Relevant Requirements Artifacts

5

Relevant Requirements Artifacts

SupplementarySpecification

Glossary

Use-Case Specifications

...

Use-Case Model

ActorsUse Cases

The Use-Case Model describes what the system will do. The Use-Case Model serves as a contract between the customer, the users, and the system developers. It allows customers and users to validate that the system will become what they expected and allows system developers to ensure that what they build is what is expected. The Use-Case Model consists of use cases and actors. Each use case in the model is described in detail, showing step-by-step how the system interacts with the actors and what the system does in the use case. The Use-Case Specification is the document where all of the use-case properties are documented (for example, brief description and use-case flows of events).

Note: The OOAD course requirements documentation includes Use-Case Specifications because it is the textual description that will drive Analysis and Design activities. (Use-case specifications only include the textual use-case properties.)

The Glossary defines a common terminology for all models and contains textual descriptions of the required system.

The Supplementary Specification contains those requirements that do not map to a specific use case (for example, nonfunctional requirements). The Supplementary Specification is an important complement to the Use-Case Model. Together they capture all requirements (functional and nonfunctional) that need to be described for a complete System Requirements Specification.




Case Study: Course Registration Problem Statement

6

Case Study: Course Registration Problem Statement

Review the problem statement provided in the Course Registration Requirements Document.

Course Registration Requirements Document

Before we discuss the details of the artifacts that drive the Analysis and Design discipline, it is important that you understand the problem domain that all of the course exercises will be based on.

With regards to the formal Requirements artifacts, the Problem Statement is part of the Vision document. The other sections have been omitted for scoping reasons. For more information on the Vision document, see the Requirements discipline of the Rational Unified Process.





7



In this section, we will discuss the key concepts of use-case modeling — the actor and the use case, as well as what relationships can exist between them. We will also look at the artifacts that make up the Use-Case Model: Use-Case Specifications, and activity diagrams.




What Is System Behavior?

8

What Is System Behavior?

System behavior is how a system acts and reacts.

It is the outwardly visible and testable activity of a system.

System behavior is captured in use cases.Use cases describe the system, its environment, and the relationship between the system and its environment.

• No system exists in isolation. Every system interacts with people or automated

systems for some purpose. These interactions result in some sort of predictable result. This predictable result is system behavior.

• Use cases are the mechanism for capturing the desired behavior for the system that is under development, but they do not specify how the behavior is to be implemented.

• The UML specifies a model for communicating system behavior — the Use-Case Model.




Major Concepts in Use-Case Modeling

9

Major Concepts in Use-Case Modeling

An actor represents anything that interacts with the system.

A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor.

Use Case

Actor

An actor represents a coherent set of roles that users of the system play when interacting with these use cases. Typically, an actor represents a human, a hardware device, or some other external system. In UML 2, actors should be named whenever possible.

A use case is a sequence of actions a system performs to yield an observable result that is of value to a particular actor. A use case describes what a system does, but it does not specify how it does it. Whenever space permits, put the name of the use case inside the icon.





10






Review: What Is a Use-Case Model?

11

Review: What Is a Use-Case Model?

A model that describes a system’s functional requirements in terms of use casesA model of the system’s intended functionality (use cases) and its environment (actors)

View Report Card

Student

Register for Courses

Login

• A Use-Case Model describes a system’s functional requirements in terms of use

cases. It is a model of the system's intended functionality and its environment. The Use-Case Model serves as a contract between the customer and the developers. Because it is a very powerful planning instrument, the Use-Case Model is generally used in all phases of the development cycle.

• When the customer approves the Use-Case Model, it’s a mutual understanding with the development team of what the customer wants. You can use the model to discuss the system with the customer during development.

• Potential users use the Use-Case Model to better understand the system. • Designers use it as a basis for their work and to get a system overview. • Testers use it to plan testing activities (use case and integration testing) as early as

possible. • Those developing the next version of the system use it to understand how the

existing version works. • Documentation writers use the use cases as a basis for writing the system user

guides. • The architect uses the Use-Case Model to identify architecturally significant

functionality. • The manager uses it to plan and follow up on use-case modeling and subsequent

design.




Review: What Are the Benefits of a Use-Case Model?

12

Review: What Are the Benefits of a Use-Case Model?

CommunicationIdentificationVerification

End User Domain Expert Users

Verification

Iden

tific

atio

n

Use Case

Communication

There are many ways to model a system, each of which may serve a different purpose. However, the most important role of a Use-Case Model is to communicate the system's behavior to the customer or end user. Consequently, the model must be easy to understand.

Communication with the end users and domain experts:

• Provides buy-in at an early stage of system development. • Ensures a mutual understanding of the requirements. Identification of system users and what the system should do:

• Establishes the requirements for the system interfaces. Verification that all requirements have been captured:

• Ensures that the development team understands the requirements. The Use-Case Model is also used to identify the actors that interact with the system. Because they represent system users, actors help delimit the system and give a clearer picture of what it is supposed to do. Use cases are developed on the basis of the actors' needs, ensuring that the system will turn out to be what the users expected.




Review: How Would You Read This Diagram?

13

Review: How Would You Read This Diagram?

View Report Card

Student


Login

Select Courses toTeach

Submit Grades

Professor

Registrar

Billing System

Maintain ProfessorInformation

Maintain StudentInformation

Close Registration

Course Catalog

Answer the following questions: 1. Which use cases can a student perform? A professor? The Course Catalog? 2. If Charlie is a student and professor, which use cases can he execute? 3. Describe the functionality of this system. 4. Describe the actor relationships for the Close Registration and Select Courses To

Teach use cases. 5. Which use case needs to run first, Register for Courses or View Report Card?





14


NameBrief descriptionFlow of EventsRelationshipsActivity diagramsUse-Case diagramsSpecial requirementsPre-conditionsPost-conditionsOther diagrams


...

Use-Case Model

Actors

Use Cases

The use case has a set of properties as shown in the graphic. The use-case properties may be documented in use-case specifications, which can include the items listed below:

• Brief description describes the role and purpose of the use case. • Flow of events are textual descriptions of what the system does with regard to

the use case. There can be multiple flows of events — for example, a basic flow and alternative flows.

• Relationships are associations. The use case can include and extend relationships that the use case participates in.

• Activity diagrams can be used to illustrate the structure of the flow of events. • Use-case diagrams can be used to show the relationships involving the use case. • Special requirements is a textual description that collects all use-case

requirements, like nonfunctional requirements, that are not considered in the Use-Case Model, yet need to be taken care of during design or implementation.

• Pre-conditions define a constraint on the system regarding when the use case may start.

• Post-conditions define a constraint on the system that applies after the use case has terminated.

• Other diagrams can be used to illustrate the use case, like hand-drawn sketches or screen captures from a user-interface prototype.




Use-Case Flow of Events

15

Use-Case Flow of Events

Has one normal, basic flowSeveral alternative flows

Regular variantsOdd casesExceptional flows for handling error situations

A use case flow of events:

• Contains the most important information derived from use-case modeling work. • Should describe the use case's flow clearly enough for an outsider to easily

understand it. • Should present what the system does, not how the system is designed to perform

the required behavior. Guidelines for the flow of events. Specify that the content must:

• Detail the flow of events. All "what“ questions should be answered. Remember that test designers will use this text to identify test cases.

• Describe how the use case starts and ends. • Describe the flow of events, not only the functionality. To reinforce this, start

every action with "When the actor. . . .” • Describe only the events that belong to the use case and not what happens in

other use cases or outside of the system. • Describe the data exchanged between the actor and the use case. • Avoid describing the details of the user interface unless they are needed to

provide an understanding the behavior of the system. • Avoid vague terminology such as "for example", "etc.," and "information."




What Is a Scenario?

16

What Is a Scenario?

A scenario is an instance of a use case.

A scenario is an instance of a use case. It is one flow through a use case.

Each use case has a web of flow of events with a scenario being an instance of a particular flow of events. The scenario may involve the basic flow and any number of alternative flows in any number of combinations.

In the example, the bold lines highlight some possible scenarios for the basic and alternative flows previously described.

How many scenarios are needed?

As many as one needs to understand the system being developed. You must elaborate the scenarios of the interesting and high-risk use cases. Scenarios can be used to understand, as well as to validate, the use-case flows of events. Some people write scenarios first and extract use cases, while others find use cases first and validate those use cases by writing scenarios.

Scenarios make excellent test cases.




What Is an Activity Diagram?

17

What Is an Activity Diagram?

An activity diagram in the Use-Case Model can be used to capture the activities in a use case.It is essentially a flow chart, showing flow of control from one activity or action to another.

Flow of Events

This use case starts when the Registrar requests that the system close registration.

1. The system checks to see if registration is in progress. If it is, then a message is displayed to the Registrar and the use case terminates. The Close Registration processing cannot be performed if registration is in progress.

2. For each course offering, the system checks if a professor has signed up to teach the course offering and at least three students have registered. If so, the system commits the course offering for each schedule that contains it.

Activity1 Activity3

Activity2

• The workflow of a use case describes what needs to be done by the system to

provide the value that the served actor is looking for. • It consists of a sequence of activities that, together, produce something for the

actor. • The workflow often consists of a basic flow and one or several alternative flows. • The structure of the workflow can be described graphically with the help of an

activity diagram.




Example: Activity Diagram

18

Example: Activity Diagram

Activity/Action

SynchronizationBar (Fork)

GuardCondition

SynchronizationBar (Join)

DecisionConcurrent

Threads

Transition

Select Course

[ add course ]

Check Schedule

Check Pre-requisites

Assign to Course

Resolve Conflicts

Update Schedule

Delete Course

[ checks completed ] [ checks failed ]

[ delete course ]

An activity diagram may include the following elements:

• Activity/Action represents the performance of a step within the workflow. • Transitions show the activity/action that follows. • Decisions evaluate conditions defined by guard conditions. These guard

conditions determine which of the alternative transitions will be made and, thus, which activities are performed. You may also use the decision icon to show where the threads merge again. Decisions and guard conditions allow you to show alternative threads in the workflow of a use case.

• Synchronization bars show parallel sub-flows. They allow you to show concurrent threads in the workflow of a use case.




Partitions

19

Partitions

Determine Need

Take Order

Setup Payment

Deliver Order

Fill Order

FulfillmentSales

An activity diagram may be partitioned using solid vertical lines.

Each partition should represent a responsibility for part of the overall workflow, carried by a part of the organization. A partition may eventually be implemented by an organization unit or a set of classes in the business object model.

The relative ordering of partitions has no semantic significance. Each action state is assigned to one partition, and activity edges may cross lanes.

This slide shows an activity diagram illustrating the workflow of a business use case that represents a (generic) sales process. In this example, the partitions represent departments in the organization.





20






Glossary

21

Glossary

Glossary

Course Registration System Glossary1. Introduction

This document is used to define terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information.

2. Definitions

The glossary contains the working definitions for the key concepts in the Course Registration System.

2.1 Course: A class offered by the university.

2.2 Course Offering: A specific delivery of the course for a specific semester – you could run the same course in parallel sessions in the semester. Includes the days of the week and times it is offered.

2.3 Course Catalog: The unabridged catalog of all courses offered by the university.

The Glossary defines important terms used in the project.

There is one Glossary for the system. This document is important to many developers, especially when they need to understand and use the terms that are specific to the project. The Glossary is used to facilitate communications between domain experts and developers.

The Glossary is developed primarily during the Inception and Elaboration phases, because it is important to agree on a common terminology early in the project. In Inception and Elaboration, it is used by domain experts (for example, business analysts) to explain all the domain-specific terminology used in their use cases. In Elaboration and Construction, developers use the Glossary to explain technical terms used in the other four models.

A system analyst is responsible for the integrity of the Glossary, ensuring that it is produced in a timely manner and is continuously kept consistent with the results of development.

The above is just a sample outline for the Glossary. Not all of these elements need to be in it. A project needs to establish the template to be used on that particular project.

Introduction: Provides a brief description of the Glossary and its purpose.

Terms: Define the term in as much detail as necessary to completely and unambiguously characterize it.




Case Study: Glossary

22

Case Study: Glossary

Review the Glossaryprovided in the Course Registration Requirements Document

Glossary

The idea is not to go over the Glossary in vivid detail, but to demonstrate how to read it, where to look for information you will need during the Analysis and Design activities, and how to detect if it is insufficient.





23






Supplementary Specification

24

Supplementary Specification

FunctionalityUsabilityReliabilityPerformanceSupportabilityDesign constraints


The nonfunctional requirements and functional requirements not captured by the use cases are included in the Supplementary Specifications. The Glossary defines a common terminology for all models. The Supplementary Specification contains those requirements that do not map to a specific use case. Functionality: List of the functional requirements that are general to many use cases. Usability: Requirements that relate to, or affect, the usability of the system. Examples include ease-of-use requirements or training requirements that specify how readily the system can be used by its actors. Reliability: Any requirements concerning the reliability of the system. Quantitative measures such as mean time between failure or defects per thousand lines of code should be stated. Performance: The performance characteristics of the system. Include specific response times. Reference related use cases by name. Supportability: Any requirements that will enhance the supportability or maintainability of the system being built. Design Constraints: Any design constraints on the system being built. Supplementary Specifications go hand-in-hand with the Use-Case Model, implying that: • They are initially considered in the Inception phase as a complement to defining

the scope of the system. • They are refined in an incremental fashion during the Elaboration and

Construction phases.




Example: Supplementary Specification

25

Example: Supplementary Specification

Review the Supplementary Specification provided in the Course Registration Requirements Document.

Course Registration Requirements Document


The idea is not to go over the Supplementary Specification in vivid detail, but to demonstrate how to read it, where to look for information you will need during the Analysis and Design activities, as well as how to detect if it is insufficient.





26






Checkpoints: Requirements: Use-Case Model

27

Checkpoints: Requirements: Use-Case Model

Is the Use-Case Model understandable?By studying the Use-Case Model, can you form a clear idea of the system's functions and how they are related? Have all functional requirements been met?Does the Use-Case Model contain any superfluous behavior?Is the division of the model into use-case packages appropriate?

...

The above, as well as the remaining checklists in this section, is a sample of the kinds of things to look for when reviewing the Use-Case Model. Explicit, detailed checklists should be established for the project to support the review of the Use-Case Model.

Verify that there are no open questions. The use cases you found must be able to perform all system behaviors; if not, some use cases are missing. If you intentionally left any requirements to be dealt with in the object models, such as nonfunctional requirements, you must mention this. Put the reference in the Supplementary Specification(s) unless the requirement concerns a specific use case, in which case state it in the Special Requirements section of the use case.

The Use-Case Model should not present more functions than were called for in the requirements.

Traceability from the original requirements to the use cases and the Supplementary Specification is critical for project management and impact assessment as well as to make sure nothing has been missed.

The packaging should make the Use-Case Model simple and intuitive to understand and maintain.




Checkpoints: Requirements: Actors

28

Checkpoints: Requirements: Actors

Have all the actors been identified? Is each actor involved with at least one use case? Is each actor really a role? Should any be merged or split?Do two actors play the same role in relation to a use case? Do the actors have intuitive and descriptive names? Can both users and customers understand the names?

Make sure that all the roles in the system's environment have been accounted for and modeled. You will not be able to do this fully until you have found and described all the use cases.

Remove any actors not mentioned in the use-case descriptions or that have no associations with a use case. However, an actor mentioned in a use-case description is likely to have a association with that particular use case.

You should be able to name at least two people who would be able to perform as a particular actor. If not, see if the role the actor models is part of another role. If so, you should merge the actors.

If any actors play similar roles in relation to the system, they should be merged into a single actor. If a particular actor will use the system in several completely different ways, or has several completely different purposes for using the use case, then there should probably be more than one actor.

If two actors play the same role in relation to a use case, then actor-generalizations should be used to model their generalized behavior.

It is important that actor names correspond to their roles.




Checkpoints: Requirements: Use-Cases

29

Checkpoints: Requirements: Use-Cases

Is each use case involved with at least one actor? Is each use case independent of the others? Do any use cases have very similar behaviors or flows of events? Do the use cases have unique, intuitive, and explanatory names so that they cannot be mixed up at a later stage? Do customers and users alike understand the names and descriptions of the use cases?

A use case that does not interact with an actor is superfluous. You should remove it.

If two use cases are always activated in the same sequence, you should probably merge them into one use case.

Use cases that have very similar behaviors or flows of events, or will be similar in the future, should be merged into a single use case. This makes it easier to introduce future changes.

Note: You must involve the users if you decide to merge use cases because the users, who interact with the new, merged use case will probably be affected.

If some part of the flow of events is already part of another use case, the sub-flow should be extracted and then be included by all of the use cases in question.

Note: You must involve the users if you decide to "reuse" the sub-flow, because the users of the existing use case will probably be affected.

Each use-case name must describe the behavior the use case supports. The names and descriptions must be understood by the users and customers.




Checkpoints: Requirements: Use-Case Specifications

30

Checkpoints: Requirements: Use-Case Specifications

Is it clear who wants to perform a use case? Is the purpose of the use case also clear? Does the brief description give a true picture of the use case? Is it clear how and when the use case's flow of events starts and ends? Does the communication sequence between actor and use case conform to the user's expectations? Are the actor interactions and exchanged information clear? Are any use cases overly complex?

Include any (nonfunctional) requirements in the use-case Special Requirements.

Behavior might exist that is activated only when a certain condition is not met. There should be a description of what will happen in such a case.

If you want your Use-Case Model to be easy to understand, you might have to split up complex use cases. A use case that contains disparate flows of events will be very difficult to understand and to maintain. It is best to divide such use cases into two or more separate ones.




Checkpoints: Requirements: Glossary

31

Checkpoints: Requirements: Glossary

Does each term have a clear and concise definition? Is each glossary term included somewhere in the use-case descriptions? Are terms used consistently in the brief descriptions of actors and use cases?

If each Glossary term is not included somewhere in the use-case descriptions, that may imply that a use case is missing or that the existing use cases are not complete. It is more likely, though, that the term is not included because it is not needed, and it should be removed from the Glossary.

A term should represent the same thing in all use-case descriptions.




Review

32

Review: Requirements Overview

What are the main artifacts of Requirements?What are the Requirements artifacts used for?What is a Use-Case Model?What is an actor?What is a use case? List examples of use case properties.What is the difference between a use case and a scenario?What is a Supplementary Specification and what does it include?What is a Glossary and what does it include?




Exercise: Payroll Requirements Document

33

Exercise: Payroll Requirements Document

Given the following Payroll Requirements artifacts:

Problem statementGlossarySupplementary Specification Use-Case Model main diagram

Review the given Requirements artifacts, noting any questions, issues, inconsistencies.

This exercise is based on the Payroll Requirements document, which is found in the Exercise Workbook. See the workbook’s table of contents for specific page numbers. These artifacts will be used as the basis for the remainder of the examples and exercises in this course, so you need to have a good foundation for moving forward. All questions, issues, etc. regarding the Requirements artifacts will be recorded and addressed here.

You will not be reviewing the use-case flow of events at this point. They will be reviewed in detail later in the course.






► ► ► Module 4 Analysis and Design Overview

1

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 4: Analysis and Design Overview

Topics

Analysis Versus Design.......................................................................................... 4-6 Analysis and Design Workflow............................................................................ 4-12 Review............................................................................................................... 4-19




Objectives: Analysis and Design Overview

2

Objectives: Analysis and Design Overview

Review the key Analysis and Design terms and conceptsIntroduce the Analysis and Design process, including roles, artifacts and workflowExplain the difference between Analysis and Design

This Analysis and Design Overview module provides an overview of the Analysis and Design Discipline. It also defines the terms that span all Analysis and Design activities.

The details of each of the Analysis and Design activities will be described in subsequent modules. This module is meant to provide context for these detailed Analysis and Design activity modules.



Module 4 - Analysis and Design Overview

Analysis and Design in Context

3

Analysis and Design in Context

The purposes of Analysis and Design are to:

• Transform the requirements into a design of the system-to-be.

• Evolve a robust architecture for the system.

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

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. • The Management Discipline plans the project and each iteration (described in an

Iteration Plan).




Analysis and Design Overview

4


Use-Case ModelDesign Model

Data Model

ArchitectureDocument

Analysis and Design

Analysis and Design Overview

Glossary

The input artifacts are the Use-Case Model, Glossary, and Supplementary Specification from the Requirements Discipline. The result of Analysis and Design is a Design Model that serves as an abstraction of the source code; that is, the Design Model acts as a blueprint of how the source code is structured and written. The Design Model consists of design classes structured into design packages; it also contains descriptions of how objects of these design classes collaborate to perform use cases (use-case realizations).

The design activities are centered around the notion of architecture. The production and validation of this architecture is the main focus of early design iterations. Architecture is represented by a number of architectural views that capture the major structural design decisions. In essence, architectural views are abstractions or simplifications of the entire design, in which important characteristics are made more visible by leaving details aside. The architecture is an important vehicle not only for developing a good Design Model, but also for increasing the quality of any model built during system development. The architecture is documented in the Architecture Document.

The development of the Architecture Document is out of the scope of this course, but we will discuss it is contents and how to interpret them.




Analysis & Design Overview Topics

5


Key ConceptsAnalysis and Design Workflow

We will start out by defining some key terms and concepts needed to describe the Analysis and Design workflow. These terms will be explained in more detail, along with other important terms and concepts in later modules of the course.

Once we have a common vocabulary, then we will walk through the Analysis and Design workflow.




Analysis Versus Design

6

Analysis Versus Design

Focus on understanding the solution Operations and attributesPerformanceClose to real code Object lifecyclesNonfunctional requirementsA large model

Focus on understanding the problemIdealized designBehaviorSystem structureFunctional requirementsA small model

DesignAnalysis

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 (Design). The real power of software design is that it can create more powerful metaphors for the real world that change the nature of the problem, making it easier to solve.




Analysis and Design Are Not Top-Down or Bottom-Up

7

Design Classes

Subsystems

Use Cases

Analysis and Design Are Not Top-Down or Bottom-Up

Analysis Classes

BottomUp

TopDown

(Define a middle level)

Analysis and Design

The Analysis and Design Discipline is not top-down or bottom-up.

The use case comes in from the left and defines a middle level.

The analysis classes are not defined in a top-down pattern or a bottom-up pattern; they are in the middle. From this middle level one may move up or down.

Defining subsystems is moving up and defining design classes is moving down.

Analysis is both top-to-middle, middle-up, middle-down and bottom-to-middle. There is no way of saying that one path is more important than another — you have to travel on all paths to get the system right.

All of these four paths are equally important. That is why the bottom-up and top-down question cannot be solved.




What Is Architecture?

8

What Is Architecture?

Software architecture encompasses a set of significant decisions about the organization of a software system.

Selection of the structural elements and their interfaces by which a system is composedBehavior as specified in collaborations among those elementsComposition of these structural and behavioral elements into larger subsystemsArchitectural style that guides this organization

Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational(derived from Mary Shaw)

Based on extensive research, Rational has established a definition of architecture.

“Significant” in this context implies strategic, of major impact.

The architecture has a static and a dynamic perspective.

The architecture for similar systems should be similar (a particular style is used).

An equation we have used is:

Architecture = Elements + Form + Rationale.

Rationale is essential for justifying a good architecture.

Patterns are the guidelines for assembling elements in some form. We will discuss patterns in the architecture modules.




Architecture Constrains Design and Implementation

9

Architecture Constrains Design and Implementation

Architecture involves a set of strategic design decisions, rules or patterns that constrain design and construction.

Architecture decisions are the most fundamental decisions, and changing them will have significant effects.

ArchitectureDesign

ImplementationCode

Architectures can be viewed as a set of key design decisions.

The architecture is the initial set of constraints placed on the system. Such constraints are the the most important ones. They constitute the fundamental decisions about the software design. Architecture puts a framework around the design. Architecture has been called strategic design.

An architect’s job is to eliminate unnecessary creativity as the design has to fit into the architectural framework. As you move closer to code, creativity is focused. (The architecture frames the design which frames the implementation.) This is good because during Implementation, the creativity can be spent elsewhere (for example, for improving the quality, and performance) of the implementation (for example, code).




Software Architecture: The “4+1 View” Model

10

Software Architecture: The “4+1 View” Model

Process View Deployment View

Logical View

Use-Case View

Implementation View

End-userFunctionality

ProgrammersSoftware management

Performance, scalability, throughputSystem integrators System topology, delivery,

installation, communication

System engineering

Analysts/DesignersStructure

The above diagram shows the model Rational uses to describe the software architecture.

Architecture is many things to many different interested parties. On a particular project, there are usually multiple stakeholders, each with their own concerns and view of the system to be developed. The goal is to provide each of these stakeholders with a view of the system that addresses their concerns, and suppresses the other details.

To address these different needs, Rational has defined the “4+1 view” architecture model. An architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns, and omitting entities that are not relevant to this perspective. Views are “slices” of models.

Not all systems require all views (for example, single processor: drop Deployment View; single process: drop Process View; small program: drop Implementation View, and so forth). A project may document all of these views or additional views. The number of views is dependent on the system you are building.

Each of these views, and the UML notation used to represent them, will be discussed in subsequent modules.





11


Key ConceptsAnalysis and Design Workflow

Because we have a common vocabulary, we can now briefly discuss the activities of Analysis and Design and how they work together.




Analysis and Design Workflow

12

Analysis and Design Workflow

Analysis

Design

[Early Elaboration Iteration]

[Inception Iteration (Optional)]

Define a CandidateArchitecture

PerformArchitectural

Synthesis

Analyze Behavior

Refine theArchitecture

DesignComponents

Design theDatabase

(Optional)

A mere enumeration of all workers, activities, and artifacts does not constitute a process. We need a way to describe the activities, some valuable result, and interactions between workers. A workflow is a sequence of activities that produces a result of observable value.

In UML terms, a workflow can be expressed as a sequence diagram, a collaboration diagram, or an activity diagram. We use a form of activity diagram in the Rational Unified Process. For each core workflow, an activity diagram is presented. This diagram shows the workflow, expressed in terms of workflow details.

This slide shows the Analysis and Design workflow. The early Elaboration Phase focuses on creating an initial architecture for the system (Define a Candidate Architecture) to provide a starting point for the main analysis work. If the architecture already exists (because it was produced in previous iterations, or projects, or is obtained from an application framework), the focus of the work changes to refining the architecture (Refine the Architecture) analyzing behavior, and creating an initial set of elements that provide the appropriate behavior (Analyze Behavior).

After the initial elements are identified, they are further refined. Design Components produce a set of components that provide the appropriate behavior to satisfy the requirements on the system. In parallel with these activities, persistence issues are handled in Design the Database. The result is an initial set of components that are further refined in the Implementation Discipline.




Analysis and Design Activity Overview

13

Analysis and Design Activity Overview

Architect

Designer

Remember, for Analysis and Design, we start out with the Use-Case Model and the supplementary specifications from the Requirements Discipline and end up with the Design Model that serves as an abstraction of the source code.

The design activities are centered around the notion of architecture. The production and validation of this architecture are the main focal points of early design iterations. The architecture is an important vehicle not only for developing a good Design Model, but also for increasing the quality of any model built during system development.

The focus of this course is on the activities of the designer. The architect activities are discussed, but many of the architectural decisions will be given. Many of the architect and designer activities will be addressed in individual course modules.




Software Architect’s Responsibilities

14

Software Architect’s Responsibilities

Architect

Software ArchitectureDocument

The Software Architect leads and coordinates technical activities and artifacts.

Reference Architecture

Analysis Model

Design Model

Deployment ModelImplementation Model

The software architect role leads and coordinates technical activities and artifacts throughout the project. The software architect establishes the overall structure for each architectural view: the decomposition of the view, the grouping of elements, and the interfaces between these major groupings. Therefore, in contrast to the other roles, the software architect's view is one of breadth as opposed to one of depth.

In summary, the software architect must be well-rounded and possess maturity, vision, and a depth of experience that allows for grasping issues quickly and making educated, critical judgment in the absence of complete information. More specifically, the software architect, or members of the architecture team, must combine these skills: • Experience in both the problem domain, through a thorough understanding of the

requirements, and the software engineering domain. If there is a team, these qualities can be spread among the team members, but at least one software architect must provide the global vision for the project.

• Leadership in order to drive the technical effort across the various teams, and to make critical decisions under pressure and make those decisions stick. To be effective, the software architect and the project manager must work closely together, with the software architect leading the technical issues and the project manager leading the administrative issues. The software architect must have the authority to make technical decisions.

• Communication to earn trust, to persuade, to motivate, and to mentor. The software architect cannot lead by decree — only by the consent of the rest of the project. In order to be effective, the software architect must earn the respect of the project team, the project manager, the customer, and the user community, as well as the management team.

• Goal orientation and being proactive with a relentless focus on results. The software architect is the technical driving force behind the project, not a visionary or dreamer. The career of a successful software architect is a long series of sub-optimal decisions made in uncertainty and under pressure. Only those who can focus on doing what needs to be done are successful in this environment of the project.




Designer’s Responsibilities

15

Designer’s Responsibilities

DesignerUse-Case Realization

Package Class/Subsystems

The designer must know use-case modeling techniques, system requirements, and software design techniques.

The designer role defines the responsibilities, operations, attributes, and relationships of one or several classes, and determines how they are adjusted to the implementation environment. In addition, the designer role may have responsibility for one or more classes, including analysis, design, subsystems, or testability.

The designer must have a solid working knowledge of:

• Use-case modeling techniques • System requirements • Software design techniques, including object-oriented Analysis and Design

techniques, and the Unified Modeling Language • Technologies with which the system will be implemented In addition, the designer must:

• Understand the architecture of the system, as represented in the Software Architecture Document.




Review: Analysis and Design Is Use-Case Driven

16

Review: Analysis and Design Is Use-Case Driven

Use cases defined for a system are the basis for the entire development process.Benefits of use cases:

Concise, simple, and understandable by a wide range of stakeholders.Help synchronize the content of different models.

Withdraw Money

Check Balance

Customer

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.




What Is a Use-Case Realization?

17

What Is a Use-Case Realization?

Class DiagramsUse Case

Communication Diagrams

Use-Case Model Design Model

Use Case Use-Case Realization

Sequence Diagrams

A use-case realization describes how a particular use case is realized within the Design Model, 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 ellipsis 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 collaboration (the classes/objects that implement the use case and their relationships — class diagrams), and the interactions of the collaborations (how these classes/objects interact to perform the use cases — communication and sequence diagrams).

The number and types of the diagrams that are used depend on what is needed to provide a complete picture of the collaboration and the guidelines developed for the project under development.




Analysis and Design in an Iterative Process

18

Analysis and Design in an Iterative Process

Iteration n Iteration n + 1

Use Case AScenarios 1 & 2

Use-Case Realization A

Start of iteration

End of iteration

Use Case B Scenario 1

Use-Case Realization A

Use Case AScenario 3

Use-Case Realization B

This course assumes the developer is using an iterative process. Remember, each pass through the sequence of process workflows is called an iteration. Thus, from a development perspective, the software lifecycle is a succession of iterations, through which the software develops incrementally.

During the Analysis and Design workflow in an iteration a use case will serve as the primary input artifact. By going through the a series of activities defined in the Analysis and Design workflow, the development team will create an associated use-case realization that describes how a particular use case will be realized.




Review

19

Review: Analysis and Design Overview

What is the purpose of the Analysis and Design Discipline?What are the input and output artifacts?Name and briefly describe the 4+1 Views of Architecture.What is the difference between Analysis and Design?What is architecture?






► ► ► Module 5 Architectural Analysis

1

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 5: Architectural Analysis

Topics

Architectural Analysis Overview............................................................................ 5-4 Package Relationships: Dependency..................................................................... 5-8 Patterns and Frameworks.................................................................................... 5-11 What Are Stereotypes? ....................................................................................... 5-18 Architectural Mechanisms: Three Categories....................................................... 5-22 What Are Key Abstractions?................................................................................ 5-30 The Value of Use-Case Realizations .................................................................... 5-35 Review............................................................................................................... 5-39




Objectives: Architectural Analysis

2

Objectives: Architectural Analysis

Explain the purpose of Architectural Analysis and where it is performed in the lifecycle.Describe a representative architectural pattern and set of analysis mechanisms, and how they affect the architecture.Describe the rationale and considerations that support the architectural decisions.Show how to read and interpret the results of Architectural Analysis:

Architectural layers and their relationshipsKey abstractionsAnalysis mechanisms

A focus on software architecture allows you to articulate the structure of the software system (the packages/components), and the ways in which they integrate (the fundamental mechanisms and patterns by which they interact).

Architectural Analysis is where we make an initial attempt at defining the pieces/parts of the system and their relationships, organizing these pieces/parts into well-defined layers with explicit dependencies, concentrating on the upper layers of the system. This will be refined, and the lower layers will be defined during Incorporate Existing Design Elements.



Module 5 - Architectural Analysis

Architectural Analysis in Context

3

Architectural Analysis in Context[Early

ElaborationIteration]

[InceptionIteration (Optional)]



Synthesis

Analyze Behavior


DesignComponents

Design theDatabase

(Optional)

ArchitectureAnalysis Architect

As you may recall, the above diagram illustrates the workflow that we are using in this course. It is a tailored version of the Analysis and Design core workflow of the Rational Unified Process. Architectural Analysis is an activity in the Define a Candidate Architecture workflow detail.

Architectural Analysis is how the project team (or the architect) decides to define the project’s high-level architecture. It is focused mostly on bounding the analysis effort in terms of agreed-upon architectural patterns and idioms, so that the “analysis” work is not working so much from “first principles.” Architectural Analysis is very much a configuring of Use-Case Analysis.

During Architectural Analysis, we concentrate on the upper layers of the system, making an initial attempt at defining the pieces/parts of the system and their relationships and organizing these pieces/parts into well-defined layers with explicit dependencies.

In Use-Case Analysis, we will expand on this architecture by identifying analysis classes from the requirements. Then, in Incorporate Existing Design Elements, the initial architecture is refined, and the lower architecture layers are defined, taking into account the implementation environment and any other implementation constraints.

Architectural Analysis is usually done once per project, early in the Elaboration phase. The activity is performed by the software architect or architecture team.

This activity can be skipped if the architectural risk is low.




Architectural Analysis Overview

4

Architectural Analysis Overview


Glossary

Use-Case Model

ArchitecturalAnalysis

Design Model

Reference Architecture

Deployment Model

VisionDocument

Software Architecture Doc

Project-SpecificGuidelines

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 • Deployment Model




Architectural Analysis Steps

5


Key ConceptsDefine the High-Level Organization of the modelIdentify Analysis mechanismsIdentify Key AbstractionsCreate Use-Case RealizationsCheckpoints

The above are the topics we will be discussing within the Architectural Analysis module. Unlike the designer activity modules, you will not be discussing each step of the activity, as the objective of this module is to understand the important Architectural Analysis concepts, not to learn HOW to create an architecture.

Before you discuss Architectural Analysis in any detail, it is important to review/define some key concepts.




Review: What Is Architecture: The “4+1 View” Model

6

Review: What Is Architecture: The “4+1 View” Model


Logical View

Use-Case View

Implementation View





System engineering


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.




Review: What Is a Package?

7

A package is a general-purpose mechanism for organizing elements into groups.It is a model element that can contain other model elements.

A package can be usedTo organize the model under development.As a unit of configuration management.

Review: What Is a Package?

University Artifacts

Packages were first introduced in the Essentials of Visual Modeling course: Concepts of Object Orientation. The slide is repeated here for review purposes.

Packages can be used to group any model elements. However, in this module, we will be concentrating on how they are used within the Design Model.




Package Relationships: Dependency

8

Packages can be related to one another using a dependency relationship.

Dependency Implications• Changes to the Supplier package may affect the

Client package.• The Client package cannot be reused independently

because it depends on the Supplier package.

Package Relationships: Dependency

Client Package Supplier Package

Dependency relationship

Elements in one package can import elements from another package. In the UML, this is represented as a dependency relationship.

The relationships of the packages reflect the allowable relationships between the contained classes. A dependency relationship between packages indicates that the contents of the supplier packages may be referenced by the client. In the above example, if a dependency relationship exists between the Client package and the Supplier package, then classes in the Client package may access classes in the Supplier package.

Some of the implications of package dependency are:

• Whenever a change is made to the Supplier package, the Client package potentially needs to be recompiled and re-tested.

• The Client package cannot be reused independently because it depends on the Supplier package.

The grouping of classes into logical sets and the modeling of their relationships can occur anywhere in the process when a set of cohesive classes is identified.




Avoiding Circular Dependencies

9

C

A

B

Hierarchy should be acyclic

A

B

C

A'

Circular dependencies make it impossible to reuse one package without the other.

Avoiding Circular Dependencies

A

B

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.

Circular dependencies may be able to be broken by splitting one of the packages into two smaller ones. In the above example, the elements in package A that were needed by the other packages were factored out into their own package, A’, and the appropriate dependencies were added.





10



Early in the software development lifecycle, it is important to define the modeling conventions that everyone on the project should use. The modeling conventions ensure that the representation of the architecture and design are consistent across teams and iterations.




Patterns and Frameworks

11

Patterns and Frameworks

PatternProvides a common solution to a common problem in a context

Analysis/Design patternProvides a solution to a narrowly-scoped technical problemProvides a fragment of a solution, or a piece of the puzzle

FrameworkDefines the general approach to solving the problemProvides a skeletal solution, whose details may be Analysis/Design patterns

The selection of the upper-level layers may be affected by the choice of an architectural pattern or framework. Thus, it is important to define what these terms mean.

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

Frameworks differ 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, and that may 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 may provide communication mechanisms, distribution mechanisms, error processing capabilities, transaction support, and so forth.

Frameworks may range in scope from persistence frameworks that describe the workings of a fairly complex but fragmentary part of an application to domain-specific frameworks that are intended to be customized (such as Peoplesoft, SanFransisco, Infinity, and SAP). For example, SAP is a framework for manufacturing and finance.




What Is a Design Pattern?

12

Structural Aspect Behavioral Aspect

What Is a Design Pattern?A design pattern is a solution to a common design problem.

Describes a common design problemDescribes the solution to the problemDiscusses the results and trade-offs of applying the pattern

Design patterns provide the capability to reuse successful designs.

ParameterizedCollaboration

Pattern Name

TemplateParameters

We will look at a number of design patterns throughout this course. Thus, it is important to define what a design pattern is up front.

Design patterns are being collected and cataloged in a number of publications and mediums. You can use design patterns to solve issues in your design without “reinventing the wheel.” You can also use design patterns to validate and verify your current approaches.

Using design patterns can lead to more maintainable systems and increased productivity. They provide excellent examples of good design heuristics and design vocabulary. In order to use design patterns effectively, you should become familiar with some common design patterns and the issues that they mitigate.

A design pattern is modeled in the UML as a parameterized collaboration. Thus it has a structural aspect and a behavioral aspect. The structural part is the classes whose instances implement the pattern, and their relationships (the static view).The behavioral aspect describes how the instance collaborate — usually by sending messages to each other — to implement the pattern (the dynamic view).

A parameterized collaboration is a template for a collaboration. The Template Parameters are used to adapt the collaboration for a specific usage. These parameters may be bound to different sets of abstractions, depending on how they are applied in the design.




What Is an Architectural Pattern?

13

What Is an Architectural Pattern?

An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them – Buschman et al, “Pattern-Oriented Software Architecture — A System of Patterns”

LayersModel-view-controller (M-V-C)Pipes and filtersBlackboard

Architectural Analysis is where you consider architectural patterns, as this choice affects the high-level organization of your object model.

Layers: The layers pattern is where an application is decomposed into different levels of abstraction. The layers range from application-specific layers at the top to implementation/technology-specific layers on the bottom.

Model-View-Controller: The MVC pattern is where an application is divided into three partitions: The Model, which is the business rules and underlying data, the View, which is how information is displayed to the user, and the Controllers, which process the user input.

Pipes and Filters: In the Pipes and Filters pattern, data is processed in streams that flow through pipes from filter to filter. Each filter is a processing step.

Blackboard: The Blackboard pattern is where independent, specialized applications collaborate to derive a solution, working on a common data structure.

Architectural patterns can work together. (That is, more than one architectural pattern can be present in any one software architecture.)

The architectural patterns listed above imply certain system characteristics, performance characteristics, and process and distribution architectures. Each solves certain problems but also poses unique challenges. For this course, you will concentrate on the Layers architectural pattern.




Typical Layering Approach

14

Typical Layering Approach

General functionality

Specific functionality Distinct application subsystems that make

up an application — contains the value adding software developed by the organization.

Business specific — contains a number of reusable subsystems specific to the type of business.

Middleware — offers subsystems for utility classes and platform-independent services for distributed object computing in heterogeneous environments and so on.

System software — contains the software for the actual infrastructure such as operating systems, interfaces to specific hardware, device drivers, and so on.

Application

Business-Specific

Middleware

System Software

Layering represents an ordered grouping of functionality, with the application-specific functions located in the upper layers, functionality that spans application domains in the middle layers, and functionality specific to the deployment environment at the lower layers.

The number and composition of layers is dependent upon the complexity of both the problem domain and the solution space: • There is generally only a single application-specific layer. • In domains with existing systems, or that have large systems composed of inter-

operating smaller systems, the Business-Specific layer is likely to partially exist and may be structured into several layers for clarity.

• Solution spaces, which are well-supported by middleware products and in which complex system software plays a greater role, have well-developed lower layers, with perhaps several layers of middleware and system software.

This slide shows a sample architecture with four layers:

• The top layer, Application layer, contains the application-specific services. • The next layer, Business-Specific layer, contains business-specific components

used in several applications. • The Middleware layer contains components such as GUI-builders, interfaces to

database management systems, platform-independent operating system services, and OLE-components such as spreadsheets and diagram editors.

• The bottom layer, System Software layer, contains components such as operating systems, databases, interfaces to specific hardware, and so on.




Example: Layers

15

Example: Layers

Application

Presentation

Session

Transport

Network

Data Link

Physical

Layer 7

Layer 6

Layer 5

Layer 4

Layer 3

Layer 2

Layer 1

Provides miscellaneous protocols for common activities

Structure information and attaches semantics

Provides dialog control and synchronization facilities

Breaks messages into packets and guarantees delivery

Selects a route from send to receiver

Detects and corrects errors in bit sequences

Transmits bits: velocity, bit-code, connection, etc.

Context A large system that requires decomposition. Problem A system that must handle issues at different levels of abstraction; for example: hardware control issues, common services issues, and domain-specific issues. It would be extremely undesirable to write vertical components that handle issues at all levels. The same issue would have to be handled (possibly inconsistently) multiple times in different components. Forces • Parts of the system should be replaceable. • Changes in components should not ripple. • Similar responsibilities should be grouped together. • Size of components — complex components may have to be decomposed. Solution Structure the systems into groups of components that form layers on top of each other. Make upper layers use services of the layers below only (never above). Try not to use services other than those of the layer directly below. (Do not skip layers unless intermediate layers would only add pass-through components.) A strict layered architecture states that design elements (classes, components, packages, and subsystems) only utilize the services of the layer below them. Services can include event-handling, error-handling, database access, and so forth. It contains more palpable mechanisms, as opposed to the raw operating system level calls documented in the bottom layer.




Layering Considerations

16


Level of abstractionGroup elements at the same level of abstraction

Separation of concernsGroup like things togetherSeparate disparate thingsApplication vs. domain model elements

Resiliency Loose couplingConcentrate on encapsulating changeUser interface, business rules, and retained data tend to have a high potential for change

Layers are used to encapsulate conceptual boundaries between different kinds of services and provide useful abstractions that make the design easier to understand.

When layering, concentrate on grouping things that are similar together, as well as encapsulating change.

There is generally only a single application layer. On the other hand, the number of domain layers is dependent upon the complexity of both the problem and the solution spaces.

When a domain has existing systems, complex systems composed of inter-operating systems, and/or systems where there is a strong need to share information between design teams, the Business-Specific layer may be structured into several layers for clarity.

In Architectural Analysis, we are concentrating on the upper-level layers (the Application and Business-Specific layers). The lower level layers (infrastructure and vendor-specific layers) will be defined in Incorporate Existing Design Elements.




Modeling Architectural Layers

17

Modeling Architectural Layers

Architectural layers can be modeled using stereotyped packages.<<layer>> stereotype

Package Name<<layer>>

Layers can be represented as packages with the <<layer>> stereotype. The layer descriptions can be included in the documentation field of the specification of the package.




What Are Stereotypes?

18

Class<<stereotypename>>

What Are Stereotypes?

Stereotypes define a new model element in terms of another model element.Sometimes you need to introduce new things that speak the language of your domain and look like primitive building blocks.

Stereotype

A stereotype can be defined as:

An extension of the basic UML notation that allows you to define a new modeling element based on an existing modeling element.

• The new element may contain additional semantics but still applies in all cases where the original element is used. In this way, the number of unique UML symbols is reduced, simplifying the overall notation.

• The name of a stereotype is shown in guillemets (<< >>). • A unique icon may be defined for the stereotype, and the new element may be

modeled using the defined icon or the original icon with the stereotype name displayed, or both.

• Stereotypes can be applied to all modeling elements, including classes, relationships, components, and so on.

• Each UML element can only have one stereotype. • Stereotype uses include modifying code generation behavior and using a

different or domain-specific icon or color where an extension is needed or helpful to make a model more clear or useful.




Example: High-Level Organization of the Model

19

Example: High-Level Organization of the Model

Application<<layer>>

Business Services <<layer>>

The above example includes the Application and Business-Specific layers for the Course Registration System.

The Application layer contains the design elements that are specific to the Course Registration application.

We expect that multiple applications will share some key abstractions and common services. These have been encapsulated in the Business Services layer, which is accessible to the Application layer. The Business Services layer contains business-specific elements that are used in several applications, not necessarily just this one.





20



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 specification of relatively complex behavior that is needed to support the functionality but which is not central to it.




What Are Architectural Mechanisms?

21

Architect


Use-Case Model

MechanismsCOTS ProductsDatabasesIPC Technology, etc.

“realized by client classes using”

“responsible for”

“constrained by”

Required Functionality

Implementation Environment

What Are Architectural Mechanisms?

In order to better understand what an analysis mechanism is, we have to understand what an architectural mechanism is.

An architectural mechanism is a strategic decision regarding common standards, policies, and practices. It is the realization of topics that should be standardized on a project. Everyone on the project should utilize these concepts in the same way, and reuse the same mechanisms to perform the operations.

An architectural mechanism represents a common solution to a frequently encountered problem. It may be patterns of structure, patterns of behavior, or both. Architectural mechanisms are an important part of the "glue" between the required functionality of the system and how this functionality is realized, given the constraints of the implementation environment.

Support for architectural mechanisms needs to be built in to the architecture. Architectural mechanisms are coordinated by the architect. The architect chooses the mechanisms, validates them by building or integrating them, verifies that they do the job, and then consistently imposes them upon the rest of the design of the system.




Architectural Mechanisms: Three Categories

22

Architectural Mechanisms: Three Categories

Architectural Mechanism CategoriesAnalysis mechanisms (conceptual)Design mechanisms (concrete)Implementation mechanisms (actual)

There are three categories of architectural mechanisms. The only difference between them is one of refinement.

Analysis mechanisms capture the key aspects of a solution in a way that is implementation-independent. They either provide specific behaviors to a domain-related class or component, or correspond to the implementation of cooperation between classes and/or components. They may be implemented as a framework. Examples include mechanisms to handle persistence, inter-process communication, error or fault handling, notification, and messaging, to name a few.

Design mechanisms are more concrete. They assume some details of the implementation environment, but are not tied to a specific implementation (as is an implementation mechanism).

Implementation mechanisms specify the exact implementation of the mechanism. Implementation mechanisms are are bound to a certain technology, implementation language, vendor, or other factor.

In a design mechanism, some specific technology is chosen (for example, RDBMS vs. ODBMS), whereas in an implementation mechanism, a VERY specific technology is chosen (for example, Oracle vs. SYBASE).

The overall strategy for the implementation of analysis mechanisms must be built into the architecture. This will be discussed in more detail in Identify Design mechanisms, when design and implementation mechanisms are discussed.




Why Use Analysis Mechanisms?

23

Why Use Analysis Mechanisms?

Oh no! I found a group of classes that has persistent data. How am I supposed to design these things if I don’t even know what database we are going to be using?

That is why we have a persistence analysis mechanism. We don’t know enough yet, so we can bookmark it and come back to it later.

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.

An analysis mechanism represents a pattern that constitutes a common solution to a common problem. These mechanisms may show patterns of structure, patterns of behavior, or both. They are used during analysis to reduce the complexity of the analysis, and to improve its consistency by providing designers with a shorthand representation for complex behavior. Analysis mechanisms are primarily used as “placeholders” for complex technology in the middle and lower layers of the architecture. When mechanisms are used as “placeholders” in the architecture, the architecting effort is less likely to become distracted by the details of mechanism behavior.

Mechanisms allow the analysis effort to focus on translating the functional requirements into software concepts without bogging down in the specification of relatively complex behavior needed to support the functionality but which is not central to it. Analysis mechanisms often result from the instantiation of one or more architectural or analysis patterns.

Persistence provides an example of analysis mechanisms. A persistent object is one that logically exists beyond the scope of the program that created it. The need to have object lifetimes that span use cases, process lifetimes, or system shutdown and startup, defines the need for object persistence. Persistence is a particularly complex mechanism. During analysis we do not want to be distracted by the details of how we are going to achieve persistence. This gives rise to a “persistence” analysis mechanism that allows us to speak of persistent objects and capture the requirements we will have on the persistence mechanism without worrying about what exactly the persistence mechanism will do or how it will work. Analysis mechanisms are typically, but not necessarily, unrelated to the problem domain, but instead are "computer science" concepts. As a result, they typically occupy the middle and lower layers of the architecture. They provide specific behaviors to a domain-related class or component, or correspond to the implementation of cooperation between classes and/or components.




Sample Analysis Mechanisms

24

Sample Analysis Mechanisms

PersistencyCommunication (IPC and RPC)Message routing DistributionTransaction management Process control and synchronization (resource contention)Information exchange, format conversionSecurity Error detection / handling / reportingRedundancy Legacy Interface

Analysis mechanisms either provide specific behaviors to a domain-related class or component, or they correspond to the implementation of cooperation between classes and/or components.

Some examples of analysis mechanisms are listed on this slide. This list is not meant to be exhaustive.

Examples of communication mechanisms include inter-process communication (IPC) and inter-node communication (a.k.a. remote process communication or RPC). RPC has both a communication and a distribution aspect.

Mechanisms are perhaps easier to discuss when one talks about them as “patterns” that are applied to the problem. So the inter-process communication pattern (that is, “the application is partitioned into a number of communicating processes”) interacts with the distribution pattern (that is, “the application is distributed across a number of nodes”) to produce the RPC pattern (that is, “the application is partitioned into a number of processes, which are distributed across a number of nodes”). This process provides us a way to implement remote IPC.




Examples of Analysis Mechanism Characteristics

25

Examples of Analysis Mechanism Characteristics

Persistency mechanismGranularityVolumeDurationAccess mechanismAccess frequency (creation/deletion, update, read)Reliability

Inter-process Communication mechanismLatencySynchronicityMessage sizeProtocol

Analysis mechanism characteristics capture some nonfunctional requirements of the system.

Persistency: For all classes whose instances may become persistent, we need to identify:

• Granularity: Range of size of the persistent objects • Volume: Number of objects to keep persistent • Duration: How long to keep persistent objects • Access mechanism: How is a given object uniquely identified and retrieved? • Access frequency: Are the objects more or less constant; are they permanently

updated? • Reliability: Shall the objects survive a crash of the process, the processor; the

whole system? Inter-process Communication: For all model elements that need to communicate with objects, components, or services executing in other processes or threads, we need to identify: • Latency: How fast must processes communicate with another? • Synchronicity: Asynchronous communication • Size of message: A spectrum might be more appropriate than a single number. • Protocol, flow control, buffering, and so on.




Example: Analysis Mechanism Characteristics (continued)

26

Example: Analysis Mechanism Characteristics (continued)

Legacy interface mechanismLatencyDurationAccess mechanismAccess frequency

Security mechanismData granularityUser granularity Security rulesPrivilege types

Others

Security:

• Data granularity: Package-level, class-level, attribute level • User granularity: Single users, roles/groups • Security Rules: Based on value of data, on algorithm based on data, and on

algorithm based on user and data • Privilege Types: Read, write, create, delete, perform some other operation




Describing Analysis Mechanisms

27

Collect all analysis mechanisms in a listDraw a map of classes to analysis mechanismsIdentify characteristics of analysis mechanismsModel using collaborations


Classes

Parsing

Authentication

Communication

Persistency

Analysis Mechanisms

Flight

Aircraft

Mission

Schedule

Route

Load

The process for describing analysis mechanisms is: 1. Collect all analysis mechanisms in a list. The same analysis mechanism may

appear under several different names across different use-case realizations, or across different designers. For example, storage, persistency, database, and repository might all refer to a persistency mechanism. Inter-process communication, message passing, or remote invocation might all refer to an inter-process communication mechanism.

2. Draw a map of the client classes to the analysis mechanisms (see graphic on slide).

3. Identify Characteristics of the analysis mechanisms. To discriminate across a range of potential designs, identify the key characteristics used to qualify each analysis mechanism. These characteristics are part functionality, part size, and performance.

4. Model Using Collaborations. Once all of the analysis mechanisms are identified and named, they should be modeled through the collaboration of a “society of classes.” Some of these classes do not directly deliver application functionality, but exist only to support it. Very often, these “support classes” are located in the middle or lower layers of a layered architecture, thus providing a common support service to all application-level classes.




Example: Course Registration Analysis Mechanisms

28

Example: Course Registration Analysis Mechanisms

Security Legacy Interface

Persistence Distribution

The above are the selected analysis mechanisms for the Course Registration System.

Persistency: A means to make an element persistent (that is, exist after the application that created it ceases to exist).

Distribution: A means to distribute an element across existing nodes of the system.

Security: A means to control access to an element.

Legacy Interface: A means to access a legacy system with an existing interface.

These are also documented in the Payroll Architecture Handbook, Architectural Mechanisms section.





29



This is where the key abstractions for the problem domain are defined. Furthermore, this is where the “vocabulary” of the software system is established.

The purpose of this step is to "prime the pump" for analysis by identifying and defining the key abstractions that the system must handle. These may have been initially identified during business modeling and requirement activities. However, during those activities, the focus was on the problem domain. During analysis and design, our focus is more on the solution domain.




What Are Key Abstractions?

30

What Are Key Abstractions?

A key abstraction is a concept, normally uncovered in Requirements, that the system must be able to handleSources for key abstractions

Domain knowledgeRequirementsGlossaryDomain Model, or the Business Model (if one exists)

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.




Defining Key Abstractions

31

Defining Key Abstractions

Define analysis classesModel analysis classes and relationships on class diagrams

Include a brief description of an analysis class

Map analysis classes to necessary analysis mechanisms

While defining the initial analysis classes, you can also define any relationships that exist between them. The relationships are those that support the basic definitions of the abstractions. It is not the objective to develop a complete class model at this point, but just to define some key abstractions and basic relationships to “kick off” the analysis effort. This will help to reduce any duplicate effort that may result when different teams analyze the individual use cases.

Relationships defined at this point reflect the semantic connections between the defined abstractions, not the relationships necessary to support the implementation or the required communication among abstractions.

The analysis classes identified at this point will probably change and evolve during the course of the project. The purpose of this step is not to identify a set of classes that will survive throughout design, but to identify the key abstractions the system must handle. Do not spend much time describing analysis classes in detail at this initial stage, because there is a risk that you might identify classes and relationships that are not actually needed by the use cases. Remember that you will find more analysis classes and relationships when looking at the use cases.




Example: Key Abstractions

32

Example: Key Abstractions

StudentProfessor

Schedule

CourseCatalog CourseCourseOffering

Professor: A person teaching classes at the university.

Student: A person enrolled in classes at the university.

Schedule: The courses a student has enrolled in for a semester.

CourseCatalog: Unabridged catalog of all courses offered by the university.

CourseOffering: A specific offering for a course, including days of the week and times.

Course: A class offered by the university.





33



A use-case realization represents the design perspective of a use case. It is an organization model element used to group a number of artifacts related to the use-case design. Use cases are separate from use-case realizations, so you can manage each individually and change the design of the use case without affecting the baseline use case. For each use case in the Use-Case Model, there is a use-case realization in the design model with a realization relationship to the use case.




Review: What is a Use-Case Realization?

34

Review: What is a Use-Case Realization?





Sequence Diagrams

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 collaboration (the classes/objects that implement the use case and their relationships — class diagrams), and the interactions of the collaborations (how these classes/objects interact to perform the use cases — collaboration and sequence diagrams).

The number and types of the diagrams that are used depend on what is needed to provide a complete picture of the collaboration and the guidelines developed for the project under development.




The Value of Use-Case Realizations

35

The Value of Use-Case RealizationsProvides traceability from Analysis and Design back to RequirementsThe Architect creates the Use-Case Realization

Use Case

Analysis & Design(Design Model)

Requirements(Use-Case Model)

Use-Caserealization

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.

For each Use Case in the Use-Case Model, create a use-case realization in the Design Model. The name for the use-case realization should be the same as the associated use case, and a realize relationship should be established from the use-case realization to its associated use case.





36



This is where the quality of the architecture modeled up to this point is assessed against some very specific criteria.

In this module, we will concentrate on those checkpoints that the designer is most concerned with (that is, looks for). The architect should do a much more detailed review of the Architectural Analysis results and correct any problems before the project moves on to the next activity. We will not cover those checkpoints, as they are out of scope of this course. (Remember, this is not an architecture course.)




Checkpoints

37

Checkpoints

GeneralIs the package partitioning and layering done in a logically consistent way? Have the necessary analysis mechanisms been identified?

PackagesHave we provided a comprehensive picture of the services of the packages in upper-level layers?

The next few slides contains the key things a designer would look for when assessing the results of Architectural Analysis. An architect would have a more detailed list.

A well-structured architecture encompasses a set of classes, typically organized into multiple hierarchies

Note: At this point, some of the packages/layers may not contain any classes, and that is okay. More classes will be identified over time, starting in the next activity, Use-Case Analysis.




Checkpoints (continued)

38


ClassesHave the key entity classes and their relationships been identified and accurately modeled? Does the name of each class clearly reflect the role it plays? Are the key abstractions/classes and their relationships consistent with the Business Model, Domain Model, Requirements, Glossary, etc.?

A well-structured class provides a crisp abstraction of something drawn from the vocabulary of the problem domain or the solution domain.




Review

39

Review: Architectural Analysis

What is the purpose of Architectural Analysis?What is a package? What is a layered architecture? Give examples of typical layers.What are analysis mechanisms? Give examples.What key abstractions are identified during Architectural Analysis? Why are they identified here?




Exercise: Architectural Analysis

40

Exercise: Architectural Analysis

Given the following:Some results from the Requirements discipline: (Exercise Workbook: Payroll Requirements)

• Problem statement• Use-Case Model main diagram• Glossary

Some architectural decisions: (Exercise Workbook: Payroll Architecture Handbook, Logical View, Architectural Analysis)

• (textually) The upper-level architectural layers and their dependencies

The goal of this exercise is to jump-start analysis.

References to givens:

• Requirements Results: Exercise Workbook: Payroll Requirements • Architectural Decisions: Exercise Workbook: Payroll Architecture Handbook,

Logical View, Architectural Analysis section. Note: This exercise has been tightly scoped to emphasize the Analysis and Design modeling concepts and reduce the emphasis on architectural issues. Thus, much of the architecture has been provided to you, rather than asking you to provide it as part of the exercise. Remember, this is not an architecture course.




Exercise: Architectural Analysis (continued)

41


Identify the following:The key abstractions

To identify the key abstractions, you can probably concentrate on the Problem Statement and the Glossary.

Create a class to represent each key abstraction. Be sure to include a brief description for each class. You do not need to allocate the classes to packages. That will occur in the next module. You do not need to define relationships between the classes at this point. We will concentrate on class relationships in later modules.

The class diagrams of the upper-level layers and their dependencies should be drawn using the given textual descriptions.

References to sample diagrams within the course that are similar to what should be produced are:

Refer to the following slides if needed;

• What Are Key Abstractions – p. 5-30 • Defining Key Abstractions – p. 5-31





42


Produce the following:Class diagram containing the key abstractions Class diagram containing the upper-level architectural layers and their dependencies

You will need to create two different class diagrams in this solution: one showing the key abstractions and one showing the architectural layers and their dependencies.

Refer to the following slides if needed;

• Package Relationships: Dependency – p. 5-8 • Example: Key Abstractions – p. 5-32 • Example: High-level Organization of the Model – p. 5-19




Exercise: Review

43

Exercise: Review

Compare your key abstractions with the rest of the class

Have the key concepts been identified?Does the name of each class reflect the role it plays?

Compare your class diagram showing the upper-level layers

Do the package relationships support the Payroll System architecture?






► ► ► Module 6 Use-Case Analysis

1

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 6: Use-Case Analysis

Topics

Use-Case Analysis Overview................................................................................. 6-4 Use-Case Analysis Steps........................................................................................ 6-8 Find Classes from Use-Case Behavior.................................................................. 6-12 Distribute Use-Case Behavior to Classes.............................................................. 6-27 Describe Responsibilities .................................................................................... 6-37 Association or Aggregation? ................................................................................ 6-46 What Are Roles?................................................................................................. 6-47 Unify Analysis Classes ......................................................................................... 6-57 Review............................................................................................................... 6-62




Objectives: Use-Case Analysis

2

Objectives: Use-Case Analysis

Explain the purpose of Use-Case Analysis and where in the lifecycle it is performedIdentify the classes which perform a use-case flow of eventsDistribute the use-case behavior to those classes, identifying responsibilities of the classesDevelop Use-Case Realizations that model the collaborations between instances of the identified classes

Use-Case Analysis is where we identify the initial classes of our system.

As the analysis classes are defined and the responsibilities are allocated to them, we will also note the usage of architectural mechanisms, more specifically, the usage of any analysis mechanisms defined in Architectural Analysis.

The analysis classes and the initial Use-Case Realizations are the key model elements being developed in this activity. These will be refined in the remaining Analysis and Design activities.



Module 6 - Use-Case Analysis

Use-Case Analysis in Context

3

Use-Case Analysis in Context[Early





Synthesis

Analyze Behavior


DesignComponents

Design theDatabase

(Optional)

Use-CaseAnalysisDesigner

As you may recall, the above diagram illustrates the workflow that we are using in this course. It is a tailored version of the Analysis and Design core workflow of the Rational Unified Process. Use-Case Analysis is an activity in the Analyze Behavior workflow detail.

At this point, we have made an initial attempt at defining our architecture — we have defined the upper layers of our architecture, the key abstractions, and some key analysis mechanisms. This initial architecture, along with the software requirements defined in the Requirements discipline, guides and serves as input to the Use-Case Analysis activity.

An instance of Use-Case Analysis is performed for each use case to be developed during an iteration. The focus during Use-Case Analysis is on a particular use case.

In Use-Case Analysis, we identify the analysis classes and define their responsibilities. As the analysis classes and their responsibilities are defined, we will also note the usage of any architectural (more specifically, analysis) patterns defined in Architectural Analysis. The architectural layers and their dependencies may affect the allocation of responsibility to the defined analysis classes.

The allocation of responsibility is modeled in Use-Case Realizations that describe how analysis classes collaborate to perform use cases. The Use-Case Realizations will be refined in the Use-Case Design Model.




Use-Case Analysis Overview

4

Use-Case Analysis Overview

SupplementarySpecifications

Glossary

Use-CaseAnalysis

Project SpecificGuidelines

Use-Case Realization

Analysis Model

Use-Case Model Analysis Classes


Use-Case Analysis is performed by the designer, once per iteration per Use-Case Realization. What event flows, and therefore what Use-Case Realizations you are going to work on during the current iteration are defined prior to the start of Use-Case Analysis in Architectural Analysis. Purpose • To identify the classes that perform a use case’s flow of events • To distribute the use case behavior to those classes, using Use-Case Realizations • To identify the responsibilities, attributes and associations of the classes • To note the usage of architectural mechanisms Input Artifacts • Glossary • Supplementary Specifications • Use-Case • Use-Case Model • Use-Case Realization • Software Architecture Document • Analysis Class • Analysis Model • Project Specific Guidelines Resulting Artifacts • Analysis Classes • Analysis Model • Use-Case Realizations Note: We will not be developing a separate Analysis Model in this course.




Use-Case Analysis Steps

5


Supplement the Use-Case DescriptionFor each Use-Case Realization

Find Classes from Use-Case Behavior Distribute Use-Case Behavior to Classes

For each resulting analysis class Describe ResponsibilitiesDescribe Attributes and AssociationsQualify Analysis Mechanisms

Unify Analysis ClassesCheckpoints

The above are the major steps of the Use-Case Analysis activity.

First we must review the use-case descriptions developed in the Requirements discipline. Chances are, they will need some enhancements to include enough detail to begin developing a model.

Next, we study the use-case flow of events, identify analysis classes, and allocate use-case responsibilities to the analysis classes. Based on these allocations, and the analysis class collaborations, we can begin to model the relationships between the identified analysis classes.

Once the use case has been analyzed, we need to take a good look at the identified classes, making sure they are thoroughly documented and identify which analysis and mechanisms they implement.

Last, but not least, we need to make sure that our developed Analysis Model is consistent.





6




For each resulting analysis class Describe Responsibilities Describe Attributes and Associations Qualify Analysis Mechanisms


The purpose of the Supplement the Descriptions of the Use Case is to capture additional information needed in order to understand the required internal behavior of the system that may be missing from the Use-Case Description written for the customer of the system. This information will be used as input to the rest of the steps in Use-Case Analysis and is used to assist in the allocation of responsibility.

Note: In some cases, we may find that some requirements were incorrect or not well-understood. In those cases, the original use-case flow of events should be updated (for example, iterate back to the Requirements discipline).




Supplement the Use-Case Description

7

• The system displays a list of course offerings.

• The system retrieves and displays a list of current course offerings from the course catalog legacy database.

Supplement the Use-Case Description

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.

Taking the Register for Courses use case as an example, the expanded description would read as: “The system retrieves a list of current course offerings from the course catalog legacy database.” This level of detail gives us a clear idea of what information is required and who is responsible for providing that information.





8






Now that we have a more detailed understanding of the Requirements, as documented in the use case, we can identify the candidate analysis classes for our system.

The purpose of the Find Classes from Use-Case Behavior step is to identify a candidate set of model elements (analysis classes) that will be capable of performing the behavior described in the use case.




Review: Class

9

An abstractionDescribes a group of objects with common:

Properties (attributes)Behavior (operations)RelationshipsSemantics Class Name

Attributes

Operations

Review: Class

ProfessornameProfessorId : UniqueId

create()save()delete()change()

As discussed in the Concepts of Object Orientation module, a class is a description of a group of objects with common properties (attributes), common behavior (operations), common relationships, and common semantics.

A class is an abstraction in that it:

• Emphasizes relevant characteristics. • Suppresses other characteristics. A class is comprised of three sections:

• The first section contains the class name. • The second section shows the structure (attributes). • The third section shows the behavior (operations).




Review: Use-Case Realization

10






Sequence Diagrams

As discussed in the Analysis and Design Overview module, a Use-Case Realization describes how a particular use case is realized within the Design Model in terms of collaborating objects. 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. A Use-Case Realization is one possible realization of a use case. A Use-Case Realization can be represented using a set of diagrams (the number and type may vary by project). • Interaction diagrams (Sequence and/or Communication diagrams) can be used to

describe how the use case is realized in terms of collaborating objects. These diagrams model the detailed collaborations of the Use-Case Realization.

• Class diagrams can be used to describe the classes that participate in the realization of the use case, as well as their supporting relationships. These diagrams model the context of the Use-Case Realization.

During analysis activities (Use-Case Analysis), the Use-Case Realization diagrams are outlined. In subsequent design activities (Use-Case Design), these diagrams are refined and updated according to more formal class interface definitions. A designer is responsible for the integrity of the Use-Case Realization. He or she must coordinate with the designers responsible for the classes and relationships employed in the Use-Case Realization. The Use-Case Realization can be used by class designers to understand the class’s role in the use case and how the class interacts with other classes. This information can be used to determine or refine the class responsibilities and interfaces.




Analysis Classes: A First Step Toward Executables

11

Use Cases AnalysisClasses

SourceCode

ExecDesignElements

Use-Case Analysis

Analysis Classes: A First Step Toward Executables

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, components, split classes, or combined classes). They provide you with a way of capturing the required behaviors in a form that we can use to explore the behavior and composition of the system. Analysis classes allow us to "play" with the distribution of responsibilities, re-allocating as necessary.




Find Classes from Use-Case Behavior

12

Find Classes from Use-Case Behavior

The complete behavior of a use case has to be distributed to analysis classes

The technique for finding analysis classes described in this module uses three different perspectives of the system to drive the identification of candidate classes. These three perspectives are:

• The boundary between the system and its actors • The information the system uses • The control logic of the system The use of stereotypes to represent these perspectives (for example, boundary, control, and entity) results in a more robust model because they isolate those things most likely to change in a system: the interface/environment, the control flow, and the key system entities. These stereotypes are conveniences used during Analysis that disappear in Design.

Identification of classes means just that: They should be identified, named, and described briefly in a few sentences.

The different stereotypes are discussed in more detail throughout this module.




What Is an Analysis Class?

13

What Is an Analysis Class?

System boundary

Use-case behavior coordination

System information

<<boundary>>

<<control>>

<<entity>>

System information

<<entity>>

System boundary

<<boundary>>

Analysis classes represent an early conceptual model for “things in the system that have responsibilities and behavior.” Analysis classes are used to capture a “first-draft” rough-cut of the Object Model of the system. Analysis classes handle primarily functional requirements. They model objects from the problem domain. Analysis classes can be used to represent "the objects we want the system to support" without making a decision about how much of them to support with hardware and how much with software. Three aspects of the system are likely to change: • The boundary between the system and its actors • The information the system uses • The control logic of the system In an effort to isolate the parts of the system that will change, the following types of analysis classes are identified with a “canned” set of responsibilities: • Boundary • Entity • Control Stereotypes may be defined for each type. These distinctions are used during Analysis, but disappear in Design. The different types of analysis classes can be represented using different icons or with the name of the stereotype in guillemets (<< >>): <<boundary>>, << control>>, <<entity>>. Each of these types of analysis classes are discussed on the following slides.




What Is a Boundary Class?

14

Environment dependent.

Analysis class stereotype

What Is a Boundary Class?

Intermediates between the interface and something outside the systemSeveral Types

User interface classesSystem interface classes Device interface classes

One boundary class per actor/use-case pair

A boundary class intermediates between the interface and something outside the system. Boundary classes insulate the system from changes in the surroundings (for example, changes in interfaces to other systems and changes in user requirements), keeping these changes from affecting the rest of the system.

A system can have several types of boundary classes:

• User interface classes—Classes that intermediate communication with human users of the system.

• System interface classes—Classes that intermediate communication with other systems. A boundary class that communicates with an external system is responsible for managing the dialog with the external system; it provides the interface to that system for the system being built.

• Device interface classes—Classes that provide the interface to devices which detect external events. These boundary classes capture the responsibilities of the device or sensor.

One recommendation for the initial identification of boundary classes is one boundary class per actor/use-case pair.




The Role of a Boundary Class

15

Model interaction between the system and its environment.

The Role of a Boundary Class

Actor 1<<boundary>>

<<control>><<boundary>>

<<entity>> <<entity>>

Actor 2

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.

A boundary object (an instance of a boundary class) can outlive a use-case instance if, for example, it must appear on a screen between the performance of two use cases. Normally, however, boundary objects live only as long as the use-case instance.




Example: Finding Boundary Classes

16

Student Course CatalogRegister for Courses

Example: Finding Boundary Classes

One boundary class per actor/use case pair

RegisterForCoursesForm CourseCatalogSystem

The goal of Analysis is to form a good picture of how the system is composed, not to design every last detail. In other words, identify boundary classes only for phenomena in the system or for things mentioned in the flow of events of the Use-Case Realization.

Consider the source for all external events and make sure there is a way for the system to detect these events.

One recommendation for the initial identification of boundary classes is one boundary class per actor/use-case pair. This class can be viewed as having responsibility for coordinating the interaction with the actor. This may be refined as a more detailed analysis is performed. This is particularly true for window-based GUI applications where there is typically one boundary class for each window, or one for each dialog box.

In the above example:

• The RegisterForCoursesForm contains a Student's "schedule-in-progress." It displays a list of Course Offerings for the current semester from which the Student may select courses to be added to his or her Schedule.

• The CourseCatalogSystem interfaces with the legacy system that provides the unabridged catalog of all courses offered by the university. This class replaces the CourseCatalog abstraction originally identified in Architectural Analysis.




Guidelines: Boundary Class

17

Concentrate on the responsibilities, not the details!

Guidelines: Boundary Class

User Interface ClassesConcentrate on what information is presented to the userDo NOT concentrate on the UI details

System and Device Interface Classes Concentrate on what protocols must be definedDo NOT concentrate on how the protocols will be implemented

When identifying and describing analysis classes, be careful not to spend too much time on the details. Analysis classes are meant to be a first cut at the abstractions of the system. They help to clarify the understanding of the problem to be solved and represent an attempt at an idealized solution (Analysis has been called “idealized Design”).

User Interface Classes: Boundary classes may be used as “holding places” for GUI classes. The objective is not to do GUI design in this analysis, but to isolate all environment-dependent behavior. The expansion, refinement and replacement of these boundary classes with actual user-interface classes (probably derived from purchased UI libraries) is a very important activity of Class Design and will be discussed in the Class Design module. Sketches or screen captures from a user-interface prototype may have been used during the Requirements discipline to illustrate the behavior and appearance of the boundary classes. These may be associated with a boundary class. However, only model the key abstractions of the system; do not model every button, list, and widget in the GUI.

System and Device Interface Classes: If the interface to an existing system or device is already well-defined, the boundary class responsibilities should be derived directly from the interface definition. If there is a working communication with the external system or device, make note of it for later reference during design.




What Is an Entity Class?

18

Glossary

Business-Domain Model

Environment independent.


Use Case

Architectural Analysis Abstractions

What Is an Entity Class?

Key abstractions of the system

Entity objects represent the key concepts of the system being developed. Entity classes provide another point of view from which to understand the system, because they show the logical data structure. Knowing the data structure can help you understand what the system is supposed to offer its users.

Frequent sources of inspiration for entity classes are the:

• Glossary (developed during requirements) • Business-Domain Model (developed during business modeling, if business

modeling has been performed) • Use-case flow of events (developed during requirements) • Key abstractions (identified in Architectural Analysis) As mentioned earlier, sometimes there is a need to model information about an actor within the system. This is not the same as modeling the actor (actors are external. by definition). In this case, the information about the actor is modeled as an entity class. These classes are sometimes called “surrogates or proxies.”




The Role of an Entity Class

19

Store and manage information in the system.

The Role of an Entity Class

Actor 1<<boundary>>



Actor 2

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 Realization and sometimes it is not even specific to the system itself. The values of its attributes and relationships are often given by an actor. An entity object may also be needed to help perform internal system tasks. Entity objects can have behavior as complicated as that of other object stereotypes. However, unlike other objects, this behavior is strongly related to the phenomenon the entity object represents. Entity objects are independent of the environment (the actors).




Example: Finding Entity Classes

20

Example: Finding Entity Classes

Use use-case flow of events as input Key abstractions of the use caseTraditional, filtering nouns approach

Underline noun clauses in the use-case flow of eventsRemove redundant candidatesRemove vague candidatesRemove actors (out of scope)Remove implementation constructsRemove attributes (save for later)Remove operations

Taking the use-case flow of events as input, underline the noun phrases in the flow of events. These form the initial candidate list of analysis classes.

Next, go through a series of filtering steps where some candidate classes are eliminated. This is necessary due to the ambiguity of the English language. The result of the filtering exercise is a refined list of candidate entity classes. While the filtering approach does add some structure to what could be an ad-hoc means of identifying classes, people generally filter as they go rather than blindly accepting all nouns and then filtering.




Example: Candidate Entity Classes

21

Example: Candidate Entity Classes

Register for Courses (Create Schedule)

Student

ScheduleCourseOffering

The following are the definitions for each of the classes shown in the above diagram:

CourseOffering: A specific offering for a course, including days of the week and times.

Schedule: The courses a student has selected for the current semester.

Student: A person enrolled in classes at the university.

As mentioned earlier, sometimes there is a need to model information about an actor within the system. This is not the same as modeling the actor. (Actors are external by definition.) These classes are sometimes called “surrogates”.

For example, a course registration system maintains information about the student that is independent of the fact that the student also plays a role as an actor in the system. This information about the student is stored in a “Student” class that is completely independent of the “actor” role the student plays. The Student class will exist whether or not the student is an actor to the system.




What Is a Control Class?

22

Use Case

Use-case dependent. Environment independent.


What Is a Control Class?

Use-case behavior coordinatorMore complex use cases generally require one or more control cases

Control classes provide coordinating behavior in the system. The system can perform some use cases without control classes by using just entity and boundary classes. This is particularly true for use cases that involve only the simple manipulation of stored information. More complex use cases generally require one or more control classes to coordinate the behavior of other objects in the system. Examples of control classes include transaction managers, resource coordinators, and error handlers.

Control classes effectively decouple boundary and entity objects from one another, making the system more tolerant of changes in the system boundary. They also decouple the use-case specific behavior from the entity objects, making them more reusable across use cases and systems.

Control classes provide behavior that:

• Is surroundings-independent (does not change when the surroundings change). • Defines control logic (order between events) and transactions within a use case. • Changes little if the internal structure or behavior of the entity classes changes. • Uses or sets the contents of several entity classes, and therefore needs to

coordinate the behavior of these entity classes. • Is not performed in the same way every time it is activated (flow of events

features several states). Although complex use cases may need more than one control class it is recommended, for the initial identification of control classes, that only one control class be created per use case.




The Role of a Control Class

23

The Role of a Control Class

Coordinate the use-case behavior.

Actor 1<<boundary>>



Actor 2

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 different control classes can participate in one use case. Not all use cases require a control object. For example, if the flow of events in a use case is related to one entity object, a boundary object may realize the use case in cooperation with the entity object. You can start by identifying one control class per Use-Case Realization, and then refine this as more Use-Case Realizations are identified, and commonality is discovered.

Control classes can contribute to understanding the system, because they represent the dynamics of the system, handling the main tasks and control flows.

When the system performs the use case, a control object is created. Control objects usually die when their corresponding use case has been performed.




Example: Finding Control Classes

24

Student

In general, identify one control class per use case.

As analysis continues, a complex use case’s control class may evolve into more than one class

Course Catalog System


Example: Finding Control Classes


One recommendation is to identify one control class per use case. However, this can become more than one use case as analysis continues. Remember that more complex use cases generally require one or more control cases. Each control class is responsible for orchestrating/controlling the processing that implements the functionality described in the associated use case.

In the above example, the RegistrationController <<control>> class has been defined to orchestrate the Register for Courses processing within the system.




Example: Summary: Analysis Classes

25

Student Course Catalog System


Use-Case Model

Design Model

Example: Summary: Analysis Classes

RegisterForCoursesForm CourseCatalogSystem Student Schedule

CourseOffering RegistrationController

For each Use-Case Realization, there is one or more class diagrams depicting its participating classes, along with their relationships. These diagrams help to ensure that there is consistency in the use-case implementation across subsystem boundaries. Such class diagrams have been called “View of Participating Classes” diagrams (VOPC, for short).

The diagram on this slide shows the classes participating in the “Register for Courses” use case. Class relationships will be discussed later in this module.





26


Supplement the Use-Case DescriptionsFor each Use-Case Realization




Now that we have identified the candidate analysis classes, we need to allocate the responsibilities of the use case to the analysis classes and model this allocation by describing the way the class instances collaborate to perform the use case in Use-Case Realization.

The purpose of “Distribute Use-Case Behavior to Classes” is to:

• Express the use-case behavior in terms of collaborating analysis classes • Determine the responsibilities of analysis classes




Distribute Use-Case Behavior to Classes

27

For each use-case flow of events: Identify analysis classes Allocate use-case responsibilities to analysis classesModel analysis class interactions in Interaction diagrams

Use Case

Distribute Use-Case Behavior to Classes

Class Diagrams

Communication DiagramsSequence

Diagrams

Use-Case Realization

You can identify analysis classes responsible for the required behavior by stepping through the flow of events of the use case. In the previous step, we outlined some classes. Now it is time to see exactly where they are applied in the use-case flow of events.

In addition to the identified analysis classes, the Interaction diagram should show interactions of the system with its actors. The interactions should begin with an actor, since an actor always invokes the use case. If you have several actor instances in the same diagram, try keeping them in the periphery of that diagram.

Interactions between actors should not be modeled. By definition, actors are external, and are out of scope of the system being developed. Thus, you do not include interactions between actors in your system model. If you need to model interactions between entities that are external to the system that you are developing (for example, the interactions between a customer and an order agent for an order-processing system), those interactions are best included in a Business Model that drives the System Model.

Guidelines for how to distribute behavior to classes are described on the next slide.




Guidelines: Allocating Responsibilities to Classes

28

Guidelines: Allocating Responsibilities to Classes

Use analysis class stereotypes as a guideBoundary Classes• Behavior that involves communication with

an actorEntity Classes• Behavior that involves the data encapsulated

within the abstractionControl Classes• Behavior specific to a use case or part of a

very important flow of events

The allocation of responsibilities in analysis is a crucial and sometimes difficult activity. These three stereotypes make the process easier by providing a set of canned responsibilities that can be used to build a robust system. These predefined responsibilities isolate the parts of the system that are most likely to change: the interface (boundary classes), the use-case flow of events (control classes), and the persistent data (entity classes).




Guidelines: Allocating Responsibilities to Classes (cont.)

29

Guidelines: Allocating Responsibilities to Classes (cont.)

Who has the data needed to perform the responsibility?

If one class has the data, put the responsibility with the dataIf multiple classes have the data:• Put the responsibility with one class and add a

relationship to the other• Create a new class, put the responsibility in the

new class, and add relationships to classes needed to perform the responsibility

• Put the responsibility in the control class, and add relationships to classes needed to perform the responsibility

A driving influence on where a responsibility should go is the location of the data needed to perform the operation.

The best case is that there is one class that has all the information needed to perform the responsibility. In that case, the responsibility goes with the data (after all, that is one of the tenets of OO — data and operations together).

If this is not the case, the responsibility may need to be allocated to a “third party” class that has access to the information needed to perform the responsibility. Classes and/or relationships might need to be created to make this happen. Be careful when adding relationships — all relationships should be consistent with the abstractions they connect. Do not just add relationships to support the implementation without considering the overall effect on the model. Class relationships will be discussed later in this module.

When a new behavior is identified, check to see if there is an existing class that has similar responsibilities, reusing classes where possible. You should create new classes only when you are sure that there is no existing object that can perform the behavior.




The Anatomy of Sequence Diagrams

30

The Anatomy of Sequence Diagrams

1: PerformResponsibility

Client Object Supplier Object

Message:Client :Supplier

Execution Occurrence

Reflexive MessageObject Lifeline

1.1: PerformAnotherResponsibility

Hierarchical MessageNumbering

Interaction Occurrenceref

Event Occurrence

A Sequence diagram describes a pattern of interaction among objects, arranged in a chronological order. It shows the objects participating in the interaction and the messages they send. An object is shown as a vertical dashed line called the "lifeline." The lifeline represents the existence of the object at a particular time. An object symbol is drawn at the head of the lifeline, and shows the name of the object and its class separated by a colon and underlined. A message is a communication between objects that conveys information with the expectation that activity will result. A message is shown as a horizontal solid arrow from the lifeline of one object to the lifeline of another object. For a reflexive message, the arrow starts and finishes on the same lifeline. The arrow is labeled with the name of the message and its parameters. The arrow may also be labeled with a sequence number. Execution Occurrence represents the relative time that the flow of control is focused in an object, thereby representing the time an object is directing messages. Execution occurrence is shown as narrow rectangles on object lifelines. Event Occurrence represents the sending or receipt of messages. Interaction Occurrence is a reference to an interaction within the definition of another interaction. Hierarchical numbering bases all messages on a dependent message. The dependent message is the message whose execution occurrence the other messages originate in. For example, message 1.1 depends on message 1. Notes describe the flow of events textually.




Example: Sequence Diagram

31

Example: Sequence Diagram

: Student: RegisterForCoursesForm : RegistrationController : Course Catalog: CourseCatalogSystem

A list of the available course offerings for this semester are displayed

Create a new schedule

1: // create schedule( )

5: // display course offerings( )

2: // get course offerings( )

3: // get course offerings(forSemester)

6: // display blank schedule( )A blank schedule is displayed for the students to select offerings


Select Offerings

Submit Schedule

ref

ref

The above example shows the object interactions to support the Create a Schedule sub-flow of the Register for Courses use case. Some of the rationale for responsibility allocation is as follows:

• 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. • Only the CourseCatalogSystem class interacts with the external legacy Course

Catalog System. • Note the inclusion of the actors. This is important as the diagram explicitly

models what elements communicate with the “outside world.”




The Anatomy of Communication Diagrams

32

PerformResponsibility


Message

Link

:Client :Supplier

The Anatomy of Communication Diagrams

A Communication diagram describes a pattern of interaction among objects. It shows the objects participating in the interaction by their links to each other and the messages that they send to each other. An object is represented in one of three ways: • Objectname:Classname • ObjectName • :ClassName A link is a relationship between objects that can be used to send messages. In Communication diagrams, a link is shown as a solid line between two objects. An object interacts with, or navigates to, other objects through its links to these objects. A link is defined as an instance of an association. A message is a communication between objects that conveys information with the expectation that activity will result. In Communication diagrams, a message is shown as a labeled arrow placed near a link. This means that the link is used to transport or otherwise implement the delivery of the message to the target object. The arrow points along the link in the direction of the target object (the one that receives the message). The arrow is labeled with the name of the message and its parameters. The arrow may also be labeled with a sequence number to show the sequence of the message in the overall interaction. Sequence numbers are often used in Communication diagrams because they are the only way of describing the relative sequencing of messages. A message can be unassigned, meaning that its name is a temporary string that describes the overall meaning of the message. You can later assign the message by specifying the operation of the message's destination object. The specified operation will then replace the name of the message.




Example: Communication Diagram

33

Example: Communication Diagram

: Student

: RegisterForCoursesForm

: RegistrationController


5: // display course offerings( )6: // display blank schedule( )

1: // create schedule( )


3: // get course offerings(forSemester)


: Course Catalog

The above example shows the collaboration of objects to support the Register for Courses use case, Create a Schedule subflow. It is the “Communication diagram equivalent” of the Sequence diagram shown earlier.




One Interaction Diagram Is Not Good Enough

34

Alternate Flow 4 Alternate Flow 5 Alternate Flow n

Alternate Flow 1 Alternate Flow 2 Alternate Flow 3

AF1

AF2

AF3

Basic Flow

One Interaction Diagram Is Not Good Enough

Model most of the flow of events to make sure that all requirements on the operations of the participating classes are identified. Start with describing the basic flow, which is the most common or most important flow of events. Then describe variants such as exceptional flows. You do not have to describe all the flow of events, as long as you employ and exemplify all operations of the participating objects. Very trivial flows can be omitted, such as those that concern only one object.

Examples of exceptional flows include the following:

• Error handling. What should the system do if an error is encountered? • Time-out handling. If the user does not reply within a certain period, the use case

should take some special measures. • Handling of erroneous input to the objects that participate in the use case (for

example, incorrect user input). Examples of optional flows include the following:

• The actor decides-from a number of options — what the system is to do next. • The subsequent flow of events depends on the value of stored attributes or

relationships. • The subsequent flow of events depends on the type of data to be processed. You can use either Communication or Sequence diagrams.




Communication Diagrams vs. Sequence Diagrams

35

Communication Diagrams vs. Sequence Diagrams

Show the explicit sequence of messagesBetter for visualizing overall flowBetter for real-time specifications and for complex scenarios

Show relationships in addition to interactionsBetter for visualizing patterns of collaborationBetter for visualizing all of the effects on a given objectEasier to use for brainstorming sessions

Sequence DiagramsCommunication Diagrams

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

Communication diagrams emphasize the structural collaboration of a society of objects and provide a clearer picture of the patterns of relationships and control that exist amongst the objects participating in a use case. Communication diagrams show more structural information (that is, the relationships among objects). Communication diagrams are better for understanding all the effects on a given object and for procedural design.

Sequence diagrams show the explicit sequence of messages and are better for real-time specifications and for 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 sequence. On Sequence diagrams, the time dimension is easier to read, operations and parameters are easier to present, and a larger number of objects are easier to manage than in Communication diagrams.

Both Sequence and Communication diagrams allow you to capture semantics of the use-case flow of events; they help identify objects, classes, interactions, and responsibilities; and they help validate the architecture.





36






At this point, analysis classes have been identified and use-case responsibilities have been allocated to those classes. This was done on a use-case-by-use-case basis, with a focus primarily on the use-case flow of events. Now it is time to turn our attention to each of the analysis classes and see what each of the use cases will require of them. A class and its objects often participate in several Use-Case Realizations. It is important to coordinate all the requirements on a class and its objects that different Use-Case Realizations may have.

The ultimate objective of these class-focused activities is to to document what the class knows and what the class does. The resulting Analysis Model gives you a big picture and a visual idea of the way responsibilities are allocated and what such an allocation does to the class collaborations. Such a view allows the analyst to spot inconsistencies in the way certain classes are treated in the system, for example, how boundary and control classes are used.

The purpose of the Describe Responsibilities step is namely to describe the responsibilities of the analysis classes.




Describe Responsibilities

37

// PerformResponsibility

:Client :Supplier

Supplier

// PerformResponsibility

Interaction Diagram

Class Diagram

Describe Responsibilities

What are responsibilities?How do I find them?

A responsibility is a statement of something an object can be asked to provide. Responsibilities evolve into one (or more) operations on classes in design; they can be characterized as: • The actions that the object can perform. • The knowledge that the object maintains and provides to other objects. Responsibilities are derived from messages on Interaction diagrams. For each message, examine the class of the object to which the message is sent. If the responsibility does not yet exist, create a new responsibility that provides the requested behavior. Other responsibilities will derive from nonfunctional requirements. When you create a new responsibility, check the nonfunctional requirements to see if there are related requirements that apply. Either augment the description of the responsibility, or create a new responsibility to reflect this. Analysis class responsibilities can be documented in one of two ways: • As “analysis” operations: When this approach is chosen, it is important that

some sort of naming convention be used. This naming convention indicates that the operation is being used to describe the responsibilities of the analysis class and that these “analysis” operations WILL PROBABLY change/evolve in design.

• Textually: In this approach, the analysis class responsibilities are documented in the description of the analysis classes.

For the OOAD course example, we will use the “analysis” operation approach. The naming convention that will be used is that the “analysis” operation name will be preceded by '//'.




Example: View of Participating Classes (VOPC) Class Diagram

38

Example: View of Participating Classes (VOPC) Class Diagram


// get course offerings()

<<control>>

CourseCatalogSystem

// get course offerings()

<<boundary>>

RegisterForCoursesForm

// display course offerings()// display blank schedule()// create schedule()

<<boundary>>

The View of Participating Classes (VOPC) class diagram contains the classes whose instances participate in the Use-Case Realization Interaction diagrams, as well as the relationships required to support the interactions. We will discuss the relationships later in this module. Right now, we are most interested in what classes have been identified, and what responsibilities have been allocated to those classes.




Maintaining Consistency: What to Look For

39

Maintaining Consistency: What to Look For

In order of criticalityRedundant responsibilities across classesDisjoint responsibilities within classes Class with one responsibilityClass with no responsibilitiesBetter distribution of behavior Class that interacts with many other classes

Examine classes to ensure they have consistent responsibilities. When a class’s responsibilities are disjoint, split the object into two or more classes. Update the Interaction diagrams accordingly.

Examine classes to ensure that there are not two classes with similar responsibilities. When classes have similar responsibilities, combine them and update the Interaction diagrams accordingly.

Sometimes a better distribution of behavior becomes evident while you are working on another Interaction diagram. In this case, go back to the previous Interaction diagram and redo it. It is better (and easier) to change things now than later in design. Take the time to set the diagrams right, but do not get hungup trying to optimize the class interactions.

A class with only one responsibility is not a problem, per se, but it should raise questions on why it is needed. Be prepared to challenge and justify the existence of all classes.





40






Now that we have defined the analysis classes and their responsibilities, and have an understanding of how they need to collaborate, we can continue our documentation of the analysis classes by describing their attributes and associations.

The purpose of Describe Attributes and Operations is to:

• Identify the other classes on which the analysis class depends. • Define the events in other analysis classes that the class must know about. • Define the information that the analysis class is responsible for maintaining.




Review: What Is an Attribute?

41

ClassName<<stereotype>>

Attribute : Type = InitValueAttribute : Type = InitValueAttribute : Type = InitValue

attribute

In analysis, do not spend time on attribute signatures.

Review: What Is an Attribute?

CourseOffering

number : String = "100"startTime : TimeendTime : Timedays : EnumnumStudents : Int

<<entity>>

Attributes are used to store information. They are atomic things with no responsibilities.

The attribute name should be a noun that clearly states what information the attribute holds. The description of the attribute should describe what information is to be stored in the attribute; this can be optional when the information stored is obvious from the attribute name.

During Analysis, the attribute types should be from the domain, and not adapted to the programming language in use. For example, in the above diagram, enum will need to be replaced with a true enumeration that describes the days the CourseOffering is offered (for example, MWF or TR).




Finding Attributes

42

Finding Attributes

Properties/characteristics of identified classesInformation retained by identified classes“Nouns” that did not become classes

Information whose value is the important thingInformation that is uniquely "owned” by an objectInformation that has no behavior

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.) Remember, the process is use-case-driven. Thus, all discovered attributes should support at least one use case. For this reason, the attributes that are discovered are affected by what functionality/domain is being modeled.





43


The semantic relationship between two or more classifiers that specifies connections among their instances A structural relationship, specifying that objects of one thing are connected to objects of another

Course<<entity>>

Student<<entity>>

Schedule<<entity>>

Associations represent structural relationships between objects of different classes; they connect instances of two or more classes together for some duration.

You can use associations to show that objects know about other objects. Sometimes, objects must hold references to each other to be able to interact; for example, to send messages to each other. Thus, in some cases, associations may follow from interaction patterns in Sequence diagrams or Communication diagrams.

Most associations are simple (exist between exactly two classes), and are drawn as solid paths connecting pairs of class symbols. Ternary relationships are also possible. Sometimes a class has an association to itself. This does not necessarily mean that an instance of that class has an association to itself; more often, it means that one instance of the class has associations to other instances of the same class.

An association may have a name that is placed on, or adjacent to the association path. The name of the association should reflect the purpose of the relationship and be a verb phrase. The name of an association can be omitted, particularly if role names are used.

Avoid names like "has" and "contains," as they add no information about what the relationships are between the classes.




Finding Relationships

44

PerformResponsibility

Link

Association

Communication Diagram

Class Diagram

0..*0..*

Client Supplier

:Client :Supplier

Client Supplier

PerformResponsibility()

Relationship for every link!

Finding Relationships

To find relationships, start studying the links in the Communication diagrams. Links between classes indicate that objects of the two classes need to communicate with one another to perform the use case. Thus, an association or an aggregation is needed between the associated classes.

Reflexive links do not need to be instances of reflexive relationships; an object can send messages to itself. A reflexive relationship is needed when two different objects of the same class need to communicate.

The navigability of the relationship should support the required message direction. In the above example, if navigability was not defined from the Client to the Supplier, then the PerformResponsibility message could not be sent from the Client to the Supplier.

Focus only on associations needed to realize the use cases; do not add associations you think "might" exist unless they are required based on the Interaction diagrams.

Remember to give the associations role names and multiplicities. You can also specify navigability, although this will be refined in Class Design.

Write a brief description of the association to indicate how the association is used, or what relationships the association represents.





45


A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts

Whole/aggregate Part

0..20..* CourseOffering<<entity>>

Schedule<<entity>>

Student<<entity>>

1 0..*1

Aggregation is a stronger form of association which is used to model a whole-part relationship between model elements. The whole/aggregate has an aggregation association to the its constituent parts. A hollow diamond is attached to the end of an association path on the side of the aggregate (the whole) to indicate aggregation. Since aggregation is a special form of association, the use of multiplicity, roles, navigation, and so forth is the same as for association. Sometimes a class may be aggregated with itself. This does not mean that an instance of that class is composed of itself (that would be silly). Instead, it means that one instance if the class is an aggregate composed of other instances of the same class. Some situations where aggregation may be appropriate include: • An object is physically composed of other objects (for example, car being

physically composed of an engine and four wheels). • An object is a logical collection of other objects (for example, a family is a

collection of parents and children). • An object physically contains other objects (for example, an airplane physically

contains a pilot). In the example on the slide, the relationship from Student to Schedule is modeled as an aggregation, because a Schedule is inherently tied to a particular Student. A Schedule outside of the context of a Student makes no sense in this Course Registration System. The relationship from Schedule to CourseOffering is an association because CourseOfferings may appear on multiple Schedules.




Association or Aggregation?

46

When in doubt, use association.

If two objects are tightly bound by a whole-part relationship

The relationship is an aggregation.

If two objects are usually considered as independent, although they are often linked

The relationship is an association.

Association or Aggregation?

Car Door

0..2,41

Car Door

0..2,41

Aggregation should be used only where the "parts" are incomplete outside the context of the whole. If the classes can have independent identity outside the context provided by other classes, or if they are not parts of some greater whole, then the association relationship should be used.

When in doubt, an association is more appropriate. Aggregations are generally obvious. A good aggregate should be a natural, coherent part of the model. The meaning of aggregates should be simple to understand from the context. Choosing aggregation is only done to help clarify; it is not something that is crucial to the success of the modeling effort.

The use of aggregation versus association is dependent on the application you are developing. For example, if you are modeling a car dealership, the relationship between a car and the doors might be modeled as aggregation, because the car always comes with doors, and doors are never sold separately. However, if you are modeling a car parts store, you might model the relationship as an association, as the car (the body) might be independent of the doors.




What Are Roles?

47

What Are Roles?

The “face” that a class plays in the association

Role Name

CourseOffering<<entity>>

Professor<<entity>>

Instructor Department<<entity>>

Department Head

Course<<entity>>

Prerequisites

Each end of an association has a role in relationship to the class on the other end of the association. The role specifies the face that a class presents on each side of the association. A role must have a name, and the role names on opposite sides of the association must be unique. The role name should be a noun indicating the associated object's role in relation to the associating object.

The use of association names and role names is mutually exclusive: one would not use both an association name and a role name. For each association, decide which conveys more information.

The role name is placed next to the end of the association line of the class it describes.

In the case of self-associations, role names are essential to distinguish the purpose for the association.

In the above example, the Professor participates in two separate association relationships, playing a different role in each.




What Does Multiplicity Mean?

48

What Does Multiplicity Mean?

Multiplicity answers two questions:Is the association mandatory or optional?What is the minimum and maximum number of instances that can be linked to one instance?

Course<<entity>>

Prerequisites 0..3

0..*

CourseOffering<<entity>> 0..* 1

• Multiplicity lets you know the lower and the upper bound number of

relationships that a given object can have with another object. Many times you do not know what the maximum number of instances may be, and you will use the “*” to specify that this number is unknown.

• The most important question that multiplicity answers: Is the association mandatory? A lower bound number that is greater than zero indicates that the relationship is mandatory.

• This example indicates that a course object can be related to zero or more course offerings. You can tell that the relationship is optional because the lower bound number is zero. The upper bound number of the relationship is unknown, as indicated by the “*”. If you read the association the other way, you will see that a given course offering object can be related to only one course. This relationship is mandatory and indicates that it is not possible for a course offering object to exist without an associated course object.




Example: Multiple Associations

49


Schedule<<entity>>

primaryCourses

alternateCourses

Multiple associations must reflect multiple roles.

Example: Multiple Associations


Schedule<<entity>> add student to

remove student from

There can be multiple associations between the same two classes, but they should represent distinct relationships, and DIFFERENT ROLES; they should not be just for invoking different operations.

If there is more than one association between two classes then they MUST be named.

It is unusual to find more than one association between the same two classes. Occurrences of multiple associations should be carefully examined.

To determine if multiple associations are appropriate, look at instances of the classes. ClassA and ClassB have two associations between them, Assoc1 and Assoc2. If an instance of ClassA has a link with two SEPARATE instances of ClassB, then multiple associations are valid.

In the above example, the top diagram is an appropriate use of multiple associations, but the bottom diagram is not. In the valid case, two associations are required between Schedule and CourseOffering, as a Schedule can contain two kind of CourseOfferings, primary and alternate. These must be distinguishable, so two separate associations are used. In the invalid case, the two relationships represent two operations of CourseOffering, not two roles of CourseOffering.

Remember, Students and CourseOfferings are related via the Schedule class. Students are enrolled in a CourseOffering if there is a relationship between the Student’s Schedule and the CourseOffering.




Example: VOPC: Finding Relationships

50

Example: VOPC: Finding Relationships

RegisterForCoursesForm<<boundary>>


Schedule<<entity>>

0..*primaryCourses

0..4Student

<<entity>>

0..*1

RegistrationController<<control>>

1 1

0..1

currentSchedule0..1

The diagram on this slide shows classes that collaborate to perform the “Register for Courses” use case, along with their relationships. As noted earlier, this type of diagram is called a View of Participating Classes (VOPC) diagram.

The relationships in this diagram are defined using the Interaction diagrams for the Register for Courses use case provided earlier in this module.

Rationale for relationships:

• From RegisterForCoursesForm to RegistrationController: There is one controller for each Schedule being created (for example, each Student registration session).

• From RegistrationController to Schedule. A RegistrationController deals with one Schedule at a time (the current Schedule for the Student registering for courses). Note the use of the “currentSchedule” role name. Note: Many RegisterForCoursesForms can be active at one time (for different sessions/students), each with their own RegistrationController.

• From Schedule to CourseOffering: Each Schedule may have up to four primary Course Offerings and up to two alternate Course Offerings. A particular Course Offering may appear on many Schedules as either a primary or an alternate.

• From Student to Schedule: A Student may have many schedules or none. A Schedule is only associated with a single Student and does not exist without a Student to be associated to.





51




For each resulting analysis class Describe Responsibilities Describe Attributes and AssociationsQualify Analysis Mechanisms


At this point, we have a pretty good understanding of the analysis classes, their responsibilities, and the collaborations required to support the functionality described in the use cases.

Now we must look into how each of the defined analysis classes implements the analysis mechanisms identified in Architectural Analysis.

The purpose of the Qualify Analysis Mechanisms step is to:

• Identify analysis mechanisms (if any) used by the class. • Provide additional information about how the class applies the analysis

mechanism. For each such mechanism, qualify as many characteristics as possible, giving ranges where appropriate, or when there is still much uncertainty.

Different architectural mechanisms will have different characteristics, so this information is purely descriptive and need only be as structured as necessary to capture and convey the information. During Analysis, this information is generally quite speculative, but the capturing activity has value, since conjectural estimates can be revised as more information is uncovered. The analysis mechanism characteristics should be documented with the class.




Review: Why Use Analysis Mechanisms?

52

Review: Why Use Analysis Mechanisms?

Oh no! I found a group of classes that has persistent data. How am I supposed to design these things if I don’t even know what database we are going to be using?

That is why we have a persistence analysis mechanism. We don’t know enough yet, so we can bookmark it and come back to it later.

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.

An analysis mechanism represents a pattern that constitutes a common solution to a common problem. These mechanisms may 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. Analysis mechanisms are primarily used as “placeholders” for complex technology in the middle and lower layers of the architecture. By using mechanisms as “placeholders” in the architecture, the architecting effort is less likely to become distracted by the details of mechanism behavior.

Mechanisms allow the Analysis effort to focus on translating the functional requirements into software concepts without bogging down in the specification of relatively complex behavior needed to support the functionality but which is not central to it. Analysis mechanisms often result from the instantiation of one or more architectural or analysis patterns. Persistence provides an example of analysis mechanisms. A persistent object is one that logically exists beyond the scope of the program that created it. During analysis, we do not want to be distracted by the details of how we are going to achieve persistence.This gives rise to a “persistence” analysis mechanism that allows us to speak of persistent objects and capture the requirements we will have on the persistence mechanism without worrying about what exactly the persistence mechanism will do or how it will work.

Analysis mechanisms are typically, but not necessarily, unrelated to the problem domain, but instead are "computer science" concepts. As a result, they typically occupy the middle and lower layers of the architecture. They provide specific behaviors to a domain-related class or component, or correspond to the implementation of cooperation between classes and/or components.





53


Collect all analysis mechanisms in a listDraw a map of the client classes to the analysis mechanismsIdentify characteristics of the analysis mechanisms

In Architectural Analysis, the possible analysis mechanisms were identified and defined.

From that point on, as classes are defined, the required analysis mechanisms and analysis mechanism characteristics should be identified and documented. Not all classes will have mechanisms associated with them. Also, it is not uncommon for a client class to require the services of several mechanisms.

A mechanism has characteristics, and a client class uses a mechanism by qualifying these characteristics. This is to discriminate across a range of potential designs. These characteristics are part functionality, and part size and performance.




Example: Describing Analysis Mechanisms

54

Analysis Class Analysis Mechanism(s)

StudentScheduleCourseOfferingCourseRegistrationController

Persistency, Security

Persistency, Legacy InterfacePersistency, Legacy InterfaceDistribution


Example: Describing Analysis Mechanisms

Analysis class to analysis mechanism map

As analysis classes are identified, it is important to identify the analysis mechanisms that apply to the identified classes.

The classes that must be persistent are mapped to the persistency mechanism.

The classes that are maintained within the legacy Course Catalog system are mapped to the legacy interface mechanism.

The classes for which access must be controlled (that is, control who is allowed to read and modify instances of the class) are mapped to the security mechanism. Note: The legacy interface classes do not require additional security as they are read-only and are considered readable by all.

The classes that are seen to be distributed are mapped to the distribution mechanism. The distribution identified during analysis is that which is specified/implied by the user in the initial requirements. Distribution will be discussed in detail in the Describe Distribution module. For now, just take it as an architectural given that all control classes are distributed for the OOAD course example and exercise.




Example: Describing Analysis Mechanisms (continued)

55

Example: Describing Analysis Mechanisms (continued)

Analysis mechanism characteristicsPersistency for Schedule class:

Granularity: 1 to 10 Kbytes per product Volume: up to 2,000 schedulesAccess frequency• Create: 500 per day• Read: 2,000 access per hour• Update: 1,000 per day• Delete: 50 per day

Other characteristics

The above is just an example of how the characteristics for an analysis mechanism would be documented for a class. For scoping reasons, the analysis mechanisms and their characteristics are not provided for all of the analysis classes.





56






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.

The purpose of Unify Analysis Classes is to ensure that each analysis class represents a single well-defined concept, with non-overlapping responsibilities.




Unify Analysis Classes

57

Unify Analysis Classes


Close Registration

Student

CourseOffering

CourseOffering

StudentCloseRegistrationController


CloseRegistrationForm

CourseCatalogSystem

Schedule

CourseCatalogSystem

CourseOffering

Schedule


Student

CloseRegistrationController

Schedule

CourseCatalogSystem

BillingSystem



BillingSystemCloseRegistration

Form

Before the Design work can be done, the analysis classes need to be filtered to ensure that a minimum number of new concepts have been created.

Different use cases will contribute to the same classes. In the example above, the classes CourseCatalogSystem, CourseOffering, Schedule and Student participate in both the Register for Courses and Close Registration use cases.

A class can participate in any number of use cases. It is therefore important to examine each class for consistency across the whole system.

Merge classes that define similar behaviors or that represent the same phenomenon.

Merge entity classes that define the same attributes, even if their defined behavior is different; aggregate the behaviors of the merged classes.

When you update a class, you should update any “supplemental” use-case descriptions (described earlier in this module), where necessary. Sometimes an update to the original Requirements (that is, use cases) may be necessary, but this should be controlled, as the Requirements are the contract with the user/customer, and any changes must be verified and controlled.




Evaluate Your Results

58

Design Model

Analysis Classes

Evaluate Your Results


Glossary

Use-Case Model

We now have a pretty good feeling about our Analysis Model. Now it is time to review our work for completeness and consistency.

Be sure to:

• Verify that the analysis classes meet the functional requirements made on the system.

• Verify that the analysis classes and their relationships are consistent with the collaborations they support.

It is very important that you evaluate your results at the conclusion of the Use-Case Analysis.

The number of reviews, the formality of the reviews, and when they are performed will vary, depending on the process defined for the project.





59






This is where the quality of the model up to this point is assessed against some very specific criteria.

In this module, we will concentrate on those checkpoints that the designer is most concerned with (that is, looks for).




Checkpoints: Analysis Classes

60

Checkpoints: Analysis Classes

Are the classes reasonable?Does the name of each class clearly reflect the role it plays?Does the class represent a single well-defined abstraction? Are all attributes and responsibilities functionally coupled?Does the class offer the required behavior?Are all specific requirements on the class addressed?

The above checkpoints for the analysis classes might be useful.

Note: All checkpoints should be evaluated with regards to the use cases being developed for the current iteration.

The class should represent a single well-defined abstraction. If not, consider splitting it.

The class should not define any attributes or responsibilities that are not functionally coupled to the other attributes or responsibilities defined by that class.

The classes should offer the behavior the Use-Case Realizations and other classes require.

The class should address all specific requirements on the class from the requirement specification.

Remove any attributes and relationships if they are redundant or are not needed by the Use-Case Realizations.




Checkpoints: Use-Case Realizations

61

Checkpoints: Use-Case Realizations

Have all the main and/or sub-flows been handled, including exceptional cases?Have all the required objects been found?Has all behavior been unambiguously distributed to the participating objects? Has behavior been distributed to the right objects?Where there are several Interaction diagrams, are their relationships clear and consistent?

The above checkpoints for the Use-Case Realizations might be useful.

Note: All checkpoints should be evaluated with regards to the use cases being developed for the current iteration.

The objects participating in a Use-Case Realization should be able to perform all of the behavior of the use case.

If there are several Interaction diagrams for the Use-Case Realization, it is important that it is easy to understand which Interaction diagrams relate to which flow of events. Make sure that it is clear from the flow of events description how the diagrams are related to each other.




Review

62

Review: Use-Case Analysis

What is the purpose of Use-Case Analysis?What is a Use-Case Realization?What is an analysis class? Name and describe the three analysis stereotypes.Describe some considerations when allocating responsibilities to analysis classes.What two questions does multiplicity answer?




Exercise: Use-Case Analysis

63

Exercise: Use-Case Analysis

Given the following:Use-Case Model, especially the use-case flows of events • Exercise Workbook: Payroll Requirements, Use-Case

Model sectionKey abstractions/classes • Payroll Exercise Solution, Architectural Analysis section

The Supplementary Specification• Exercise Workbook: Payroll Requirements,

Supplementary Specification sectionThe possible analysis mechanisms• Exercise Workbook: Payroll Architecture Handbook,

Architectural Mechanisms, Analysis Mechanisms section

The goal of this exercise is to identify classes that must collaborate to perform a use case, allocate the use-case responsibilities to those classes, and diagram the collaborations.

Good sources for the analysis classes are the Glossary and any analysis classes defined during Architectural Analysis.

References to the givens:

• Use-Case Model: Exercise Workbook - Payroll Requirements, Use-Case Model section.

• Key abstractions: Payroll Exercise Solution, Architectural Analysis section. • Supplementary Specification: Exercise Workbook - Payroll Requirements,

Supplementary Specification section. • The analysis mechanisms we are concentrating on in this course include:

persistency, distribution, security, and legacy interface). See the Exercise Workbook: Payroll Architecture Handbook, Architectural Mechanisms, Analysis Mechanisms section for more information on these analysis mechanisms.




Exercise: Use-Case Analysis (continued)

64


Identify the following for a particular use case:

The analysis classes, along with their:• Brief descriptions• Stereotypes• Responsibilities

The collaborations needed to implement the use caseAnalysis class attributes and relationships

When identifying analysis classes from the use-case flows of events, use the analysis stereotypes for guidance (boundary, control, and entity).

Be sure to define the identified classes. These definitions become very important as you start to allocate responsibilities to those classes.

The relationships to be identified are those needed to support the collaborations modeled in the use-case Interaction diagrams. The attributes to be identified are the “obvious” properties of the identified classes. More attributes may be defined during later Class Design.

For each identified analysis class, determine if any of the analysis mechanisms apply. To make this decision, the Supplementary Specification may be needed.

Refer to the following slides if needed:

• Example: Finding Boundary Classes – p. 6-16 • Example: Finding Entity Classes – p. 6-20 • Example: Finding Control Classes – p. 6-24 • Describe Responsibilities – p. 6-37 • Finding Attributes – p. 6-42 • Finding Relationships – p. 6-44 • Example: Describing Analysis Mechanisms – p. 6-55





65


Produce the following for a particular use case:

Use-Case Realization Interaction diagram for at least one of the use-case flows of eventsVOPC class diagram, containing the analysis classes, their stereotypes, responsibilities, attributes, and relationships Analysis class to analysis mechanism map

Start with diagramming the basic flow and then do the other sub-flows if you have time.

The Interaction diagrams may be Communication or Sequence diagrams. On an Interaction diagram, sending a message to an object means that you are allocating responsibility for performing that task to the object.

Be sure to use the “//” naming convention for responsibilities.


• Review: What is a Use-Case Realization? – p. 6-10 • Example: Sequence Diagram – p. 6-31 • Example: Communication diagram – p. 6-33 • Example: VOPC Finding Relationship – p. 6-50




Exercise: Review

66

Exercise: Review

Compare your Use-Case Realization with the rest of the class

Do the Interaction diagrams carry out the use-case flow of events?Are the stereotypes behaving properly?Is each association supported by a link?Does each association have multiplicity assigned? Have role names been assigned? Do they accurately represent the face the class plays in the relationship?

Payroll System

After completing a model, it is important to step back and review your work. Some helpful questions are the following:

• Has the use case behavior been successfully represented in the model? In other words, is the flow of events the same in the specifications as it is in the model?

• Has there been any significant behavior that was added? Removed? Changed? The model should reflect the intent of the Use-Case Specifications.

• Is each stereotype behaving properly? Are actors only interfacing with boundary classes? Are control classes controlling the use-case flow of events only? Are any classes doing operations on data (attributes) that are not owned by that class?







June 2004











Contents

Module 7 Identify Design Elements Identify Design Elements Overview ................................................................ 7-4 Identifying Design Classes .............................................................................. 7-8 Identifying Interfaces.................................................................................... 7-28 Identify Reuse Opportunities........................................................................ 7-36 Layering Considerations ............................................................................... 7-41 Review ........................................................................................................ 7-55

Module 8 Identify Design Mechanisms Identify Design Mechanisms Overview........................................................... 8-4 What Is a Design Pattern? .............................................................................. 8-8 Describing Analysis Mechanisms .................................................................. 8-16 What Is a Combined Fragment? ................................................................... 8-26 Review ........................................................................................................ 8-34

Module 9 Describe the Run-Time Architecture Describe the Run-time Architecture Overview................................................ 9-4 What Is Concurrency?.................................................................................... 9-6 Identifying Processes and Threads ................................................................ 9-15 Creating and Destroying Processes and Threads ........................................... 9-19 Mapping Processes onto the Implementation ............................................... 9-22 Design Elements-to-Processes Strategies ....................................................... 9-26 Review ........................................................................................................ 9-32

Module 10 Describe Distribution Describe Distribution Overview ................................................................... 10-4 The Network Configuration........................................................................ 10-15 Process-to-Node Allocation Considerations ................................................ 10-20 What is Deployment? ................................................................................ 10-22 Distribution Mechanism............................................................................. 10-29 Review ...................................................................................................... 10-38

► ► ► Module 7 Identify Design Elements

1

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 7: Identify Design Elements

Topics

Identify Design Elements Overview....................................................................... 7-4 Identifying Design Classes..................................................................................... 7-8 Identifying Interfaces .......................................................................................... 7-28 Identify Reuse Opportunities .............................................................................. 7-36 Layering Considerations...................................................................................... 7-41 Review............................................................................................................... 7-55




Objectives: Identify Design Elements

2

Objectives: Identify Design Elements

Define the purpose of Identify Design Elements and demonstrate where in the lifecycle it is performedAnalyze interactions of analysis classes and identify Design Model elements

Design classesSubsystemsSubsystem interfaces

In this module, we will describe WHAT is performed in Identify Design Elements, but will not describe HOW to do it. Such a discussion is the purpose of an architecture course, which this course is not.

Understanding the rationale and considerations that support the architectural decisions is needed in order to understand the architecture, which is the framework in which designs must be developed.



Module 7 - Identify Design Elements

Identify Design Elements in Context

3

Identify Design Elements in Context[Early





Synthesis

Analyze Behavior


DesignComponents

Design theDatabase

(Optional)Identify DesignElements Architect

As you may recall, the above diagram illustrates the workflow that we are using in this course. It is a tailored version of the Analysis and Design core workflow of the Rational Unified Process. Identify Design Elements is an activity in the Refine the Architecture workflow detail.

In Architectural Analysis, an initial attempt was made to define the layers of our system, concentrating on the upper layers. In Use-Case Analysis, you analyzed your requirements and allocated the responsibilities to analysis classes.

In Identify Design Elements, the analysis classes are refined into design elements (design classes and subsystems).

In Use-Case Analysis, you were concerned with the “what.” In the architecture activities, you are concerned with the “how” (for example, Design). Architecture is about making choices.




Identify Design Elements Overview

4


Identify Design

Elements

SoftwareArchitectureDocument

Design Model

Identify Design Elements Overview

Analysis Model


The architect performs Identify Design Elements, once per iteration.

Purpose

• To analyze interactions of analysis classes to identify Design Model elements Input Artifacts

• Supplementary Specifications • Project Specific Guidelines • Software Architecture Document • Analysis Classes • Analysis Model • Design Model Resulting Artifacts

• Design Model elements • Classes • Packages • Subsystems




Identify Design Elements Steps

5


Identify classes and subsystemsIdentify subsystem interfacesUpdate the organization of the Design ModelCheckpoints

The above are the topics we will be discussing within the Identify Design Elements module. Unlike the designer activity modules, we will not be discussing each step of the activity, as the objective of this module is to understand the important Identify Design Elements concepts, not to learn HOW to create an architecture.





6


Identify classes and subsystemsIdentify subsystem interfacesIdentify reuse opportunitiesUpdate the organization of the Design ModelCheckpoints

Analysis Classes

The purpose of Identify Classes and Subsystems is to refine the analysis classes into appropriate Design Model elements.

Remember, analysis classes will seldom retain their same structure through Design. Analysis classes may be expanded, collapsed, combined, or even deleted in Design.




From Analysis Classes to Design Elements

7

From Analysis Classes to Design ElementsAnalysis Classes Design Elements

<<boundary>>

<<control>>

<<entity>>

<<boundary>>

Many-to-Many Mapping



Identify Design Elements is 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 Elements that 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.




Identifying Design Classes

8

Identifying Design Classes

An analysis class maps directly to a design class if:

It is a simple classIt represents a single logical abstraction

More complex analysis classes may Split into multiple classesBecome a packageBecome a subsystem (discussed later)Any combination …

If the analysis class is simple and already represents a single logical abstraction, then it can be directly mapped, one-to-one, to a design class. Typically, entity classes survive relatively intact into Design.

Throughout the design activities, analysis classes are refined into design elements (for example, design classes, packages, and subsystems). Some analysis classes may be split, joined, removed, or otherwise manipulated. In general, there is a many-to-many mapping between analysis classes and design elements. The possible mappings include the following. • An analysis class can become:

• One single class in the Design Model. • A part of a class in the Design Model. • An aggregate class in the Design Model (meaning that the parts in this

aggregate may not be explicitly modeled in the Analysis Model.) • A group of classes that inherits from the same class in the Design Model. • A group of functionally related classes in the Design Model (for example, a

package). • A subsystem in the Design Model . • A relationship in the Design Model.

• A relationship between analysis classes can become a class in the Design Model. • Part of an analysis class can be realized by hardware, and not modeled in the

Design Model at all. • Any combination of the above.




Review: Class and Package

9

What is a class?A description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics

What is a package?A general purpose mechanism for organizing elements into groupsA model element which can contain other model elements

Review: Class and Package

Package Name

Class Name

A package is a general purpose mechanism for organizing elements into groups. They provide the ability to organize the model under development. A package is represented as a tabbed folder.

Later in this module, we will contrast “vanilla” packages, as defined above, with subsystems.




Group Design Classes in Packages

10

You can base your packaging criteria on a number of different factors, including:

Configuration unitsAllocation of resources among development teamsReflect the user typesRepresent the existing products and services the system uses

Package C

Group Design Classes in Packages

Package B

Package A

When identifying classes, you should group them into packages, for organizational and configuration management purposes.

The Design Model can be structured into smaller units to make it easier to understand. By grouping Design Model elements into packages and subsystems, then showing how those groupings relate to one another, it is easier to understand the overall structure of the model.

You might want to partition the Design Model for a number of reasons:

• You can use packages and subsystems as order, configuration, or delivery units when a system is finished.

• Allocation of resources and the competence of different development teams might require that the project be divided among different groups at different sites.

• Subsystems can be used to structure the Design Model in a way that reflects the user types. Many change requirements originate from users; subsystems ensure that changes from a particular user type will affect only the parts of the system that correspond to that user type.

• Subsystems are used to represent the existing products and services that the system uses.




Packaging Tips: Boundary Classes

11

Packaging Tips: Boundary ClassesIf it is likely the system interface will undergo considerable changes

Boundary classes placed in separate packages

If it is unlikely the system interface will undergo considerable changes

Boundary classes packaged with functionally related classes

When the boundary classes are distributed to packages, there are two different strategies that can be applied. Which one to choose depends on whether or not the system interfaces are likely to change greatly in the future.

• If it is likely that the system interface will be replaced, or undergo considerable changes, the interface should be separated from the rest of the Design Model. When the user interface is changed, only these packages are affected. An example of such a major change is the switch from a line-oriented interface to a window-oriented interface.

• If no major interface changes are planned, changes to the system services should be the guiding principle, rather than changes to the interface. The boundary classes should then be placed together with the entity and control classes with which they are functionally related. This way, it will be easy to see what boundary classes are affected if a certain entity or control class is changed.

Mandatory boundary classes that are not functionally related to any entity or control classes, should be placed in separate packages, together with boundary classes that belong to the same interface.

If a boundary class is related to an optional service, group it in a separate subsystem with the classes that collaborate to provide the service. The subsystem will map onto an optional component that will be provided when the optional functionality is ordered.




Packaging Tips: Functionally Related Classes

12

Packaging Tips: Functionally Related Classes

Criteria for determining if classes are functionally related:

Changes in one class' behavior and/or structure necessitate changes in another classRemoval of one class impacts the other classTwo objects interact with a large number of messages or have a complex intercommunicationA boundary class can be functionally related to a particular entity class if the function of the boundary class is to present the entity classTwo classes interact with, or are affected by changes in the same actor

A package should be identified for each group of classes that are functionally related. There are several practical criteria that can be applied when judging if two classes are functionally related. These are, in order of diminishing importance:

• If changes in one class' behavior and/or structure necessitate changes in another class, the two classes are functionally related.

• It is possible to find out if one class is functionally related to another by beginning with a class — for example, an entity class — and examining the impact of it being removed from the system. Any classes that become superfluous as a result of a class removal are somehow connected to the removed class. By superfluous, we mean that the class is only used by the removed class, or is itself dependent upon the removed class.

• Two objects can be functionally related if they interact with a large number of messages, or have an otherwise complicated intercommunication.

• A boundary class can be functionally related to a particular entity class if the function of the boundary class is to present the entity class.

• Two classes can be functionally related if they interact with, or are affected by changes in, the same actor. If two classes do not involve the same actor, they should not lie in the same package. The last rule can, of course, be ignored for more important reasons.




Packaging Tips: Functionally Related Classes (continued)

13

Packaging Tips: Functionally Related Classes (continued)

Criteria for determining if classes are functionally related (continued):

Two classes have relationships between each otherOne class creates instances of another class

Criteria for determining when two classes should NOT be placed in the same package:

Two classes that are related to different actors should not be placed in the same packageAn optional and a mandatory class should not be placed in the same package

• Two classes can be functionally related if they have relationships between each

other (associations, aggregations, and so on). Of course, this criterion cannot be followed mindlessly but can be used when no other criterion is applicable.

• A class can be functionally related to the class that creates instances of it. These two criteria determine when two classes should not be placed in the same package:

• Two classes that are related to different actors should not be placed in the same package.

• An optional and a mandatory class should not be placed in the same package.




Package Dependencies: Package Element Visibility

14

PackageB

PackageA

Public visibility

Private visibility

Only public classes can be referenced

outside of the owning package

OO Principle: Encapsulation

Package Dependencies: Package Element Visibility

A

B

+ Class A1

+ Class A2

+ Class A3

+ Class B1

- Class B2

In Architectural Analysis, we discussed package dependencies. Now let’s look at package dependencies in more detail and see how visibility can be defined.

Visibility can be defined for package elements the same way it is defined for class attributes and operations. This visibility allows you to specify how other packages can access the elements that are owned by the package.

The visibility of a package element can be expressed by including a visibility symbol as a prefix to the package element name.

There are three types of visibility defined in the UML:

Public: Public classes can be accessed outside of the owning package. Visibility symbol: +.

Protected: Protected classes can only be accessed by the owning package and any packages that inherit from the owning package. Visibility symbol: #.

Private: Private classes can only be accessed by classes within the owning package. Visibility symbol: -.

The public elements of a package constitute the package’s interface. All dependencies on a package should be dependencies on public elements of the package.

Package visibility provides support for the OO principle of encapsulation.




Package Coupling: Tips

15

A

B

X

Package Coupling: Tips

Packages should not be cross-coupled

Packages in lower layers should not be dependent upon packages in upper layers

In general, dependencies should not skip layers

A B

Upper Layer

Lower Layer

C

X

X = Coupling violation

X

Package coupling is good and bad: Good, because coupling represents re-use, and bad, because coupling represents dependencies that make the system harder to change and evolve. Some general principles can be followed:

• Packages should not be cross-coupled (that is, co-dependent); for example, two packages should not be dependent on one another. In these cases, the packages need to be reorganized to remove the cross-dependencies.

• Packages in lower layers should not be dependent upon packages in upper layers. Packages should only be dependent upon packages in the same layer and in the next lower layer. In these cases, the functionality needs to be repartitioned. One solution is to state the dependencies in terms of interfaces, and organize the interfaces in the lower layer.

• In general, dependencies should not skip layers, unless the dependent behavior is common across all layers, and the alternative is to simply pass through operation invocations across layers.

• Packages should not depend on subsystems — only on other packages or on interfaces.




Example: Registration Package

16

Example: Registration Package

MainRegistrarForm

1

11

MainStudentForm

1

RegisterForCoursesForm<<boundary>>

0..10..1

11

CloseRegistrationForm<<boundary>>

0..10..1

CloseRegistrationController<<control>>

RegistrationController<<control>>

1

The next few slides describe the packaging decisions for the Course Registration System.

All classes specifically supporting registration were partitioned into the Registration package.

For simplicity on the above diagram, only the Student Registration package classes have been shown, and the operations and attributes are not displayed.




Example: University Artifacts Package: Generalization

17

FulltimeStudent<<entity>>

ParttimeStudent<<entity>> PrimaryScheduleOfferingInfo

<<entity>>

ScheduleOfferingInfo<<entity>>

Student<<entity>>

Example: University Artifacts Package: Generalization




Example: University Artifacts Package: Associations

18

Student<<entity>>

Professor<<entity>>

Schedule<<entity>>


CourseOfferingList

1

Prerequisites0..*

Course<<entity>> 0..*

1

instructor

0..1

0..*

0..*0..*

0..*

0..4

primaryCourses

0..*

0..2alternateCourses

0..*1

Example: University Artifacts Package: Associations




Example: External System Interfaces Package

19

IBillingSystem<<Interface>>

ICourseCatalogSystem<<Interface>>

Example: External System Interfaces Package

The external system access classes were partitioned into the External System Interfaces package. This is so that the external system interface classes can be configuration-managed independently from the subsystems that realize them. For simplicity, only the External System Interfaces package classes have been shown on the above diagram. The operations and attributes are not displayed.




Review: Subsystems and Interfaces

20

Realizes one or more interfaces that define its behavior

Subsystem


InterfaceRealization (Canonical form)

Realization (Elided form)Interface Name

Subsystem Name <<subsystem>>Interface Name

<<interface>>

Subsystem Name <<subsystem>>

A subsystem is a model element that has the semantics of a package, such that it can contain other model elements, and a class, such that it has behavior. A subsystem realizes one or more interfaces, which define the behavior it can perform.

A subsystem can be represented as a UML package (that is, a tabbed folder) with the «subsystem» stereotype.

An interface is a model element that defines a set of behaviors (a set of operations) offered by a classifier model element (specifically, a class, subsystem, or component). The relationship between interfaces and classifiers (subsystems) is not always one-to-one. An interface can be realized by multiple classifiers, and a classifier can realize multiple interfaces.


The realization relationship can be modeled as a dashed line with a hollow arrowhead pointing at the contract classifier (canonical form), or when combined with an interface, as a “ball” (elided form). Thus, in the above example, the two interface/subsystem pairs with the relation between them are synonymous.

Interfaces are a natural evolution from the public classes of a package (described on the previous slide) to abstractions outside the subsystem. Interfaces are pulled out of the subsystem like a kind of antenna, through which the subsystem can receive signals. All classes inside the subsystem are then private and not accessible from the outside.




Subsystems and Interfaces (continued)

21

Subsystems and Interfaces (continued)

Subsystems :Completely encapsulate behavior Represent an independent capability with clear interfaces (potential for reuse) Model multiple implementation variants

InterfaceK

X()W()

<<Interface>>

SubsystemA<<subsystem>>

SubsystemB<<subsystem>>

ClassA1

W()

ClassA2

X()

ClassB1

W()Y()

ClassB2

X()

ClassB3

Z()

A subsystem encapsulates its implementation behind one (or more) interfaces. Interfaces isolate the rest of the architecture from the details of the implementation. Operations defined for the interface are implemented by one or more elements contained within the subsystem.

An interface is a pure specification. Interfaces provide the “family of behavior” that a classifier that implements the interface must support. Interfaces are separate things that have separate life spans from the elements that realize them.This separation of interface and implementation exemplifies the OO concepts of modularity and encapsulation, as well as polymorphism. Note: Interfaces are not abstract classes. Abstract classes allow you to provide default behavior for some or all of their methods. Interfaces provide no default behavior.

As mentioned earlier, an interface can be realized by one or more subsystems. Any two subsystems that realize the same interfaces can be substituted for one another. The benefit of this is that, unlike a package, the contents and internal behaviors of a subsystem can change with complete freedom, so long as the subsystem's interfaces remain constant.

In the above example, InterfaceK defines the operations X() and Y(). Both SubsystemA and SubsystemB realize InterfaceK, which means that they provide the implementation for operations X() and Y(). Thus, SubsystemA and SubsystemB are completely “plug-and-playable” (that is, one can be replaced by the other without any impacts on clients of the subsystems).




Packages versus Subsystems

22

Encapsulation is the key!

Packages versus Subsystems

Subsystems Provide behaviorCompletely encapsulate their contentsAre easily replaced

Subsystem A<<subsystem>>

Package BClassB1

ClassB2

Packages Don’t provide behaviorDon’t completely encapsulate their contentsMay not be easily replaced

Client Class

Subsystems and packages are very alike, but are different in some essential ways. A subsystem provides interfaces by which the behavior it contains can be accessed. Packages provide no behavior; they are simply containers of things that have behavior. Packages help organize and control sets of classes that are needed in common, but which are not really subsystems. Packages are just used for model organization and configuration management.

Subsystems completely encapsulate their contents, providing behavior only through their interfaces. Dependencies on a subsystem are on its interface(s), not on specific subsystem contents. With packages, dependencies are on specific elements within the package.

With subsystems, the contents and internal behaviors of a subsystem can change with complete freedom as long as the subsystem's interfaces remain constant. With packages, it is impossible to substitute packages for one another unless they have the same public classes. The public classes and their public operations get frozen by the dependencies that external classes have on them. Thus, the designer is not free to eliminate these classes or change their behaviors if a better idea presents itself.

Note: Even when using packages, it is important that you hide the implementation from elements external to the package. All dependencies on a package should be on the public classes of the package. Public classes can be considered the interface of the package and should be managed as such (stabilized early).




Subsystem Usage

23

Subsystems raise the level of abstraction.

Subsystem Usage

Subsystems can be used to partition the system into parts that can be independently:

ordered, configured, or delivered developed, as long as the interfaces remain unchangeddeployed across a set of distributed computational nodeschanged without breaking other parts of the systems

Subsystems can also be used to:partition the system into units which can provide restricted security over key resourcesrepresent existing products or external systems in the design (e.g. components)

Subsystems provide a “replaceable design” element: Any two subsystems (or classes, for that matter) that realize the same interfaces are interchangeable.

Subsystems support multiple implementation variants. Subsystems can be used when modeling one of many implementation variants.

Subsystems can be used to represent components from the Implementation Model in the Design Model.




Identifying Subsystems Hints

24

Identifying Subsystems Hints

Look at object collaborations.Look for optionality.Look to the user interface of the system.Look to the actors.Look for coupling and cohesion between classes.Look at substitution.Look at distribution.Look at volatility.

Object collaborations: If the classes in a collaboration interact only with each other to produce a well-defined set of results, then encapsulate them within a subsystem.

Optionality: If collaborations model optional behavior, or features that may be removed, upgraded, or replaced with alternatives, then encapsulate them within a subsystem.

User interface: Create “horizontal” subsystems (boundary classes and related entity classes in separate subsystems) or “vertical” subsystems (related boundary and entity classes in the same subsystem), depending on the coupling of the user interface and entity classes.

Actors: Partition functionality used by two different actors, since each actor can independently change requirements.

Class coupling and cohesion: Organize highly coupled classes into subsystems, separating along the lines of weak coupling.

Substitution: Represent different service levels for a particular capability (for example, high, medium, and low availability) as a separate subsystem, that realizes the same interfaces.

Distribution: If particular functionality must reside on a particular node, ensure that the subsystem functionality maps onto a single node.

Volatility: You will want to encapsulate those chunks of your system that you expect to change.




Candidate Subsystems

25

Analysis classes which may evolve into subsystems:Classes providing complex services and/or utilitiesBoundary classes (user interfaces and external system interfaces)

Existing products or external systems in the design (e.g., components):

Communication softwareDatabase access supportTypes and data structuresCommon utilitiesApplication-specific products

Candidate Subsystems

Subsystem A<<subsystem>>

Subsystem B<<subsystem>>

Subsystem C<<subsystem>>

Examples of analysis classes that may evolve into subsystems include:

• Classes providing complex services and/or utilities. For example: • Credit or risk evaluation engines in financial applications • Rule-based evaluation engines in commercial applications • Security authorization services in most applications.

• Boundary classes, both for user interfaces and external system interfaces. If the interface(s) are simple and well-defined, a single class may be sufficient. Often, however, these interfaces are too complex to be represented using a single class. They often require complex collaborations of many classes. Moreover, these interfaces may be reusable across applications. As a result, a subsystem more appropriately models these interfaces in many cases.

Examples of products the system uses that you can represent by a subsystem include:

• Communication software (middle-ware, COM/CORBA support) • Database access support (RDBMS mapping support) • Types and data structures (stacks, lists, queues) • Common utilities (math libraries) • Application-specific products (billing system, scheduler) Interfaces and subsystems provide the necessary decoupling between interface and implementation to model (in Design) what components do for Implementation.




Identifying Subsystems

26

Identifying Subsystems

<<control>>ClassA

X()W()

X()W()

<<Interface>>

“SupermanClass”

InterfaceK SubsystemA<<subsystem>>

ClassA1

X()

ClassA2

W()

When the analysis class is complex, such that it appears to embody behaviors that cannot be the responsibility of a single class acting alone, or the responsibilities may need to be reused, the analysis class should be refined into a subsystem. This is a decision based largely on conjecture guided by experience. The actual representation may take a few iterations to stabilize.

As discussed earlier, the use of a subsystem allows the interface to be defined and stabilized, while leaving the design details of the interface implementation to remain hidden while its definition evolves.

The decision to make something a subsystem is often driven by the knowledge and experience of the architect. Since it tends to have a strong effect on the partitioning of the solution space, the decision needs to be made in the context of the whole model. It is the result of more detailed design knowledge, as well as the imposition of constraints imposed by the implementation environment.

When an analysis class is evolved into a subsystem, the responsibilities that were allocated to the “superman” analysis class are then allocated to the subsystem and an associated interface (that is, they are used to define the interface operations). The details of how that subsystem actually implements the responsibilities (that is, the interface operations) is deferred until Subsystem Design.





27



Interfaces define a set of operations that are realized by some classifier. In the Design Model, interfaces are principally used to define the interfaces for subsystems. This is not to say that they cannot be used for classes as well. But for a single class it is usually sufficient to define public operations on the class. These operators, in effect, define its “interface.”

Interfaces are important for subsystems because they allow the separation of the declaration of behavior (the interface) from the realization of behavior (the specific classes within the subsystem that realize the interface). This de-coupling provides us with a way to increase the independence of development teams working on different parts of the system, while retaining precise definitions of the “contracts” between these different parts.




Identifying Interfaces

28

Stable, well-defined interfaces are key to a stable, resilient architecture.

Identifying Interfaces

PurposeTo identify the interfaces of the subsystems based on their responsibilities

StepsIdentify a set of candidate interfaces for all subsystems.Look for similarities between interfaces.Define interface dependencies.Map the interfaces to subsystems.Define the behavior specified by the interfaces.Package the interfaces.

Once the subsystems are identified, their interfaces need to be identified.

Identify candidate interfaces. Organize the subsystem responsibilities into groups of cohesive, related responsibilities. These groupings define the initial, first-cut set of interfaces for the subsystem. To start with, identify an operation for each responsibility, complete with parameters and return values.

Look for similarities between interfaces. Look for similar names, similar responsibilities, and similar operations. Extract common operations into a new interface. Be sure to look at existing interfaces as well, re-using them where possible.

Define interface dependencies. Add dependency relationships from the interface to all classes and/or interfaces that appear in the interface operation signatures.

Map the interfaces to subsystems. Create realization associations from the subsystem to the interface(s) it realizes.

Define the behavior specified by the interfaces. If the operations on the interface must be invoked in a particular order, define a state machine that illustrates the publicly visible (or inferred) states that any design element that realizes the interface must support.

Package the interfaces. Interfaces can be managed and controlled independently of the subsystems themselves. Partition the interfaces according to their responsibilities.




Interface Guidelines

29

Interface Guidelines

Interface nameReflects role in system

Interface descriptionConveys responsibilities

Operation definitionName should reflect operation resultDescribes what operation does, all parameters and result

Interface documentationPackage supporting info: sequence and state diagrams, test plans, etc.

Interface name: Name the interface to reflect the role it plays in the system. The name should be short — one-to-two words. It is not necessary to include the word "interface" in the name; it is implied by the type of model element (that is, interface).

Interface description: The description should convey the responsibilities of the interface.The description should be several sentences long, up to a short paragraph. The description should not simply restate the name of the interface. Instead, it should illuminate the role the interface plays in the system.

Operation definition: Each interface should provide a unique and well-defined set of operations. Operation names should reflect the result of the operation. When an operation sets or gets information, including “set” or “get” in the name of the operation is redundant. Give the operation the same name as the property of the model element that is being set or retrieved. Example: name() returns the name of the object; name(aString) sets the name of the object to aString.

The description of the operation should describe what the operation does, including any key algorithms, and what value it returns. Name the parameters of the operation to indicate what information is being passed to the operation. Identify the type of the parameter.

Interface documentation: The behavior defined by the interface is specified as a set of operations.




Example: Design Subsystems and Interfaces

30

All other analysis classes map directly to design classes.

Analysis Design

Example: Design Subsystems and Interfaces

BillingSystem

//submit bill()

<<boundary>>

Billing System<<subsystem>>

IBillingSystem

submitBill(forTuition : Double, forStudent : Student)

CourseCatalogSystem

//get course offerings()

<<boundary>>

Course Catalog System <<subsystem>>

ICourseCatalogSystem

getCourseOfferings(forSemester : Semester, forStudent : Student) : CourseOfferingListinitialize()

During Use-Case Analysis, we modeled two boundary classes, the BillingSystem and the CourseCatalogSystem, whose responsibilities were to cover the details of the interfaces to the external systems. It was decided by the architects of the Course Registration System that the interactions to support external system access will be more complex than can be implemented in a single class. Thus, subsystems were identified to encapsulate these responsibilities and provide interfaces that give the external systems access. The above diagram includes these subsystems, as well as their interfaces.

The BillingSystem subsystem provides an interface to the external billing system. It is used to submit a bill when registration ends and students have been registered in courses.

The CourseCatalogSystem subsystem encapsulates all the work involved for communicating to the legacy Course Catalog System. The system provides access to the unabridged catalog of all courses and course offerings provided by the university, including those from previous semesters.

These are subsystems rather than packages because a simple interface to their complex internal behaviors can be created. Also, by using a subsystem with an explicit and stable interface, the particulars of the external systems to be used (in this case, the Billing System and the legacy Course Catalog System) could be changed at a later date with no impact on the rest of the system.




Example: Analysis-Class-To-Design-Element Map

31

Analysis Class Design ElementCourseCatalogSystem

BillingSystem

All other analysis classes map directly to design classes

CourseCatalogSystem Subsystem

BillingSystem Subsystem

Example: Analysis-Class-To-Design-Element Map

The above table is an example of how you could document the mapping of analysis classes to design elements. This may be refined as the Design process continues.




Modeling Convention: Subsystems and Interfaces

32

Interfaces start with an “I”

Modeling Convention: Subsystems and Interfaces

CourseCatalogSystem<<subsystem>>

ICourseCatalogSystem + initialize ()+ getCourseOfferings ()


+ initialize ()+ getCourseOfferings ()

ICourseCatalogSystem<<interface>>

+ getCourseOfferings ()+ initialize ()

For this course, we will represent subsystems as three items in the model:

• A <<subsystem>> package (that is, package with a stereotype of <<subsystem>>),

• A <<subsystem proxy>> class (that is, class with a stereotype of <<subsystem proxy>>)

• A subsystem interface (class with a stereotype of <<interface>>. The interface names will start with an ‘I’.

The <<subsystem>> package provides a container for the elements that comprise the subsystem, the interaction diagrams that describe how the subsystem elements collaborate to implement the operations of the interfaces the subsystem realizes, and other diagrams that clarify the subsystem elements. The subsystem realizes the interface.

The <<subsystem proxy>> class realizes the interface(s) (as a proxy) and will orchestrate the implementation of the subsystem interface(s) operations. (This will be discussed further in the module on Subsystem Design.)

Such conventions make the consistent modeling of subsystems easier. We will see later in the course how we utilize this convention in representing subsystems in our diagrams.

Remember, interfaces are EXTERNAL to the subsystem package.




Example: Subsystem Context: CourseCatalogSystem

33

Example: Subsystem Context: CourseCatalogSystem

Provided interfacedefined

ICourseCatalogSystem<<Interface>>


+ // is registration open?()+ // close registration()

<<control>>

0..1

+courseCatalog


+ initialize ()+ getCourseOfferings ()

+ getCourseOfferings ( for Semester: Semester )+ initialize ()


+ getCurrentSchedule()+ deleteCurrentSchedule()+ submitSchedule()+ saveSchedule()+ getCourseOfferings()+ setSession()+ <<class>> new()+ getStudent()

<<control>>

CourseOfferingList

+ new()+ add()

1

Required interfacedefined

The above is a context diagram for the CourseCatalogSystem subsystem.

A subsystem context class diagram should contain the subsystem, interface(s), associated realizes relationship(s), and any subsystem relationships (both to/from the subsystem and from/to other design elements).

The ICourseCatalogSystem interface is dependent on the CourseOfferingList class as the CourseOfferingList class appears in the signature of one its operations.

The RegistrationController and the CloseRegistrationController classes are dependent on the ICourseCatalogSystem interface to obtain the list of CourseOfferings being offered for a particular semester.

Notice the use of the modeling conventions, especially the subsystem proxy class and the realization relationship.

In Identify Design Elements, the interfaces are completely defined, including their signatures. This is important, as these interfaces will serve as synchronization points that enable parallel development.

There is not a Semester class. It is envisioned that this will be some type of enumeration in the implementation.




Example: Subsystem Context: Billing System

34

Example: Subsystem Context: Billing System

IBillingSystem

+ submitBill(forStudent : Student, forTuition : double)

<<Interface>>1

0..1

+ Biller 1

Student<<entity>>


+ // is registration open?()+ // close registration()

<<control>>

BillingSystem<<subsystem>>

+ submitBill(forStudent : Student, forTuition : double)

The above is a context diagram for the BillingSystem subsystem.

A subsystem context class diagram should contain the subsystem, interface(s), associated realizes relationship(s), and any subsystem relationships (both to/from the subsystem and from/to other design elements).

The IBillingSystem interface is dependent on the student class as the student class appears in the signature of one its operations. (Stay tuned for dependencies in the Class Design module.)

The CloseRegistrationController is dependent on the IBillingSystem interface to bill the student for the courses he or she is enrolled in.

Notice the use of the modeling conventions, especially the subsystem proxy class and the realization relationship.





35



The identification of reuse opportunities is an important architectural step. It will help you to determine which subsystems and packages to develop, which ones to reuse, and which ones to buy. It is desirable to reuse existing components, wherever possible. Such reuse allows you to leverage existing successful implementations, eliminating (or greatly reducing) the resources needed to develop and test the component.

The identification of reuse opportunities is a unification effort, since it is determined if “things” that have been identified can be satisfied by what already exists.

The most effective reuse identification occurs after there is an understanding of the required behavior of the system and after some initial partitioning of the design elements has occurred.

On the next three slides, you will see the possible sources of reuse and how such reuse could be incorporated into the architecture.




Identify Reuse Opportunities

36

Identification of Reuse Opportunities

PurposeTo identify where existing subsystems and/or components can be reused based on their interfaces.

StepsLook for similar interfacesModify new interfaces to improve the fitReplace candidate interfaces with existing interfaces Map the candidate subsystem to existing components

Look for existing subsystems or components that offer similar interfaces. Compare each identified interface to the interfaces provided by existing subsystems or components. There usually will not be an exact match, but approximate matches can be found. Look first for similar behavior and returned values, then consider parameters. Modify the newly identified interfaces to improve the fit. There may be opportunities to make minor changes to a candidate interface that will improve its conformance to the existing interface. Simple changes include rearranging or adding parameters to the candidate interface. They also include factoring the interface by splitting it into several interfaces, one or more of which match those of the existing component, with the "new" behaviors located in a separate interface. Replace candidate interfaces with existing interfaces where exact matches occur. After simplification and factoring, if there is an exact match to an existing interface, eliminate the candidate interface and simply use the existing interface. Map the candidate subsystem to existing components. Look at existing components and the set of candidate subsystems. Factor the subsystems so that existing components are used wherever possible to satisfy the required behavior of the system. Where a candidate subsystem can be realized by an existing component, create traceability between the subsystem and the component. Note in the description for this subsystem that the behavior is satisfied by the associated existing component. In mapping subsystems onto components, consider the design mechanisms associated with the subsystem. Performance or security requirements may disqualify a component from reuse despite an otherwise perfect match between operation signatures.




Possible Reuse Opportunities

37

Software

Possible Reuse Opportunities

Internal to the system being developedRecognized commonality across packages and subsystems

External to the system being developedCommercially available componentsComponents from a previously developed applicationReverse engineered components

Software

In organizations that build similar systems, there is often a set of common components that provide many of the architectural mechanisms needed for a new system. There may also be components available in the marketplace that also fill the need for architectural mechanisms. Existing components should be examined to determine their suitability and compatibility within the software architecture. These components can be reverse engineered into the Design Model for examination and incorporation. You can then use design elements as proxies for the components. This allows you to show how what has been bought and what needs to be built interact (a necessary requirement unless you are buying all your components and only doing assembly).

The advent of commercially successful component infrastructures such as CORBA, the Internet, ActiveX and JavaBeans triggers a whole industry of off-the-shelf components for various domains, allowing you to buy and integrate components rather than developing them all in-house. Reusable components provide common solutions to a wide range of common problems and may be larger than just collections of utilities or class libraries; they form the basis of reuse within an organization, increasing overall software productivity and quality.




Reuse Opportunities Internal to System

38

?

Reuse Opportunities Internal to System

Reuse can be discovered within the current software system. There may be design elements that are needed by more than one subsystem or package. The above slide is meant to visually represent what happens as reuse is discovered: • Build the first application and some general parts. • Build the second application, and you find that some parts of the first can be

reused, but the parts were not designed to be reused. (Some are reused any way, with chaos as result). It is recognized that something is being used by one element that other elements may find useful (first diagram).

• Take the candidate reusable design elements (classes, packages, or subsystems) and make them reusable. This may involve changing their names, making them more general, improving their documentation, moving them to a common functionality layer, etc. Essentially, the candidate reusable entity is “pushed down” to a lower layer in the architecture so other elements may access it. Initially, only the original client of the element may use it (second diagram).

• Now can you use them for the new application. • When the first application is upgraded, the old versions of the elements can be

replaced with the reusable ones (third diagram). It is important for the architect to look within and across the design elements for common behavior (for example, common collaborations), pulling it out where possible. This is a reuse scavenging activity that falls under the Identify Design Elements umbrella.

Note: To see an example of reuse of a Security mechanism, refer to the Security Mechanism tab in the Additional Information Appendix.





39

Identify classes and subsystemsIdentify subsystem interfacesIdentify reuse opportunitiesUpdate the organization of the Design ModelCheckpoints ClassB

Y()Z()

ClassA

Y()Z()


ClassC

Y()Z()

ClassD

Y()Z()

ClassC

Y()Z()

ClassE

Y()Z()

As new elements have been added to the Design Model, re-packaging the elements of the Design Model is often necessary. Repackaging achieves several objectives: It reduces coupling between packages and improves cohesion within packages in the Design Model. The ultimate goal is to allow different packages (and subsystems) to be designed and developed independently of one another by separate individuals or teams. While complete independence is probably impossible to achieve, loose coupling between packages tends to improve the ease of development of large or complex systems.

As new model elements are added to the system, existing packages may grow too large to be managed by a single team: The package must be split into several packages which are highly cohesive within the package but loosely coupled between the packages. Doing this may be difficult — some elements may be difficult to place in one specific package because they are used by elements of both packages. There are two possible solutions:

• Split the element into several objects, one in each package (this works where the element has several 'personalities,' or sets of somewhat disjoint responsibilities)

• Move the element into a package in a lower layer, where all higher layer elements might depend upon it equally.

You will discuss modeling the lower layers in this step.




Review: Typical Layering Approach

40

Review: Typical Layering Approach

General functionality

Specific functionality Distinct application subsystems that make

up an application — contains the value adding software developed by the organization.

Business specific — contains a number of reusable subsystems specific to the type of business.

Middleware — offers subsystems for utility classes and platform-independent services for distributed object computing in heterogeneous environments and so on.

System software — contains the software for the actual infrastructure such as operating systems, interfaces to specific hardware, device drivers, and so on.

Application

Business-Specific

Middleware

System Software

This is a repeat of the slide first introduced in Architectural Analysis. It is included here as a review.

During Architectural Analysis, the focus was on the upper-level layers (that is, the application and business-specific layers). During Identify Design Elements, the focus is on the lower-level layers.

The layering principles originally described for packages also apply to subsystems.





41

Goal is to reduce coupling and to ease maintenance effort.


VisibilityDependencies only within current layer and below

Volatility Upper layers affected by requirements changesLower layers affected by environment changes

GeneralityMore abstract model elements in lower layers

Number of layersSmall system: 3-4 layersComplex system: 5-7 layers

Layering provides a logical partitioning of packages into layers with certain rules concerning the relationships between layers. Restricting inter-layer and inter-package dependencies makes the system more loosely coupled and easier to maintain. Failure to restrict dependencies causes architectural degradation, and makes the system brittle and difficult to maintain. Visibility: Elements should only depend on elements in the same layer and the next lower layer. Exceptions include cases where packages need direct access to lower-layer services (for example, primitive services needed throughout the system, such as printing, sending messages, and so forth). There is little value in restricting messages to lower layers if the solution is to effectively implement call pass-throughs in the intermediate layers. Volatility: In the highest layers, put elements that vary when user requirements change. In the lowest layers, put elements that vary when the implementation platform (hardware, language, operating system, database, and so forth) changes. Sandwiched in the middle, put elements that are generally applicable across wide ranges of systems and implementation environments. Add layers when additional partitions within these broad categories help to organize the model. Generality: Abstract model elements tend to be placed lower in the model, where they can be reused. If not implementation-specific, they tend to gravitate toward the middle layers. Number of Layers: For a small system, three layers are sufficient. For a complex system, five-to-seven layers are usually sufficient. For any degree of complexity, more than ten layers should be viewed with suspicion that increases with the number of layers.




Design Elements and the Architecture

42

Layer 1

Layer 2

Layer 3

Design Elements and the Architecture

The identified design elements need to be allocated to specific layers in the architecture.

The above diagram is not meant to recommend or suggest specific layers. What is meant is that layers are not “just by stereotype.” You can have boundary classes in the Business Services layer (for example, outgoing interfaces), control classes in the Middleware layer (for example, transaction manager), and so on.

Even though all three stereotypes can appear in any layer, there are general trends that may help guide a novice designer. Most boundary classes tend to appear at the top, most control classes tend to appear in the services layer where control across entities is required, and most entities appear towards the bottom layers.

An experienced designer makes packages of classes that work together to provide a service (that is, he or she groups pieces of the system together that work closely to support some high-level capability). This leads to cohesive, reusable packages.




Example: Architectural Layers

43

Example: Architectural Layers

Middleware<<layer>>

Base Reuse

global


Business Services

<<layer>>

Necessary because the Application Layer must have access to the core distribution mechanisms provided with Java RMI.

The layers defined in this activity are built on the architectural layers originally defined in Architectural Analysis.

The Middleware layer and the Base Reuse package were added in this activity.

The Middleware layer provides utilities and platform-independent services.

The Base Reuse package contains some common, generic reusable design elements and patterns.

The contents of each of these layers is described later in this module.




Partitioning Considerations

44

Partitioning Considerations

Coupling and cohesionUser organizationCompetency and/or skill areasSystem distributionSecrecyVariability

Try to avoid cyclic dependencies.

Coupling and cohesion: Design elements with tight coupling/cohesion (for example, lots of relationships and communication) should be placed in the same partition.

User organization: This occurs when an existing Enterprise Model has a strongly organizationally partitioned structure. Usually affects the top layers (application-specific services).

Competence and/or skill areas: In the middle and lower layers, specialization in skills should be considered during the development and support of complex infrastructure technology (for example, network, distribution, database, and/or communication management; process control). In the upper layers, the specialization of skills should be considered in the problem domain (for example, telecommunication call management, securities trading, insurance claims processing, and air traffic control).

System distribution: This helps to visualize the network communication, which will occur as the system executes.

Secrecy areas: Functionality requiring special security clearance must be partitioned into subsystems that will be developed independently, with the interfaces to the secrecy areas the only visible aspect of these subsystems.

Variability areas: Functionality that is likely to be optional, and thereby delivered only in some variants of the system, should be organized into subsystems.

When partitioning, try to avoid circular dependencies, as they make it impossible to reuse one package without the other.




Example: Partitioning

45

B

A Package A

Package B

Example: Partitioning

The above example shows a partitioning of design elements. The diagram on the left shows some classes divided into two partitions, A and B. The diagram on the right shows the resulting packages.

Notice the following:

• Maximum coupling and cohesion within packages versus minimal coupling between packages (left diagram).

• The dependencies between packages (right diagram) reflect/support the dependencies between the classes contained within the packages (left diagram).




Example: Application Layer

46

Registration

<<layer>>Application

Example: Application Layer

The next few slides describe the layering decisions for the Course Registration System.

The Application layer contains application-specific design elements.

The Registration package that was previously defined has been allocated to the Application layer.

In the Course Registration example, we have been concentrating on the Student Registration application. As additional applications are defined within the Course Registration System, additional packages could be added to the Application layer — for example, Student Evaluation.




Example: Application Layer Context

47

Security

GUI FrameworkSecure Interfaces


Business Services

<<layer>>


<<layer>>Business Services

Example: Application Layer Context


Registration

External System Interfaces

The Registration package depends on the University Artifacts package for the core abstractions, the External System Interface packages for the external system interfaces, and the GUI Framework and Security Interfaces packages for the security framework.

Notice how the package dependencies are consistent with the layer dependencies.




Example: Business Services Layer

48

Example: Business Services Layer



UniversityArtifacts

ObjectStore Support


GUIFramework

SecureInterfaces

Security

<<subsystem>>SecurityManager


The Business Services layer contains business-specific elements that are used in several applications.

The external system access subsystems, their interfaces, the key abstractions package, the OODBMS persistency support package, and the security package were placed in the Business Services layer. It is anticipated that these packages might be required by multiple applications.




Example: Business Services Layer Context

49

Middleware<<layer>>

Business Services

<<layer>>

Example: Business Services Layer Context

java.sqlcom.odi

<<layer>>Middleware





ObjectStoreSupport


GUIFramework

SecureInterfaces

Security

<<subsystem>>SecurityManager

The above diagram models the context of the Business Services layer. It models the relationships that the Business Services layer has with the other layers in our architecture, and shows how the design element dependencies are consistent with the layer dependencies.

Packages within the Business Services layer require access to the com.odi and java.sql packages in order to utilize the core persistency mechanisms.




Example: Middleware Layer

50

com.odi

Database(from com.odi)

Session(from com.odi)

Transaction(from com.odi)

Map(from com.odi)

java.sql

ResultSet(from com.odi)

Connection(from com.odi)

Statement(from com.odi)

DriverManager(from com.odi)

Example: Middleware Layer

<<layer>>Middleware

The Middleware layer provides utilities and platform-independent services.

All of these packages are commercially available, com.odi from ObjectStore and java.sql with most standard Java IDEs.





51



This is where the quality of the architecture modeled up to this point is assessed against some very specific criteria.

In this module, we will concentrate on those checkpoints that the designer is most concerned with. The architect should do a much more detailed review of the Identify Design Elements results and correct any problems before the project moves on to the next activity. We will not cover those checkpoints, as they are out of scope of this course. (Remember, this is not an architecture course.)




Checkpoints

52

CheckpointsGeneral

Does it provide a comprehensive picture of the services of different packages? Can you find similar structural solutions that can be used more widely in the problem domain?

LayersAre there more than seven layers?

SubsystemsIs subsystem partitioning done in a logically consistent way across the entire model?

The next few slides contain the key things a designer would look for when assessing the results of Identify Design Elements. As stated earlier, an architect would have a more detailed list.

A well-structured architecture:

• Encompasses a set of classes, typically organized into multiple hierarchies. • Provides a set of collaborations that specify how those classes cooperate to

provide various system functions.





53


PackagesAre the names of the packages descriptive? Does the package description match with the responsibilities of contained classes?Do the package dependencies correspond to the relationships between the contained classes?Do the classes contained in a package belong there according to the criteria for the package division?Are there classes or collaborations of classes within a package that can be separated into an independent package?Is the ratio between the number of packages and the number of classes appropriate?

If the classes contained in a package do not belong there according to the criteria for the package division then move them to other packages or create more packages.

If the classes in the packages are not related functionally, then move some of the classes to other packages or create more packages.

As a guideline regarding an appropriate ratio between the number of packages and the number of classes, 5 packages and 1,000 classes is probably a sign that something is wrong.





54


ClassesDoes the name of each class clearly reflect the role it plays? Is the class cohesive (i.e., are all parts functionally coupled)?Are all class elements needed by the use-case realizations? Do the role names of the aggregations and associations accurately describe the relationship? Are the multiplicities of the relationships correct?

A well-structured class:

• Provides a crisp abstraction of some thing drawn from the vocabulary of the problem domain or the solution domain.

• Embodies a small, well-defined set of responsibilities, and carries them all out very well.

• Provides a clear separation of the abstraction's behavior and its implementation. • Is understandable and simple yet extensible and adaptable. A sampling of some class checkpoints are listed above. A more detailed set of checkpoints for classes will be discussed in the Class Design module.




Review

55

Review: Identify Design Elements

What is the purpose of Identify Design Elements?What is an interface?What is a subsystem? How does it differ from a package?What is a subsystem used for, and how do you identify them?What are some layering and partitioning considerations?




Exercise: Identify Design Elements

56


Given the following:The analysis classes and their relationships• Payroll Exercise Solution, Use-Case Analysis,

Part 2 (use-case realization VOPCs)

The layers, packages, and their dependencies• Exercise Workbook: Payroll Architectural

Handbook, Logical View, Architectural Layers and their Dependencies

The goal of this exercise is to identify design elements (subsystems, interfaces, design classes) and then identify the location of the design elements in the architecture.

Use the results of the Use-Case Analysis exercise as input for this activity.


• The analysis classes and their relationships: Payroll Exercise Solution, Use-Case Analysis, Part 2 (use-case realization VOPCs).

• The architectural layers and their dependencies: Exercise Workbook: Payroll Architectural Handbook, Logical View, Architectural Layers and their Dependencies.




Exercise: Identify Design Elements (continued)

57

Exercise: Identify Design Elements (continued)

Identify the following:Design classes, subsystems, their interfaces and their relationships with other design elementsMapping from the analysis classes to the design elementsThe location of the design elements (e.g. subsystems and their design classes) in the architecture (i.e., the package/layer that contains the design element)

Review the previously defined analysis classes, and look for potential subsystems, keeping in mind the subsystem usage suggestions discussed in this module. For each subsystem you choose, be prepared to justify the choice.

Remember to complete the signatures for the identified interfaces.

Note: Subsystems might be depended on by other design elements. The dependencies on a subsystem should be on the subsystem interface(s). It is important to understand the context in which the subsystem exists.

Once subsystems have been identified and their interfaces defined, it is important to document the mapping from the initial analysis classes to these design elements as this will provide analysis-to-design traceability.

Up to this point, the analysis classes were not mapped to a specific position in the architecture. (They were not mapped to packages.) It is during Identify Design Elements that we must allocate the design elements (subsystems and classes) to an appropriate place in the architecture (that is, a package and/or layer). This involves partitioning, as we discussed earlier in the module.

When partitioning the design elements, make sure that the dependencies between the packages and layers support the dependencies needed between the model elements contained in the packages and layers.





58


Produce the following:For each subsystem, an interface realization class diagramTable mapping analysis classes to design elementsTable listing design elements and their “owning” package

The interface realization class diagram should contain the subsystem proxy class, the interface(s) the subsystem realizes, the associated realization relationship(s), and any subsystem relationships (both to and from the subsystem to other design elements). Since the objective of this exercise is NOT to do the design of the subsystems, in most cases this diagram will only contain relationships TO the subsystem INTERFACE.

Be sure to use the conventions defined in the course. (For example, use the recommended stereotypes.)

The produced table should have two columns: “Design Element” and “Owning Package.” The “owning” package is the UML package that directly contains the design element.

Refer to the following slide if needed:

• Subsystem context diagrams: Slides 33-34




Exercise: Review

59

Exercise: Review

Compare your results with the rest of the class

What subsystem did you find? Is it partitioned logically? Does it realize an interface(s)? What analysis classes does it map to?Do the package dependencies correspond to the relationships between the contained classes? Are the classes grouped logically?Are there classes or collaborations of classes within a package that can be separated into an independent package?

Payroll System


• Has the use case behavior been successfully represented in the model? In other words, is the flow of events the same in the specifications as it is in the model?

• Has there been any significant behavior that was added? Removed? Changed? The model should reflect the intent of the use-case specifications.

• Is each stereotype behaving properly? Are actors only interfacing with boundary classes? Are control classes controlling the use-case flow of events only? Are any classes doing operations on data (attributes) that are not owned by that class?






► ► ► Module 8 Identify Design Mechanisms

1

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 8: Identify Design Mechanisms

Topics

Identify Design Mechanisms Overview ................................................................. 8-4 What Is a Design Pattern?..................................................................................... 8-8 Describing Analysis Mechanisms......................................................................... 8-16 What Is a Combined Fragment?.......................................................................... 8-26 Review............................................................................................................... 8-34




Objectives: Identify Design Mechanisms

2

Objectives: Identify Design Mechanisms

Define the purpose of the Identify Design Mechanisms activity and explain when in the lifecycle it is performedExplain what design and implementation mechanisms are and how they map from Analysis mechanismsDescribe some key mechanisms that will be utilized in the case study

In this module, we will describe WHAT is performed in Identify Design Mechanisms, but will not describe how to do it. Such a discussion is the purpose of an architecture course, which this course is not.

Understanding the rationale and considerations that support the architectural decisions is needed in order to understand the architecture, which is the framework in which designs must be developed.



Module 8 - Identify Design Mechanisms

Identify Design Mechanisms in Context

3

Identify Design Mechanisms in Context[Early





Synthesis

Analyze Behavior


Design theDatabase

(Optional)Identify DesignMechanisms Architect

DesignComponents

As you may recall, the above diagram illustrates the workflow that we are using in this course. It is a tailored version of the Analysis and Design core workflow of the Rational Unified Process. Identify Design Mechanisms is an activity in the Refine the Architecture workflow detail.

Identify Design Mechanisms is where we refine the analysis mechanisms into design mechanisms based on the constraints imposed by the implementation environment.




Identify Design Mechanisms Overview

4

Identify Design Mechanisms Overview


Identify Design

Mechanisms


Design Model

Analysis Class

Identify Design Mechanisms is performed by the architect, once per iteration.

Purpose

• To refine the analysis mechanisms into design mechanisms based on the constraints imposed by the implementation environment.

Input Artifacts

• Supplementary Specifications • Software Architecture Document • Analysis Class • Design Model Resulting Artifacts

• Design Model elements • Classes • Packages • Subsystems

• Software Architecture Document




Identify Design Mechanisms: Steps

5


Categorize clients of analysis mechanismsDocument architectural mechanisms

The above are the topics we will be discussing within the Identify Design Elements module. Unlike the Designer activity modules, we will not be discussing each step of the activity, as the objective of this module is to understand the important architectural concepts and not to learn how to create an architecture.





6


Categorize clients of analysis mechanismsDocumenting architectural mechanisms

Analysis mechanisms provide conceptual sets of services that are used by analysis objects. They offer a convenient shorthand for fairly complex behaviors that will ultimately have to be worried about, but that are out of scope for the analysis effort.Their main purpose is to allow us to capture the requirements of these yet-to-be designed services of the system without having to be concerned about the details of the service provider itself.

Now we must begin to refine the information gathered on the analysis mechanisms.

We discussed analysis mechanisms in Architectural Analysis. Now we will look at design and implementation mechanisms.

In this section, we will define what design and implementation mechanisms are and how they map from analysis mechanisms. We will provide abstract patterns of behavior for the mechanisms that we will utilize in the later Design activities.

The goal is not to teach you how to identify and design the presented mechanisms, but to be able to produce designs that incorporate those mechanisms.




Review: Patterns and Frameworks

7

Review: Patterns and Frameworks

PatternProvides a common solution to a common problem in a context

Analysis/Design PatternProvides a solution to a narrowly scoped technical problemProvides a fragment of a solution, or a piece of the puzzle

FrameworkDefines the general approach to solving the problemProvides a skeletal solution, whose details may be analysis/design patterns

A pattern codifies 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.

Frameworks differ 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 communication mechanisms, distribution mechanisms, error processing capabilities, transaction support, and so forth.

Frameworks can range in scope from persistence frameworks that describe the workings of a fairly complex but fragmentary part of an application, to domain-specific frameworks that are intended to be customized (such as Peoplesoft, SanFransisco, Infinity, and SAP). SAP is a framework for manufacturing and finance.





8


A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular context.

Erich Gamma et al. 1994. Design Patterns—Elements of Reusable Object-Oriented Software

Pattern Name

TemplateParameters

Design patterns are medium-to-small-scale patterns, smaller in scale than architectural patterns but typically independent of programming language. When a design pattern is bound, it forms a portion of a concrete design model (perhaps a portion of a design mechanism). Design patterns tend, because of their level, to be applicable across domains.




Examples of Pattern Usage

9

Examples of Pattern Usage

Issue a request to an object without knowing anything about the operation requested or the receiver of the request: for example, the response to a menu item, an undo request, the processing of a time-out

Command(behavioral pattern)

When the state of an object changes, the dependent objects are notified. The changed object is independent of the observers.Note: The MVC architectural pattern is an extension of the Observer design pattern

Observer(behavioral pattern)

Handle distributed objects in a way that is transparent to the client objects (remote proxy)Load a large graphical object or any entity object “costly” to create/initialize only when needed (on demand) and in a transparent way (virtual proxy)

Proxy(structural pattern)

Create GUI objects (buttons, scrollbars, windows, etc.) independent of the underlying OS: the application can be easily ported to different environments

Abstract factory(creational pattern)

ExamplePattern




Detailing the Command Pattern

10

Detailing the Command Pattern

cmd.Process();

Application

Menu

1+menu 1MenuItem

- label : String

+ Clicked()

0..*

+items

0..* Command

+ Process()

11

+cmd

The problem — imagine we want to build a reusable GUI component. To keep it simple, we will limit ourselves to the implementation of generic menus in a windowing system (in such a way that it will be possible to add new menus without having to modify the GUI component).

• Application: it is the client class, it “simulates” the application. • Menu: to simplify, we will make the assumption that our “application” has only

one menu represented by an association with a multiplicity of 1 and a role name menu.

• MenuItem: a menu is composed of menu items. • Command: this is an abstract class. It has one operation called Process. It is an

abstract operation, which means it must be overridden by subclasses of Command.

• We will now make the assumption that the underlying windowing system requires that we define in MenuItem an operation called Clicked that will be automatically invoked when the user selects the corresponding menu during execution time. The code for Clicked is (using a Java-like pseudo-code):

cmd.Process();




Detailing the Command Pattern (continued)

11


cmd.Process();

AskUser();DoOpen();

Application

Menu

1+menu 1MenuItem

- label : String

+ Clicked()

0..*

+items

0..* Command

+ Process()

11

+cmd

OpenCommand

+ Process()

Suppose now that you want to implement the menu command Open… Create a new class called OpenCommand that inherits from Command. This class overrides the operation Process to prompt the user to for the file to open and to open it:

AskUser();

DoOpen();





12


Initialization

The user selects the Open… menu item

myapp ocmd : OpenCommand

aNewItem : MenuItem

2. AddItem("Open...",ocmd)

1. OpenCommand( )

3. MenuItem("Open...", ocmd)

A user

theMenuItem cmd : Command

3. AskUser( )4. DoOpen( )

1. Clicked( ) 2. Process( )

menu

• Look at the dynamic behavior of the system: first, create an interaction diagram

showing the initialization of the system. When the system started up, the objects myapp:Application and menu:Menu were created. Then myapp creates the object ocmd:OpenCommand (message 1). Then it invokes a new operation from menu called AddItem that takes two arguments: s of type String (the label of the menu item to create) and c of type Command. Note that myapp passes to AddItem, a subclass of Command (message 2).

• Menu creates a new menu item (message 3). The arguments of the constructor for MenuItem are the same as AddItem. The code of the constructor is straightforward: label = s; cmd = c;

It is very important to note that cmd is initialized with a subclass of Command but that MenuItem “thinks” it is a Command object! This is all the magic of polymorphism!

Now, draw a second interaction diagram that will show what happens when the user selects the menu item “Open…”. The Clicked operation is invoked (message 1). Clicked simply executes the Process operation of the associated cmd object. In this case, the cmd object is actually the OpenCommand object (although this is transparent to the MenuItem object).





13


Clicked(): cmd.Process();

AskUser();DoOpen();

Application

Menu

+ AddItem(s : String, c : Command)

MenuItem- label : String

+ Clicked()+ MenuItem(s : String, c : Command)

Command

+ Process()

OpenCommand

+ Process()+ OpenCommand()- AskUser()- DoOpen()

+menu 11

+items

0..*0..*

+cmd1

MenuItem():cmd = c;label = s;

To complete the class diagram, there should be a Uses relationship from Application to OpenCommand to account for the fact that the former creates the latter, and there should be another Uses relationship from Menu to Command as the AddItem operation takes one argument of type Command.





14


app

Application CloseCommand

OpenCommand

gui

Menu MenuItem

com

Command

So what about reuse? Assign the classes to packages: OpenCommand and Application to app (you have also added a new class, CloseCommand), Menu and MenuItem to gui and Command to com, now add the appropriate dependencies. You have created a reusable set of components (gui and com) independent of the application packages using them! MenuItem can be made an Implementation class only! Only Menu is exported.




Representing Design Patterns in UML

15

Representing Design Patterns in UML

A design pattern is a parameterized collaboration:

The parameters (stereotype <<role>>) of the collaboration

ConcreteCommand

+ Process()

<<role>>

Client<<role>>

Command

+ Process()

Invoker<<role>>

Command

ClientInvokerConcreteCommand

In the example on the previous slides, the Client role was played by the classes Application and Menu, the Invoker was MenuItem, and the ConcreteCommand was OpenCommand.





16


Collect all analysis mechanisms in a listDraw a map of the client classes to the analysis mechanisms

Identify characteristics of the Analysis mechanisms

Analysis Class

Persistence, Legacy InterfacePersistence, Legacy Interface

Analysis Mechanism(s)


Persistence, Security

Distribution

Persistence, Security

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.




Categorize Analysis Mechanisms

17

Categorize Analysis Mechanisms

PurposeTo refine the information gathered on the analysis mechanisms

StepsIdentify the clients of each analysis mechanismIdentify characteristic profiles for each analysis mechanismGroup clients according to their use of characteristic profilesProceed bottom up and make an inventory of the implementation mechanisms that you have at your disposal

Identify the clients of each analysis mechanism. Scan all clients of a given analysis mechanism, looking at the characteristics they require for that mechanism. For example, a number of analysis objects might make use of a persistence mechanism, but their requirements on this can widely vary: A class that has one thousand persistent instances has significantly different persistence requirements than a class that has four million persistent instances. Similarly, a class whose instances must provide sub-millisecond response to instance data requires a different approach than a class whose instance data is accessed through batch applications.

Identify characteristic profiles for each analysis mechanism. There may be widely varying characteristics profiles, providing varying degrees of performance, footprint, security, economic cost, and so forth. Each analysis mechanism is different – so different characteristics will apply to each. Many mechanisms require estimates of the number and size of instances to be managed. The movement of large amounts of data through any system creates tremendous performance issues that must be dealt with.

Group clients according to their use of characteristic profiles. Identify a design mechanism for groups of clients that seem to share a need for an analysis mechanism with a similar characteristics profile. These groupings provide an initial cut at the design mechanisms. An example analysis mechanism, "inter-process communication," might map onto a design mechanism "object request broker." Different characteristic profiles will lead to different design mechanisms that emerge from the same analysis mechanism. The simple persistence mechanism in analysis will give rise to a number of persistence mechanisms in design: in-memory persistence, file-based, database-based, distributed, and so forth.





18


Categorize clients of analysis mechanismsDocumenting architectural mechanisms

Design mechanisms provide an abstraction of the implementation mechanisms, bridging the gap between analysis mechanisms and implementation mechanisms. The use of abstract architectural mechanisms during Design allows us to consider how we are going to provide architectural mechanisms without obscuring the problem-at-hand with the details of a particular mechanism. It also allows us to potentially substitute one specific implementation mechanism for another without adversely affecting the design.




Design and Implementation Mechanisms

19

Design and Implementation Mechanisms

Remote Method Invocation (RMI)

Persistency

AnalysisMechanism

(Conceptual)

DesignMechanism(Concrete)

ImplementationMechanism

(Actual)

OODBMS

RDBMS JDBC

ObjectStore

Java 1.2 from Sun

Legacy Data

New Data

Distribution

Persistency

During Architecture Analysis, you identified the key architectural mechanisms that might be required to solve the problem. Now it is time to refine these and incorporate the decisions made about our implementation.

Design mechanism assumes some details of the implementation environment, but it is not tied to a specific implementation (as is an implementation mechanism). Examples of design mechanisms include:

• Persistency: RDBMS, OODBMS, flash card, in-memory storage. • Inter-process communication (IPC): Shared memory, function-call-like IPC,

semaphore-based IPC. Implementation mechanisms are used during the Implementation process. They are refinements of design mechanisms, and they specify the exact implementation of the mechanism. They are are bound to a certain technology, implementation language, vendor, etc. Some examples of implementation mechanisms include the actual programming language, COTS products, database (Oracle, Sybase), and the inter-process communication/distribution technology in use (COM/DCOM, CORBA).

The above slide shows the architectural mechanism decisions that have been made for each example. For RDBMS persistency (that is, legacy data access), JDBC was chosen. For OODBMS persistency, ObjectStore was chosen, and for Distribution, RMI was chosen. The JDBC mechanism is discussed later in this module. Information on the ObjectStore and RMI mechanisms are provided in the Additional Information Appendix.




Review: Documenting Architectural Mechanisms

20

Architectural mechanisms can be treated as patterns (i.e., parameterized collaboration)

Review: Documenting Architectural Mechanisms

Structural Aspect Behavioral Aspect

Documented in Design Guidelines

Pattern Name

TemplateParameters

Design patterns as parameterized collaborations were discussed in the Architectural Analysis module. Architectural mechanisms can be treated as patterns and documented the same way (that is, as parameterized collaborations).

Like the patterns discussed in Architectural Analysis, an architectural mechanism parameterized collaboration has a structural aspect and a behavioral aspect. The structural part consists of the classes whose instances implement the mechanism and their relationships (the static view). The behavioral aspect describes how the instances collaborate (that is, send messages to each other) to implement the mechanism (the dynamic view).

The role of the architect is to decide upon and validate mechanisms by building or integrating them, as well as by verifying that they do the job. The architect must then consistently impose the mechanisms upon the rest of the system design. Thus, for each architectural mechanism the architect must provide a static and a dynamic view, accompanied by rules of use.

The mechanisms, the mapping between them, and details regarding their use, must be documented in the Design Guidelines specific to the project, not in the Software Architecture Document (SAD). The SAD captures actual architectural choices made for a system on the basis of nonfunctional requirements and functional requirements. The Design Guidelines document provides for design not yet done. In many organizations, the design guidelines exist as an organizational asset independent of particular projects. It represents the collected reusable design wisdom for that organization in a particular domain. It might then require refinement to suit a project. Therefore, the SAD is the architectural representation (or at least the most significant parts of it). The Design Guidelines cover how to do design, in a very specific, not just conceptual, way.




Review: Course Registration Analysis Mechanisms

21

Review: Course Registration Analysis Mechanisms

Security Legacy Interface

Persistence Distribution

The above slide lists the selected analysis mechanisms for the Course Registration System.

Persistency: A means to make an element persistent (that is, exist after the application that created it ceases to exist).

Distribution: A means to distribute an element across existing nodes of the system.

Security: A means to control access to an element.

Legacy Interface: A means to access a legacy system with an existing interface.

These mechanisms are also documented in the Payroll Architecture Handbook, Architectural Mechanisms section.

Next, we will discuss the design mechanisms for persistence, distribution, and security.




Mechanism: Persistency: RDBMS: JDBC

22

Mechanism: Persistency: RDBMS: JDBC

Persistence characteristics:GranularityVolumeDurationAccess mechanismAccess frequency (creation/deletion, update, read)Reliability

Note: JDBC is the standard Java API for talking to a SQL database.

These characteristics were first introduced in Architectural Analysis. When we described the persistency architectural mechanism, we used the following characteristics;

Persistency: For all classes whose instances might become persistent, we need to identify:

• Granularity: What is the range of the persistent objects? • Volume: How many objects must be kept persistent? • Duration: How long must the persistent objects be kept? • Access mechanism: How is a given object uniquely identified and retrieved? • Access frequency: Are the objects more or less constant? Are they permanently

updated? • Reliability: Can the objects survive a crash of the process, the processor, or the

whole system?




Example: Persistency: RDBMS: JDBC

23

Example: Persistency: RDBMS: JDBC

Statement

executeQuery(sql : String) : ResultSetexecuteUpdate(sql : String) : int

(from java.sql)ResultSet

getString() : String

(from java.sql)Connection

createStatement() : Statement

(from java.sql)

DriverManager

getConnection(url, user, pass) : Connection

(from java.sql)

DBClass

create() : PersistentClassread(searchCriteria : String) : PersistentClassListupdate(c : PersistentClass)delete(c : PersistentClass)

<<role>>

1

1

PersistencyClient(from SamplePersistency Client)

<<role>>

PersistentClass

getData()setData()command()new()

(from SamplePersistentClass)

<<role>>

PersistentClassList

new()add(c: PersistentClass)

(from SamplePersistentClass)

<<role>>

0..*1

0..*

Roles to be filled by the designer applying the

mechanism

The next few slides demonstrate the pattern of use of the persistent mechanism chosen for the RDBMS classes in our example: JDBC. The above diagram is the static view.

For JDBC, a client works with a DBClass to read and write persistent data. The DBClass is responsible for accessing the JDBC database using the DriverManager class. Once a database Connection is opened, the DBClass can then create SQL statements that will be sent to the underlying RDBMS and executed using the Statement class. The Statement is what “talks” to the database. The result of the SQL query is returned in a ResultSet object.

The DBClass is the one responsible for making another class instance persistent. It understands the OO-to-RDBMS mapping and has the behavior to interface with the RDBMS. The DBClass flattens the object, writes it to the RDBMS, reads the object data from the RDBMS, and builds the object. Every class that is persistent has a corresponding DBClass.

The PersistentClassList is used to return a set of persistent objects as a result of a database query (for example, DBClass.read()).

The <<role>> stereotype was used for anything that should be regarded as a placeholder for the actual design element to be supplied by the developer. This convention makes it easier to apply the mechanism, because it is easier to recognize what the designer must supply.




Example: Persistency: RDBMS: JDBC: Initialize

24

Example: Persistency: RDBMS: JDBC: Initialize

: DBClass : DriverManager

1. getConnection(url, user, pass)

Initialization must occur before any persistent class can be accessed.

To initialize the connection to the database, the DBClass must load the appropriate driver by calling the DriverManager getConnection() operation with a URL, user, and password.

getConnection() attempts to establish a connection to the given database URL. The DriverManager attempts to select an appropriate driver from the set of registered JDBC drivers.

Parameters:

url: A database url of the form jdbc:subprotocol:subname. This URL is used to locate the actual database server. It is not Web-related in this instance.

user: The database user on whose behalf the connection is being made.

password: The user's password. It returns a connection to the URL.




Example: Persistency: RDBMS: JDBC: Create

25

Example: Persistency: RDBMS: JDBC: Create: Connection : Statement: PersistencyClient : DBClass : PersistentClass

1. create( )1.1. New()

1.2. getData( )

1.3. createStatement( )

1.4. executeUpdate(String)

To create a new class, the persistency client asks the DBClass to create the new class. The DBClass creates a new instance of PersistentClass with default values. The DBClass then creates a new Statement using the Connection class createStatement() operation. The Statement is executed, and the data is inserted into the database.




What Is a Combined Fragment?

26

What Is a Combined Fragment?

A construct within an interaction that comprises an operator keyword and one or more interaction operands, each of which is a fragment of an interaction.

It is shown as a nested region within a sequence diagram.


:Client :Supplier

interaction operand

The general notation for a combined fragment is a rectangle with a small pentagon in the upper left corner containing the interaction operand. The rectangle is nested within its containing fragment or within the sequence diagram as a whole.




What is an Interaction Operand?

27

What is an Interaction Operand?

Each fragment comprises one or more interaction operands, each a subfragment of the interaction.

The number of operands depends on the type of combined fragment.• For example, a loop has one operand (the loop

body) and a conditional has one or more operands (the branches of the conditional).

An operand is a nested fragment of an interaction.• Each operand covers the lifelines covered by

the combined fragment or a subset of them.

The value of the Interaction Operand is given as text in a small compartment in the upper left corner of the Combined Fragment frame (alt, assert, break, consider, critical, ignore, loop, neg, opt, par, seq, strict). Multiple interaction operands will be separated by a dashed horizontal line and together make up the framed Combined Fragment.




What is an Interaction Expression?

28

What is an Interaction Expression?

A specification of the range of number of iterations of a loop.

Range can be specified with minimum and maximum valuesA guard condition, enclosed in square brackets, can be included on a lifeline.

1: PerformResponsibility


InteractionExpression:Client :Supplier

loop (range)

[guard exp]

The range on the number of iterations of a loop are included in parentheses as part of the tag after the keyword loop:

• loop Minimum = 0, unlimited maximum • loop (repeat) Minimum = maximum = repeat • loop (minimum, maximum) Explicit minimum and maximum bounds In addition to the bounds, a Boolean expression can be included as a guard on a lifeline. As long as the expression is true, the loop will continue to iterate.




Example: Persistency: RDBMS: JDBC: Read

29

Example : Persistency: RDBMS: JDBC: Read: PersistentClass: Connection : Statement : ResultSet: PersistencyClient : DBClass : PersistentClassList

1. read(string)


1.2. executeQuery(string)

1.5. new()

1.6. getString( )

1.7. setData( )

Returns a Statement

1.4. new( )

Create a list to hold all retrieved data

1.8. add(PersistentClass)

The SQL statement built by the DBClass using the given criteria is passed to executeQuery()The criteria used

to access data for the persistent class

loop

[for each class from execute query]

loop

[for each attribute in class]

1.3 // executeQuery()

To read a persistent class, the persistency client asks the DBClass to read. The DBClass creates a new Statement using the Connection class createStatement() operation. The Statement is executed, and the data is returned in a ResultSet object. The DBClass then creates a new instance of the PersistentClass and populates it with the retrieved data. The data is returned in a collection object, an instance of the PersistentClassList class.

Note: The string passed to executeQuery() is not the exact same string as the one passed into the read(). The DBClass builds the SQL query to retrieve the persistent data from the database, using the criteria passed into the read(). This is because we do not want the client of the DBClass to have the knowledge of the internals of the database to create a valid query. This knowledge is encapsulated within DBClass.




Example: Persistency: RDBMS: JDBC: Update

30

Example: Persistency: RDBMS: JDBC: Update: DBClass: PersistencyClient : PersistentClass : Connection : Statement

1. update(PersistentClass)


1.1. getData( )

1.3. executeUpdate(string)

execute SQL statement

To update a class, the persistency client asks the DBClass to update. The DBClass retrieves the data from the given PersistentClass object, and creates a new Statement using the Connection class createStatement() operation. Once the Statement is built the update is executed and the database is updated with the new data from the class.

Remember — that it is the DBClass’s job to “flatten” the PersistentClass and write it to the database. That is why it must be retrieved from the given PersistentClass before creating the SQL Statement.

Note: In the above mechanism, the PersistentClass must provide access routines for all persistent data so that DBClass can access them. This provides external access to certain persistent attributes that would have otherwise have been private. This is a price you have to pay to pull the persistence knowledge out of the class that encapsulates the data.




Example: Persistency: RDBMS: JDBC: Delete

31

Example: Persistency: RDBMS: JDBC: Delete

: PersistencyClient : DBClass : Connection : Statement

1. delete(PersistentClass)


1.2. executeUpdate(string)

execute SQL statement

To delete a class, the persistency client asks the DBClass to delete the PersistentClass. The DBClass creates a new Statement using the Connection class createStatement() operation. The Statement is executed, and the data is removed from the database.




Incorporating JDBC: Steps

32

1. Provide access to the class libraries needed to implement JDBC

Provide java.sql package2. Create the necessary DBClasses

Assign one DBClass per persistent class3. Incorporate DBClasses into the design

Allocate to package/layerAdd relationships from persistency clients

4. Create/Update interaction diagrams that describe:Database initializationPersistent class access: Create, Read, Update, Delete

Deferred

Incorporating JDBC: Steps

The above is a summary of the steps that can be used to implement the RDBMS persistency mechanism (JDBC). The italicized text on the slide describes the architectural decisions made in regards to JDBC for our Course Registration example. Here are some explanations:

• The java.sql package contains the design elements that support the RDBMS persistency mechanism. It will be depended on by the package(s) in which the DBClasses are placed.

• There is one DBClass per persistent class. • Once created, the DBClasses must be incorporated into the existing design.

They must be allocated to a package/layer. • Once the DBClasses have been allocated to packages/layers, the relationships to

the DBClasses from all classes requiring persistence support will need to be added.

The interaction diagrams provide a means to verify that all required database functionality is supported by the design elements. The sample interaction diagrams provided for the persistency architectural mechanisms during Identify Design Mechanisms should serve as starting points for the specific interaction diagrams defined in detailed design.

In Identify Design Mechanisms, make sure that the architecture has the necessary infrastructure (that is, that we have access to the class libraries that are needed to implement JDBC). The definition of the actual DBClasses and the development of the detailed interaction diagrams is deferred until detailed design.




Example: Incorporating JDBC

33

java.sql

ResultSet(from java.sql)

Connection(from java.sql)

Statement(from java.sql)

DriverManager(from java.sql)

Sample Persistency

Client Package

Example: Incorporating JDBC

The following changes must be made to the Course Registration Model to incorporate the JDBC persistency mechanisms:

• Access must be provided to the java.sql package that contains the design elements that support the RDBMS persistency mechanism. The packages where the created DBClasses reside must have a dependency on the java.sql package. Remember, there will be a DBClass for every RDBMS persistent class.

• The creation of the DB classes and the decision as to where they reside in the architecture will be determine during detailed design (for example, Use-Case and Subsystem Design).




Review

34

Review: Identify Design Mechanisms

What does an analysis mechanism do? What is a pattern? What makes a framework different from a pattern?Why should you categorize analysis mechanisms? Identify the steps.



► ► ► Module 9 Describe the Run-Time Architecture

1

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 9: Describe the Run-time Architecture

Topics

Describe the Run-time Architecture Overview ...................................................... 9-4 What Is Concurrency? .......................................................................................... 9-6 Identifying Processes and Threads....................................................................... 9-15 Creating and Destroying Processes and Threads .................................................. 9-19 Mapping Processes onto the Implementation...................................................... 9-22 Design Elements-to-Processes Strategies.............................................................. 9-26 Review............................................................................................................... 9-32




Objectives: Describe the Run-time Architecture

2

Objectives: Describe the Run-time Architecture

Define the purpose of the Describe the Run-time Architecture activity and when in the lifecycle it is performedDemonstrate how to model processes and threadsExplain how processes can be modeled using classes, objects and componentsDefine the rationale and considerations that support architectural decisions

The Describe the Run-time Architecture activity focuses on the identification and modeling of the independent system of control of flows (for example, process and threads) and the ways in which they communicate.

The focus of the Describe the Run-time Architecture activity is on developing the Process View of the architecture.

In this module, you will describe what is performed in Describe the Run-time Architecture but will not describe how to do it. Such a discussion is of interest in an architecture course, which this course is not.

The goal of this module is to give the student an understanding of how to model the Process View using the UML.

A comprehension of the rationale and considerations that support the architectural decisions is needed in order to understand the architecture, which is the framework in which designs must be developed.



Module 9 - Describe the Run-Time Architecture

Describe the Run-time Architecture in Context

3

Describe the Run-time Architecture in Context[Early





Synthesis

Analyze Behavior


DesignComponents

Design theDatabase

(Optional)Describe the Run-time ArchitectArchitecture

As you may recall, the above diagram illustrates the workflow that we are using in this course. It is a tailored version of the Analysis and Design core workflow of the Rational Unified Process. Describe the Run-time Architecture is an activity in the Refine the Architecture workflow detail.

At this point, the subsystems, their interfaces, and their dependencies is normally defined. The initial design classes and the packages in which they belong have also been defined.

In Describe the Run-time Architecture, the independent threads of control are identified, and the design elements (subsystems and classes) are mapped to these threads of control. The focus is on the Process View of the architecture.

If the system under development needs only to run one process, then there is no need for a separate Process View. In such a case, Describe the Run-time Architecture can be skipped.




Describe the Run-time Architecture Overview

4

Describe the Run-time Architecture Overview

Describethe Run-timeArchitecture


Design Model


The architect performs the Describe the Run-time Architecture, once per iteration.

Purpose

• To analyze concurrency requirements, to identify processes, identify inter-process communication mechanisms, allocate inter-process coordination resources, identify process lifecycles, and distribute model elements among processes.

Input Artifacts

• Supplementary Specifications • Design Model • Software Architecture Document Resulting Artifacts

• Software Architecture Document • Design Model




Key Concepts: The Process View

5

Key Concepts: The Process View

The Process View is an “architecturally significant” slice of the processes and threads of the Design Model.


Logical View

Use-Case View

Implementation View





System engineering


In Describe the Run-time Architecture, we will be concentrating on the Process View. Before we discuss the details of what occurs in Describe the Run-time Architecture, you need to review what the Process View is.

The above slide describes the model Rational uses to describe the software architecture. For each view, the stakeholder interested in it and the concern addressed in it are listed.

The Process View describes the planned process structure of the system. It is concerned with dynamic, run-time decomposition and takes into account some nonfunctional requirements, such as performance and availability. It also includes some derived requirements resulting from the need to spread the system onto several computers.

In the Process View, the system is decomposed into a set of independent tasks and threads, processes, and process groups.

The Process View describes process interaction, communication, and synchronization.




What Is Concurrency?

6

What Is Concurrency?

Example of concurrency at work:

Parallel roads require little coordination Two-way roads require some coordination for safe interactionIntersections require careful coordination

Parallel

Two-way

Intersections

Concurrency is the tendency for things to happen at the same time in a system. Concurrency is a natural phenomenon, of course. In the real world, at any given time many things are happening simultaneously. When we design software to monitor and control real-world systems, we must deal with this natural concurrency.

When dealing with concurrency issues in software systems, you must consider two important aspects:

• Being able to detect and respond to external events occurring in a random order. • Ensuring that these events are responded to in some minimum required interval. If each concurrent activity evolved independently, in a truly parallel fashion, managing them would be relatively simple: we could just create separate programs to deal with each activity. However, this is not the case. The challenges of designing concurrent systems arise mainly because of the interactions that happen between concurrent activities. When concurrent activities interact, some sort of coordination is required.

Vehicular traffic provides a useful analogy. Parallel traffic streams on different roadways having little interaction cause few problems. Parallel streams in adjacent lanes require some coordination for safe interaction, but a much more severe type of interaction occurs at an intersection, where careful coordination is required.




Why Are We Interested in Concurrency?

7

Why Are We Interested in Concurrency?

Software might need to respond to seemingly random externally generated eventsPerforming tasks in parallel can improve performance if multiple CPUs are available

Example: Startup of a systemControl of the system can be enhanced through concurrency

Some of the driving forces behind finding ways to manage concurrency are external. That is, they are imposed by the demands of the environment. In real-world systems, many things are happening simultaneously and must be addressed “in real-time” by software. To do so, many real time software systems must be “reactive.” They must respond to externally generated events that might occur at somewhat random times, in somewhat random order, or both.

Designing a conventional procedural program to deal with these situations is extremely complex. It can be much simpler to partition the system into concurrent software elements to deal with each of these events. The key phrase here is “can be,” since complexity is also affected by the degree of interaction between the events.

There also can be internally inspired reasons for concurrency. For example, performing tasks in parallel can substantially speed up the computational work of a system if multiple CPUs are available. Even within a single processor, multitasking can dramatically speed things up by preventing one activity from blocking another while waiting for I/O. A common situation in which this occurs is during the startup of a system. There are often many components, each of which requires time to be made ready for operation. Performing these operations sequentially can be painfully slow.

Controllability of the system can also be enhanced by concurrency. For example, one function can be started, stopped, or otherwise influenced in midstream by other concurrent functions — something extremely difficult to accomplish without concurrent components.




Realizing Concurrency: Concurrency Mechanisms

8

To support concurrency, a system must provide for multiple threads of controlCommon concurrency mechanisms

Multiprocessing• Multiple CPUs execute concurrently

Multitasking• The operating systems simulate

concurrency on a single CPU by interleaving the execution of different tasks

Application-based solutions• the application software takes

responsibility for switching between different branches of code at appropriate times

Realizing Concurrency: Concurrency Mechanisms

When the operating system provides multitasking, a common unit of concurrency is the process. A process is an entity provided, supported, and managed by the operating system whose sole purpose is to provide an environment in which to execute a program. The process provides a memory space for the exclusive use of its application program, a thread of execution for executing it, and perhaps some means for sending messages to and receiving them from other processes. In effect, the process is a virtual CPU for executing a concurrent piece of an application. Many operating systems, particularly those used for real-time applications, offer a “lighter weight” alternative to processes, called “threads” or “lightweight threads.” Threads are a way of achieving a slightly finer granularity of concurrency within a process. Each thread belongs to a single process, and all the threads in a process share the single memory space and other resources controlled by that process. Usually each thread is assigned a procedure to execute. Of course, multiple processors offer the opportunity for truly concurrent execution. Most commonly, each task is permanently assigned to a process in a particular processor, but under some circumstances tasks can be dynamically assigned to the next available processor. Perhaps the most accessible way of doing this is by using a “symmetric multiprocessor.” In such a hardware configuration, multiple CPUs can access memory through a common bus. Operating systems that support symmetric multiprocessors can dynamically assign threads to any available CPU. Examples of operating systems that support symmetric multiprocessors are SUN’s Solaris and Microsoft’s Windows NT.




Describe the Run-time Architecture Steps

9


Analyze concurrency requirementsIdentify processes and threadsIdentify process lifecyclesMap processes onto the implementationDistribute model elements among processes

You will discuss the above topics in the Describe the Run-time Architecture module. Unlike the designer activity modules, you will not discuss each step of the activity, since the objective of this module is to understand the important concurrency concepts, not to learn how to design the concurrency aspects of the architecture.





10






Concurrency Requirements

11

Concurrency Requirements

Concurrency requirements are driven by:

The degree to which the system must be distributed.The degree to which the system is event-driven.The computation intensity of key algorithms.The degree of parallel execution supported by the environment

Concurrency requirements are ranked in terms of importance to resolve conflicts.

Concurrency requirements define the extent to which parallel execution of tasks is required for the system. These requirements help shape the architecture.

A system whose behavior must be distributed across processors or nodes virtually requires a multi-process architecture. A system that uses some sort of Database Management System or Transaction Manager also must consider the processes that those major subsystems introduce.

If dedicated processors are available to handle events, a multi-process architecture is probably best. On the other hand, to ensure that events are handled, a uni-process architecture may be needed to circumvent the “fairness” resource-sharing algorithm of the operating system: It may be necessary for the application to monopolize resources by creating a single large process, using threads to control execution within that process.

In order to provide good response times, it might be necessary to place computationally intensive activities in a process or thread of their own so that the system still is able to respond to user inputs while computation takes place, albeit with fewer resources. If the operating system or environment does not support threads (lightweight processes), there is little point in considering their impact on the system architecture.

The above requirements are mutually exclusive and might conflict with one another. Ranking requirements in terms of importance will help resolve the conflict.




Example: Concurrency Requirements

12

Example: Concurrency Requirements

In the Course Registration System, the concurrency requirements come from the requirements and the architecture:

Multiple users must be able to perform their work concurrentlyIf a course offering becomes full while a student is building a schedule including that offering, the student must be notifiedRisk-based prototypes have found that the legacy course catalog database cannot meet our performance needs without some creative use of mid-tier processing power

The above concurrency requirements were documented in the Course Registration System Supplemental Specification (see the Course Registration Requirements Document).

The first requirement is typical of any system, but the multi-tier aspects of our planned architecture will require some extra thought for this requirement.

The second requirement demonstrates the need for a shared, independent process that manages access to the course offerings.

The third issue leads us to use some sort of mid-tier caching or preemptive retrieval strategy.





13



We have discussed what concurrency requirements are and how they drive the identification of the independent threads of control (for example, processes and threads) that will exist in the system. Now we will learn how to model those threads of control.




Key Concepts: Process and Thread

14

Key Concepts: Process and Thread

ProcessProvides heavyweight flow of controlIs stand-aloneCan be divided into individual threads

ThreadProvides lightweight flow of controlRuns in the context of an enclosing process

Process: A unique address space and execution environment in which instances of classes and subsystems reside and run. The execution environment can be divided into one or more threads of control.

Thread: An independent computation executing within the execution environment and address space defined by an enclosing process.

From UML Toolkit by Hans-Erik Eriksson and Magnus Penker —

The difference between process and thread has to do with the memory space in which they execute:

• A process executes in its own memory space and encapsulates and protects its internal structure. A process can be viewed as being a system of its own. It is initiated by an executable program. A process can contain multiple threads (that is, a number of processes can execute within a single process, sharing the same memory space).

• A thread executes in a memory space that it can share with other threads.




Identifying Processes and Threads

15

For each separate flow of control needed by the system, create a process or thread

Separate threads of control might be needed to: • Utilize multiple CPUs and/or nodes• Increase CPU utilization• Service time-related events• Prioritize activities• Achieve scalability (load sharing) • Separate the concerns among software areas• Improvement of system availability• Support major subsystems

Identifying Processes and Threads

For each separate flow of control needed by the system, create a process or a thread (lightweight process). A thread should be used in cases where there is a need for nested flow of control. (Within a process, there is a need for independent flow of control at the subtask level.)

For example, we can say (not necessarily in order of importance) that separate threads of control might be needed to:

• Utilize multiple CPUs: There may be multiple CPUs in a node or multiple nodes in a distributed system.

• Increase CPU utilization: Processes can be used to increase CPU utilization by allocating cycles to other activities when a thread of control is suspended.

• Service time-related events: For example, timeouts, scheduled activities, periodic activities.

• Prioritize activities: Separate processes allow functionality in different processes to be prioritized individually.

• Achieve scalability: Load sharing across several processes and processors. • Separation of concerns: Separating concerns between different areas of the

software, such as safety. • Improve system availability: Higher system availability from backup and

redundant processes. • Support major subsystems: Some major subsystems might require separate

processes (for example, the DBMS, and Transaction Manager).




Modeling Processes

16

Modeling Processes

Processes can be modeled using Active classes (Class Diagrams) and Objects (Interaction Diagrams)Components (Component Diagrams)

Stereotypes: <<process>> or <<thread>>Process relationships can be modeled as dependencies

<<process>>ActiveClassName

<<process>>ActiveClassName

This course will model processes and threads using Class Diagrams.

<<process>>ComponentName

You can use “active” classes to model processes and threads. An active class is a class that “owns” its own thread of execution and can initiate control activity, contrasted with passive classes that can only be acted upon. Active classes can execute in parallel (that is, concurrently) with other active classes.

The model elements can be stereotyped to indicate whether they are processes (<<process>> stereotype) or threads (<<thread>> stereotype).

Note: Even though you use “active” classes to model processes and threads, they are classes only in the meta-modeling sense. They aren’t the same kind of model elements as classes. They are only meta-modeling elements used to provide an address space and a run-time environment in which other class instances execute, as well as to document the process structure. If you try to take them further than that, confusion may result.

Process communication is modeled using dependency relationship whether you use classes or components to represent your processes.

In cases where the application has only one process, the processes may never be explicitly modeled. As more processes or threads are added, modeling them becomes important.

The Class Diagram will be used to represent the Process View for the remainder of the course.




Example: Modeling Processes: Class Diagram

17

composition

<<process>>CourseCatalogSystemAccess

<<thread>>CourseCache

<<process>>CourseRegistrationProcess

<<thread>>OfferingCache

dependency

11

1

1

<<process>>StudentApplication

Example: Modeling Processes: Class Diagram

The above example demonstrates how processes and threads are modeled. Processes and threads are represented as stereotyped classes. Separate processes have dependencies among them. When there are threads within a process composition is used. The composition relationship indicates that the threads are contained within the process (that is, cannot exist outside of the process).

The StudentApplication process manages the student functionality, including user interface processing and coordination with the business processes. There is one instance of this process for each student who is currently registering for courses.

The CourseRegistrationProcess encapsulates the course registration processing. There is one instance of this process for each student who is currently registering for courses.

The CourseRegistrationProcess talks to the separate CourseCatalogSystemAccess process, which manages access to the legacy system. CourseCatalogSystemAccess is a separate process that can be shared by multiple users registering for courses. This allows for a cache of recently retrieved courses and offerings to improve performance.

The separate threads within the CourseCatalogSystemAccess process, CourseCache, and OfferingCache are used to asynchronously retrieve items from the legacy system. This improves response time.

The above example is a subset of the Process View of the Course Registration system.





18



Now that we have identified processes and threads, we must determine when those processes and threads are created and destroyed.




Creating and Destroying Processes and Threads

19

Creating and Destroying Processes and Threads

Single-process architectureProcess creation takes place when the application startsProcess destruction takes place when the application ends

Multi-process architectureNew processes are typically created from the initial process that was created when the application was startedEach process must be individually destroyed

Note: The Course Registration System utilizes a multi-process architecture.

Each process or thread of control must be created and destroyed. In a single-process architecture, process creation occurs when the application is started, and process destruction occurs when the application ends. In multi-process architectures, new processes (or threads) are typically spawned or forked from the initial process created by the operating system when the application is started. These processes must be explicitly destroyed as well.

The sequence of events leading up to process creation and destruction must be determined and documented, as well as the mechanism for creation and deletion.




Example: Create Processes and Threads

20

Example: Create Processes and Threads

: CourseCatalogSystem Access : OfferingCache: CourseCache

1: createThread

2: createThread

Creation of threads during application startup.

In the Course Registration System, a main process is started which is responsible for coordinating the behavior of the entire system. It in turn spawns a number of subordinate threads of control to monitor various parts of the system — the devices in the system and events emanating from the Course Catalog System. The creation of these processes and threads can be shown with classes in UML, and the creation of instances of these active classes can be shown in a sequence diagram, as shown above.





21



At this point, we have defined the flows of control (for example, processes and threads). Now we need to map these "flows of control" onto the concepts supported by the implementation environment.




Mapping Processes onto the Implementation

22

Mapping Processes onto the Implementation

Processes and threads must be mapped onto specific implementation constructsConsiderations

Process couplingPerformance requirementsSystem process and thread limitsExisting threads and processesIPC resource availability

Conceptual processes must be mapped onto specific constructs in the operating environment. In many environments, there are choices of types of processes, at the very least process and threads. The choices are based on the degree of coupling (processes are stand-alone, whereas threads run in the context of an enclosing process) and the performance requirements of the system (intra-process communication between threads is generally faster and more efficient than that among processes).

In many systems, there may be a maximum number of threads per process or processes per node. These limits might not be absolute, but might be practical limits imposed by the availability of scarce resources.

The threads and processes already running on a target node need to be considered, along with the threads and processes proposed in the process architecture.





23



At this point, the processes that are to run in the implementation environment have been defined. Now it is time to determine the processes within which the identified classes and subsystems should execute.

Instances of a given design element (class or subsystem) must execute within at least one process; they might in fact execute in several different processes. The process provides an "execution environment” for the design element.

This step is where the “Design Model meet the Process View,” and where consistency is established and maintained between these two very important aspects of the system.




Design Element Allocation

24

Design Element Allocation

Instances of a given class or subsystem must execute within at least one process

They may execute in several processes

RegisterForCoursesFormMainStudentForm

Student Application Process

The purpose of this step is to determine the processes within which classes and subsystems should execute. Instances of a given class or subsystem must execute within at least one process; it might in fact execute in several different processes. The process provides an "execution environment” for the class or subsystem.

On this slide, the box represents the execution environment for the instances of the MainStudentForm and RegisterForCoursesForm.




Design Elements-to-Processes Considerations

25

Design Elements-to-Processes Considerations

Based on:Performance and concurrency requirementsDistribution requirements and support for parallel execution Redundancy and availability requirements

Class/subsystem characteristics to consider:AutonomySubordinationPersistenceDistribution

When deciding which classes and subsystems to map to which processes, there are some important characteristics to consider:

• Whether or not the class or subsystem is active, passive, or protected. • What is its lifetime? Is it contained within, or does it contain, other

classes/subsystems. • Is it persistent? • Should its state, operations, or both be distributed? Each of these considerations affects how classes and subsystems are allocated to processes.




Design Elements-to-Processes Strategies

26

Design Elements-to-Processes Strategies

Two Strategies (used simultaneously)Inside-Out

Group elements that closely cooperate and must execute in the same thread of controlSeparate elements that do not interact Repeat until you reach the minimum number of processes that still provide the required distribution and effective resource utilization

Outside-InDefine a separate thread of control for each external stimulus Define a separate server thread of control for each serviceReduce number of threads to what can be supported

Classes and subsystems can be allocated to one or more processes and threads.

Inside-Out

• Group classes and subsystems together in sets of cooperating elements that (a) closely cooperate with one another and (b) need to execute in the same thread of control. Consider the impact of introducing inter-process communication into the middle of a message sequence before separating elements into separate threads of control.

• Conversely, separate classes and subsystems that do not interact at all, placing them in separate threads of control.

• This clustering proceeds until the number of processes has been reduced to the smallest number that still allows distribution and use of the physical resources.

Outside-In

• Identify external stimuli to which the system must respond. Define a separate thread of control to handle each stimuli and a separate server thread of control to provide each service.

• Consider the data integrity and serialization constraints and then reduce this initial set of threads of control to the number that can be supported by the execution environment.




Modeling the Mapping of Elements to Processes

27

Class diagramsActive classes as processes/threads

Composition relationships from processes/threads to classes

Composition relationships from processes/threads to subsystems

Class NameProcess Name<<process>>

Process Name<<process>>

Process Name<<process>>

Modeling the Mapping of Elements to Processes

Thread Name<<thread>>

<<subsystem>>Subsystem Name

Processes and threads are composed of instances of design elements (that is, classes and subsystems). To show this allocation, class diagrams are drawn that model the processes and threads as active classes, and show the composition of the active classes (for example, composition relationships drawn from the process elements to the design elements that execute within it).

The relationship between a process (active class) and the elements it contains is always a composition (that is, aggregation-by-value) relationship, since processes contain instances of classes and subsystems.

Note: It is only necessary to model the top-most design element that is mapped to the process or thread. You do not need to model all the design elements that the top-most element has relationships with unless they are in different threads.




Process Relationships

28

ClassBProcess Y<<process>>

ClassAProcessX<<process>>

0..*

1

supports

Process Relationships

Process relationships must support design element relationships

The process relationships can be derived from the class relationships. If two classes must communicate and they have been mapped to different processes, then there must be a relationship between the two processes.

Thus, the process relationships should be justified by the associated design element relationships.




Example: Register for Course Processes

29

CourseRegistrationProcess<<process>>

StudentApplication<<process>>

CourseCatalogSystem(from CourseCatalogSystem)

<<subsystem>>

RegisterForCoursesForm(from Registration)

<<boundary>>

MainStudentForm(from Registration)

RegistrationController(from Registration)

<<control>>ICourseCatalogSystem

(from External System Interfaces)

<<Interface>>

CourseCatalogSystemAccess<<process>>

11

1

1

0..1

1

1

1

1

0..*

+courseCatalog

1

1

Example: Register for Course Processes

The above slide demonstrates how to use composition to model the mapping of design elements to the processes on which they run.

• The classes associated with the individual user interfaces have been mapped to the application process.

• The classes associated with the individual business services have been mapped to the controller process.

• The class associated with access to the legacy course catalog system has been mapped to the access process.

Notice how the process relationships (modeled using dependency relationships) support the relationships between the design elements mapped to the processes.

The above example is a subset of the Process View for the Course Registration System, specifically the processes that support the Register for Courses use-case realization.




Example: Register for Course Processes (continued)

30

CourseCache<<thread>>

Course(from University Artifacts)

<<entity>>

OfferingCache<<thread>>

CourseOffering(from University Artifacts)

<<entity>>

1 0..*

1 0..*

CourseCatalogSystemAccess<<process>>

1 1

11

Example: Register for Course Processes (continued)

The above example demonstrates how to use composition to model the mapping of design elements to the threads on which they run.

Note the additional composition relationship from the process to the threads it contains.




Checkpoints: Describe the Run-time Architecture

31

Checkpoints: Describe the Run-time Architecture

Have all the concurrency requirements been analyzed?Have the processes and threads been identified?Have the process life cycles been identified?Have the processes been mapped onto the implementation?Have the model elements been distributed among the processes?




Review

32

Review: Describe the Run-time Architecture

What is the purpose of the Describe the Run-time Architecture activity?What is a process? What is a thread?Describe some of the considerations when identifying processes.How do you model the Process View? What modeling elements and diagrams are used?




Exercise: Describe the Run-time Architecture

33


Given the following:Design elements (classes and subsystems) and their relationships• Payroll Exercise Solution, Exercise: Identify

Design Elements (subsystem context diagrams)

Processes• Exercise Workbook: Payroll Architecture

Handbook, Process View, Processes section

What classes and subsystems are mapped to what processes?• Exercise Workbook: Payroll Architecture Handbook,

Process View, Design Element to Process Mapping section

In this exercise, a part of the process architecture will be given textually. The entire process architecture will not be derived, since such a derivation is out of the scope of this course. The exercise allows you to identify the necessary process relationships and produce a visual model of the process architecture.


• Design elements and their relationships: For subsystems and interfaces: Payroll Exercise Solution, Exercise: Identify Design Elements (subsystem context diagrams). For other design elements, see their associated Analysis element relationships: Payroll Exercise Solution, Exercise: Use-Case Analysis, Part 2 (VOPC diagrams).

• Processes: Exercise Workbook: Payroll Architecture Handbook, Process View, Processes section.

• Classes and subsystems: Exercise Workbook: Payroll Architecture Handbook, Process View, Design Element to Process Mapping section.




Exercise: Describe the Run-time Architecture (continued)

34

Exercise: Describe the Run-time Architecture (continued)

Identify the following:• Process relationships

The process relationships can be derived from the class relationships. If two classes must communicate and they have been mapped to different processes, then there must be a relationship between the two processes.


• Key Concept: Processes and Threads – 9-14 • Modeling Processes – 9-16 • Example: Modeling Processes: Class Diagram – 9-17





35


Produce the following:Class diagram showing the:• Processes • Mapping of classes and

subsystems to processes• Process relationships

The Payroll process class diagram that is produced should include the design element relationships that justify the associated process element relationships. All of the design element relationships do not have to be shown. Only the design element relationships that justify the associated process element relationships must be included.


• Modeling the Mapping of Elements to Processes – 9-27 • Process Relationships – 9-28 • Example: Register for Courses Processes – 9-29 and 9-30




Exercise: Review

36

Exercise: Review

Compare your Process View with those created by the rest of the class

Are processes and threads stereotyped properly? If a thread is defined, is there a composition relationship from the process to the thread?Is there a composition relationship from the process elements to the design elements?Do the necessary relationships exist between the process elements in order to support the relationships to the design elements mapped to those process elements?

Payroll System


• Are processes and threads stereotyped properly? If a thread is defined, is there a composition relationship from the process to the thread? Processes and threads should be modeled as <<process>> and <<thread>> stereotyped classes, respectively. If a <<thread>> is defined, there must be a composition relationship from some <<process>> to the << thread>>, since a <<thread>> never exists outside the context of a <<process>>.

• Is there a composition relationship from the process elements to the design elements? There should be composition relationships modeled from the process elements to the design elements mapped to those process elements.

• Do the necessary relationships exist between the process elements in order to support the relationships to the design elements mapped to those process elements?



► ► ► Module 10 Describe Distribution

1

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 10: Describe Distribution

Topics

Describe Distribution Overview.......................................................................... 10-4 The Network Configuration .............................................................................. 10-15 Process-to-Node Allocation Considerations....................................................... 10-20 What is Deployment? ....................................................................................... 10-22 Distribution Mechanism ................................................................................... 10-29 Review............................................................................................................. 10-38




Objectives: Describe Distribution

2

Objectives: Describe Distribution

Explain the purpose of the Describe Distribution activity and when in the lifecycle it is performedDescribe how the functionality of the system can be distributed across physical nodesModel the distribution decisions of the system in the Deployment ModelArticulate the rationale and considerations that support the architectural decisions

The Describe Distribution activity is where the processes defined in the Describe the Run-time Architecture activity are allocated to actual physical nodes. Just identifying the individual processes is not enough; the relationship between the processes and the hardware must be described.

The focus of the Describe Distribution activity is on developing the Deployment View of the architecture. This activity is really only required for distributed systems.

In this module, we will describe what is performed in Describe Distribution, but will not describe how to do it. Such a discussion is the purpose of interest in an architecture course, which this course is not.

The goal of this module is to give the student an understanding of how to model the Deployment Model using the UML.

An understanding of the rationale and considerations that support the architectural decisions is needed in order to understand the architecture, which is the framework in which designs must be developed.



Module 10 - Describe Distribution

Describe Distribution in Context

3

Describe Distribution in Context[Early





Synthesis

Analyze Behavior


DesignComponents

Design theDatabase

(Optional)Describe Distribution Architect

As you might recall, the above diagram illustrates the workflow that we are using in this course. It is a tailored version of the Analysis and Design core workflow of the Rational Unified Process. In the Architectural Analysis module, distribution was identified as an analysis mechanism. This analysis mechanism was then used to indicate what classes need to be distributed. In the Identify Design Elements module, the subsystems, their interfaces, and their dependencies were defined. The initial design classes and the packages in which they belong were also defined. In addition to the definition of the design elements, the technologies and mechanisms to support distribution were selected in the Identify Design Mechanisms module. In the Describe the Run-time Architecture module, the independent threads of control were identified and the design elements were mapped to these threads of control. In Describe Distribution, the physical architecture will be modeled using nodes and connections. The independent threads of control identified in Describe the Run-time Architecture are mapped to the nodes. Describe Distribution is a separate activity, which is at the same level as Identify Design Elements and Identify Design Mechanisms. If the system under development will only run on one node, then there is no need for a separate Deployment Model. In such a case, the Describe Distribution activity can be skipped.




Describe Distribution Overview

4

DescribeDistribution

Implementation Model

Describe Distribution Overview


Deployment Model

Design Model


The Describe Distribution activity is performed by the Architect.

Purpose

The purpose of the Describe Distribution activity is to describe how the functionality of the system is distributed across physical nodes. This is required only for distributed systems.

Input Artifacts

• Software Architecture Document • Deployment Model • Implementation Model • Design Model • Supplementary Specifications Resulting Artifacts

• Software Architecture Document • Deployment Model Note: The Implementation Model is a collection of components and the implementation subsystems that contain them. Components include both deliverable components, such as executables, and components from which the deliverables are produced, such as source code files. The Implementation Model is developed in the Implementation discipline which is out of the scope of this Analysis and Design course.




Key Concepts: The Deployment View

5

Key Concepts: The Deployment View

The Deployment View is an “architecturally significant” slice of the Deployment Model.


Logical View

Use-Case View

Implementation View


Programmers

Software management

Performance, scalability, throughput

System integrators System topology, delivery, installation, communication

System engineering

Analysts/Designers

Structure

In Describe Distribution, we will concentrate on the Deployment View. Thus, before we can discuss the details of what occurs in Describe Distribution, you need to review what the Deployment View is.

The above diagram describes the model Rational uses to describe the software architecture. For each view, the stakeholder interested in the view, and the concern addressed in the view, are both listed.

The Deployment View contains the description of the various physical nodes and their interconnections for the most typical platform configurations, along with the allocation of the threads of control (from the Process View) to the physical nodes.

The Deployment View is a subset of the Deployment Model, and is necessary only if the system is distributed.

Note: All processors are considered architecturally significant, so the Deployment View of the architecture contains all processors.

The Deployment View is represented graphically on Deployment diagrams. These diagrams will be discussed in detail later in this module.




Why Distribute?

6

Why Distribute?

Reduce processor loadSpecial processing requirementsScaling concernsEconomic concernsDistributed access to the system

Before we discuss some common distribution patterns, you need to look at some of the reasons why you would distribute an application in the first place. There are many cases where the system workload cannot be handled by one processor. This can be due to special processing requirements, as in the case of digital signal processing, which may require specialized and dedicated processors. The need for distribution may also result from inherent scaling concerns, where the large number of concurrent users are simply too many to support on any single processor. Alternatively, it may result from economic concerns, where the price performance of smaller, cheaper processors cannot be matched in larger models. For some systems, the ability to access the system from distributed locations might mean that the system itself must be distributed.

The distribution of processes across two or more nodes requires a closer examination of the patterns of inter-process communication in the system. Often, there is a naïve perception that distribution of processing can “off-load” work from one machine onto a second. In practice, the additional inter-process communication workload can easily negate any gains made from workload distribution if the process and node boundaries are not considered carefully. Achieving real benefits from distribution requires work and careful planning.




Distribution Patterns

7

Distribution Patterns

Client/Server3-tierFat ClientFat ServerDistributed Client/Server

Peer-to-peer

There are a number of typical patterns of distribution in systems, depending on the functionality of the system and the type of application. Typically, the distribution pattern is described as “the architecture” of the system, although the full architecture encompasses this, but also many more things. In client/server architectures, there are specialized network processor nodes called clients and nodes called servers. Clients are consumers of services provided by servers. The distribution of the system functionality to the clients and servers distinguishes the different types or styles of client/server architectures. 3-tier : Functionality is equally divided into three logical partitions: application, business, and data services. Fat client: More functionality is placed on the client. Examples: database and file servers. Fat server: More functionality is placed on the server. Examples: Groupware, transaction, and Web servers. Distributed client/server: The application and business and data services reside on different nodes, potentially with specialization of servers in the business services and data services tiers. A full realization of a 3-tier architecture. In a Peer-to-Peer architecture, any process or node in the system can be both client and server. Each of these architectural patterns is described briefly in this module.




Client/Server Architectures

8

Thinner client, thicker server

Database Server(s)

Client/Server Architectures

Application

Business ObjectServices

Client A

Business ObjectEngine



Business Object Server

COMMTS

BeansETS

Client B

Application

DCOMADO/R CORBA Beans

Client C

WWW Browser

Web Server

HTMLCGI ASP Java



Client/server is a conceptual way of breaking up the application into service requestors (clients) and service providers (servers).

A client often services a single user and often handles end-user presentation services (GUIs). A system can consist of several different types of clients, examples of which include user workstations and network computers.

The server usually provides services to several clients simultaneously. These services are typically database, security, or print services. A system can consist of several different types of servers. For example: database servers, handling database machines such as Sybase, Ingres, Oracle, Informix; print servers, handling the driver logic, such as queuing for a specific printer; communication servers (TCP/IP, ISDN, X.25); window manager servers (X); and file servers (NFS under UNIX).

The application and business logic is distributed among both the client and the server (application partitioning).

In the above example, Client A is an example of a two-tier architecture, with most application logic located in the server. Client B is a typical three-tier architecture, with business services implemented in a Business Object Server. Client C is a typical Web-based application. You will look at each of these distribution strategies in more detail.




Client/Server: Three-Tier Architecture

9

Application Services

Business Services

Data Services

Client/Server: Three-Tier Architecture

Database Server(s)



Business Object Server

COMMTS

BeansETS

Client B

Application


Three-tier architecture is a special case of the client/server architecture in which functionality in the system is divided into three logical partitions: application services, business services, and data services. The “logical partitions” may in fact map to three or more physical nodes.

Application services, primarily dealing with GUI presentation issues, tend to execute on a dedicated desktop workstation with a graphical, windowing operating environment.

Data services tend to be implemented using database server technology, which normally executes on one or more high-performance, high-bandwidth nodes that serve hundreds or thousands of users, connected over a network.

Business services are typically used by many users in common, so they tend to be located on specialized servers as well, although they may reside on the same nodes as the data services.

Partitioning functionality along these lines provides a relatively reliable pattern for scalability: by adding servers and rebalancing processing across data and business servers, a greater degree of scalability is achieved.




Client/Server: “Fat Client” Architecture

10

Application Services

Business Services

Data Services

Client/Server: “Fat Client” Architecture

Application


Client A


Database Server(s)

The fat client distribution pattern is a special case of the client/server architecture in which much of the functionality in the system runs on the client.

The client is “fat" since nearly everything runs on it (except in a variation, called the “two-tier architecture,” in which the data services are located on a separate node). Application services, business services and data services all reside on client machine. The database server is usually on another machine.




Client/Server: Web Application Architecture

11

Application ServicesBusiness Services

Data Services

Client/Server: Web Application ArchitectureClient C

WWW Browser

Web Server

HTMLCGI ASP Java



Database Server(s)

At the other end of the spectrum from the fat client is the typical Web Application (which might be characterized as fat server or “anorexic client”). Since the client is simply a Web browser running a set of HTML pages and Java applets, Java Beans, or ActiveX components, there is very little application there at all. Nearly all work takes place on one or more Web servers and data servers.

Web applications are easy to distribute and easy to change. They are relatively inexpensive to develop and support (since much of the application infrastructure is provided by the browser and the web server). However, they might not provide the desired degree of control over the application, and they tend to saturate the network quickly if not well-designed (and sometimes despite being well-designed).




Peer-to-Peer Architecture

12

ApplicationServices

BusinessServices

Data Services

Peer-to-Peer Architecture



COMMTS

BeansETS

Application




COMMTS

BeansETS

Application


In the peer-to-peer architecture, any process or node in the system can be both client and server. Distribution of functionality is achieved by grouping inter-related services together to minimize network traffic while maximizing throughput and system utilization. Such systems tend to be complex, and there is a greater need to be aware of issues such as deadlock, starvation between processes, and fault handling.




Describe Distribution Steps

13


Define the network configurationAllocate processes to nodesDefine the distribution mechanism

The above are the topics you will discuss within the Describe Distribution module. Unlike the Designer activity modules, this module does not discuss each step of the activity, since the objective is to understand the important distribution concepts, not to learn how to design the distributed aspects of the architecture.





14



The configuration and topology of the network is modeled in order to make it understandable and check for any inconsistencies.




The Network Configuration

15

The Network Configuration

End-user workstation nodes”Headless" processing server nodesSpecial configurations

Development Test

Specialized processors

The topology of the network and the capabilities and characteristics of the processors and devices on the network determine the nature and degree of distribution possible in the system.

The following information needs to be captured:

• The physical layout of the network, including locations. • The nodes on the network, their configurations and capabilities. The

configuration includes both the hardware and the software installed on the nodes, the number of processors, the amount of disk space, the amount of memory, the amount of swap, and so forth. Hardware installed on the node can be represented using “devices.”

• The bandwidth of each segment on the network. • The existence of any redundant pathways on the network. (This will aid in

providing fault tolerance capabilities.) • The primary purpose of the node. This includes:

• Workstation nodes used by end users • Server nodes on which "headless" processing occurs • Special configurations used for development and test. • Other specialized processors

• IP design and facilities (for example, DNS and VPN), if IP network exists. • The role of the Internet in the solution.




Review: What Is a Node?

16

Review: What Is a Node?

Represents a run-time computational resource

Generally has at least memory and often processing capability.

Types:Device• Physical computational

resource with processing capability.

• May be nestedExecution Environment• Represent particular

execution platforms

<<exe env>>EE Name

<<device>>Device Name

<<device>>Sub Device

Name

The essential elements of a deployment diagram are nodes and their connectors. A node is a run-time physical object that represents a computational resource, generally having at least memory and often processing capability as well.

Execution Environment and device are types of node but the UML 2 distinction between them is rather vague.

• Devices may have artifacts deployed for execution software that controls the functionality of the device itself (physical computational resource with processing capability). Typical examples include <<print server>>, <<application server>>, <<client workstation>>, <<mobile device>>, <<embedded device>>, <<processor>>, etc. Devices may be complex and contain other devices.

• Execution Environments represent particular execution platforms, such as an operating system (<<Win2K>>, <<VxWorks>>, etc.), a workstation engine (<<workstation engine>>), a database management system <<DB2>>), etc.




Review: What Is a Connector?

17

Review: What Is a Connector?

A connector represents a:Communication mechanism• Physical medium• Software protocol

<<application server>>Server

<<RS-232>>

<<100-T Ethernet>>

Connector

<<client workstation>>Console

<<client workstation>>Kiosk

Connectors can be drawn between nodes. These connectors represent communication mechanisms and can be described by physical mediums (for example, Ethernet, fiber optic cable) or software protocol (for example, TCP/IP, RS-232). A stereotype may be used to specify the type of connector.




Review: Example: Deployment Diagram

18

Review: Example: Deployment Diagram

<<legacy RDBMS>>Course Catalog

<<Campus LAN>>

<<Campus LAN>><<Campus LAN>>

<<application server>>Registration Server

<<client workstation>>PC

Billing System

<<legacy>>

0..20001

1

1

1

1

Deployment diagrams allow you to capture the topology of the system nodes, including the assignment of run-time elements to nodes. This allows you to visually see potential bottlenecks.

A Deployment diagram contains nodes connected by associations. The associations indicate a communication path between the nodes.

The above diagram illustrates the Deployment View for the Course Registration System.

There are PC clients on the campus network.

The main business processing hardware is the Registration Server. It talks to the two machines that host the legacy systems. All nodes are on the campus network.





19






Process-to-Node Allocation Considerations

20

Process-to-Node Allocation Considerations

Distribution patternsResponse time and system throughputMinimization of cross-network trafficNode capacityCommunication medium bandwidthAvailability of hardware and communication linksRerouting requirements

Processes must be assigned to a hardware device for execution in order to distribute the workload of the system.

If the chosen architecture implies or requires a specific distribution pattern, this should be realized. Distribution patterns were discussed earlier in this module.

Those processes with fast response time requirements should be assigned to the fastest processors.

Processes should be allocated to nodes so as to minimize the amount of cross-network traffic. Network traffic, in most cases, is quite expensive. It is an order of magnitude or two slower than inter-process communication. Processes that interact to a great degree should be co-located on the same node. Processes that interact less frequently can reside on different nodes. The crucial decision, and one that sometimes requires iteration, is where to draw the line.

Additional considerations:

• Node capacity (in terms of memory and processing power) • Communication medium bandwidth (bus, LANs, WANs) • Availability of hardware and communication links • Rerouting requirements for redundancy and fault-tolerance




Review: Example: Deployment Diagram with Processes

21

<<legacy RDBMS>>Course Catalog

Review: Example: Deployment Diagram with Processes

<<Campus LAN>>

<<Campus LAN>><<Campus LAN>>

<<application server>>Registration Server


CourseCatalogSystemAccessCourseRegistrationProcessBillingSystemAccess

BillingSystem

<<legacy>>

0..2000

1

1

11

1

Deployment diagrams allow you to capture the topology of the system nodes, including the assignment of run-time elements to them. This allows you to visually see potential bottlenecks.

As discussed earlier, a Deployment diagram contains nodes connected by associations. The associations indicate a communication path between the nodes.

Nodes may contain artifacts which indicates that the artifact lives on or runs on the node. Those entities that have been “compiled away” are not shown. An example of a run-time object is a process.

The above diagram once again illustrates the Deployment View for the Course Registration System. It has been updated to include the processes which execute on the nodes. These processes are the ones that were defined in the Describe the Run-time Architecture module.

Note: No threads are shown in the above diagram, because threads always run in the context of a process.




What is Deployment?

22

What is Deployment?

Deployment is the assignment, or mapping, of software artifacts to physical nodes during execution.

Artifacts are the entities that are deployed onto physical nodes• Processes are assigned to computers

Artifacts model physical entities.Files, executables, database tables, web pages, etc.

Nodes model computational resources.Computers, storage units.




Example: Deploying Artifacts to Nodes

23

Example: Deploying Artifacts to Nodes


StudentApplication



<<deploy>>



Here are three examples of valid UML 2 artifacts deployed to nodes.




What is Manifestation?

24

What is Manifestation?

The physical implementation of a model element as an artifact.

A relationship between the model element and the artifact that implements it• Model elements are typically implemented as

a set of artifacts.Source files, executable files, documentation file




Example: Manifestation

25

Example: Manifestation



<<deploy>>

MainStudentForm

<<manifest>>

<<header>>MainStudentForm

<<source>>MainStudentForm

<<manifest>>

<<manifest>>

The <<header>> and <<source>> artifacts are an implementation manifestation for the MainStudentForm model element class.

The <<client workstation>> PC deploys the <<process>> StudentApplication artifact which is a run-time manifestation of the MainStudentForm model element class.




What is a Deployment Specification?

26

What is a Deployment Specification?

A detailed specification of the parameters of the deployment of an artifact to a node.

May define values that parameterize the execution




Example: Deployment Specification

27

Example: Deployment Specification



<<deploy>>

MainStudentForm

<<manifest>>

<<header>>MainStudentForm

<<source>>MainStudentForm

<<manifest>>

<<manifest>>

<<deploymentSpec>>StuAppDeploy

execution =priority =location =

The <<header>> and <<source>> artifacts are an implementation manifestation for the MainStudentForm model element class.





28



If you remember from Architectural Analysis, distribution was identified as an important architectural mechanism. In this section, we will discuss the patterns of use for incorporating the chosen distribution mechanism.




Distribution Mechanism

29

Distribution Mechanism


AnalysisMechanism

(Conceptual)



(Actual)

Java 1.2 from SunDistribution

RMI was chosen as the implementation mechanism for distribution

As mentioned in Identify Design Mechanisms, Remote Method Invocation (RMI) was chosen as the implementation mechanism for distribution.

Lightweight RMI was chosen as a low-cost alternative to a full CORBA distribution. The use of CORBA would be reconsidered if you needed to connect to non-Java systems or in cases where you required features of CORBA that were not found in RMI.

The details of the RMI mechanisms are provided in the Additional Information Appendix, RMI Mechanism section.




Design Mechanisms: Distribution: RMI

30

Design Mechanisms: Distribution: RMI

Distribution characteristicsLatencySynchronicityMessage SizeProtocol





31

InvokeOp()


RemoteObject

Naming

Client

Lookup(serverURL)

RemoteStub

Remote

InvokeOp()

RMI Transport

RemoteSkeleton

Provided “for free” with RMI for each distributed class.

Distributed Class

Remote Method Invocation (RMI) is a Java-specific mechanism that allows client objects to invoke operations on server objects as if they were local. The only catch is that, with basic RMI, you must know where the server object resides. The mechanisms of invoking an operation on a remote object are implemented using “proxies” on the client and server, as well as a service that resides on both that handles the communication. The client establishes the link with the remote object via the Naming utility that is delivered with RMI. There is a single instance of the Naming class on every node. The Naming instances communicate with one another to locate remote objects. Once the connection is established (via lookup()), it may be reused any time the client needs to access the remote object. The above diagram describes what happens “under the hood,” but in reality, you do not need to model the RemoteStub and RemoteSkeleton since these are automatically generated by tools from Sun. To get them, you run the compiled distributed class through the rmic compiler to generate the stubs and skeletons. You then must add the code to look up the object on the server. The lookup returns a reference to the auto-generated RemoteStub. For example, say we had a class, ClassA, that is distributed through RMI. Once ClassA is created, it is run through the rmic compiler, which generates the stub and skeleton. When you do the lookup, the Naming object returns a reference to a ClassA, but it is really a ClassA stub. Thus, no client adjusting needs to happen. Once a class is run through rmic, you can access it as if it were a local class, the client does not know the difference.




Remote Method Invocation (RMI) (continued)

32

Remote Method Invocation (RMI) (continued)

OneInstanceper node

For all classes that realize the Remote interface, a remote stub and a remote skeleton are created. These classes handle the communication that must occur to support distribution.

Naming.

lookup(name : String) : Remote

(from java.rmi)

SampleDistributedClass

doSomething(aParameter : SamplePassedData)

<<role>>

Remote(from java.rmi)

SampleDistributedClassClient<<role>>

SamplePassedData<<role>>

Any Java class that you want to pass as an argument to an operation on a remote interface must realize the Serializable Interface.

UnicastRemoteObject(from Server)

To "distribute" a class in Java, you must define an interface that inherits from Remote. The distributed class needs to realize the defined Remote interface and also inherit from (extend) the UnicastRemoteObject.

ISampleDistributedClass

doSomething(aParameter : SamplePassedData)

<<Interface>>

Serializable(from java.io)

Roles to be filled by the designer applying the

mechanism

The above diagram describes the pattern that will be used to implement the distribution mechanism. It provides a static view of the classes needed to incorporate the RMI distribution mechanism. As discussed in the Identify Design Mechanisms module, the <<role>> stereotype can be used to denote those elements that need to be supplied by the designer incorporating the mechanism. The roles for the RMI distribution mechanism are shown above. Note: In the above example the ISampleDistributedClassInterface class has a stereotype of <<interface>>, rather than role. This is because it must be an interface, and a class can only have one stereotype. To "distribute" a class in Java, you must define an interface that inherits from Remote. For all classes that realize the Remote interface, a remote stub and a remote “skeleton” are created. These classes handle the communication that must occur to support distribution (see the previous slide). The distributed class needs to realize the defined Remote interface and also inherit from (extend) the UnicastRemoteObject. Any Java class that you want to pass as an argument to an operation on a remote interface must realize the Serializable interface. Java RMI uses that interface to marshal instances of the class back and forth across a distributed environment. The same holds true for returned values. Clients of distributed classes will need to look up the location of the remote object using the provided Naming service. Note: Both Remote and Serializable have no operations. The interfaces themselves only "declare" an object as either a Remote or Serializable, but there are no operations to implement.




Incorporating RMI: Steps

33

Incorporating RMI: Steps

1. Provide access to RMI support classes (e.g., Remote and Serializable interfaces, Naming Service)

java.rmi and java.io package in Middleware layer2. For each class to be distributed:

Controllers to be distributed are in the Application layer Dependency from the Application to the Middleware layer is needed to access java packagesDefine interface for class that realizes RemoteHave class inherit from UnicastRemoteObject

Deferred

The next few slides contain a summary of the steps that can be used to implement the RMI distribution mechanism described in this module. The italicized text on the slide describes the architectural decisions made with regards to RMI for our Course Registration example. • The RMI support classes can be found in the java.rmi (including the nested Server

package) and the java.io packages. These packages reside in the Middleware layer.

• For any class that is to be distributed, an interface must be defined that realizes the Java Remote interface. The distributed class will need to realize that interface, as well as inherit from UnicastRemoteObject.

• For the Course Registration System, the control classes are distributed. (The classes to be distributed were tagged with the analysis mechanism, distribution.) The interface classes that are defined for the distributed control classes are placed in the same package as the associated distributed control classes. The control classes were allocated to the Application layer of the architecture in Identify Design Mechanisms. Thus, a dependency must be added from the Application layer to the Middleware layer so the control class interfaces can access the Remote interface, and so the distributed class can access to UnicastRemoteObject class.

• The definition of the distributed class interfaces, and the generalization and realization relationships described above have been deferred until detailed design (for example, Use-Case and Subsystem Design).

The remaining steps are discussed on the subsequent slides.




Incorporating RMI: Steps (continued)

34

3. Have classes for data passed to distributed objects realize the Serializable interface

Core data types are in Business Services layerDependency from Business Services layer to the Middleware layer is needed to access java.rmiAdd the realization relationships

4. Run pre-processor Out of scope

Deferred


• Any class whose instances are passed between the client and the server needs to

realize the Serializable interface. • For the Course Registration System, most of the data passed will be of one of the

core data types. The core data types were allocated to the Business Services layer of the architecture (the University Artifacts package, specifically) in Identify Design Elements. Thus, a dependency is needed from the Business Services layer to the Middleware layer so the core data classes can access the Remote interface. This relationship already exists.

• The definition of the realizes relationships from the classes to be passed and the Serializable interface has been deferred until detailed design (for example, Use-Case and Subsystem Design).

• The developer must run the compiled distributed class through the rmic compiler provided by Sun to generate the stubs and skeletons for all classes that realize the Remote interface. These classes handle the communication that must occur to support distribution (see previous slide). Once a class is run through rmic, you can access it as if it were a local class. The client does not know the difference. This is really implementation, and thus, is out of the scope of this course.

The remaining steps are discussed on the next slide.





35

Deferred


5. Have distributed class clients lookup the remote objects using the Naming service

Most Distributed Class Clients are formsForms are in the Application layerDependency from the Application layer to the Middleware layer is needed to access java.rmiAdd relationship from Distributed Class Clients to Naming Service

6. Create and update interaction diagrams with distribution processing

• Clients of distributed classes will need to look up the location of the remote

object using the Naming service.The lookup returns a reference to the distributed class interface.

• In the Course Registration System, the distributed control class clients are forms, and the forms were allocated in the Application layer of the architecture in Identify Design Elements. Thus, a dependency must be added from the Application layer to the Middleware layer so the control classes can access the Naming service.

• The definition of the dependency relationship from the distributed class clients and the Naming Service has been deferred until detailed design (for example, Use-Case and Subsystem Design).

• The developer must create Interaction diagrams that model the added distribution functionality. Do not be too concerned with modeling the processing that is provided by the distribution infrastructure (for example, the Remote Stub and Skeleton). Just model the use of the Naming service and the distributed class interface. The development of any Interaction diagrams has been deferred until detailed design (for example, Use-Case and Subsystem Design).




Example: Incorporating RMI

36



<<layer>>Middleware


University Artifacts(from Business Services)

Middleware<<layer>>


Business Services

<<layer>>

java.rmi

<<interface>>remote

(from java.rmi)

Naming(from java.rmi)

UnicastRemoteObject

(from Server)

Server<<interface>>Serializable(from java.io)

Java.io

Registration Package

(from Application)

The above diagram describes the package dependencies needed to support the RMI distribution mechanism. The sample application represents any application package that contains controllers that will need to be distributed along with their associated clients. The following package dependencies were added to support distribution.

The java.rmi package containing the classes that implement the RMI distribution mechanism. • Dependency from Application packages to java.rmi to provide access to the

Remote interface for distributed controller interfaces, and to the Naming service for the distributed controller clients.

• Dependency from the Application packages to the Java Server package to provide access to the UnicastRemoteObject class for distributed controllers.

• Dependency from University Artifacts to java.io to provide access to the Serializable interface for classes whose instances must be passed for distributed objects.

These package dependencies required the following change to the layer dependencies originally defined in Identify Design Elements: • Dependency from Application layer to Middleware layer to support the new

dependency from the Application packages to the java.rmi package. This is an example of how the architecture might need to be adjusted as design details are added. Such changes are architectural changes that must be made by the architect. Note: In the above diagram, only a subset of the packages in the layers are shown. The remaining packages in the layers have been omitted for clarity.




Checkpoints: Deployment View

37

Checkpoints: Deployment View

Have the distributed data update coordination and synchronization issues been addressed and documented?Are services that require more rapid response available locally (LAN vs. WAN)?Have all redundant server issues been addressed and documented (primary vs. secondary)?Are the failure modes documented?

Above are the key things that a designer would look for when assessing the results of the Describe Distribution activity. As stated earlier, an architect would have a more detailed list.

Make sure the following points are addressed and well documented:

• Consider how to coordinate and synchronize updates to data that is distributed across multiple nodes. This usually involves some form of a two-phase commit protocol. The situation where multiple copies of the same object can become out of sync with one another needs to be prevented, or recovered from.

• Make sure that services that require more rapid response are available locally via a LAN rather than WAN.

• Consider the situation where more than one server "thinks" it is primary, or the situation where no processors end up being primary needs to be prevented, or recovered from.

• Consider what should happen if a server goes down.




Review

38

Review: Describe Distribution

What is the purpose of the Describe Distribution activity?What is a node? Describe the two different “types” of nodes. Describe some of the considerations when mapping processes to nodes.How do you model the Deployment View? What modeling elements and diagrams are used?




Exercise: Describe Distribution

39

Exercise: Describe Distribution

Given the following textual information:Network configuration (e.g., nodes and their connectors)• What processes run on what nodes?

Exercise Workbook: Payroll Architecture Handbook, Deployment View section

In this exercise, the deployment architecture for the course exercise is given, textually. The architecture is not derived, since such a derivation is out of the scope of this course. The exercise allows the student to produce the visual model of the described deployment architecture.

References:

• Exercise Workbook: Payroll Architecture Handbook, Deployment View section.




Exercise: Describe Distribution (continued)

40

Exercise: Describe Distribution (continued)

Produce the following:• A Deployment diagram depicting:

• Nodes• Connectors• What processes run

on what nodes


• What is a Node? – 10-16 • What is a Connector? – 10-17 • Example: Deployment Diagram with Processes – 10-21




Exercise: Review

41

Exercise: Review

Compare your Deployment Model with those developed by the rest of the class.

Have nodes and node connections been modeled?Have processes been identified and assigned to nodes? Do the allocations make sense?Are the processes listed beneath the nodes in the Deployment diagram?

Payroll System


• Have nodes and node connections been modeled? • Have processes been identified and assigned to nodes? Do the allocations make

sense? The processes identified in the Deployment Model should correspond to those in the Process Model. Threads should not appear on the Deployment Model, because threads always execute within the context of their parent process.

• Are the processes listed beneath the nodes in the Deployment diagram?










June 2004











Contents

Module 11 Use-Case Design Use-Case Design Overview.......................................................................... 11-4 Use-Case Realization Refinement Steps...................................................... 11-10 Guidelines: Encapsulating Subsystem Interactions....................................... 11-26 Modeling Transactions ............................................................................... 11-31 Detailed Flow of Events Description Options.............................................. 11-34 Review ...................................................................................................... 11-39

Module 12 Subsystem Design Subsystem Design Overview ........................................................................ 12-4 Subsystem Responsibilities ........................................................................... 12-9 What Are Gates?........................................................................................ 12-11 Subsystem Dependencies: Guidelines ........................................................ 12-27 Review ...................................................................................................... 12-32

Module 13 Class Design Class Design Overview................................................................................. 13-4 Class Design Considerations......................................................................... 13-7 Define Operations ..................................................................................... 13-12 Define Methods......................................................................................... 13-21 Define States ............................................................................................. 13-23 Define Attributes ....................................................................................... 13-35 Define Dependencies ................................................................................ 13-44 Define Associations.................................................................................... 13-54 Define Internal Structure............................................................................ 13-73 Define Generalizations............................................................................... 13-82 Resolve Use-Case Collisions ..................................................................... 13-106 Handle Non-Functional Requirements in General .................................... 13-108 Review .................................................................................................... 13-115

Module 14 Database Design Database Design Overview .......................................................................... 14-4 Relational Databases and Object Orientation ............................................... 14-7 Object-Relational Framework: Characteristics ............................................ 14-11 What Are Stored Procedures? .................................................................... 14-19 Review ...................................................................................................... 14-23

Glossary

Additional Resources

► ► ► Module 11 Use-Case Design

1

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 11: Use-Case Design

Topics

Use-Case Design Overview ................................................................................ 11-4 Use-Case Realization Refinement Steps ............................................................ 11-10 Guidelines: Encapsulating Subsystem Interactions ............................................. 11-26 Modeling Transactions...................................................................................... 11-31 Detailed Flow of Events Description Options .................................................... 11-34 Review............................................................................................................. 11-39




Objectives: Use-Case Design

2

Objectives: Use-Case Design

Define the purpose of Use-Case Design and when in the lifecycle it is performedVerify that there is consistency in the use-case implementationRefine the use-case realizations from Use-Case Analysis using defined Design Model elements

Use-Case Design is when the use-case implementations are verified for consistency. This means that for all the use-case realizations for each use case, the following items are verified:

• All the necessary behavior to support a use-case implementation has been distributed among the appropriate participating classes.

• The use case flows naturally over the participating design elements. • All associations between design elements (classes or subsystems) needed for the

use-case realizations have been defined. • All of the attributes needed for the use-cases have been defined. To assist in this verification, use-case realizations initially developed in Use-Case Analysis are refined to include the defined Design model elements from the originally defined Analysis Model elements. The Design Model elements are the design classes and subsystems that the analysis classes “morphed into.”

In addition, any applicable architectural mechanisms should be incorporated into the use-case realizations.



Module 11 - Use-Case Design

Use-Case Design in Context

3

Use-Case Design in Context[Early





Synthesis

Analyze Behavior


DesignComponents

Design theDatabase

(Optional)

Use-CaseDesign Designer

As you may recall, the above diagram illustrates the workflow that we are using in this course. It is a tailored version of the Analysis and Design core workflow of the Rational Unified Process. At this point, you have made an initial attempt at defining the architecture. You have defined the major elements of your system (that is, the subsystems, their interfaces, the design classes, the processes and threads) and their relationships, and you have an understanding of how these elements map into the hardware on which the system will run. In Use-Case Design, you are going to concentrate on how a use-case has been implemented and make sure that there is consistency from beginning to end. You will also be verifying that nothing has been missed (that is, you will make sure that what you have done in the previous design activities is consistent with regards to the use-case implementation). Use-Case Design is where the design elements (design classes and subsystems) meet the architectural mechanisms. The use-case realization initially defined in Use-Case Analysis is refined to include the design elements, using the patterns of interaction defined for the architectural mechanisms. You might need to do some Use-Case Design before Subsystem Design, because after Analysis and Identify Design Elements, you usually only have sketchy notions of responsibilities of classes and subsystems. The real details need to get worked out in Use-Case Design, before you will be really ready to design the classes and subsystems. The detailed design activities (for example, Subsystem Design, Class Design and Use-Case Design) are tightly bound and tend to alternate between one another.




Use-Case Design Overview

4

Use-Case Design Overview


Use-CaseDesign Design Use-Case

Realization

Design Subsystems and Interfaces

Use case

Design Model

Analysis Model

Analysis Use-Case Realization

Use-Case Design is performed by the designer, once per use case.

Purpose:

• To refine use-case realizations in terms of interactions. • To refine requirements on the operations of design classes. • To refine requirements on the operations of design subsystems and/or their

interfaces. Input Artifacts:

• Analysis Model • Supplementary Specifications • Use cases • Analysis use-case realization • Design classes • Design subsystems • Design Model • Design use-case realization • Interfaces Resulting Artifacts:

• Design use-case realization • Design Model




Use-Case Design Steps

5


Describe interaction among design objectsSimplify sequence diagrams using subsystemsDescribe persistence-related behaviorRefine the flow of events descriptionUnify classes and subsystems

The above slide shows the major steps of the Use-Case Design activity.

Use-case realizations evolve from interactions among analysis classes to interactions among design elements (for example, design classes and subsystems).

The purpose of Use-Case Design is to make sure these are consistent and make sense. During Use-Case Design, the focus is on the use case, and this includes crossing subsystem boundaries. The use-case designer needs to make sure the use case is implemented completely and consistently across the subsystems.

Anything done from the use-case perspective is part of Use-Case Design.

This module will address each of these steps listed on the slide.





6



In this step, describe the use-case flow of events in terms of the Design Model (that is, interactions between design classes and/or subsystems). This involves replacing analysis classes with the design elements that they were refined into during Identify Design Elements, as well as incorporating any applicable architectural mechanisms.





7






Sequence Diagrams

Before discussing the steps of the Use-Case Design activity, it is important to review what a use-case realization is, since refining a use-case realization is the focus of the activity.

Use-case realizations were first introduced in the Analysis and Design Overview module. The initial development of use-case realizations was discussed in the Use-Case Analysis module. The above diagram is included here as a review. For details on the use-case realization, refer to that module.

As stated in that module, a designer is responsible for the integrity of the use-case realization. He or she must coordinate with the designers responsible for the design elements (that is, classes and subsystems) and the relationships employed in the use-case realization.




Review: From Analysis Classes to Design Elements

8

Analysis Classes Design Elements

Many-to-Many Mapping

Review: From Analysis Classes to Design Elements

<<boundary>>

<<control>>

<<entity>>

<<boundary>>



Before moving forward in Use-Case Design, it is important that you revisit what happened to the analysis classes that were identified in Use-Case Analysis. These analysis classes were mapped to design elements that were identified by the architect during the Identify Design Elements activity. You will be incorporating these design elements into your models in Use-Case Design.

Identify Design Elements is where the analysis classes identified during Use-Case Analysis are refined into design elements (for example, classes or subsystems). Analysis classes primarily handle 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 Elements that you decide which analysis "classes" are really classes, which are subsystems (that 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.




Use-Case Realization Refinement

9

Class Diagrams

Use-Case Realization Refinement

Identify participating objectsAllocate responsibilities among objectsModel messages between objectsDescribe processing resulting from messagesModel associated class relationships

Sequence Diagrams

Each use-case realization should be refined to describe the interactions between participating design objects as follows:

• Identify each object that participates in the use-case flow of events. These objects can be instances of design classes and subsystems, or they can be instances of actors that the participating objects interact with.

• Represent each participating object in an interaction diagram. Subsystems can be represented by instances of the subsystem’s interface(s).

• Illustrate the message-sending between objects by creating messages (arrows) between the objects. The name of a message should be the name of the operation invoked by it. For messages going to design classes, the operation is a class operation. For messages going to subsystems, the operation is an interface operation.

• Describe what an object does when it receives a message. This is done by attaching a script or note to the corresponding message. When the person responsible for an object's class assigns and defines its operations, these notes or scripts will provide a basis for that work.

For each use-case realization, illustrate the class relationships that support the collaborations modeled in the interaction diagrams by creating one or more class diagrams.




Use-Case Realization Refinement Steps

10

1. Identify each object that participates in the flow of the use case

2. Represent each participating object in a sequence diagram

3. Incrementally incorporate applicable architectural mechanisms

Use-Case Realization Refinement Steps

Look at the interaction diagrams.

For each class that has been refined into a subsystem, replace the class with the associated subsystem interface. Any interactions that describe how the subsystem should implement the service should be deferred until subsystem design.

Incrementally incorporate any applicable architectural mechanisms, using the patterns of behavior defined for them during the architectural activities.This may include the introduction of new design elements and messages.

Any updates need to be reflected in both the static and dynamic parts of the use-case realization (that is, the interaction diagrams and the VOPC class diagram).




Representing Subsystems on a Sequence Diagram

11

Representing Subsystems on a Sequence Diagram

InterfacesRepresent any model element that realizes the interfaceNo message should be drawn from the interface

Subsystem ComponentRepresents a specific subsystemMessages can be drawn from the subsystem

Object A Interface Object B

1: Message 12: Message 2

Object A Subsystem Component

Object B

1: Message 12: Message 2X

Invalid message Valid message

You have two choices for representing the subsystems:

• You can use the interfaces realized by the subsystem. This is the better choice in cases where any model element that realizes the same interface can be used in place of the interface. If you choose to show interfaces on the sequence diagram, be aware that you will want to ensure that no messages are sent from the interface to other objects. The reason for this is that interfaces completely encapsulate the internal realization of their operations. Therefore, you cannot be certain that all model elements that realize the interface will in fact actually be designed the same way. So on sequence diagrams, no messages should be shown being sent from interfaces.

• You can use a subsystem component (which is discussed in the Subsystem Design Module) to represent the subsystem on sequence diagrams. This component is contained within the subsystem and is used to represent the subsystem in diagrams that do not support the direct use of packages and subsystems as behavioral elements. The subsystem component should be used in cases where a specific subsystem responds to a message. Messages can be sent from the subsystem proxy to other objects.

For this class, you will use interfaces to represent subsystems in the design.




Example: Incorporating Subsystem Interfaces

12

All other analysis classes are mapped directly to design classes.

Analysis Classes Design Elements

Example: Incorporating Subsystem Interfaces

BillingSystem

//submit bill()

<<boundary>> Billing System<<subsystem>>

IBillingSystem

submitBill(forTuition : Double, forStudent : Student)

CourseCatalogSystem

//get course offerings()

<<boundary>>


getCourseOfferings(forSemester : Semester, forStudent : Student) : CourseOfferingListinitialize()

Course Catalog System<<subsystem>>

In Identify Design Elements, it was determined by the architects of the Course Registration System that the interactions to support external system access were going to be more complex than could be implemented in a single class. Thus, subsystems were identified to encapsulate the access to these external systems. The above diagram includes these subsystems, as well as their interfaces.

The BillingSystem subsystem provides an interface to the external Billing System. It is used to submit a bill when registration ends and students have been registered in courses.

The CourseCatalogSystem subsystem encapsulates all the work that goes on in communicating to the legacy Course Catalog System. The system provides access to the unabridged catalog of all courses and course offerings offered by the university, including those from previous semesters.

All other analysis classes map directly to design classes in the Design Model.




Example: Incorporating Subsystems (Before)

13

Example: Incorporating Subsystems (Before)Analysis class to be replaced

: Student

: RegisterForCoursesForm : RegistrationController : Schedule : Student: CourseCatalogSystem

Student wishesto create a newschedule

1. // create schedule( )

1.2. // display course offerings( )

1.1. // get course offerings( )

1.1.1. // get course offerings(forSemester)

1.3. // display blank schedule( )A blank scheduleis displayed for thestudents to selectofferings

A list of the availablecourse offerings for thissemester are displayed

Select Offerings

Submit Schedule

ref

ref

The above slide shows part of the Register for Courses use-case realization developed during Use-Case Analysis.

You know from Identify Design Elements that a CourseCatalogSystem subsystem has been defined to encapsulate access to the external legacy CourseCatalogSystem. Thus, you need to refine this interaction diagram and replace the original CourseCatalogSystem boundary class with the associated subsystem interface, ICourseCatalogSystem.




Example: Incorporating Subsystems (After)

14

Example: Incorporating Subsystems (After)

: RegisterForCoursesForm : RegistrationController : Schedule : Student: ICourseCatalogSystem

1: // create schedule1.1: // get course offerings

1.1.1: getCourseOfferings

1.2: // display course offeringsA list of the available course offerings for this semester are displayed

Replaced with subsystem interface

A blank schedule is displayed for the Student to select offerings

Student wishes tocreate a new schedule

1.3: // display blank schedule

Select Offerings

Submit Schedule

ref

ref

The above is a fragment of the sequence diagram from the Register for Courses use-case realization. It demonstrates how interactions are modeled between design elements, where one of the elements is a subsystem.

You know from Identify Design Elements that a CourseCatalogSystem subsystem was defined to encapsulate access to the external legacy CourseCatalogSystem. Thus, the original use-case realization (shown on the previous slide) was refined, and the original CourseCatalogSystem boundary class was replaced with the associated subsystem interface, ICourseCatalogSystem.

In this module, you will not flesh out the internals of the CourseCatalogSystem subsystem. That is the purpose of Subsystem Design. The above diagram will become the subsystem context diagram in Subsystem Design. In Subsystem Design, you will concentrate on the internals of the subsystem.




Example: Incorporating Subsystem Interfaces (VOPC)

15

Example: Incorporating Subsystem Interfaces (VOPC)ICourseCatalogSystem

getCourseOfferings()initialize()


<<Interface>>


// submit schedule()// display course offerings()// display schedule()// save schedule()// create schedule()// select 4 primary and 2 alternate offerings()// display blank schedule()

(from Registration)

<<boundary>>

Student.

- name- address- studentID : int

// addSchedule()// getSchedule()// hasPrerequisites()// passed()

(from University Artifacts)

<<entity>>


// submit schedule()// save schedule()// create schedule with offerings()// getCourseOfferings()

(from Registration)

<<control>>

0..1

0..1registrant

1 1Schedule

semester

// submit()// save()// any conflicts?()// new()


<<entity>>

0..*

1

0..1

0..1

CourseOffering

numberstartTimeendTimedays

// addStudent()// removeStudent()// new()// setData()


<<entity>>

0..*

0..4primaryCourses

0..*


0..*1

Subsystem interface

currentSchedule

The above example is the VOPC after incorporating the design elements. The original CourseCatalogSystem boundary class has been replaced with the associated subsystem interface, ICourseCatalogSystem.




Incorporating Architectural Mechanisms: Security

16


Student

CourseOfferingCourse



Persistency, Legacy InterfacePersistency, Legacy Interface

Distribution

Incorporating Architectural Mechanisms: Security

Analysis Class to Architectural-Mechanism Map from Use-Case Analysis

Schedule Persistency, Security

During Use-Case Analysis, applicable mechanisms for each identified analysis class were documented. This information, along with the information on what analysis classes became what design elements, allows the applicable mechanisms for a design element to be identified.

Since we have been concentrating on course registration, the above table contains only the classes for the Register for Courses use-case realization that have analysis mechanisms assigned to them.

The details of incorporating the security mechanism are provided in the Additional Information Appendix in the Security Mechanism section.




Incorporating Architectural Mechanisms: Distribution

17


Student





Distribution

Incorporating Architectural Mechanisms: Distribution

Analysis Class to Architectural-Mechanism Map from Use-Case Analysis


We started the discussion of the distribution mechanism in the Describe Distribution module. Now we will see how to incorporate this mechanism into the use-case realizations.




Review: Incorporating RMI: Steps

18

Review: Incorporating RMI: Steps

1. Provide access to RMI support classes (e.g., Remote and Serializable interfaces, Naming Service)

Use java.rmi and java.io package in Middleware layerFor each class to be distributed:

Controllers to be distributed are in Application layer Dependency from Application layer to Middleware layer is needed to access java packagesDefine interface for class that realizes RemoteHave class inherit from UnicastRemoteObject

√

√ = Done

√√

The next few slides contain a summary of the steps that can be used to implement the RMI distribution mechanism described in this module.The italicized text describes the architectural decisions made with regards to RMI for our Course Registration example.

These steps were first discussed in the Describe Distribution module. They are repeated here for convenience. The check marks indicate what steps have been completed.

In Use-Case Design, you will continue to incorporate this mechanism. You will define the distributed class interfaces, and the supporting generalization and realization relationships. As pointed out in the Describe Distribution module, for any class that is to be distributed, an interface must be defined that realizes the Java Remote interface. The distributed class will need to realize that interface, as well as inherit from UnicastRemoteObject.

As previously decided, for the Course Registration System, the control classes will be distributed. (The classes to be distributed were tagged with the analysis mechanism, distribution.) The interface classes that will be defined for the distributed control classes should be placed in the same package as the associated distributed control classes.

The remaining steps are discussed on the next two slides.




Review: Incorporating RMI: Steps (continued)

19

2. Have classes for data passed to distributed objects realize the Serializable interface

Core data types are in Business Services layerDependency from Business Services layer to Middleware layer is needed to get access to java.rmiAdd the realization relationships

3. Run pre-processor – out of scope


√

√

√ = Done

• Any class whose instances will be passed between the client and the server needs to realize the Serializable interface. For the Course Registration System, most of the data passed is of one of the core data types. The core data types were allocated to the Business Services layer of the architecture (specifically, the University Artifacts package) in Identify Design Elements. Thus, a dependency exists from the Business Services layer to the Middleware layer so the core data classes can access to Remote interface. Now we will define the realization relationships from the classes to be passed and the Serializable interface.

• The developer must run the compiled distributed class through the RMI compiler (RMIC) provide by Sun to generate the stubs and skeletons for all classes that realize the Remote interface. These classes handle the communication that must occur to support distribution (see the previous slide). Once a class is run through RMIC, you can access it as if it were a local class; the client does not know the difference. This is really implementation, which is out of the scope of this course.

The remaining steps are discussed on the next slide.





20


4. Have distributed class clients look up the remote objects using the Naming service

Most Distributed Class Clients are formsForms are in Application layerDependency from Application layer to Middleware layer is needed to get access to java.rmiAdd relationship from Distributed Class Clients to Naming Service

5. Create/update interaction diagrams with distribution processing (optional)

√

√√

√ = Done

Clients of distributed classes will need to lookup the location of the remote object using the Naming service. The look up returns a reference to the distributed class interface.

Now we will define the dependency relationships from the distributed class clients and the Naming Service. You will also develop interaction diagrams that model the distribution functionality.





21


currentSchedule

registrant

CourseOfferingList(from University Artifacts)

Naming

+ lookup()

(from rmi)

RegisterForCoursesForm(from Registration)

<<boundary>>

Remote(from rmi)

<<Interface>>

RegistrationController(from Registration)

<<Control>>

Student(from University Artifacts)

<<Entity>>

UnicastRemoteObject(from server)

Serializable(from io)

<<Interface>>Schedule


<<Entity>>

Distributed Class Client

Distributed Class

Passed Class

IRegistrationController

+ getCurrentSchedule(forStudent : Student, forSemester : Semester) : Schedule+ deleteCurrentSchedule()+ submitSchedule()+ saveSchedule()+ getCourseOfferings() : CourseOfferingList

(from Registration)

<<Interface>>

1

1

0..1

0..1

0..1

0..n

0..1

1

The above diagram provides a static view of the classes needed to incorporate the RMI distribution mechanism into the Course Registration System design.

The RegistrationController class is distributed, so an interface was defined, IRegistrationController, that realizes the Remote interface. The distributed class, RegistrationController realizes this new interface, and inherits from the UnicastRemoteObject.

Instances of the Student, Schedule, and CourseOfferingList classes are passed to and from the distributed class (note the operation signatures for the IRegistrationController interface), so they will realize the Serializable interface.

The RegisterForCoursesForm needs to look up the location of the RegistrationController using the Naming service, so a dependency was added from the RegisterForCoursesForm to Naming.

The remaining steps are discussed on the next two slides.




Example: Incorporating RMI (continued)

22



<<layer>>Middleware


Middleware<<layer>>


Business Services

<<layer>>

java.rmi

<<interface>>remote

(from java.rmi)

Naming(from java.rmi)

UnicastRemoteObject

(from Server)

Server<<interface>>Serializable(from java.io)

Java.io

Registration Package

(from Application)University Artifacts

(from Business Services)

The above diagram describes the package dependencies needed to support the distribution pattern described in this module (and the class relationships shown on the previous slide). This diagram is very similar to the one included in the Describe Distribution module, but the generic Sample Application package has been replaced with the Registration package. The Registration package contains the RegistrationController class that needs to be distributed; the created IRegistrationController interface; and the distributed class client, the RegisterForCoursesForm class. As discussed in the Describe Distribution module, the following package dependencies were added to support distribution: • The java.rmi package contains the classes that implement the RMI distribution

mechanism. This package is commercially available with most standard Java IDEs. • Dependency from the Application packages to java.rmi provides access to the

Remote interface for distributed controller interfaces, and to the Naming service for the distributed controller clients.

• Dependency from the Application packages to the Java Server package provides access to the UnicastRemoteObject class for distributed controllers.

• Dependency from the University Artifacts package to java.io provides access to the Serializable interface for classes, whose instances must be passed for distributed objects.

The layer dependencies that support the package dependencies are shown on the right side of diagram.

Note: In the above diagram, only a subset of the packages are shown. The remaining packages have been omitted for clarity. The remaining steps are discussed on the next slide.





23


Added to support distribution

All calls to the distributed class interface areforwarded to the remote instance.

RegisterForCoursesForm : Naming. :IRegistrationController

Lookup remote object by specifying it's URL1: lookup(string)

2: doSomething

The above diagram provides an example of what you would include in an interaction diagram to model the distribution functionality.

Notice the addition of a call to the Naming utility to locate the distributed class instance as well as the replacement of the original RegistrationController control class with the IRegistrationController interface. (Naming returns a reference to an IRegistrationController.) The remainder of the interaction diagram remains the same as before the distribution mechanism was incorporated.





24



When a use case is realized, the flow of events is usually described in terms of the executing objects, that is, as interactions between design objects. To simplify diagrams and to identify reusable behavior, there might be a need to encapsulate a subflow of events within a subsystem. When this is done, large subsections of the interaction diagram are replaced with a single message to the subsystem. Within the subsystem, a separate interaction diagram might illustrate the internal interactions within the subsystem that provide the required behavior. These subsystem interaction diagrams are developed during Subsystem Design.

At first glance, this step may appear similar to the previous one, Describe Interactions among Design Objects. However, they differ in perspective. In the case of Describe Interactions among Design Objects, the common subflows are identified outside-in. (Common collaborations have already been encapsulated within the subsystems identified in Identify Design Elements.) In the case of Simplify Interaction Diagrams Using Subsystems, the common subflows are discovered inside-out — after modeling the flows of events using design elements, you recognize common subflows. This step is optional if common subflows are not discovered.




Encapsulating Subsystem Interactions

25

Raises the level of abstraction.

Encapsulating Subsystem Interactions

Interactions can be described at several levelsSubsystem interactions can be described in their own interaction diagrams

A use-case realization can be described, if necessary, at several levels in the subsystem hierarchy.

In the above example, the lifelines in the middle diagram represent subsystems; the interactions in the circles represent the internal interaction of subsystem members in response to the message.

This approach raises the level of abstraction of the use-case realization flows of events.

The advantages of this approach are described on the next three slides.




Guidelines: Encapsulating Subsystem Interactions

26

InterfaceA

<<subsystem>>MySubsystem

op1()

Guidelines: Encapsulating Subsystem Interactions

Subsystems should be represented by their interfaces on interaction diagramsMessages to subsystems are modeled as messages to the subsystem interfaceMessages to subsystems correspond to operations of the subsystem interfaceInteractions within subsystems are modeled in Subsystem Design

<<interface>>:InterfaceA

To achieve true substitutability of subsystems that realize the same interface, only their interfaces can be visible in the interaction diagrams; otherwise all diagrams will need to be changed whenever a subsystem is substituted for another.

On an interaction diagram, sending a message to an interface lifeline means that any subsystem that realizes the interface can be substituted for the interface in the diagram.

In many cases, the interface lifeline does not have messages going out from it, since different subsystems realizing the interface may send different messages. However, if you want to describe what messages should be sent (or are allowed to be sent) from any subsystem realizing the interface, such messages can originate from the interface lifeline.

With this approach, when describing the interactions, the focus remains on the services, not on how the services are implemented within the design elements. This is known as “Design by Contract” and is one of the core tenets of robust software development using abstraction and encapsulation mechanisms.

Describing how the services are implemented is the focus of Subsystem Design for the design subsystems and Class Design for the design classes.




Advantages of Encapsulating Subsystem Interactions

27

Advantages of Encapsulating Subsystem Interactions

Use-case realizations: Are less clutteredCan be created before the internal designs of subsystems are created (parallel development)Are more generic and easier to change (Subsystems can be substituted.)

The advantages of encapsulating subsystem interactions over modeling the entire system at once are:

• Use-case realizations become less cluttered, especially if the internal design of some subsystems is complex.

• Use-case realizations can be created before the internal designs of subsystems are created. This can be used to make sure that use-case functionality has not been “lost” between the allocation of use-case responsibility in Use-Case Analysis and the identification of design elements (subsystems and design classes) in Identify Design Elements, and before Subsystem Design is performed.

• Use-case realizations become more generic and easier to change, especially if a subsystem needs to be substituted for another subsystem.

Encapsulating subsystem interactions raises the level of abstraction of the use-case realization flows of events.




Parallel Subsystem Development

28

Use subsystem interfaces as synchronization points.

Parallel Subsystem Development

Concentrate on requirements that affect subsystem interfaces Outline required interfacesModel messages that cross subsystem boundaries Draw interaction diagrams in terms of subsystem interfaces for each use case Refine the interfaces needed to provide messagesDevelop each subsystem in parallel

In some cases, it is appropriate to develop a subsystem more or less independently and in parallel with the development of other subsystems. To achieve this, we must first find subsystem dependencies by identifying the interfaces between them.

This work can be done as follows:

• Concentrate on the requirements that affect the interfaces between the subsystems.

• Make outlines of the required interfaces, showing the messages that are going to pass over the subsystem borders.

• Draw interaction diagrams in terms of subsystem interfaces for each use case. • Refine the interfaces needed to provide messages. • Develop each subsystem in parallel using the interfaces as synchronization

instruments between development teams. You can also choose whether to arrange the interaction diagrams in terms of subsystems or in terms of their interfaces only. In some projects, it might even be necessary to implement the classes providing the interfaces before you continue with the rest of the modeling.

The detailed design of the subsystem “internals” is done during Subsystem Design. The interfaces are what ensure compatibility between the Use-Case Design and the Subsystem Design.





29



You will now take a closer look at the incorporation of the persistency mechanism.




Use-Case Design Steps: Describe Persistence-Related Behavior

30

Describe Persistence-Related Behavior

Use-Case Design Steps: Describe Persistence-Related Behavior

Reading Persistent Objects Deleting Persistent Objects

Modeling Transactions Writing Persistent Objects

In practice, there may be times when the application needs to control various aspects of persistence. These include:

• When determining how transactions are managed. • When persistent objects are written — either the initial time when the object is

written to the persistent object store or the subsequent times when the object is updated.

• When persistent objects are read. Retrieval of objects from the persistent object store is necessary before the application can send messages to that object. You need to send a message to an object that knows how to query the database, retrieve the correct objects, and instantiate them.

• When persistent objects are deleted. Unlike transient objects, which simply disappear when the process that created them dies, persistent objects exist until they are explicitly deleted. So, it is important to delete the object when it is no longer being used. However, this is hard to determine. Just because one application is done with an object does not mean that all applications, present and future, are done. And, because objects can and do have associations that even they do not know about, it is not always easy to figure out if it is okay to delete an object. The persistence framework may also provide support for this.

We will look at each one of these situations on the next two slides.




Modeling Transactions

31

Modeling Transactions

What is a transaction?Atomic operation invocations“All or nothing”Provide consistency

Modeling optionsTextually (scripts)Explicit messages

Error conditionsRollbackFailure modesMay require separate interaction diagrams

Before we discuss the modeling of the persistence-related behavior, we need to define what transactions are. Transactions define a set of operation invocations that are atomic: either all or none of them are performed. In the context of persistence, a transaction defines a set of changes to a set of objects that are either all performed or none are performed. Transactions provide consistency, ensuring that sets of objects move from one consistent state to another. If all operations specified in a transaction cannot be performed (usually because an error occurred), the transaction is aborted, and all changes made during the transaction are reversed.

Anticipated error conditions often represent exceptional flows of events in use cases. In other situations, error conditions occur because of some failure in the system. Error conditions should be documented in interactions. Simple errors and exceptions can be shown in the interaction where they occur; complex errors and exceptions might require their own interactions. Failure modes of specific objects can be shown on state machines. Conditional flow of control handling of these failure modes can be shown in the interaction in which the error or exception occurs.

Transactions can be represented either textually using scripts or via explicit messages. The examples provided on the next slide demonstrate the use of separate messages.




Incorporating the Architectural Mechanisms: Persistency

32


Student





Distribution


Analysis-Class-to-Architectural-Mechanism Map from Use-Case Analysis


Legacy persistency (RDBMS ) is deferred to Subsystem Design.

OODBMS Persistency

RDBMS Persistency

During Use-Case Analysis, applicable mechanisms for each identified analysis class were documented. This information, along with the information on what analysis classes became what design elements, allows the applicable mechanisms for a design element to be identified.

In our example, we have been concentrating on course registration. Thus, the above table contains only the classes for the Register for Courses use-case realization that have analysis mechanisms assigned to them.

The legacy interface mechanism distinguishes the type of persistency. Remember, legacy data is stored in an RDBMS. The RDMBS JDBC mechanism is described in the Identify Design Mechanisms module.

The details of incorporating the ObjectStore mechanism are provided in the Additional Information Appendix in the ObjectStore Mechanism section.

RDBMS persistency is deferred to Subsystem Design since access to the legacy systems has been encapsulated within a subsystem.





33



In this step you refine the flow of events originally outlined in Use-Case Analysis as needed to clarify the developed interaction diagrams.

This will make it easier for external observers to read the diagrams.




Detailed Flow of Events Description Options

34

Detailed Flow of Events Description Options

Annotate the interaction diagrams

: Actor1 : ClassA : ClassB

1: Do Something

2: Do Something More

Scripts can be used to describe the details surrounding these messages.

Notes can include more information about a particular diagram element

Script

Note

In those cases where the flow of events is not fully clear from just examining the messages sent between participating objects, you might need to add additional descriptions to the interaction diagrams.

These steps are taken in cases where timing annotations, notes on conditional behavior, or clarification of operation behavior is needed to make it easier for external observers to read the diagrams.

Often, the name of the operation does not sufficiently explain why the operation is being performed. Textual notes or scripts in the margin of the diagram might be needed to clarify the interaction diagram. Textual notes and scripts might also be needed to represent control flow such as decision steps, looping, and branching. In addition, textual tags might be needed to correlate extension points in the use case with specific locations in interaction diagrams.





35



At this point, you have a pretty good understanding of the design elements, their responsibilities, and the collaborations required to support the functionality described in the use cases. Now you must review your work to make sure that it is as complete and as consistent as possible before moving on to the detailed design activities of Subsystem and Class Design.

The purpose of Unify Classes and Subsystems is to ensure that each design element represents a single well-defined concept, with non-overlapping responsibilities. It is important to unify the identified classes and subsystems to ensure homogeneity and consistency in the model.

The next slide describes some of the considerations that a designer for a particular use case is concerned with (for example, consistency among collaborating design elements, and between the use-case flows of events and the Design Model). This is where you make sure that everything hangs together and fix it if does not.




Design Model Unification Considerations

36

Model element names should describe their functionMerge similar model elementsUse inheritance to abstract model elementsKeep model elements and flows of events consistent

Design Model Unification Considerations

Points to consider:

• Names of model elements should describe their function. Avoid similar names and synonyms, because they make it difficult to distinguish between model elements.

• Merge model elements that define similar behaviors or that represent the same phenomenon.

• Merge classes that represent the same concept or have the same attributes, even if their defined behaviors are different.

• Use inheritance to abstract model elements, which tends to make the model more robust.

• When updating a model element, also update the affected use-case realizations.




Checkpoints: Use-Case Design

37

Checkpoints: Use-Case Design

Is package/subsystem partitioning logical and consistent?Are the names of the packages/subsystems descriptive? Do the public package classes and subsystem interfaces provide a single, logically consistent set of services?Do the package/subsystem dependencies correspond to the relationships between the contained classes?Do the classes contained in a package belong there according to the criteria for the package division? Are there classes or collaborations of classes that can be separated into an independent package/subsystem?

The Design Model as a whole must be reviewed to detect glaring problems with layering and responsibility partitioning.The purpose of reviewing the model as a whole is to detect large-scale problems that a more detailed review would miss.

We want to ensure that the overall structure for the Design Model is well-formed, as well as detect large-scale quality problems that might not be visible by looking at lower-level elements.

The above checkpoints are important, because new packages/subsystems might be created when common subflows are identified.

Five packages and 1,000 classes is probably a sign that something is wrong.




Checkpoints: Use-Case Design (continued)

38

Checkpoints: Use-Case Design (continued)

Have all the main and/or subflow for this iteration been handled?Has all behavior been distributed among the participating design elements?Has behavior been distributed to the right design elements?If there are several interaction diagrams for the use-case realization, is it easy to understand which Communication diagrams relate to which flow of events?

Once the structure of the Design Model is reviewed, the behavior of the model needs to be scrutinized. First, make sure that there are no missing behaviors by checking to see that all scenarios for the current iteration have been completely covered by use-case realizations. All of the behaviors in the relevant use-case subflow must be described in the completed use-case realizations.

Next, make sure the behavior of the use-case realization is correctly distributed between model elements in the realizations. Make sure the operations are used correctly, that all parameters are passed, and that return values are of the correct type.

We want to ensure that the behavior of the system (as expressed in use-case realizations) matches the required behavior of the system (as expressed in use cases). Is it complete? We also want to ensure that the behavior is allocated appropriately among model elements, that is, is it correct?

Participating objects must be present to perform all the behaviors of the corresponding use case.

You need to make sure that the flow of events description clarifies how the diagrams are related to each other.




Review

39

Review: Use-Case Design

What is the purpose of Use-Case Design?What is meant by encapsulating subsystem interactions? Why is it a good thing to do?




Exercise: Use-Case Design

40

Exercise: Use-Case Design

Given the following:Analysis use-case realizations (VOPCs and interaction diagrams)The analysis class to design-element mapThe analysis class to analysis-mechanism mapAnalysis mechanism to design-mechanism mapPatterns of use for the architectural mechanisms

The goal of this exercise is to refine the use-case realizations developed in Use-Case Analysis to incorporate the design classes and subsystems, as well as to (optionally) incorporate the patterns of use for the architectural mechanisms (persistency, security, and distribution). This exercise can also include the incorporation of the implementation mechanism.

References to the givens listed on this slide:

• Use-case realizations: Payroll Exercise Solution, Use-Case Analysis section • Analysis class to design-element map: Payroll Exercise Solution, Identify Design

Elements section The following are not needed if no mechanisms are being applied:

• Analysis class to analysis-mechanism map: Payroll Exercise Solution, Use-Case Analysis

• Analysis to design-mechanism map: Exercise Workbook: Payroll Architecture Handbook, Architectural Mechanisms section

• The patterns of use for the architectural mechanisms: Exercise Workbook: Payroll Architecture Handbook, Architectural Mechanisms: Implementation Mechanisms section.

Additional information on the incorporation of the ObjectStore OODBMS persistency mechanism for the Payroll System is provided in the Exercise Workbook: Payroll Architectural Handbook, Logical View: Architectural Design section.




Exercise: Use-Case Design (continued)

41


Identify the following:The design elements that replaced the analysis classes in the analysis use-case realizationsThe architectural mechanisms that affect the use-case realizationsThe design element collaborations needed to implement the use caseThe relationships between the design elements needed to support the collaborations

You can determine which design elements have replaced the original analysis classes by referring back to the analysis-class-to-design-element map defined in the Identify Design Elements module.

You can determine which architectural mechanisms affect the use-case realization, by looking at the:

• Analysis-class-to-analysis-mechanism map • Analysis-class-to-design-element map • Analysis-to-design-to-implementation-mechanism map Using this information, you can determine which architectural mechanisms affect the design elements involved in the use-case realization.

Based on what design elements have replaced the analysis classes and what architectural mechanisms must be incorporated, the analysis use-case realizations will need to be refined, including both the interaction diagrams and the VOPCs. As use-case responsibilities were allocated among analysis classes in Use-Case Analysis, use-case responsibilities must now be reallocated among the defined design elements.





42


Produce the following:Design use-case realization• Interaction diagram(s) per use-

case flow of events that describes the design element collaborations required to implement the use case

• Class diagram (VOPC) that includes the design elements that must collaborate to perform the use case, and their relationships

The produced interaction diagrams might be communication or sequence diagrams, but they should show the necessary collaborations. The VOPC class diagrams should reflect the relationships needed to support the collaborations.

Design elements can be either design classes or subsystems.

Where the interactions involve subsystems, the interaction diagram should only “go to” the subsystem interface and not “step within” the subsystem. The interactions within the subsystem will be developed in the Subsystem Design module.

Where necessary, include notes and scripts to clarify the use-case flow of events.

Refer to the following slides:

• Incorporating Subsystems: 11-14 • Incorporating Subsystems Interfaces (VOPC): 11-15




Exercise: Review

43

Exercise: Review

Compare your use-case realizationsHave all the main and subflows for this iteration been handled?Has all behavior been distributed among the participating design elements?Has behavior been distributed to the right design elements?Are there any messages coming from the interfaces?


• Have all the main and subflows for this iteration been handled? • Has all behavior been distributed among the participating design elements? This

includes design classes and interfaces. • Has behavior been distributed to the right design elements? • Are there any messages coming from the interface? Remember, messages should

not come from an interface, since the behavior is realized by the subsystem.






► ► ► Module 12 Subsystem Design

1

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 12: Subsystem Design

Topics

Subsystem Design Overview............................................................................... 12-4 Subsystem Responsibilities.................................................................................. 12-9 What Are Gates? .............................................................................................. 12-11 Subsystem Dependencies: Guidelines............................................................... 12-27 Review............................................................................................................. 12-32




Objectives: Subsystem Design

2

Objectives: Subsystem Design

Describe the purpose of Subsystem Design and where in the lifecycle it is performedDefine the behaviors specified in the subsystem's interfaces in terms of collaborations of contained classesDocument the internal structure of the subsystemDetermine the dependencies upon elements external to the subsystem

Subsystem Design is where you flesh out the detailed collaborations of classes that are needed to implement the responsibilities documented in the subsystem interfaces. In order to support these collaborations, additional relationships between subsystems may need to be defined.



Module 12 - Subsystem Design

Subsystem Design in Context

3

Subsystem Design in Context[Early





Synthesis

Analyze Behavior


DesignComponents

Design theDatabase

(Optional)

SubsystemDesign Designer

As you may recall, the above diagram illustrates the workflow that you are using in this course. It is a tailored version of the Analysis and Design core workflow of the Rational Unified Process.

At this point, you have defined the design classes, subsystems, their interfaces, and their dependencies. Some of the things that you have identified up to this point are components or subsystems: “containers” of complex behavior that, for simplicity, you treat as a “black box.” At some point, you need to flesh out the details of the internal interactions. This means that you need to determine what classes exist in the subsystem and how they collaborate to support the responsibilities documented in the subsystem interfaces. You do this in Subsystem Design.

In Subsystem Design, you look at the responsibilities of a subsystem in detail. You define and refine the classes that are needed to implement the responsibilities, and refine subsystem dependencies, as needed. The internal interactions are expressed as collaborations of classes and possibly other components or subsystems. The focus is on the subsystem.

The activity is iterative and recursive, but eventually feeds into Class Design.




Subsystem Design Overview

4

Subsystem Design Overview

SubsystemDesign

Design Subsystems and Interfaces

Design Classes



Design Model

Subsystem Design is performed once per Design Subsystem.

Purpose:

• To define the behaviors specified in the subsystem's interfaces in terms of collaborations of contained design elements and external subsystems/interfaces

• To document the internal structure of the subsystem • To define realizations between the subsystem's interfaces and contained classes • To determine the dependencies upon other subsystems Input Artifacts:

• Design Subsystems and Interfaces • Project Specific Guidelines • Design Model Resulting Artifacts:

• Design Subsystems and Interfaces • Design classes • Design Model





5

A Subsystem:Is a “cross between” a package and a classRealizes one or more interfaces that define its behavior


Interface Subsystem


Interface

Realization (Canonical form)

Realization (Elided form)

<<interface>>Interface


A subsystem is a model element that has the semantics of a package, such that it can contain other model elements, and the semantics of a class, such that it has behavior. A subsystem realizes one or more interfaces, which define the behavior it can perform.

A subsystem may be represented as a UML package (a tabbed folder) with the «subsystem» stereotype.

An interface is a model element that defines a set of behaviors (a set of operations) offered by a classifier model element (specifically, a class, subsystem or component). A classifier may realize one or more interfaces. An interface may be realized by one or more classifiers.

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

Interfaces may be represented as classes with the “interface” stereotype, or may be represented as “lollipops.”


The realization relationship may be modeled as a dashed line with a hollow arrowhead pointing at the contract classifier (canonical form), or when combined with an interface, as a “lollipop” (elided form).




Subsystem Guidelines

6

Key is abstraction and encapsulation

A<<subsystem>>

B<<subsystem>>

C<<subsystem>>

Subsystem Guidelines

GoalsLoose coupling Portability, plug-and-play compatibility Insulation from change Independent evolution

Strong SuggestionsDo not expose details, only interfacesDepend only on other interfaces

Each subsystem should be as independent as possible from other parts of the system. It should be possible to evolve different parts of the system independently from other parts. This minimizes the impact of changes and eases maintenance efforts.

It should be possible to replace any part of the system with a new part, provided the new part supports the same interfaces. In order to ensure that subsystems are replaceable elements in the model, the following conditions are necessary:

• A subsystem should not expose any of its contents. No element contained by a subsystem should have “public” visibility. No element outside the subsystem should depend on the existence of a particular element inside the subsystem.

• A subsystem should depend only on the interfaces of other model elements, so that it is not directly dependent on any specific model elements outside the subsystem. The exceptions are cases where a number of subsystems share a set of class definitions in common, in which case those subsystems “import” the contents of the packages that contain the common classes. This should be done only with packages in lower layers in the architecture, and only to ensure that common definitions of classes that must pass between subsystems are consistently defined.

• All dependencies on a subsystem should be dependencies on the subsystem interfaces. Clients of a subsystem are dependent on the subsystem interface(s), not on elements within the subsystem. In that way, the subsystem can be replaced by any other subsystem that realizes the same interfaces.




Subsystem Design Steps

7

Distribute subsystem behavior to subsystem elements

Document subsystem elements

Describe subsystem dependencies

Checkpoints


This slide shows the major steps involved in the Subsystem Design activity.

We first must take the responsibilities allocated to the subsystems and further allocate those responsibilities to the subsystem elements.

Once the subsystem elements have been identified, the internal structure of the subsystems (a.k.a. subsystem element relationships) must be documented.

Once you know how the subsystem will implement its responsibilities, you need to document the interfaces upon which the subsystem is dependent.

Finally, we will discuss the kinds of things you should look for when reviewing the results of Subsystem Design.





8


Distribute subsystem behavior to subsystem elementsDocument subsystem elementsDescribe subsystem dependenciesCheckpoints

You first must take the responsibilities allocated to the subsystems and further allocate those responsibilities to the subsystem elements.

The purpose of this step is to:

• Specify the internal behaviors of the subsystem • Identify new classes or subsystems needed to satisfy subsystem behavioral

requirements. In designing the internals of the subsystem interactions, you will need to take into consideration the use-case details; the architectural framework, including defined subsystems, their interfaces and dependencies; and the design and implementation mechanisms selected for the system.

Up to this point, you have created interaction diagrams in terms of design elements (that is, design classes and subsystems). In this activity, you will describe the "local" interactions within a subsystem to clarify its internal design.




Subsystem Responsibilities

9

Subsystem responsibilities defined by interface operations

Model interface realizationsInterface may be realized by

Internal class behaviorSubsystem behavior


getCourseOfferings ()Initialize ()

<<interface>>

Subsystem responsibility

Subsystem Responsibilities


getCourseOfferings ()Initialize ()

The external behaviors of the subsystem are defined by the interfaces it realizes. When a subsystem realizes an interface, it makes a commitment to support each and every operation defined by the interface.

The operation may be in turn realized by:

• An operation on a class contained by the subsystem; this operation may require collaboration with other classes or subsystems.

• An operation on an interface realized by a contained subsystem. The collaborations of model elements within the subsystem should be documented using sequence diagrams that show how the subsystem behavior is realized. Each operation on an interface realized by the subsystem should have one or more documenting sequence diagrams. This diagram is owned by the subsystem, and is used to design the internal behavior of that subsystem.




Distributing Subsystem Responsibilities

10

Distributing Subsystem Responsibilities

Identify new, or reuse existing, design elements (for example, classes and/or subsystems)Allocate subsystem responsibilities to design elements Incorporate applicable mechanisms (for example, persistence, distribution)Document design element collaborations in “interface realizations”

One or more interaction diagrams per interface operationClass diagram(s) containing the required design element relationships

Revisit “Identify Design Elements”Adjust subsystem boundaries and dependencies, as needed

For each interface operation, identify the classes (or, where the required behavior is complex, a contained subsystem) within the current subsystem that are needed to perform the operation. Create new classes/subsystems where existing classes/subsystems cannot provide the required behavior (but try to reuse first).

Creation of new classes and subsystems should force reconsideration of subsystem content and boundary. Be careful to avoid having effectively the same class in two different subsystems. Existence of such a class implies that the subsystem boundaries may not be well-drawn. Periodically revisit Identify Design Elements to re-balance subsystem responsibilities.

The collaborations of model elements within the subsystem should be documented using interaction diagrams that show how the subsystem behavior is realized. Each operation on an interface realized by the subsystem should have one or more documenting interaction diagrams. This "internal" interaction diagram shows exactly what classes provide the interface, what needs to happen internally to provide the subsystem’s functionality, and which classes send messages out from the subsystem. These diagrams are owned by the subsystem, and are used to design the internal behavior of the subsystem. The diagrams are essential for subsystems with complex internal designs. They also enable the subsystem behavior to be easily understood, rendering it reusable across contexts.

These internal interaction diagrams should incorporate any applicable mechanisms initially identified in Identify Design Mechanisms (for example, persistence, distribution, and so on.)




What Are Gates?

11

What Are Gates?

A connection point in an interaction for a message that comes into or goes outside the interaction.

A point on the boundary of the sequence diagramThe name of the connected message is the name of the gate

Input gate

Output gate

sd example

: ClassName

A gate is a parameter that represents a message that crosses the boundary of an interaction or interaction fragment. Messages within the interaction can be connected to the gate. If the interaction is referenced within another interaction, messages may be connected to its gates. When the interaction is executed, messages connected through gates will be delivered properly.




Subsystem Interaction Diagrams

12

Internal subsystem interactions


Subsystem Interaction Diagrams

: Client Subsystem : Supplier Subsystem

performResponsibility( )

Black box view of subsystems

All elements on a diagram should represent the same level of abstraction.




Internal Structure of Supplier Subsystem

13

Internal Structure of Supplier Subsystem

Subsystem Manager coordinates the internal behavior of the subsystem.

The complete subsystem behavior is distributed amongst the internal Design Element classes.

: Subsystem Manager

: DesignElement1

: DesignElement2

Supplier Subsystem




Modeling Convention: Internal Subsystem Interaction

14

Modeling Convention: Internal Subsystem Interaction

: SubsystemManager

: DesignElement1

: DesignElement2

performResponsibility( )doThis( )

thisAgain( )

doThat( )

thatAgain( )

sd PerformResponsibility

White box view of Supplier Subsystem

This slide describes the modeling conventions we will be using to model the internal subsystem element interactions.

As discussed earlier, there should be at least one interaction diagram per interface operation to illustrate how the operations offered by the interfaces of the subsystem are performed by model elements contained in the subsystem.

These interaction diagrams should start with a message coming through a gate, the message should be mapped to/associated with the interface operation that is being modeled in the interaction diagram.

The remainder of the diagram should model how the <<subsystem>> class delegates responsibility for performing the invoked operation to the other subsystem elements.

It is recommended that you name the interaction diagram using the operation name. This naming convention simplifies future tracing of interface behaviors to the classes that implement the interface operations.




Example: CourseCatalogSystem Subsystem in Context

15

Example: CourseCatalogSystem Subsystem in Context

Legacy RDBMS Database Access

Subsystem


: RegisterForCoursesForm : RegistrationController : Schedule : Student: CourseCatalogSystem

1: // create schedule1.1: // get course offerings

1.1.1: getCourseOfferings

1.3: // display course offeringsA list of the available course offerings for this semester are displayed

A blank schedule is displayed for the Student to select offerings

Student wishes tocreate a new schedule

1.5: // display blank schedule

Select Offerings

Submit Schedule

ref

ref

The above sequence diagram is the same as was shown in the Use-Case Design module. It demonstrates how interactions are modeled between design elements, where one of the elements is a subsystem. In the Use-Case Design module, we did not flesh out the internals of the CourseCatalog subsystem. That is the purpose of this activity, Subsystem Design.

The sequence diagram sets the context of what will be performed in Subsystem Design. It puts requirements on the subsystem, and is the primary input specification to the task of creating local interactions for the subsystem.

In the above example we see the operations that the CourseCatalog subsystem must support. This shows the simple way that a client (RegistrationController here) deals with the task of requesting the course offerings from the legacy course catalog system. The ICourseCatalogSystem::getCourseOfferings() documentation specifies the following: “Retrieve the course offerings available for the specified semester.” Thus, the retrieval of the course offerings from the legacy database is the responsibility of the CourseCatalog subsystem. It is now, in Subsystem Design, that we will describe exactly how this is done, using the defined RDBMS persistency mechanism.





16


Student





Distribution


Analysis-Class-to-Architectural-Mechanism Map from Use-Case Analysis


OODBMS Persistency was discussed in Use-Case Design

OODBMS Persistency

RDBMS Persistency

During Use-Case Analysis, applicable mechanisms for each identified analysis class were documented. This information, along with the information on what analysis classes became what design elements allows the applicable mechanisms to identify a design element.

In this example, you have been concentrating on course registration. Thus, the above table contains only the classes for the Register for Courses Use-Case Realization that have analysis mechanisms assigned to them.

In this section, you will incorporate the legacy RDBMS persistency mechanism because access to the legacy systems has been encapsulated within a subsystem (the CourseCatalog subsystem). The legacy interface mechanism distinguishes the type of persistency. Remember, legacy data is stored in an RDBMS.




Review: Incorporating JDBC: Steps

17

1. Provide access to the class libraries needed to implement JDBC

Provide java.sql package2. Create the necessary DBClasses

One DBClass per persistent classCourse Offering persistent class => DBCourseOffering

Review: Incorporating JDBC: Steps

√

√ = Done

This slide summarizes the steps that can be used to implement the RDBMS Persistency mechanism (JDBC) described in this module. The italicized text describes the architectural decisions made with regard to JDBC for our Course Registration example.

These steps were first introduced in the Identify Design Mechanisms module. They are repeated here for convenience (with some additions). The check marks indicate what steps have already been completed.

It is here, in Subsystem Design, where you actually incorporate this mechanism. Now you will define the actual DBClasses (and their dependency on the java.sql package) and develop the detailed interaction diagrams.

• The java.sql package contains the design elements that support the RDBMS persistency mechanism. For our example, the CourseCatalogSystem subsystem will depend on it since that is where the created DBCourseOffering class will be placed (see below). Thus, a dependency will need to be added from CourseCatalogSystem to java.sql.

• There is one DBClass per persistent class. For our example, there is a persistent class, CourseOffering. Thus, a DBCourseOffering class will be created.

See the next slide for the rest of the steps.




Review: Incorporating JDBC: Steps (continued)

18

3. Incorporate DBClasses into the designAllocate to package/layer• DBCourseOffering placed in

CourseCatalogSystem subsystemAdd relationships from persistency clients• Persistency clients are the

CourseCatalogSystem subsystem clients4. Create/Update interaction diagrams that

describe:Database initializationPersistent class access: Create, Read, Update, Delete

Review: Incorporating JDBC: Steps (continued)

This slide continues the summary of the steps that use the RDBMS Persistency mechanism (JDBC). The italicized text describes the architectural decisions made with regard to JDBC for our Course Registration example.

• Once created, the DBClasses must be incorporated into the existing design.They must be allocated to a package/layer. For our example, the DBCourseOffering class will be placed in the CourseCatalogSystem subsystem.

• Once the DBClasses have been allocated to packages/layers, the relationships to the DBClasses from all classes requiring persistence support (that is, the persistency clients) will need to be added. For our example, the persistency clients are the clients of the CourseCatalogSystem subsystem. These dependencies have already been established (see earlier context diagram).

• The interaction diagrams provide a means to verify that all required database functionality is supported by the design elements.The sample interaction diagrams provided for the persistency architectural mechanisms during Identify Design Mechanisms should serve as a starting point for the specific interaction diagrams defined in detailed design.




Review: Persistency: RDBMS: JDBC: Read

19

Review : Persistency: RDBMS: JDBC: Read: PersistentClass: Connection : Statement : ResultSet: PersistencyClient : DBClass : PersistentClassList

1. read(string)


1.2. executeQuery(string)

1.5. new()

1.6. getString( )

1.7. setData( )

Returns a Statement

1.4. new( )

Create a list to hold all retrieved data

1.8. add(PersistentClass)

The SQL statement built by the DBClass using the given criteria is passed to executeQuery()The criteria used to

access data for the persistent class

loop

[for each class from execute query]

loop[for each attribute in class]

1.3 // executeQuery()






Example: Local CourseCatalogSystem Subsystem Interaction

20

Example: Local CourseCatalogSystem Subsystem Interaction

persistentClass

: CourseOffering

: Connection : Statement : ResultSetpersistencyClient :CourseCatalog

System

dbClass :DBCourseOffering

persistentClassList: Course

OfferingList : Course Catalog

sd getCourseOfferings

refJDBC Read

//executeQuery()

getCourseOffering()

Subsystem






Example: Billing System Subsystem In Context

21

Example: Billing System Subsystem In Contextsubsystem interface

: Registrar : CloseRegistrationForm

: CourseOffering

: Schedule : Student. : IbillingSystem

: ICourseCatalogSystem

: CloseRegistrationController

Close registration for each course offering

Retrieve a list of course offerings for the current semester

If the maximum number of selected primary courses have not been committed, select alternate course offerings).

Currently assuming tuition based on number of offerings taken and certain attributes of students. If different offerings get different prices this will change slightly.

Repeat twice thisis for simplicity; realistically, an indefinite numberof iterations could occur)

Finally commit or cancel the course offering once all leveling has occurred

1. // close registration( )

2. // close registration( )

2.2. // close registration( )

1.1. // is registration open?( )

2.6. submitBill(Student, double)

2.3. // level( )

2.1. getCourseOfferings(Semester)

2.4. // close( )

2.5. getTuition( )

subsystem responsibility

do the actual billing to the student for the schedule.

Send student and tuition to the Billing System, which will

In this example, we will demonstrate the design of a subsystem that does not require the incorporation of an architectural mechanism.

The above sequence diagram is a portion of the Close Registration use-case realization sequence diagram. The internals of the Billing System subsystem have not been designed yet. That is the purpose of this activity, Subsystem Design.

This diagram sets the context of what will be performed in Subsystem Design. It puts requirements on the subsystem, and is the primary input specification for the task of creating local interactions for the subsystem.

In the above example for the BillingSystem subsystem, we see the operations the subsystem must support. This shows the simple way that some client (CloseRegistrationController here) deals with the task of submitting a student bill to the legacy Billing System. The IBillingsystem:submitBill() operation documentation specifies the following: “Billing information must be converted into a format understood by the external Billing System, and then submitted to the external Billing System.” Thus, the actual generation and submission of the bill is the responsibility of the Billing System subsystem. In Subsystem Design, we will describe exactly how this is done.




Example: Local BillingSystem Subsystem Interaction

22

Example: Local BillingSystem Subsystem InteractionSubsystem

Billing System Client

: BillingSystem : StudentBillingTransaction :BillingSystemInterface : Billing System: Student

1. submitBill(Student, double)

1.1. create(Student, double)

1.2. submit(StudentBillingTransaction)

1.1.1. // get contact info( )

Retrieve the information that must be included on the bill

1.2.1. // open connection( )

1.2.2. // process transaction( )

1.2.3. // close connection( )

Designing the internals of a subsystem should yield (local) interaction diagrams like the sequence diagram shown above.

This example “looks inside” the BillingSystem subsystem and shows the collaborations required to implement the submitBill() operation of the IBillingSystem interface.

The client object initiating the interaction is abstracted to be an untyped object here.That is because, within the scope of the design of this one subsystem, we do not care who the client is.

The BillingSystem subsystem proxy class actually realizes the IBillingSystem interface. It is the class that delegates the implementation of the interface to the subsystem elements.

The BillingSystem proxy class instance creates a StudentBillingTransaction specific to the external Billing System. This transaction will be in a format that the Billing System can process. The StudentBillingTransaction knows how to create itself using information from the given Student. After creating the StudentBillingTransaction, the BillingSystem proxy class instance submits the transaction to the class instance that actually communicates with the Billing System.





23



At this point, the responsibilities allocated to the subsystems have been further allocated to subsystem elements, and the collaborations between the subsystem elements have been modeled using interaction diagrams.

Now you must document and model the internal structure of the subsystem. This internal structure is driven by what is required to support the collaborations to implement the subsystem interfaces, as documented in the previous step.

This is where you model the subsystem element relationships.

To document the internal structure of the subsystem, create one or more class diagrams showing the elements contained by the subsystem and their associations with one another. One class diagram should be sufficient, but more can be used to reduce complexity and improve readability.

In addition, a state diagram might be needed to document the possible states the subsystem can assume (interfaces and subsystems are “stateful”).

It is also important to document any order dependencies between subsystem interface operations (for example, op1 must be executed before op2, and so on).




Example: CourseCatalogSystem Subsystem Elements

24

Example: CourseCatalogSystem Subsystem Elements

Subsystem Component

Subsystem Interface


getCourseOfferings(forSemester : Semester) : CourseOfferingList


<<Interface>>

1

1

CourseOfferingList

new()add()


1

0..*

CourseOffering

new()setData()


<<Entity>>Statement

executeQuery()executeUpdate()

(from java.sql)Connection

createStatement()

(from java.sql) ResultSet

getString()

(from java.sql)

DBCourseOfferring

create() : CourseOfferingread(searchCriteria : string) : CourseOfferingList

CourseCatalogSystem

getCourseOfferings(forSemester : Semester) : CourseOfferingList

<<subsystem >>

DriverManager

getConnection(url, user, pass) : Connection

(from java.sql)

This diagram models the subsystem elements and their relationships. These relationships support the required collaborations between the design elements to support the behavior of the subsystem (as documented in the subsystem interfaces). For our purposes, we concentrated on the getCourseOfferings() interface operation.

CourseCatalogSystem works with DBCourseOffering to read and write persistent data from the Course Catalog System RDBMS. DBCourseOffering is responsible for accessing the JDBC database using the previously established Connection (see JDBC Initialize interaction diagram). Once a database connection is opened, DBCourseOffering can then create SQL statements that will be sent to the underlying RDBMS and executed using the Statement class. The results of the SQL query is returned in a ResultSet class object.

Note: Elements outside of the subsystem are shown, as well, to provide context. These elements can be identified because their owning package is listed in parentheses below the class name (for example, “from University Artifacts”).

Just as in Use-Case Analysis and Use-Case Design, the subsystem element collaborations modeled previously in the interaction diagrams drive the relationships defined between the participating design elements.

This is exactly the same approach we used to identify analysis class relationships in Use-Case Analysis and to identify design element relationships in Use-Case Design.




Example: Billing System Subsystem Elements

25

Example: Billing System Subsystem Elements

Subsystem Interface

0..1

1

Subsystem Component

StudentBillingTransaction

create(forStudent : Student, forAmount : double)

Student

// get contact info()


<<Entity>>

BillingSystem

submitBill(forStudent : Student, forTuition : double)

<<subsystem>>

BillingSystemInterface

submit(theTransaction : StudentBillingTransaction)

IBillingSystem

submitBill()


<<Interface>>

This diagram models the subsystem elements and their relationships. These relationships support the required collaborations between the design elements to support the behavior of the subsystem (as documented in the subsystem interfaces). For our purposes, we concentrated on the submitBill() interface operation.

Note: Elements outside of the subsystem are shown, as well, to provide context. These elements can be identified because their owning package is listed in parentheses below the class name (for example, “from University Artifacts”).

Just as in Use-Case Analysis and Use-Case Design, the subsystem element collaborations modeled previously in the interaction diagrams drive the relationships defined between the participating design elements.

This is exactly the same approach we used to identify analysis class relationships in Use-Case Analysis and to identify design element relationships in Use-Case Design.





26



At this point, subsystem elements have been defined to implement the subsystem responsibilities, the resulting collaborations between the elements have been modeled using interaction diagrams, and the internal structure of the subsystem (that is, the relationships between subsystem elements) has been modeled using class diagrams.

Now we must document the elements external to the subsystem, upon which the subsystem is dependent. These dependencies may have been introduced when designing the internals of the subsystem as described earlier in this module.

Note: Subsystems might not be able to stand alone; they might need the services of other subsystems. Rather than forcing all the definition work onto the architect (or architecture team), which could become rather bureaucratic and cumbersome, the subsystem designer should feel free to use the services of other subsystems. However, the architect establishes the ground rules for such referencing (through design and layering guidelines), and ultimately must agree with the dependencies.




Subsystem Dependencies: Guidelines

27

Subsystem dependency on a subsystem

Subsystem dependency on a package

Subsystem Dependencies: Guidelines

Flexible, Preferred

Server

Use with careClient Support<<subsystem>>

SupportingTypes

Client Support<<subsystem>>

Server Support<<subsystem>>

When a subsystem element uses some behavior of an element contained by another subsystem or package, a dependency on the external element is needed.

If the element on which the subsystem is dependent is within a subsystem, the dependency should be on the subsystem interface, not on the subsystem itself or on any element in the subsystem. This allows the design elements to be substituted for one another as long as they offer the same behavior. It also gives the designer total freedom in designing the internal behavior of the subsystem, as long as it provides the correct external behavior. If a model element directly references a model element in another subsystem, the designer is no longer free to remove that model element or redistribute the behavior of that model element to other elements. As a result, the system is more brittle.

If the element the subsystem element is dependent on is within a package, the dependency should be on the package itself. Ideally, a subsystem should only depend on the interfaces of other model elements for the reasons stated above.The exception is where a number of subsystems share a set of common class definitions, in which case those subsystems “import” the contents of the packages containing the common classes. This should be done only with packages in lower layers in the architecture to ensure that common class definitions are defined consistently. The disadvantage is that the subsystem cannot be reused independent of the depended-on package.




Example: CourseCatalogSystem Subsystem Dependencies

28

Example: CourseCatalogSystem Subsystem Dependencies

java.sql(from Middleware)

CourseCatalogSystem


<<subsystem>> External System Interfaces



This diagram models the dependencies that the CourseCatalogSystem subsystem has with other design elements. These dependencies support the relationships of the enclosed classes as modeled on the earlier subsystem class diagrams. They are on standard packages that do not have a specific interface. Thus, the CourseCatalogSystem subsystem cannot be reused without the packages it depends on.

The CourseCatalogSystem subsystem is dependent on the java.sql package in order to gain access to the design elements that implement the RDBMS persistency mechanism.

The CourseCatalogSystem subsystem is dependent on the External System Interfaces package for gaining access to the subsystem interface itself (ICourseCatalogSystem). Remember, the subsystem interfaces were not packaged with the subsystems themselves.

The CourseCatalogSystem subsystem is dependent on the University Artifacts package in order to gain access to the core types of the Course Registration System.




Example: BillingSystem Subsystem Dependencies

29

Example: BillingSystem Subsystem Dependencies

BillingSystem(from Business Services)

<<subsystem>>




This diagram models the dependencies that the BillingSystem subsystem has with other design elements. These dependencies support the relationships of the enclosed classes as modeled on the earlier subsystem class diagrams. They are on standard packages that do not have a specific interface. Thus, the BillingSystem subsystem cannot be reused without the packages it depends on.

The BillingSystem subsystem is dependent on the External System Interfaces package in order to gain access to the subsystem interface itself (IBillingSystem). Remember, the subsystem interfaces were not packaged with the subsystems themselves.

The BillingSystem subsystem is dependent on the University Artifacts package in order to gain access to the core types of the Course Registration System.





30



Now we will discuss the kinds of things you should look for when reviewing the results of Subsystem Design.




Checkpoints: Design Subsystems

31

Checkpoints: Design Subsystems

Is a realization association defined for each interface offered by the subsystem?Is a dependency association defined for each interface used by the subsystem?Are you sure that none of the elements within the subsystem have public visibility?Is each operation on an interface realized by the subsystem documented in a interaction diagram? If not, is the operation realized by a single class, so that it is easy to see that there is a simple 1:1 mapping between the class operation and the interface operation?

This checklist includes the key things to look for when assessing the results of Subsystem Design.

A designer is responsible for the integrity of the design subsystem, ensuring that:

• The subsystem encapsulates its contents, only exposing contained behavior through interfaces it realizes.

• The operations of the interfaces the subsystem realizes are distributed to contained classes or subsystems.

• The subsystem properly implements its interfaces.




Review

32

Review: Subsystem Design

What is the purpose of Subsystem Design?What are gates? Why should dependencies on a subsystem be on the subsystem interface?




Exercise: Subsystem Design

33

Exercise: Subsystem Design

Given the following:The defined subsystems, their interfaces and their relationships with other design elements (the subsystem context diagrams)• Payroll Exercise Solution, Identify Design

Elements

Patterns of use for the architectural mechanisms• Exercise Workbook: Payroll Architecture

Handbook, Architectural Mechanisms, Implementation Mechanisms section

The goal is to perform the subsystem design of one of the previously identified subsystems. There are not really any specific requirements for these subsystems, so, for the purpose of this exercise, concentrate on incorporating the applicable architectural mechanisms (for example, persistency, security, distribution), and just some basic functionality the subsystem may perform. Do not worry about developing a detailed subsystem design. For such a design, you would need more detailed requirements.

• Subsystem context class diagrams: Payroll Exercise Solution, Identify Design Elements,

• Exercise: Identify Design Elements, Subsystem Context Diagrams section. Note the operations descriptions.

• The patterns of use for the architectural mechanisms: Exercise Workbook: Payroll Architecture Handbook, Architectural Mechanisms, Implementation Mechanisms section.




Exercise: Subsystem Design (continued)

34


Identify the following for a particular subsystem(s):

The design elements contained within the subsystem and their relationshipsThe applicable architectural mechanisms The interactions needed to implement the subsystem interface operations

The process used in Subsystem Design is no different from that used in Use-Case Analysis and Use-Case Design, except instead of allocating use-case responsibilities, you are allocating subsystem interface responsibilities. For each subsystem interface operation, you identify design elements that are needed to implement the interface, and then you allocate some responsibilities to it. Next, you develop interaction diagrams to illustrate the necessary collaborations, and class diagrams to model the supporting relationships. You are, in fact, developing “interface realizations” rather than Use-Case Realizations.

There are no explicit requirements for the details of the subsystem (that’s what detailed design is all about). In any case, use the documentation for the interface and interface operations to guide you.

Remember, design elements can be classes and/or subsystems.

When developing the interactions, do not forget to incorporate any applicable architectural mechanisms. In this course, we are concentrating on the following architectural mechanisms: persistency, security, distribution, and legacy interface.

The defined design element relationships should support the interactions required to implement the subsystem interface responsibilities/interfaces.





35


Produce the following diagrams for a particular subsystem(s):

“Interface realizations”• Interaction diagram for each interface

operation• Class diagram containing the subsystem

design elements that realize the interface responsibilities and their relationships

Class diagram that shows the subsystem and any dependencies on external package(s) and/or subsystem(s) (subsystem dependencies class diagram)

There is one interaction diagram per interface operation to ensure that all responsibilities have been allocated to a subsystem element. Naming the diagrams to reflect the operation they model helps with traceability. The interaction diagrams may be communication or sequence diagrams.

As with Use-Case Realizations, for interface realizations there is a class diagram that contains the design elements that realize the interface responsibilities. Just like the VOPC for use-case realizations, for every link on the interaction diagrams, there should be a relationship on the class diagram.

During detailed design, we may have found that the subsystem needs the services of something outside of the subsystem in order to fulfill its responsibilities. In such a case, the subsystem must have a dependency on that element (or the containing package or subsystem). These elements are “suppliers” of the subsystem. Such dependencies are usually monitored and regulated by the architecture team.

The subsystem dependencies class diagram should contain the subsystem and any dependencies on external packag(es) and/or subsystem(s). This diagram is meant to show the subsystem dependencies on external design elements.

Remember to use the conventions recommended in the course.

References to sample diagrams within the course that are similar to what should be produced are: • Subsystem interface operation interaction diagram: 12-21. • Subsystem class diagram: 12-24 and 12-25. • Subsystem dependencies class diagram: 12-28 and 12-29.




Exercise: Review

36

Exercise: Review

Compare your Subsystem Interface Realizations

Have all the main and/or subflows for the interface operations been handled?Has all behavior been distributed among the participating design elements?Has behavior been distributed to the right design elements?Are there any messages coming from the interfaces?

After completing a model, it is important to step back and review your work. Some helpful questions are:

• Have all the main and/or subflows for the interface operations been handled? • Has all behavior been distributed among the participating design elements? This

includes design classes and interfaces. • Has behavior been distributed to the right design elements? • Are there any messages coming from the interface? Remember, messages should

not come from an interface because the behavior is realized by the subsystem.



► ► ► Module 13 Class Design

1

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 13: Class Design

Topics Class Design Overview ....................................................................................... 13-4 Class Design Considerations ............................................................................... 13-7 Define Operations............................................................................................ 13-12 Define Methods ............................................................................................... 13-21 Define States.................................................................................................... 13-23 Define Attributes .............................................................................................. 13-35 Define Dependencies....................................................................................... 13-44 Define Associations .......................................................................................... 13-54 Define Internal Structure .................................................................................. 13-73 Define Generalizations ..................................................................................... 13-82 Resolve Use-Case Collisions............................................................................ 13-106 Handle Non-Functional Requirements in General........................................... 13-108 Review........................................................................................................... 13-115




Objectives: Class Design

2

Objectives: Class Design

Define the purpose of Class Design and where in the lifecycle it is performedIdentify additional classes and relationships needed to support implementation of the chosen architectural mechanismsIdentify and analyze state transitions in objects of state-controlled classesRefine relationships, operations, and attributes

In Class Design, the focus is on fleshing out the details of a particular class (for example, what operations and classes need to be added to support, and how do they collaborate to support, the responsibilities allocated to the class).



Module 13 - Class Design

Class Design in Context

3

Class Design in Context[Early





Synthesis

Analyze Behavior


DesignComponents

Design theDatabase

(Optional)

ClassDesign Designer

As you may recall, the above diagram illustrates the workflow that we are using in this course. It is a tailored version of the Analysis and Design core workflow of the Rational Unified Process.

Identify Design Elements is where you decide what the infrastructure is. The infrastructure is the pieces of the architecture, if you will, and how they interact. Use-Case Design is where the responsibilities of the system are allocated to the pieces. Subsystem Design and Class Design are where you detail the specifics of the pieces.

During Class Design, you take into account the implementation and deployment environments.You may need to adjust the classes to the particular products in use, the programming languages, distribution, adaptation to physical constraints (for example, limited memory), performance, use of component environments such as COM or CORBA, and other implementation technologies.

There is frequent iteration between Class Design, Subsystem Design, and Use-Case Design.

Class Design is performed for each class in the current iteration.




Class Design Overview

4

Class Design Overview


ClassDesign


Design Classes

Design Model

Design Use-Case Realization Analysis Use-Case

Realization

Analysis Classes

Purpose:

• Ensure that the classes provide the behavior the Use-Case Realizations require. • Ensure that sufficient information is provided to implement the class. • Handle non-functional requirements related to the class. • Incorporate the design mechanisms used by the class. Input Artifacts:

• Supplementary Specifications • Project Specific Guidelines • Analysis Classes • Analysis use-case realization • Design classes • Design Model • Design use-case realization Resulting Artifacts:

• Design classes • Design Model The detailed steps performed during this activity are summarized on the next page, and described in the remainder of this module.




Class Design Steps

5

Class Design Steps

Create Initial Design ClassesDefine OperationsDefine MethodsDefine StatesDefine AttributesDefine DependenciesDefine AssociationsDefine Internal StructureDefine GeneralizationsResolve Use-Case CollisionsHandle Nonfunctional Requirements in GeneralCheckpoints

The Class Design steps that you will address in this module are listed above.




Class Design Steps

6

Class Design Steps

Create Initial Design ClassesDefine OperationsDefine MethodsDefine StatesDefine AttributesDefine DependenciesDefine AssociationsDefine Internal StructureDefine GeneralizationsResolve Use-Case CollisionsHandle Non-Functional Requirements in GeneralCheckpoints

At this point, we create one or several (initial) design classes from the original design classes given as input to this activity. The design classes created in this step will be refined, adjusted, split and/or merged in the subsequent steps when assigned various "design" properties, such as operations, methods, and a state machine, describing how the class is designed.




Class Design Considerations

7

Class Design Considerations

Class stereotypeBoundaryEntityControl

Applicable design patternsArchitectural mechanisms

PersistenceDistributionetc.

When performing Class Design, you need to consider:

• How the classes that were identified in analysis as boundary, control, and entity classes will be realized in the implementation.

• How design patterns can be used to help solve implementation issues. • How the architectural mechanisms will be realized in terms of the defined design

classes. Specific strategies can be used to design a class, depending on its original analysis stereotype (boundary, control, and entity). These stereotypes are most useful during Use-Case Analysis when identifying classes and allocating responsibility. At this point in design, you really no longer need to make the distinction — the purpose of the distinction was to get you to think about the roles objects play, and make sure that you separate behavior according to the forces that cause objects to change. Once you have considered these forces and have a good class decomposition, the distinction is no longer really useful.

Here the class is refined to incorporate the architectural mechanisms.

When you identify a new class, make an initial pass at its relationships. These are just the initial associations that tie the new classes into the existing class structure. These will be refined throughout Class Design.




How Many Classes Are Needed?

8

A class should have a single well-focused purpose. A class should do one thing and do it well!

How Many Classes Are Needed?

Many, simple classes means that each class Encapsulates less of the overall system intelligenceIs more reusableIs easier to implement

A few, complex classes means that each classEncapsulates a large portion of the overall system intelligenceIs less likely to be reusableIs more difficult to implement

These are some things you should think about as you define additional classes.

The proper size of a class depends heavily on the implementation environment. Classes should map directly to some phenomenon in the implementation language in such a way that the mapping results in good code.

With that said, you should design as if you had classes and encapsulation even if your implementation language does not support it. This will help keep the structure easy to understand and modify.




Strategies for Designing Boundary Classes

9

Strategies for Designing Boundary Classes

User interface (UI) boundary classesWhat user interface development tools will be used?How much of the interface can be created by the development tool?

External system interface boundary classesUsually model as subsystem

<<subsystem>>MainForm

SubWindow

DropDownListButton

MainWindow

During Analysis, high-level boundary classes are identified. During Design, the design must be completed. You may need to create additional classes to support actual GUI and external system interactions.

Some mechanisms used to implement the UI can be architecturally significant. These should be identified and described by the architect in the Identify Design Mechanisms activity, and applied by the designer here in the Class Design activity. Design of user interface boundary classes will depend on the user interface development tools being used on the project. You only need design what the development environment will not automatically create for you. All GUI builders are different. Some create objects containing the information from the window. Others create data structures with the information. Any prototyping of the user interface done earlier is a good starting point for this phase of design.

Since interfaces to external systems usually have complex internal behavior, they are typically modeled as subsystems. If the interface is less complex, such as a pass through to an existing API, you may represent it with one or more design classes. In the latter case, use a single design class per protocol, interface, or API.




Strategies for Designing Entity Classes

10

Strategies for Designing Entity Classes

Entity objects are often passive and persistentPerformance requirements may force some re-factoring

Analysis

FatClassLazyDataHelper

- rarelyUsedAttr1- rarelyUsedAttr2

DesignFatClass

- privateAttr

+ getCommonlyUsedAttr1()+ getCommonlyUsedAttr2()+ getRarelyUsedAtt1()+ getRarelyUsedAtt2()

FatClassDataHelper

- commonlyUsedAttr1- commonlyUsedAttr2

1 0..1

FatClass- privateAttr- commonlyUsedAttr1- commonlyUsedAttr2- rarelyUsed1- rarelyUsed2

<< Entity >>

During Analysis, entity classes may have been identified and associated with the analysis mechanism for persistence, representing manipulated units of information. Performance considerations may force some re-factoring of persistent classes, causing changes to the Design Model that are discussed jointly between the database designer and the designer responsible for the class. The details of a database-based persistence mechanism are designed during Database Design, which is beyond the scope of this course.

Here we have a persistent class with five attributes. One attribute is not really persistent; it is used at runtime for bookkeeping. From examining the use cases, we know that two of the attributes are used frequently. Two other attributes are used less frequently. During Design, we decide that we’d like to retrieve the commonly used attributes right away, but retrieve the rarely used ones only if some client asks for them. We do not want to make a complex design for the client, so, from a data standpoint, we will consider the FatClass to be a proxy in front of two real persistent data classes. It will retrieve the FatClassDataHelper from the database when it is first retrieved. It will only retrieve the FatClassLazyDataHelper from the database in the rare occasion that a client asks for one of the rarely used attributes.

Such behind-the-scenes implementation is an important part of tuning the system from a data-oriented perspective while retaining a logical object-oriented view for clients to use.




Strategies for Designing Control Classes

11

Strategies for Designing Control Classes

What happens to Control Classes?Are they really needed?Should they be split?

How do you decide?ComplexityChange probabilityDistribution and performanceTransaction management

If control classes seem to be just “pass-throughs” from the boundary classes to the entity classes, they may be eliminated.

Control classes may become true design classes for any of the following reasons:

• They encapsulate significant control flow behavior. • The behavior they encapsulate is likely to change. • The behavior must be distributed across multiple processes and/or processors. • The behavior they encapsulate requires some transaction management. We saw in the Describe Distribution module how a single control class in Analysis became two classes in Design (a proxy and a remote). For our example, the control classes were needed in Design.




Define Operations

12

Class Design Steps


At this point, an initial set of design classes has been identified. Now we can turn our attention to finalizing the responsibilities that have been allocated to those classes.




Operations: Where Do You Find Them?

13

Messages displayed in interaction diagrams

Other implementation dependent functionality Manager functionsNeed for class copiesNeed to test for equality

Operations: Where Do You Find Them?

: ClassA

1 : //Perform Responsibility

: ClassB : ClassA

1 : performResponsibility (): result

: ClassB

To identify operations on design classes:

• Study the responsibilities of each corresponding analysis class, creating an operation for each responsibility. Use the description of the responsibility as the initial description of the operation.

• Study the Use-Case Realizations in the class participations to see how the operations are used by the Use-Case Realizations. Extend the operations, one Use-Case Realization at a time, refining the operations, their descriptions, return types and parameters. Each Use-Case Realization's requirements, as regards classes, are textually described in the Flow of Events of the Use-Case Realization.

• Study the use-case Special Requirements, to make sure that you do not miss implicit requirements on the operation that might be stated there.

Use-Case Realizations cannot provide enough information to identify all operations. To find the remaining operations, consider the following:

• Is there a way to initialize a new instance of the class, including connecting it to instances of other classes to which it is associated?

• Is there a need to test to see if two instances of the class are equivalent? • Is there a need to create a copy of a class instance? • Are any operations required on the class by mechanisms which they use?

(Example: a “garbage collection” mechanism may require that an object be able to drop all of its references to all other objects in order for unused resources to be freed.)




Name and Describe the Operations

14

Name and Describe the Operations

Create appropriate operation namesIndicate the outcomeUse client perspectiveAre consistent across classes

Define operation signaturesoperationName([direction]parameter : class,..) : returnType• Direction is in (default), out or inout• Provide short description, including meaning

of all parameters

Operations should be named to indicate their outcome. For example, getBalance() versus calculateBalance(). One approach for naming operations that get and set properties is to simply name the operation the same name as the property. If there is a parameter, it sets the property; if not, it returns the current value.

You should name operations from the perspective of the client asking for a service to be performed by the class. For example, getBalance() versus receiveBalance(). The same applies to the operation descriptions. Descriptions should always be written from the operation USER’s perspective. What service does the operation provide?

It is best to specify the operations and their parameters using implementation language syntax and semantics. This way the interfaces will already be specified in terms of the implementation language when coding starts.




Guidelines: Designing Operation Signatures

15

Guidelines: Designing Operation Signatures

When designing operation signatures, consider if parameters are:

Passed by value or by referenceChanged by the operationOptionalSet to default valuesIn valid parameter ranges

The fewer the parameters, the betterPass objects instead of “data bits”

In addition to the short description of the parameter, be sure to include things like:

• Whether the parameter should be passed by value or by reference, and if by reference, is the parameter changed by the operation? By value means that the actual object is passed. By reference means that a pointer or reference to the object is passed. The signature of the operation defines the interface to objects of that class, and the parameters should therefore be designed to promote and define what that interface is. For example, if a parameter should never be changed by the operation, then design it so that it is not possible to change it — if the implementation environment supports that type of design.

• Whether parameters may be optional and/or have default values when no value is provided.

• Whether the parameter has ranges of valid values. The fewer parameters you have, the better. Fewer parameters help to promote understandability, as well as maintainability. The more parameters clients need to understand, the more tightly coupled the objects are likely to be conceptually.

One of the strengths of OO is that you can manipulate very rich data structures, complete with associated behavior. Rather than pass around individual data fields (for example, StudentID), strive to pass around the actual object (for example, Student). Then the recipient has access to all the properties and behavior of that object.




Operation Visibility

16

Public operations

Protected operations

Privateoperations

Operation Visibility

Visibility is used to enforce encapsulationMay be public, protected, or private

Operation visibility is the realization of the key object-orientation principle of encapsulation.

Public members are accessible directly by any client.

Protected members are directly accessible only by instances of subclasses.

Private members are directly accessible only by instances of the class to which they are defined.

How do you decide what visibility to use? Look at the Interaction diagrams on which the operation is referenced. If the message is from outside of the object, use public. If it is from a subclass, use protected. If it’s from itself, use private. You should define the most restrictive visibility possible that will still accomplish the objectives of the class. Client access should be granted explicitly by the class and not taken forcibly.

Visibility applies to attributes as well as operations. Attributes are discussed later in this module.




How Is Visibility Noted?

17

How Is Visibility Noted?

The following symbols are used to specify export control:

+ Public access # Protected access- Private access

Class1- privateAttribute+ publicAttribute# protectedAttribute

- privateOperation ()+ publicOPeration ()# protecteOperation ()

In the UML, you can specify the access clients have to attributes and operations. Export control is specified for attributes and operations by preceding the name of the member with the following symbols:

+ Public

# Protected

- Private




Scope

18

Scope

Determines number of instances of the attribute/operation

Instance: one instance for each class instanceClassifier: one instance for all class instances

Classifier scope is denoted by underlining the attribute/operation name

Class1- classifierScopeAttr- instanceScopeAttr+ classifierScopeOp ()+ instanceScopeOp ()

The owner scope of an attribute/operation determines whether or not the attribute/operation appears in each instance of the class (instance scoped), or if there is only one instance for all instances of the class (classifier scoped).

Classifier-scoped attributes and operations are denoted by underlining their names. Lack of an underline indicates instance-scoped attributes and operations.

Classifier-scoped attributes are shared among all instances of the classifier type.

In most cases, attributes and operations are instance scoped. However, if there is a need to have a single instance of an operation, say to generate a unique ID among class instances, or to create a class instance, the classifier scope operations can be used.

Classifier-scoped operations can only access classifier-scoped attributes.




Example: Scope

19

Example: Scope

Student- name- address

- nextAvailID : int

+ addSchedule ([in] theSchedule : Schedule, [in] forSemester : Semester)+ getSchedule ([in] forSemester : Semester) : Schedule+ hasPrerequisites ([in] forCourseOffering : CourseOffering) : boolean# passed ([in] theCourseOffering : CourseOffering) : boolean+ getNextAvailID () : int

- studentID

In the above example, there is a single classifier-scoped attribute, nextAvailID, and a single classifier-scoped operation, getNextAvailID(). These classifier-scoped class features support the generation of a unique ID for each Student.

Each Student instance has its own unique StudentID, whereas, there is only one nextAvailID for all Student instances.

The getNextAvailID() classifier-scoped operation can only access the classifier scope attribute nextAvailID.




Example: Define Operations

20

Example: Define Operations

Student

+ getTuition() : double+ addSchedule ( [in] aSchedule : Schedule)+ getSchedule ( [in] forSemester : Semester) : Schedule+ deleteSchedule ( [in] forSemester : Semester)+ hasPrerequisites ( [in] forCourseOffering : CourseOffering) : boolean# hasPassed ( [in] aCourseOffering : CourseOffering) : boolean+ getNextAvailID() : int+ getStudentID() : int+ getName() : String+ getAddress() : String

0..1

0..1+ registrant

1

0..*RegistrationController

+ submitSchedule()+ saveSchedule()+ getCourseOfferings() : CourseOfferingList+ getCurrentSchedule ( [in] forStudent : Student, [in] forSemester : Semester) : Schedule+ deleteCurrentSchedule()+ new ( [in] forStudentID : String)+ getStudent ( [in] anID : int) : Student


+ getCourseOfferings()+ initialize()

<<Interface>>

This example is a portion of the VOPC for the Register for Courses Use-Case Realization.

Notice the <<class>> operations.

Those operations marked with a ‘+’ are public and can be invoked by clients of the class.

Those operations marked with a # are protected and can only be invoked by the defining class and any subclasses. These operations usually correspond to reflexive operations on the interaction diagrams.

The dependency from the Student class to the CourseOfferingClass was added to support the inclusion of the CourseOffering as a parameter to operations within the Student class.

Semester is included as the type for several parameters in the Student operations. For the Course Registration System, it is considered to be an abstract data type that has no significant behavior and thus is not modeled as a separate class.

Note: The attribute compartment has been suppressed in the above diagram.




Define Methods

21

Class Design Steps


Once the operations have been defined, some additional information may need to be documented for the class implementers.




Define Methods

22

Define Methods

What is a method?Describes operation implementation

PurposeDefine special aspects of operation implementation

Things to consider:Special algorithmsOther objects and operations to be usedHow attributes and parameters are to be implemented and usedHow relationships are to be implemented and used

A method specifies the implementation of an operation. It describes how the operation works, not just what it does.

The method, if described, should discuss:

• How operations are to be implemented. • How attributes are to be implemented and used to implement operations. • How relationships are to be implemented and used to implement operations. The requirements will naturally vary from case to case. However, the method specifications for a class should always state:

• What is to be done according to the requirements. • What other objects and operations are to be used. More specific requirements may concern:

• How parameters are to be implemented. • Any special algorithms to be used. In many cases, where the behavior required by the operation is sufficiently defined by the operation name, description and parameters, the methods are implemented directly in the programming language. Where the implementation of an operation requires use of a specific algorithm, or requires more information than is presented in the operation's description, a separate method description is required.




Define States

23


Class Design Steps

Now that we have a pretty clear understanding of the functionality provided by each of the classes, we can determine which of these classes have significant state behavior and model that behavior.

Note: State machines diagrams are specific to a class and are important during detailed design, so they are presented here in Class Design. However, state machines may be developed at any point in the software development lifecycle.




Define States

24

Define States

PurposeDesign how an object’s state affects its behaviorDevelop state machines to model this behavior

Things to consider:Which objects have significant state?How to determine an object’s possible states? How do state machines map to the rest of the model?

The state an object resides in is a computational state, and is defined by the stimuli the object can receive and what operations can be performed as a result. An object that can reside in many computational states is state-controlled.

For each class exhibiting state-controlled behavior, describe the relations between an object’s states and an object’s operations.




What is a State Machine?

25

What is a State Machine?

A directed graph of states (nodes) connected by transitions (directed arcs)Describes the life history of a reactive object

State StateTransition

Guard Condition

ActivityEvent

State1Event(args)[guard condition]/activity

State2

A state machine is a tool for describing: • States the object can assume. • Events that cause an object to transition from state to state. • Significant activities and actions that occur as a result. A state machine is a diagram used to show the life history of a given class, the events that cause a transition from one state to another, and the actions that result from a state change. State machines emphasize the event-ordered behavior of a class instance.

The state space of a given class is the enumeration of all the possible states of an object.

A state is a condition in the life of an object. The state of an object determines its response to different events.

An event is a specific occurrence (in time and space) of a stimulus that can trigger a state transition.

A transition is a change from an originating state to a successor state as a result of some stimulus. The successor state could possibly be the originating state. A transition may take place in response to an event, and can be labeled with an event.

A guard condition is a Boolean expression of attribute values that allows a transition only if the condition is true.

An action is an atomic execution that results in a change in state, or the return of a value.

An activity is a non-atomic execution within a state machine.




Pseudo States

26

Pseudo States

Initial state The state entered when an object is createdMandatory, can only have one initial state

ChoiceDynamic evaluation of subsequent guard conditionsOnly first segment has a trigger

Final state Indicates the object’s end of life Optional, may have more than one

State1

State2

Initial State

Choice

Final State

The initial state is the state entered when an object is created

• An initial state is mandatory. • Only one initial state is permitted. • The initial state is represented as a solid circle. A final state indicates the end of life for an object

• A final state is optional. • More than one final state may exist. • A final state is indicated by a bull’s eye.




Identify and Define the States

27

Significant, dynamic attributes

Existence and non-existence of certain links

Identify and Define the States

The maximum number of students per course offering is 10

numStudents < 10 numStudents > = 10

Link to Professorexists

Link to Professordoesn’t exist

Professor

CourseOffering

Open Closed

0..*

0..1 Assigned Unassigned

The states of an object can be found by looking at its class’ attributes and relationships with other classes.

Do not forget to establish the initial and final states for the object. If there are pre-conditions or post-conditions of the initial and final states, define those as well.

It is important not only to identify the different states, but also to explicitly define what it means to be in a particular state.

The above example demonstrates two states of a CourseOffering class instance. A CourseOffering instance may have a Professor assigned to teach it or not (hence the multiplicity of 0..1 on the Professor end of the CourseOffering-Professor association). If a Professor has been assigned to the CourseOffering instance, the state of the CourseOffering instance is “Assigned.” If a Professor has not been assigned to the CourseOffering instance, the state of the CourseOffering instance is “Unassigned.”




Identify the Events

28

Look at the class interface operations

Events: addProfessor,removeProfessor

Identify the Events

CourseOffering

+ addProfessor()+ removeProfessor()

0..*

0..1Professor

Determine the events to which the object responds. These can be found in the object's interfaces or protocols.

The class must respond to all messages coming into the class instances on all of the interaction diagrams. These messages should correspond to operations on the associated classes. Thus, looking at the class interface operations provides an excellent source for the events the class instance must respond to.

In the above example, two of the CourseOffering operations are addProfessor() and removeProfessor. Each of these operations can be considered an event that a CourseOffering instance must respond to.

Note: A subset of the CourseOffering behavior is shown above.

Events are not operations, although they often map 1 to 1. Remember: Events and operations are not the same thing.




Identify the Transitions

29

Identify the Transitions

For each state, determine what events cause transitions to what states, including guard conditions, when neededTransitions describe what happens in response to the receipt of an event

CourseOffering

+ addProfessor()+ removeProfessor()

0..*

0..1Professor

Assigned

Unassigned

removeProfessor addProfessor

From the initial state to the final state, lay out the top-level states the object may be in. Connect these states with transitions triggered by the appropriate events. Continue by adding these transitions.

If there are multiple automatic transitions, each transition needs a guard condition. The conditions must be mutually exclusive.

Each state transition event can be associated with an operation. Depending on the object's state, the operation may have a different behavior. The transition events describe how this occurs.

In the above example, when a CourseOffering instance is Unassigned (meaning a Professor has not been assigned to teach it yet), and the instance receives an addProfessor event, the CourseOffering instance transitions into the Assigned state. Conversely, when a CourseOffering instance is Assigned (meaning a Professor has been assigned to teach it), and the instance receives a “removeProfessor” event, the CourseOffering instance transitions into the Unassigned state.

Note: A subset of the CourseOffering behavior is shown above.




Add Activities

30

StateCExit/someAction

StateBDo/anActivity

StateA

Add Activities

EntryExecuted when the state is entered

DoOngoing execution

ExitExecuted when the state is exited

Entry/anAction

Entry Activity – Executed when the state is entered, after any activity associated with an incoming transition and before any internal Do activity.

Do Activity – An ongoing activity that is executed as long as the state is active.

Exit Activity – Executed when the state is exited, after completion of any internal Do activity and before any activity associated with an outgoing transition.




Example: State Machine

31

Example: State MachineaddStudent / numStudents = numStudents + 1

Unassigned

Assigned

Full

Canceleddo/ Send cancellation notices

Committeddo/ Generate class roster

closeRegistration [ has Professor assigned ]

close

/ numStudents = 0

addProfessor

closeRegistration

removeStudent [numStudents >0]/ numStudents = numStudents - 1

cancel

removeProfessor

[ numStudents = 10 ]

close[ numStudents < 3 ]

closeRegistration[ numStudents >= 3 ]

close[ numStudents >= 3 ]

addStudent /numStudents = numStudents + 1

cancel

removeStudent[ numStudents > 0] / numStudents = numStudents - 1

close

[ numStudents = 10 ] cancel

The above is a state machine for the CourseOffering class. Here are some things to note about it:

• A student can be added or removed from the course offering when the course offering is in the assigned or unassigned state.

• The closing of a course occurs in two phases: Close registration is where course offerings are committed if they have a professor and enough students or canceled if there is no professor. At this point, the course offering is not closed due to low enrollment because during schedule leveling, students may be added or removed from the course offering. Leveling is where it is verified that the maximum number of selected course offerings have been committed by selecting alternates, where necessary.

Close is where the final status of a course offering is determined. If there is a professor and there are enough students, the course offering is committed. If not, the course offering is canceled. This is meant to occur after leveling.




Example: State Machine with Nested States and History

32

Example: State Machine with Nested States and Historysuperstate

substate

addStudent /numStudents = numStudents + 1

Open

Unassigned

Assigned

H

add a professor

Closed

Canceleddo/ Send cancellation notices

Full

Committeddo/ Generate class roster

closeRegistration

close

remove a professorclose[ numStudents < 3 ]

[ numStudents = 10 ]

closeRegistration[ numStudents >= 3 ]

close[ numStudents >= 3 ]

closeRegistration [ has Professor assigned ]

close

/ numStudents = 0

removeStudent[ numStudents > 0] / numStudents = numStudents - 1

cancelcancel

State machines can become unmanageably large and complex. Nested states may be used to simplify complex diagrams. A superstate is a state that encloses nested states called substates. Common transitions of the substates are represented at the level of the superstate. Any number of levels of nesting is permitted.

The history indicator supports the modeling of “memorized” states. A history indicator (circled H) is placed in the state region whose last executed state needs to be “remembered” after an activity has been interrupted. The use of the history feature indicates that upon return to a superstate, the most recently visited substate will be entered.

The history indicator is a “pseudo-state,” similar to the stop state. States that make use of history must have their transition arrows going to the history pseudo-state. Transitions to the history indicator cause the last state that was executed in the enclosing state region to be resumed. Transitions to the outer boundary of the state region cause a transition back to the start state of the region. If the history feature is not used, the initial substate will always be entered when the superstate is entered.

The above is the CourseOffering class state machine where nested states with history have been used to simplify the diagram. The Open superstate was created to leverage the common transitions of the Unassigned and Assigned states. The use of the history indicator demonstrates that when the common transitions occur, the CourseOffering returns to the substate that it was in when the event was received.




Which Objects Have Significant State?

33

Which Objects Have Significant State?

Objects whose role is clarified by state transitionsComplex use cases that are state-controlledIt is not necessary to model objects such as:

Objects with straightforward mapping to implementationObjects that are not state-controlledObjects with only one computational state

The state an object resides in is a computational state. It is defined by the stimuli the object can receive and what operations can be performed as a result. An object that can reside in many computational states is state-controlled.

The complexity of an object depends on:

• The number of different states. • The number of different events it reacts to. • The number of different actions it performs that depend on its state. • The degree of interaction with its environment (other objects). • The complexity of conditional, repetitive transitions.




How Do State Machines Map to the Rest of the Model?

34

Events may map to operationsMethods should be updated with state-specific informationStates are often represented using attributes

This serves as input into the “Define Attributes” step

How Do State Machines Map to the Rest of the Model?

Open

CourseOffering- numStudents+ addStudent()

Closed

[numStudents>=10]

addStudent / numStudents = numStudents + 1

[numStudents<10]

Some state transition events can be associated with an operation. Depending on the object's state, the operation may have a different behavior. The transition events describe how this occurs.

The method description for the associated operation should be updated with the state-specific information, indicating what the operation should do for each relevant state.

Operation calls are not the only source of events. In the UML, you can model four different kinds of events:

• Signals • Calls • Passing of time • Change in state States are often represented using attributes. The state machines serve as input into the attribute identification step.




Define Attributes

35

Class Design Steps


At this point, we have a pretty good understanding of the design classes, their functionality, and their states. All of this information affects what attributes are defined.




Attributes: How Do You Find Them?

36

Attributes: How Do You Find Them?

Examine method descriptionsExamine statesExamine any information the class itself needs to maintain

Attributes the class needs to carry out its operations and the states of the class are identified during the definition of methods. Attributes provide information storage for the class instance and are often used to represent the state of the class instance. Any information the class itself maintains is done through its attributes.

You may need to add additional attributes to support the implementation and establish any new relationships that the attributes require.

Check to make sure all attributes are needed. Attributes should be justified — it is easy for attributes to be added early in the process and survive long after they are no longer needed due to shortsightedness. Extra attributes, multiplied by thousands or millions of instances, can have a large effect on the performance and storage requirements of the system.




Attribute Representations

37

Attribute Representations

Specify name, type, and optional default valueattributeName : Type = Default

Follow naming conventions of implementation language and projectType should be an elementary data type in implementation language

Built-in data type, user-defined data type, or user-defined class

Specify visibilityPublic: +Private: -Protected: #

In analysis, it was sufficient to specify the attribute name only, unless the representation was a requirement that was to constrain the designer.

During Design, for each attribute, define the following:

• Its name, which should follow the naming conventions of both the implementation language and the project.

• Its type, which will be an elementary data type supported by the implementation language.

• Its default or initial value, to which it is initialized when new instances of the class are created.

• Its visibility, which will take one of the following values: • Public: The attribute is visible both inside and outside the package

containing the class. • Protected: The attribute is visible only to the class itself, to its subclasses, or

to friends of the class (language dependent) • Private: The attribute is visible only to the class itself and to friends of the

class. For persistent classes, also include whether the attribute is persistent (the default) or transient. Even though the class itself may be persistent, not all attributes of the class need to be persistent.




Derived Attributes

38

Derived Attributes

What is a derived attribute?An attribute whose value may be calculated based on the value of other attribute(s)

When do you use it?When there is not enough time to re-calculate the value every time it is neededWhen you must trade-off runtime performance versus memory required

Derived attributes and operations indicate a constraint between values. They can be used to describe a dependency between attribute values that must be maintained by the class. They do not necessarily mean that the attribute value is always calculated from the other attributes.




Example: Define Attributes

39

- name- address- nextAvailID : int- studentID : int- dateOfBirth : Date

Student

Example: Define Attributes


0..1

ICourseCatalogSystem<< interface >>

Schedule

CourseOffering- number : String = “100”- startTime : Time- endTime : Time- day : String- /numStudents : int = ()

- semester : Semester

0..1

0..1

0..1

+ registrant

+ currentSchedule

0..*

0..40..2

0..*

+ alternateCourses

10..*

+ primaryCourses

The above example is a portion of the VOPC for the Register for Courses Use-Case Realization. It is the same diagram that was provided earlier in the Define Operations section, except now the operation compartment has been suppressed.

Notice the <<class >> attribute.

In this example, all attributes are private (marked with a “-”) to support encapsulation.

The number of students currently enrolled in the CourseOffering is represented by the derived attribute, numStudents, which has a default value of 0.

Semester, Time, and Date are included as the type for some of the attributes. For the Course Registration System, they are considered to be abstract data types that have no significant behavior and thus are not modeled as separate classes.




Exercise 1: Class Design

40


Given the following:The architectural layers, their packages, and their dependencies• Payroll Exercise Solution, Architectural Design,

Packages and their Dependencies

Design classes for a particular use case• Payroll Exercise Solution, Class Design,

Exercise: Class Design, Exercise: Define Operations

The goal of this exercise is to design the attributes and operations of design classes for a use case. This exercise will also require the students to model state-controlled behavior of a design class in a state machine.

References to the givens on the slide:

• The architectural layers, their packages, and their dependencies: Payroll Exercise Solution, Architectural Design, Packages and their Dependencies section

• Design classes for a particular use case: Payroll Exercise Solution, Class Design, Exercise: Class Design, Exercise: Define Operations section.




Exercise 1: Class Design (continued)

41


Identify the following:Attributes, operations, and their complete attribute signaturesAttribute and operation scope and visibilityAny additional relationships and/or classes to support the defined attributes and attribute signaturesClass(es) with significant state-controlled behaviorThe important states and transitions for the identified class

A complete operation signature includes the operation name, operation parameters, and operation return value. This may drive the identification of new classes and relationships.

Operation visibility may be public, private, or protected.

A complete attribute signature includes the attribute name, attribute type, and attribute default value (optional). This may drive the identification of new classes and relationships.

Attribute visibility may be public, private, or protected.

When adding relationships and/or classes, the package/subsystem interrelationships may need to be refined. Such a refinement can be approved only by the architecture team.

The produced state machine should include states, transitions, events, and guard conditions.





42

Produce the following:Design Use-Case Realization• State machine for one of the

classes that exhibits state-controlled behavior

• Class diagram (VOPC) that includes all operations, operation signatures, attributes, and attribute signatures


One of the goals of this exercise is to model state-controlled behavior of a design class in a state machine.

The produced state machine should include states, transitions, events, and guard conditions.

A complete operation signature includes the operation name, operation parameters, and operation return value. This may drive the identification of new classes and relationships.


• Operations: p.13-20 • State machines: p. 13-32 • Attributes: p. 13-39




Exercise 1: Review

43

Exercise 1: Review

Compare your resultsIs the name of each operation descriptive and understandable? Does the name of the operation indicate its outcome?Does each attribute represent a single conceptual thing? Is the name of each attribute descriptive and does it correctly convey the information it stores?Is the state machine understandable? Do state names and transitions reflect the context of the domain of the system? Does the state machine contain any superfluous states or transitions?

Payroll System

After completing a model, it is important to step back and review your work. Here are some helpful questions:

• Is the name of each operation descriptive and understandable? The operation should be named from the perspective of the user, so the name of the operation should indicate its outcome.

• Does each attribute represent a single conceptual thing? Is the name of each attribute descriptive and does it correctly convey the information it stores?

• Is the state machine understandable? Do the state names and transitions accurately reflect the domain of the system? The state machine should accurately reflect the lifetime of an object.

• Does the state machine contain any superfluous states or transitions? States and transitions should reflect the object’s attributes, operations, and relationships. Do not read anything extra into the lifetime of the object that cannot be supported by the class structure.




Define Dependencies

44

Class Design Steps


Prior to Design, many of the relationships were modeled as associations. Now, with the added knowledge you have gained throughout Design, you are in a position to refine some of those relationships into dependencies.




Define Dependency

45

What Is a Dependency?A relationship between two objects

PurposeDetermine where structural relationships are NOT required

Things to look for :What causes the supplier to be visible to the client

Define Dependency

SupplierClient

During Analysis, we assumed that all relationships were structural (associations or aggregations). In Design, we must decide what type of communication pathway is required.

A dependency relationship denotes a semantic relationship between model elements, where a change in the supplier may cause a change in the client.




Dependencies vs. Associations

46

Dependencies vs. Associations

Associations are structural relationshipsDependencies are non-structural relationshipsIn order for objects to “know each other” they must be visible

Local variable referenceParameter referenceGlobal referenceField reference Association

Dependency

Supplier2

Client

Supplier1

There are four options for creating a communication pathway to a supplier object:

• Global: The supplier object is a global object. • Parameter: The supplier object is a parameter to, or the return class of, an

operation in the client object. • Local: The supplier object is declared locally (that is, created temporarily during

execution of an operation). • Field: The supplier object is a data member in the client object. A dependency is a type of communication pathway that is a transient type of relationship. These occur when the visibility is global, parameter, or local.

Look at each association relationship and determine whether it should remain an association or become a dependency. Associations and aggregations are structural relationships (field visibility). Association relationships are realized by variables that exist in the data member section of the class definition. Any other relationships (global, local, and parameter visibility) are dependency relationships.




Associations vs. Dependencies in Collaborations

47

Associations vs. Dependencies in Collaborations

An instance of an association is a linkAll links become associations unless they have global, local, or parameter visibilityRelationships are context-dependent

Dependencies are transient links with:A limited durationA context-independent relationshipA summary relationship

A dependency is a secondary type of relationship in that it doesn't tellyou much about the relationship. For details you need to consult thecollaborations.

According to the UML 2 Specification, a link is an instance of an association. Specifically, an association declares a connection (link) between instances of the associated classifiers (classes). A dependency relationship indicates that the implementation or functioning of one or more elements requires the presence of one or more other elements.

Note that links modeled as parameter, global, or local are transient links. They exist only for a limited duration and in the specific context of the collaboration; in that sense, they are instances of the association role in the collaboration. However, the relationship in a class model (independent of context) should be, as stated above, a dependency. In The UML Reference Manual, the definition of a transient link is: "It is possible to model all such links as associations, but then the conditions on the associations must be stated very broadly, and they lose much of their precision in constraining combinations of objects." In this situation, the modeling of a dependency is less important than the modeling of the relationship in the collaboration, because the dependency does not describe the relationship completely, only that it exists.

If you believe that a link in a collaboration is a transient link, it indicates that the context-independent relationship between the classes is a dependency. Dependency is a “summary” relationship — for details you have to consult the behavioral model.

Context is defined as "a view of a set of related modeling elements for a particular purpose."




Local Variable Visibility

48

Local Variable Visibility

The op1() operation contains a local variable of type ClassB

ClassA

+ op1 ( )

ClassB

Is the receiver a temporary object created and destroyed during the operation itself? If so, establish a dependency between the sender and receiver classes in a class diagram containing the two classes.




Parameter Visibility

49

Parameter Visibility

The ClassB instance is passed to the ClassA instance

ClassA

+ op1 ( [in] aParam : ClassB )

ClassB

Is the reference to the receiver passed as a parameter to the operation? If so, establish a dependency between the sender and receiver classes in a Class diagram containing the two classes.




Global Visibility

50

Global Visibility

The ClassUtility instance is visible because it is global

ClassA

+ op1 ( )

ClassB

+ utilityOp ( )

Is the receiver a “global?” If so, establish a dependency between the sender and receiver classes in a class diagram containing the two classes.




Identifying Dependencies: Considerations

51

Permanent relationships — Association (field visibility)Transient relationships — Dependency

Multiple objects share the same instance• Pass instance as a parameter (parameter visibility)• Make instance a managed global (global visibility)

Multiple objects don’t share the same instance (local visibility)

How long does it take to create/destroy?Expensive? Use field, parameter, or global visibilityStrive for the lightest relationships possible

Identifying Dependencies: Considerations

Strive for real-world relationships. Semantic, structural relationships should be associations.

Strive for the lightest relationships possible. Dependency is the cheapest to keep, easiest to use, and benefits from encapsulation.

Is the relationship transient? Will you need this relationship again and again, or do you just need it to do some work and then throw it away? If its needed again and again, that is, if a thing appears to remain related to another thing even across the execution of one or more operations, then it is likely an association and should benefit from field visibility. Otherwise, the relationship may be transient and can have local, parameter, or global visibility.

Is the same instance shared across objects? If many objects at runtime need it again and again and they share the same instance, maybe you should pass it around as a parameter. If there is only one instance in existence in the whole process, set it up as a managed global (for example, Singleton design pattern). If the same instance is not shared, then having a local copy will suffice (local visibility).

How long does the instance take to create and destroy? Is it expensive to connect and disconnect every time you need it? If so, you would want to give the object field, parameter, or global visibility.




Example: Define Dependencies (before)

52

Example: Define Dependencies (before)<<interface>>


+ getCourseOfferings ( [in] forSemester : Semester) : CourseOfferingList

Student

- name- address- StudentID : int

+ addSchedule ( [in] aSchedule : Schedule )+ getSchedule ( [in] forSemester : Semester ) : Schedule+ hasPrerequisites ( [in] forCourseOffering : CourseOffering ) : boolean# passed ( [in] aCourseOffering : CourseOffering ) : boolean


+ // submit schedule ()+ // save schedule ()+ // create schedule with offerings ()+ // get course offerings ()

0..1

0..1 + registrant

0..* 1

+ courseCatalog

Schedule


+ submit ()+ //save ()# any conflicts? ()+ //create with offerings()

0..*

1

0..1

0..1+ currentSchedule

CourseOffering

- number : String = "100"- startTime : Time- endTime : Time- day : String

+ addStudent ( [in] aStudentSchedule : Schedule)+ removeStudent ( [in] aStudentSchedule : Schedule)+ new ()+ setData ()

0..*

0..4+ primaryCourses

0..*


This class diagram is a subset of the View of Participating Classes (VOPC) from the Register for Courses use case.

Up to this point, most of the relationships that we have defined have been associations (and aggregations). Now we will see how some of these associations/aggregations are refined into dependencies.

The dependency shown above from Schedule to CourseOffering was previously defined in the Define Operations section to support the Schedule operation signatures.

Note: All association/aggregation relationships should be examined to see if they should be dependencies. We have just chosen to work with a VOPC subset for this example.




Example: Define Dependencies (after)

53

Example: Define Dependencies (after)<<interface>>


+ getCourseOfferings ( [in] forSemester : Semester) : CourseOfferingList


+ // submit schedule ()+ // save schedule ()+ // create schedule with offerings ()+ // get course offerings ()

0..1

+ registrant

Schedule


+ submit ()+ //save ()# any conflicts? ()+ //create with offerings()

0..*

0..1

0..1+ currentSchedule

CourseOffering

- number : String = "100"- startTime : Time- endTime : Time- day : String

+ addStudent ( [in] aStudentSchedule : Schedule)+ removeStudent ( [in] aStudentSchedule : Schedule)+ new ()+ setData ()

0..4

0..*


Global visibility

Parameter visibility

Field visibility Field visibility

Student

- name- address- StudentID : int

+ addSchedule ( [in] aSchedule : Schedule )+ getSchedule ( [in] forSemester : Semester ) : Schedule+ hasPrerequisites ( [in] forCourseOffering : CourseOffering ) : boolean# passed ( [in] aCourseOffering : CourseOffering ) : boolean

0..1 10..*

+ primaryCourses

This example demonstrates how an association on the class diagram provided on the previous slide has been refined into a dependency relationship.

During a registration session, the RegistrationController works with one Student, the registrant (the Student that is registering), and one Schedule, the current Schedule (the Student’s Schedule for the current semester). These instances need to be accessed by more than one of the RegistrationController’s operations, so field visibility is chosen from RegistrationController to Student and from RegistrationController to Schedule. Thus, the relationships remain associations.

A Student manages its own Schedules, so field visibility is chosen from Student to Schedule and the relationship remains an aggregation.

CourseOfferings are part of the semantics of what defines a Schedule (a Schedule is the courses a that a Student has selected for a semester). Thus, field visibility is chosen from Schedule to CourseOffering and the relationships remain associations.

The Student class has several operations where CourseOffering appears in the parameter list. Thus, parameter visibility is chosen from Student to CourseOffering. This relationship was actually defined earlier in the Define Operations section.

It is envisioned that the course Catalog System may need to be accessed by multiple clients in the system, so global visibility was chosen, and the relationship becomes a dependency. This is the only change that was made to the relationships shown on the previous slide.




Define Associations

54

Class Design Steps


We now are going to turn our attention to the remaining class associations, adding some Design-level refinements that drive the implementation.




Define Associations

55

Define Associations

PurposeRefine remaining associations

Things to look for :Association vs. AggregationAggregation vs. CompositionAttribute vs. AssociationNavigabilityAssociation class designMultiplicity design

At this point, we have identified which class relationships should be dependencies. Now it is time to design the details of the remaining associations.

Also, additional associations may need to be defined to support the method descriptions defined earlier. Remember, to communicate between their instances, classes must have relationships with each other.

We will discuss each of the “things to look for” topics on subsequent slides, except for “Association vs. Aggregation,” which was discussed in the Use-Case Analysis module.





56


A form of aggregation with strong ownership and coincident lifetimes

The parts cannot survive the whole/aggregate

Whole

Composition

Part

PartWhole

Composition is a form of aggregation with strong ownership and coincident lifetimes of the part with the aggregate. The whole “owns” the part and is responsible for the creation and destruction of the part. The part is removed when the whole is removed. The part may be removed (by the whole) before the whole is removed.

A solid filled diamond is attached to the end of an association path (on the “whole side”) to indicate composition.

In some cases, composition can be identified as early as Analysis, but more often it is not until Design that such decisions can be made confidently. That is why composition is introduced here rather than in Use-Case Analysis.




Aggregation: Shared vs. Non-shared

57

Shared Aggregation

Non-shared Aggregation

Aggregation: Shared vs. Non-shared

By definition, composition is non-shared aggregation.

Whole Part1..* 0..*

Multiplicity > 1

Multiplicity = 1 Multiplicity = 1

1Whole Part1 0..* Whole Part0..*

Composition

For composition, the multiplicity of the aggregate end may not exceed one (it is unshared). The aggregation is also unchangeable; that is, once established its links cannot be changed. Parts with multiplicity having a lower bound of 0 can be created after the aggregate itself, but once created, they live and die with it. Such parts can also be explicitly removed before the death of the aggregate.

Non-shared aggregation does not necessarily imply composition.

An aggregation relationship that has a multiplicity greater than one established for the aggregate is called “shared,” and destroying the aggregate does not necessarily destroy the parts. By implication, a shared aggregation forms a graph, or a tree with many roots.

An example of shared aggregation may be between a University class and a Student class (the University being the “whole” and the Students being the “parts”). With regards to registration, a Student does not make sense outside the context of a University, but a Student may be enrolled in classes in multiple Universities.




Aggregation or Composition?

58

Aggregation or Composition?

ConsiderationLifetimes of Class1 and Class2

Aggregation

Composition

Class1 Class2

Class1 Class2

The use of association versus aggregation was discussed in the Use-Case Analysis module. Here we discuss the use of “vanilla” aggregation versus composition.

Composition should be used over "plain" aggregation when there is a strong interdependency between the aggregate and the parts, where the definition of the aggregate is incomplete without the parts. For example, it does not make sense to have an Order if there is nothing being ordered.

Composition should be used when the whole and part must have coincident lifetimes. Selection of aggregation or composition will determine how object creation and deletion are designed.




Example: Composition

59

Example: Composition

1

0..*

ScheduleStudent

RegisterForCoursesForm 1

1


This slide demonstrates two examples of composition.

The top graphic demonstrates how a previous aggregation relationship has been refined into a composition relationship.The relationship from Student to Schedule is modeled as a composition because if you got rid of the Student, you would get rid of any Schedules for that Student.

The bottom graphic demonstrates how a previous association relationship has been refined into a composition relationship. It was decided that an instance of a RegistrationController would NEVER exist outside the context of a particular Register For Courses Student session. Thus, since the RegisterForCoursesForm represents a particular Register For Courses session, a RegistrationController would NEVER exist outside of the context of a particular RegisterForCoursesForm. When a MaintainScheduleForm is created, an instance of RegistrationController should always be created. When MaintainScheduleForm is deleted, the instance of the RegistrationController should always be deleted. Thus, because they now have coincident lifetimes, composition is used instead of an association.




Attributes vs. Composition

60

Attributes vs. Composition

Use composition whenProperties need independent identitiesMultiple classes have the same propertiesProperties have a complex structure and properties of their ownProperties have complex behavior of their ownProperties have relationships of their own

Otherwise use attributes

A property of a class is something that the class knows about. You can model a class property as a class (with a composition relationship), or as a set of attributes of the class. In other words, you can use composition to model an attribute.

The decision whether to use a class and composition, or a set of attributes, depends on the following:

• Do the properties need to have independent identity, such that they can be referenced from a number of objects? If so, use a class and composition.

• Do a number of classes need to have the same properties? If so, use a class and composition.

• Do the properties have a complex structure, properties, and behavior of their own? If so, use a class (or classes) and composition.

• Otherwise, use attributes. The decision of whether to use attributes or a composition association to a separate class may also be determined based on the degree of coupling between the concepts being represented. When the concepts being modeled are tightly connected, use attributes. When the concepts are likely to change independently, use composition.




Example: Attributes vs. Composition

61

Example: Attributes vs. Composition

Composition of separate class

AttributeStudent

- name- address- nextAvailID : int- StudentID : int- dateofBirth : Date

+ addSchedule ()+ getSchedule ()+ delete Schedule ()+ hasPrerequisites ()# hasPassed ()

Schedule

+ submit ()+ //save ()# any conflicts? ()+ //create with offerings ()+ new ()+ passed ()


0..*

1

In this example, Semester is not a property that requires independent identity, nor does it have a complex structure. Thus, it was modeled as an attribute of Schedule.

On the other hand, the relationship from Student to Schedule is modeled as a composition rather than an attribute because Schedule has a complex structure and properties of its own.




Review: What Is Navigability?

62

Review: What Is Navigability?

Indicates that it is possible to navigate from an associating class to the target class using the association

RegistrationController<<Control>>


The navigability property on a role indicates that it is possible to navigate from an associating class to the target class using the association. This may be implemented in a number of ways: by direct object references, by associative arrays, hash-tables, or any other implementation technique that allows one object to reference another.

Navigability is indicated by an open arrow placed on the target end of the association line next to the target class (the one being navigated to). The default value of the navigability property is true (associations are bi-directional by default).

In the course registration example, the association between the Schedule and the Course Offering is navigable in both directions. That is, a Schedule must know the Course Offering assigned to the Schedule and the Course Offering must know the Schedules it has been placed in.

When no arrowheads are shown, the association is assumed to be navigable in both directions.

In the case of the associations between Schedule and Registration Controller, the Registration Controller must know its Schedules, but the Schedules have no knowledge of the Registration Controllers (or other classes, since many things have addresses) associated with the address. As a result, the navigability property of the Registration Controller end of the association is turned off.




Navigability: Which Directions Are Really Needed?

63

Navigability: Which Directions Are Really Needed?

Explore interaction diagramsEven when both directions seem required, one may work

Navigability in one direction is infrequentNumber of instances of one class is small

?0..40..*

+ primaryCourses CourseOfferingSchedule

0..40..*


0..40..*


During Use-Case Analysis, associations (and aggregations) may have been assumed to be bi-directional (that is, communication may occur in both directions).

During Class Design, the association’s navigability needs to be refined so that only the required communication gets implemented.

Navigation is readdressed in Class Design because we now understand the responsibilities and collaborations of the classes better than we did in Use-Case Analysis. We also want to refine the relationships between classes.Two-way relationships are more difficult and expensive to implement than one-way relationships. Thus, one of the goals in Class Design is the reduction of two-way (bi-directional) relationships into one-way (unidirectional) relationships.

The need for navigation is revealed by the use cases and scenarios. The navigability defined in the class model must support the message structure designed in the interaction diagrams.

In some circumstances even if two-way navigation is required, a one-way association may suffice. For example, you can use one-way association if navigation in one of the directions is very infrequent and does not have stringent performance requirements, or the number of instances of one of the classes is very small.




Example: Navigability Refinement

64

Example: Navigability Refinement

Total number of Schedules is small, orNever need a list of the Schedules on which the CourseOffering appears

Total number of CourseOfferings is small, orNever need a list of CourseOfferings on a Schedule

Total number of CourseOfferings and Schedules are not smallMust be able to navigate in both directions

0..40..*


0..40..*


0..40..*


In Situation 1: Implement only the Schedule-to-CourseOffering direction. If navigation is required in the other direction (that is, if a list of Schedules on which the CourseOffering appears is needed), it is implemented by searching all of the Schedule instances and checking the CourseOfferings that appear on them.

In Situation 2: Implement only the CourseOffering-to-Schedule direction. If navigation is required in the other direction (that is, if a list of CourseOfferings on a Schedule is needed), it is implemented by searching all of the CourseOffering instances and checking the Schedules on which they appear.

For the example in this course, the first option (navigation from Schedule to the Primary CourseOfferings) was chosen.

Note: This navigation decision holds true for the navigability from Schedule to the alternate CourseOfferings, as well.




Association Class

65

Association Class

A class is “attached” to an associationContains properties of a relationshipHas one instance per link

<<entity>>ScheduleOfferingInfo

- status

+ // is selected ()+ // mark as selected ()+ // mark as cancelled ()


0..* 0..4+ primaryCourses

+ alternateCourses0..* 0..2

PrimaryScheduleOfferingInfo- grade

+ // is enrolled in? ()+ // mark as enrolled in ()+ // mark as committed ()

<<entity>>

An association class is a class that is connected to an association. It is a full-fledged class and can contain attributes, operations, and other associations.

Association classes allow you to store information about the relationship itself. The association class includes information that is not appropriate for, or does not belong in, the classes at either end of the relationship.

There is an instance of the association class for every instance of the relationship (that is, for every link).

In many cases, association classes are used to resolve many-to-many relationships, as shown in the example above. In this case, a Schedule includes multiple primary CourseOfferings and a CourseOffering can appear on multiple schedules as a primary. Where would a Student’s grade for a primary CourseOffering “live”? It cannot be stored in Schedule because a Schedule contains multiple primary CourseOfferings. It cannot be stored in CourseOffering because the same CourseOffering can appear on multiple Schedules as primary. Grade is really an attribute of the relationship between a Schedule and a primary CourseOffering.

The same is true of the status of a CourseOffering, primary or alternate, on a particular Schedule.

Thus, association classes were created to contain such information. Two classes related by generalization were created to leverage the similarities between what must be maintained for primary and alternate CourseOfferings. Remember, Students can only enroll in and receive a grade in a primary CourseOffering, not an alternate.




Example: Association Class Design

66

Example: Association Class Design

Design Decisions

0..* 0..4+ primaryCourses


PrimaryScheduleOfferingInfo

- grade+ // is enrolled in? ()+ // mark as enrolled in ()+ // mark as committed ()

Schedule CourseOffering


1

0..*- theCourseOffering


PrimaryScheduleOfferingInfo- grade+ // is enrolled in? ()+ // mark as enrolled in ()+ // mark as committed ()

- primaryCourseOfferingInfo

0..4

1

If there are attributes on the association itself (represented by "association classes"), create a design class to represent the “association class,” with the appropriate attributes. Interpose this class between the other two classes, and by establishing associations with appropriate multiplicity between the association class and the other two classes.

The above example demonstrates how an association class can be further designed.

When defining the navigability between the resulting classes, it was decided not to provide navigation directly to CourseOffering from Schedule (must go through PrimaryScheduleOfferingInfo).

Note: Association class design needs to be done only if the implementation does not directly support association classes and an exact visual model of the implementation is required. The above example is hypothetical. It is not included in the Course Registration Model provided with the course since the additional design details because only complicated the Design Model.




Multiplicity Design

67

Multiplicity = 1, or Multiplicity = 0..1May be implemented directly as a simple value or pointerNo further “design” is required

Multiplicity > 1Cannot use a simple value or pointerFurther “design” may be required

Multiplicity Design

Needs a container for

CourseOfferings

0..1 0..*Professor CourseOffering+ Instructor

0..1 0..*Professor CourseOffering+ Instructor

Multiplicity is the number of instances that participate in an association. Initial estimates of multiplicity made during analysis must be updated and refined during design.

All association and aggregation relationships must have multiplicity specified.

For associations with a multiplicity of 1 or 0..1, further design is not usually required, as the relationship can be implemented as a simple value or a pointer.

For associations with a multiplicity upper bound that is greater than 1, additional decisions need to be made. This is usually designed using “container” classes. A container class is a class whose instances are collections of other objects. Common container classes include sets, lists, dictionaries, stacks, and queues.




Multiplicity Design Options

68

Multiplicity Design Options

Explicit Modeling of a Container Class Detail Container via Note

0..1 0..*Professor CourseOffering

+ Instructor

0..1 0..*Professor CourseOfferingList

+ Instructor

CourseOffering 0..1 0..*Professor

+ Instructor

CourseOffering

List

The design of a relationship with a multiplicity greater than one can be modeled in multiple ways. You can explicitly model a container class, or you can just indicate what kind of container class will be used. The latter approach keeps the diagrams from getting too cluttered with very detailed implementation decisions. However, the former approach may be useful if you want to do code generation from your model.

Another option that is a more refined version of the first approach is to use a parameterized class (template) as the container class. This is discussed in more detail on the next few slides.




What Is a Parameterized Class (Template)?

69

What Is a Parameterized Class (Template)?

A class definition that defines other classesOften used for container classes

Some common container classes:• Sets, lists, dictionaries, stacks, queues

ParameterizedClass

Formal Arguments

List

Item

In the UML, parameterized classes are also known as templates.

The formal arguments are expressed as a parameter list (for example: [T: class, size: Int]).

A parameterized class cannot be used directly; it must be instantiated to be used. It is instantiated by supplying actual arguments for the formal arguments. Instantiation is discussed on the next slide.

Container classes can be modeled as parameterized classes. Common container classes, like List, from existing implementation libraries are often just noted as a standard approach, and are not modeled at all. The standard mechanism is noted in the Design Document, or as a note on the Class diagram.

Consider your implementation language when deciding to use these. Parameterized classes are not supported in every language. For example, C++ supports templates, while Java does not.

See the language-specific appendices for more information.




Instantiating a Parameterized Class

70

Instantiating a Parameterized Class

ParameterizedClass

Formal Arguments

InstantiatedClass ActualArgument

<<bind>> (ActualArgument)

Using a parameterized class requires that you specify a bound element (that is, actual arguments for the parameterized classes’ formal arguments).

A dependency stereotyped with <<bind>> is used to specify that the source instantiates the parameterized class using the actual parameters.




Example: Instantiating a Parameterized Class

71

Example: Instantiating a Parameterized Class

Before

AfterList

Item

CourseOfferingList CourseOffering

<<bind>> (CourseOffering)

1

0..*

CourseOfferingList CourseOffering1

0..*

Initially, we just defined a CourseOfferingList. During Detailed Design, it is decided that the List class will be used as a base class for the CourseOfferingList.




Multiplicity Design: Optionality

72

Multiplicity Design: Optionality

If a link is optional, make sure to include an operation to test for the existence of the link

Professor CourseOffering

+ isTeaching () : boolean

0..1

0..* + hasProfessor () : boolean

If a link is optional, an operation to test for the existence of the link should be added to the class.

For example, if a Professor can be on sabbatical, a suitable operation should be included in the Professor class to test for the existence of the CourseOffering link.




Define Internal Structure

73


Class Design Steps

In Analysis, inheritance that was intrinsic to the problem domain may have been defined. Class Design is where generalizations are defined to improve/ease the implementation. Design is the real activity of inventing inheritance.




What is Internal Structure?

74

What is Internal Structure?

The interconnected parts and connectors that compose the contents of a structured class.

It contains parts or roles that form its structure and realize its behavior.Connectors model the communication link between interconnected parts.

The interfaces describe what a class must do; its internal structure describes how the work is accomplished.




Review: What Is a Structured Class?

75

Review: What Is a Structured Class?

A structured class contains parts or roles that form its structure and realize its behavior

Describes the internal implementation structureThe parts themselves may also be structured classes

Allows hierarchical structure to permit a clear expression of multilevel models.

A connector is used to represent an association in a particular context

Represents communications paths among parts

A role is 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.




What Is a Connector?

76

What Is a Connector?

A connector models the communication link between interconnected parts. For example:

Assembly connectors• Reside between two elements (parts or ports)

in the internal implementation specification of a structured class.

Delegation connectors• Reside between an external (relay) port and

an internal part in the internal implementation specification of a structured class.

For delegation connectors, environment connections to the external port are treated as going to the internal element at the other end of the delegation connector.




Review: What Is a Port?

77

Review: What Is a Port?

A port is a structural feature that encapsulates the interaction between the contents of a class and its environment.

Port behavior is specified by its provided and required interfaces• They permit the internal structure to be

modified without affecting external clientsExternal clients have no visibility to internals

A class may have a number of portsEach port has a set of provided and required interfaces

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

Another class connected to a port may request the provided services from the owner of the port but must also be prepared to supply the required services to the owner.




Review: Port Types

78

Review: Port Types

Ports can have different implementation types

Service ports are only used for the internal implementation of the class.Behavior ports are used where requests on the port are implemented directly by the class.Relay ports are used where requests on the port are transmitted to internal parts for implementation.

The use of service ports are rare because the main purpose of ports is to encapsulate communication with the environment. These ports are located inside the class boundary.

Behavior ports are shown by a line from the port to a small state symbol (a rectangle with rounded corners). This is meant to suggest a state machine, although other forms of behavior implementation are also permitted.




Review: Structure Diagram With Ports

79

Review: Structure Diagram With Ports

Structured Class Name

partA partB

Behavior Port

Relay Port

Service Port

Assembly Connector

Delegation Connector




Review: Structure Diagram

80

Review: Structure Diagram


: StudentManagementSystem

: CourseCatalogSystem: BillingSystem





Example: Structure Diagram Detailed

81

Example: Structure Diagram Detailed


StudentManagementSystem


: RegistrationController : MainStudentForm

: BillingSystem





Define Generalizations

82


Class Design Steps

Light

In Analysis, inheritance that was intrinsic to the problem domain may have been defined. Class Design is where generalizations are defined to improve/ease the implementation. Design is the real activity of inventing inheritance.




Review: Generalization

83

Review: Generalization

One class shares the structure and/or behavior of one or more classes“Is a kind of” relationshipIn Analysis, use sparingly

Superclass (Parent)

(Ancestor)

Generalization Relationship

Subclasses (Child)

(Descendants)

Account+ balance+ name+ number

+ withdraw ()+ createStatement ()

Checking Savings

+ getInterest ()

As discussed in Concepts of Object Orientation, generalization is a relationship among classes where one class shares the structure and/or behavior of one or more classes. This slide is repeated here for review purposes.

Generalization refines a hierarchy of abstractions in which a sub-class inherits from one or more super-classes.

Generalization is an “is a kind of” relationship. You should always be able to say that your generalized class “is a kind of” the parent class.

The terms “ancestor” and “descendent” may be used instead of “super-class” and “sub-class”.

In Analysis, generalization should be used only to model shared behavioral semantics (that is, generalization that passes the “"is a"” test). Generalization to promote and support reuse is determined in Design. In Analysis, the generalization should be used to reflect shared definitions/semantics. This promotes “brevity of expression.” The use of generalization makes the definitions of the abstractions easier to document and understand.

When generalization is found, a common super-class is created to contain the common attributes, associations, aggregations, and operations. The common behavior is removed from the classes that are to become sub-classes of the common super-class. A generalization relationship is drawn from the sub-class to the super-class.




Abstract and Concrete Classes

84

There are no direct instances of Animal

Lion Tiger

Animal

+ communicate ()

+ communicate ()+ communicate ()

Abstract and Concrete Classes

Abstract classes cannot have any objectsConcrete classes can have objects

All objects are either lions or tigers

Abstract class

Abstract operation

Communication

Discriminator

A class that exists only for other classes to inherit from it is an abstract class. Classes that are to be used to instantiate objects are concrete classes.

An operation can also be tagged as abstract. This means that no implementation exists for the operation in the class where it is specified. A class that contains at least one abstract operation must be an abstract class. Classes that inherit from an abstract class must provide implementations for the abstract operations. Otherwise, the operations are considered abstract within the subclass, and the subclass is considered abstract, as well. Concrete classes have implementations for all operations.

In the UML, you designate a class as abstract by putting the class name in italics. For abstract operations, you put the operation signature in italics. The name of the abstract item can also be shown in italics.

A discriminator can be used to indicate on what basis the generalization/specialization occurred. A discriminator describes a characteristic that differs in each of the subclasses. In the above example, we generalized/specialized in the area of communication.




Multiple Inheritance: Problems

85

Name clashes on attributes or operations Repeated inheritance

Multiple Inheritance: Problems

Resolution of these problems is implementation-dependent.

SomeClass

Bird

Animal+ color+ getColor ()

FlyingThing+ color+ getColor ()

Bird

Animal+ color+ getColor ()

FlyingThing+ color+ getColor ()

In practice, multiple inheritance is a complex design problem and may lead to implementation difficulties.

In general, multiple inheritance causes problems if any of the multiple parents have structure or behavior that overlaps. If the class inherits from several classes, you must check how the relationships, operations, and attributes are named in the ancestors.

Specifically, there are two issues associated with multiple inheritance:

Name collisions: Both ancestors have attributes and/or operations with the same name. If the same name appears in several ancestors, you must describe what this means to the specific inheriting class, for example, by qualifying the name to indicate its source of declaration.

Repeated inheritance: The same ancestor is being inherited by a descendant more than once. When this occurs, the inheritance hierarchy will have a "diamond shape" as shown above. The descendents end up with multiple copies of an ancestor. If you are using repeated inheritance, you must have a clear definition of its semantics; in most cases this is defined by the programming language supporting the multiple inheritance.

In general, the programming language rules governing multiple inheritance are complex, and often difficult to use correctly. Therefore, it is recommended that you use multiple inheritance only when needed and always with caution.

Note: You can use delegation as a workaround to multiple inheritance problems. Delegation is described later in this module.




Generalization Constraints

86

Generalization Constraints

Complete End of the inheritance tree

Incomplete Inheritance tree may be extended

DisjointSubclasses mutually exclusiveDoesn’t support multiple inheritance

Overlapping Subclasses are not mutually exclusiveSupports multiple inheritance

The UML defines four standard constraints for generalization relationships:

Complete: This constraint indicates the end of the inheritance hierarchy. All children in the generalization relationship have been defined in the model. No more children can be defined. The “leaves” of the inheritance hierarchy cannot be specialized any further. Use the Complete constraint to explicitly note that the generalization hierarchy has not been fully specified in the model.

Incomplete: All children in the generalization relationship have not been defined in the model. More children may be defined. The “leaves” of the inheritance hierarchy may be specialized. Use the Incomplete constraint to explicitly note that the generalization hierarchy has not been fully specified in the model.

The following two constraints only apply in the context of multiple inheritance:

Disjoint: An object of the parent cannot have more than one of the children as its type (that is, subclasses are mutually exclusive). Disjoint is used to support the modeling of static classification, where an object cannot change its type at run-time.

Overlapping: An object of the parent may have more than one of the children as its type. Overlapping is used to support the modeling of dynamic classification, where an object can change its type at run-time. It shows the potential types of an object.




Example: Generalization Constraints

87

Example: Generalization Constraints

Asset

Real EstateBank Account Security

Savings Checking Stock Bond

{disjoint}

{disjoint,complete} {disjoint}

End of inheritance hierarchy

Multiple Inheritancenot supported

This example demonstrates the use of the Complete and Disjoint constraints:

Complete: The Savings and Checking classes cannot be specialized (a generalization relationship cannot be defined in which they are the parent). These classes (and any siblings) mark the end of the inheritance hierarchy.

Disjoint: A BankAccount object cannot be both a Savings and a Checking account (that is, no multiple inheritance where parents in the multiple inheritance are the children of BankAccount).




Example: Generalization Constraints (continued)

88

Example: Generalization Constraints (continued)

Vehicle

AmphibiousVehicle

WaterVehicleLandVehicle

{overlapping}

Multipleinheritancesupported

This example demonstrates the use of the overlapping constraint. The AmphibiousVehicle class can inherit from both LandVehicle and WaterVehicle, which both inherit from Vehicle.




Generalization vs. Aggregation

89

Is this correct?


Generalization and aggregation are often confused

Generalization represents an “is a” or “kind-of” relationshipAggregation represents a “part-of” relationship

Window

WindowWithScrollbar

Scrollbar

The key phrases “is a” and “part of” help to determine correct relationship.

With inheritance:

• Keywords “is a” • One object With Aggregation:

• Keywords “part of” • Relates multiple objects Is the above example a proper use of generalization? If not, what would be a better way to model the information that maintains generalization“ "is a"” semantics?





90

Window

WindowWithScrollbar

Scrollbar


Scrollbar

Window

WindowWithScrollbar1

1

A WindowWithScrollbar “is a” WindowA WindowWithScrollbar “contains a” Scrollbar

In this example, Scrollbar is “part of” a WindowWithScrollbar and, as such, the relationship is a composition. Scrollbar object is created/destroyed along with the WindowWithScrollbar object.

WindowWithScrollbar, on the other hand, “is a” Window, so its relationship to Window is a generalization.




Generalization: Share Common Properties and Behavior

91

Do these classes follow the “is a” style of programming?

Generalization: Share Common Properties and Behavior

Follows the “is a” style of programmingClass substitutability

List

+ insertTop ([in] item)+ insertBottom ([in] item)+ removeTop ()+ removeBottom ()+ insert ([in] item, [in] position)

StackLion Tiger

Animal

+ communicate ()


A subtype is a type of relationship expressed with inheritance. A subtype specifies that the descendent is a type of the ancestor and must follow the rules of the “is a” style of programming.

The “is a” style of programming states that the descendent "is a" type of the ancestor and can fill in for all its ancestors in any situation.

The “is a” style of programming passes the Liskov Substitution Principle, which states: “If for each object O1 of type S there is an object O2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when O1 is substituted for O2 then S is a subtype of T.”




Generalization: Share Common Properties and Behavior (cont.)

92

Generalization: Share Common Properties and Behavior (cont.)

List

+ insertTop ([in] item)+ insertBottom ([in] item)+ removeTop ()+ removeBottom ()+ insert ([in] item, [in] position)

StackLion Tiger

Animal

+ communicate ()


The classes on the left-hand side of the diagram do follow the "is a" style of programming: a Lion is an Animal and a Tiger is an animal.

The classes on the right side of the diagram do not follow the “is a” style of programming: a Stack is not a List. Stack needs some of the behavior of a List but not all of the behavior. If a method expects a List, then the operation insert(position) should be successful. If the method is passed a Stack, then the insert (position) will fail.




Generalization: Share Implementation: Factoring

93

Generalization: Share Implementation: Factoring

Supports the reuse of the implementation of another classCannot be used if the class you want to “reuse” cannot be changed

List+ insertTop ([in] item)+ insertBottom ([in] item)+ removeTop ()+ removeBottom ()+ insert ([in] item, [in] position)

Stack

SequentialContainer

List

+ insertTop ([in] item)+ removeTop ()

Stack

+ insertBottom ([in] item)+ removeBottom ()+ insert ([in] item, [in] position)

Factoring is useful if there are some services provided by a class that you want to leverage in the implementation of another class.

When you factor, you extract the functionality you want to reuse and inherit from the new base class.




Generalization Alternative: Share Implementation: Delegation

94

Generalization Alternative: Share Implementation: Delegation

Supports the reuse of the implementation of another classCan be used if the class you want to “reuse” cannot be changed

List+ insertTop ([in] item)+ insertBottom ([in] item)+ removeTop ()+ removeBottom ()+ insert ([in] item, [in] position)

Stack List

Stack

+ insertBottom ([in] item)+ removeBottom ()+ insert ([in] item, [in] position)

1

1

With delegation, you use a composition relationship to “reuse” the desired functionality. All operations that require the “reused” service are “passed through” to the contained class instance.

With delegation, you lose the benefit of polymorphic behavior, but you do have a model that more clearly expresses the nature of the domain (being that it is NOT "is a").

This is commonly used by mix-ins. Implementing mix-ins with composition permits run-time binding to objects rather than compile-time binding enforced by inheritance.

Note: You can also use delegation as a workaround to multiple inheritance problems discussed earlier. Have the sub-class inherit from one of the super-classes, and then use aggregation from the subclass to access the structure and behaviors of the other classes.




Implementation Inheritance

95

push() and pop() can access methods of List but instances of Stack cannot

Implementation Inheritance

Ancestor public operations, attributes, and relationships are NOT visible to clients of descendent class instancesDescendent class must define all access to ancestor operations, attributes, and relationships

List

+ insertTop ([in] item)+ insertBottom ([in] item)+ removeTop ()+ removeBottom ()

Stack

<<implementation>>

+ push (item)+ pop ()

An <<implementation>> stereotype can be used to model implementation inheritance. Implementation inheritance is where the implementation of a specific element is inherited or reused.

Implementation inheritance often leads to illogical inheritance hierarchies that are difficult to understand and to maintain. Therefore, it is recommended that you use inheritance only for implementation reuse, unless something else is recommended in using your programming language. Maintenance of this kind of reuse is usually quite tricky.

In the above example, any change in the class List can imply large changes of all classes inheriting from the class List. Be aware of this and inherit only stable classes. Inheritance will actually freeze the implementation of the class List because changes to it are too expensive.





96

Manufacturer AManufacturer B Manufacturer C

OO Principle:Encapsulation


The ability to hide many different implementations behind a single interface

Remote Control

Polymorphism was first introduced in the Concepts of Object Orientation module. This slide is repeated here for review purposes.

The Greek term polymorphos means “having many forms”. Every implementation of the interface must implement at least the interface. The implementation can in some cases implement more than the interface.




Generalization: Implement Polymorphism

97

Generalization: Implement Polymorphism

Without Polymorphism

if animal = “Lion” thenLion communicate

else if animal = “Tiger” thenTiger communicate

end

With Polymorphism

Animal communicate

Lion Tiger

Animal

+ communicate ()


Inheritance provides a way to implement polymorphism in cases where polymorphism is implemented the same way for a set of classes. This means that abstract base classes that simply declare inherited operations, but which have no implementations of the operations, can be replaced with interfaces. Inheritance can now be restricted to inheritance of implementations only, if desired.

Polymorphism is not generalization; generalization is one way to implement polymorphism. Polymorphism through generalization is the ability to define alternate methods for ancestor class operations in the descendent classes. This can reduce the amount of code to be written, as well as help abstract the interface to descendent classes.

Polymorphism is an advantage of inheritance realized during implementation and at run time.

Programming environments that support polymorphism use dynamic binding, meaning that the actual code to execute is determined at run time rather than compile time.




Polymorphism: Use of Interfaces vs. Generalization

98

Polymorphism: Use of Interfaces vs. Generalization

Interfaces support implementation-independent representation of polymorphism

Realization relationships can cross generalization hierarchies

Interfaces are pure specifications, no behaviorAbstract base class may define attributes and associations

Interfaces are totally independent of inheritanceGeneralization is used to re-use implementationsInterfaces are used to re-use behavioral specifications

Generalization provides a way to implement polymorphism

There are several differences between the use of generalization (abstract base classes) and interfaces:

• Interfaces 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. Interfaces are orthogonal to class inheritance lineage; two different classifiers may realize the same interface but be unrelated in their class hierarchies.

• Interfaces are purely specifications of behavior (a set of operation signatures). An abstract base class may define attributes and associations as well.

• Interfaces are totally independent of inheritance. Generalization is employed to re-use implementations; interfaces are employed to re-use and formalize behavioral specifications

• Generalization provides a way to implement polymorphism in cases where polymorphism is implemented the same way for a set of classes. The use of generalization to support polymorphism was discussed earlier in this module.




Polymorphism via Generalization Design Decisions

99

Polymorphism via Generalization Design Decisions

Provide interface only to descendant classes?Design ancestor as an abstract classAll methods are provided by descendent classes

Provide interface and default behavior to descendent classes?

Design ancestor as a concrete class with a default methodAllow polymorphic operations

Provide interface and mandatory behavior to descendent classes?

Design ancestor as a concrete classDo not allow polymorphic operations

When designing the use of generalization to support polymorphism, there are three basic decisions that must be made:

• Do you want to provide a function’s interface only to descendant classes? If so, design the ancestor as an abstract class, and only design methods for the descendent classes.

• Do you want to provide a function’s interface and default behavior to descendent classes? If so, design the ancestor as a concrete class with a default method, and allow descendents to redefine the method.

• Do you want to provide a function’s interface and mandatory behavior to descendent classes? If so, design the ancestor as a concrete class and disallow descendents from defining their own method for the operations.




What Is Metamorphosis?

100

Metamorphosis exists in the real world.How should it be modeled?

What Is Metamorphosis?

Metamorphosis1. A change in form, structure, or function; specifically the physical change undergone by some animals, as of the tadpole to the frog.

2. Any marked change, as in character, appearance, or condition.

~ Webster’s New World Dictionary, Simon & Schuster, Inc.




Example: Metamorphosis

101

Example: Metamorphosis

In the university, there are full-time students and part-time students

Part-time students may take a maximum of three courses but there is no maximum for full-time studentsFull-time students have an expected graduation date but part-time students do not

FullTimeStudent+ name+ address+ studentID+ gradDate

PartTimeStudent+ name+ address

+ maxNumCourses+ studentID




Modeling Metamorphosis: One Approach

102

What happens if apart-time student

becomes a full-time student?

Modeling Metamorphosis: One Approach

A generalization relationship may be created

FullTimeStudent

Student+ name+ address+ studentID

+ gradDate

PartTimeStudent+ maxNumCourses




Modeling Metamorphosis: Another Approach

103

Inheritance may be used to model common structure, behavior, and/or relationships to the “changing” parts

Modeling Metamorphosis: Another Approach


FullTimeStudent+ gradDate

PartTimeStudent+ maxNumCourses

FullTimeClassification+ gradDate

PartTimeClassification+ maxNumCourses


Classification1

1+ changeToFullTime

This example shows the “before” and “after” with regard to implementing metamorphosis.




Modeling Metamorphosis: Another Approach (continued)

104

Modeling Metamorphosis: Another Approach (continued)

Metamorphosis is accomplished by the object “talking” to the changing parts

: Student

: FullTimeClassification

: StudentManager : PartTimeClassification

2 : delete

3 : create

1 : changeToFullTime

X

The “x” referred here in the sequence diagram is a stop. It shows that the life of the instance has ended. This is a preferred way of showing the termination of the instance. The “create” introduces a new object in the sequence diagram.




Metamorphosis and Flexibility

105

Metamorphosis and Flexibility

This technique also adds to the flexibility of the model

ResidentInformation

1

0..1+ dorm+ room+ roomKeyID

FullTimeClassification+ gradDate

PartTimeClassification+ maxNumCourses


Classification1

1+ changeToFullTime

In this example, a student might also live on campus. In this case, there is a dorm identifier, a room number, and a room key number.

ResidentInformation is just a hypothetical class. It does not exist in the Course Registration model supplied with the course materials.




Resolve Use-Case Collisions

106

Class Design Steps


The purpose of this step is to prevent concurrency conflicts caused when two or more use cases access instances of the design class simultaneously, in potentially inconsistent ways.





107


Multiple use cases may simultaneously access design objectsOptions

Use synchronous messaging => first-come first-serve order processingIdentify operations (or code) to protectApply access control mechanisms• Message queuing• Semaphores (or “tokens”)• Other locking mechanism

Resolution is highly dependent on implementation environment

One of the difficulties with proceeding use case-by-use case through the design process is that two or more use cases may simultaneously attempt to invoke operations on design objects in potentially conflicting ways. In these cases, concurrency conflicts must be identified and resolved explicitly.

If synchronous messaging is used, execution of an operation will block subsequent calls to the objects until the operation completes. Synchronous messaging implies a first-come first-served ordering to message processing. This may resolve the concurrency conflict, as in cases where all messages have the same priority, or where every message runs within the same execution thread. In cases where an object may be accessed by different threads of execution, explicit mechanisms must be used to prevent or resolve the concurrency conflict.

For each object that may be accessed concurrently by different threads of execution, identify the code sections that must be protected from simultaneous access. If code is not available, identify which operations must be protected.

Next, select or design appropriate access control mechanisms to prevent conflicting simultaneous access. Examples of these mechanisms include message queuing to serialize access, use of semaphores (or “tokens”) to allow access to only one thread at a time, or other variants of locking mechanisms.

The choice of mechanism tends to be highly implementation —dependent, and typically varies with the programming language and operating environment. See the project-specific Design Guidelines for guidance on selecting concurrency mechanisms.




Handle Non-Functional Requirements in General

108

Class Design Steps


The purpose of this step is to make sure the design classes are refined to handle general non-functional requirements as stated in the Design Guidelines specific to the project (that is, to make sure that all mechanisms mapped to the class have been taken into account).





109





Persistency, Legacy InterfacePersistency, Legacy InterfaceDistribution


DesignGuidelines


Persistency

AnalysisMechanism

(Conceptual)



(Actual)

OODBMS

RDBMS

JDBC

ObjectStore

Java 1.2 from Sun

Legacy Data

New Data

Distribution

Persistency

SomeDesignClass

The design classes should be refined to handle general non-functional requirements as stated in the Design Guidelines specific to the project. Important inputs to this step are the non-functional requirements on a class that may already be stated in its special requirements and responsibilities. Such requirements are often specified in terms of what architectural (analysis) mechanisms are needed to realize the class. In this step the class is refined to incorporate the design mechanisms corresponding to these analysis mechanisms.

If you remember, the available design mechanisms were identified and characterized by the architect during Identify Design Mechanisms and were documented in the Design Guidelines.

In this step, the designer should, for each design mechanism needed, qualify as many characteristics as possible, giving ranges where appropriate.

Several general design guidelines and mechanisms that need to be taken into consideration when classes are designed, including:

• How to use existing products and components • How to adapt to the programming language • How to distribute objects • How to achieve acceptable performance • How to achieve certain security levels • How to handle errors




Class Design Steps

110

Class Design Steps


In this step, we verify that the Design Model fulfills the requirements of the system, is consistent with respect to the general design guidelines, and that it serves as a good basis for its implementation.

You should check the Design Model at this stage to verify that your work is headed in the right direction. There is no need to review the model in detail, but you should consider the checkpoints described on the next few slides.




Checkpoints: Classes

111

Checkpoints: Classes

Clear class namesOne well-defined abstraction Functionally coupled attributes/behaviorGeneralizations were madeAll class requirements were addressedDemands are consistent with state machinesComplete class instance life cycle is describedThe class has the required behavior

These are the questions you should be asking at this stage: Does the name of each class clearly reflect the role it plays? • Does the class represent a single well-defined abstraction?

If the class does not represent a single well-defined abstraction, you should consider splitting it.

• Are all attributes and responsibilities functionally coupled? The class should only define attributes, responsibilities, or operations that are functionally coupled to the other attributes, responsibilities, or operations defined by that class.

• Are there any class attributes, operations or relationships that should be generalized, that is, moved to an ancestor?

• Are all specific requirements on the class addressed? • Are the demands on the class consistent with any state machines that model the

behavior of the class and its instances? The demands on the class (as reflected in the class description and by the objects in sequence diagrams) should be consistent with any state diagram that models the behavior of the class and its objects.

• Is the complete life cycle of an instance of the class described? The complete lifecycle of an instance of the class should be described. Each object must be created, used, and removed by one or more Use-Case Realizations.

• Does the class offer the required behavior? The classes should offer the behavior that the Use-Case Realizations and other classes require.




Checkpoints: Operations

112

Checkpoints: Operations

Operations are easily understood State description is correct Required behavior is offeredParameters are defined correctlyMessages are completely assigned operationsImplementation specifications are correctSignatures conform to standards All operations are needed by Use-Case Realizations

These are the questions you should ask about the operations of each class:

• Are the operations understandable? The names of the operations should be descriptive and the operations should be understandable to those who want to use them.

• Is the state description of the class and its objects' behavior correct? • Does the class offer the behavior required of it? • Have you defined the parameters correctly?

Make sure that the parameters have been defined for each operation, and that there are not too many parameters for an operation.

• Have you assigned operations for the messages of each object completely? • Are the implementation specifications (if any) for an operation correct? • Do the operation signatures conform to the standards of the target programming

language? • Are all the operations needed by the Use-Case Realizations?

Remove any operations that are redundant or not needed by the Use-Case Realizations.




Checkpoints: Attributes

113

Checkpoints: Attributes

A single concept Descriptive namesAll attributes are needed by Use-Case Realizations

When thinking about attributes consider the following questions:

• Does each attribute represent a single conceptual thing? • Are the names of the attributes descriptive? • Are all the attributes needed by the Use-Case Realizations? Remove any attributes that are redundant or not needed by the Use-Case Realizations.

Be sure to identify and define any applicable default attribute values.




Checkpoints: Relationships

114

Checkpoints: Relationships

Descriptive role namesCorrect multiplicities

• Are the role names descriptive? • Are the multiplicities of the relationships correct? The role names of the aggregations and associations should describe the relationship between the associated class and the relating class.




Review

115

Review: Class Design

What is the purpose of Class Design?In what ways are classes refined?Are state machines created for every class?What are the major components of a state machine? Provide a brief description of each.What is the difference between a dependency and an association?What is a structured class? What is a connector?





116


Given the following:The Use-Case Realization for a use case and/or the detailed design of a subsystem• Payroll Exercise Solution, Exercise: Use-Case

Design, Part 1

The design of all participating design elements• Payroll Exercise Solution, Exercise:

Subsystem Design

The goal of this exercise is to refine the relationships that a design class has with other design elements (that is, to design the class relationships).

For this exercise, we will focus our efforts on the Use-Case Realizations that were developed in the Use-Case Design module and/or the subsystem interface realizations developed in the Subsystem Design module.

At this point, the design of the model elements (classes and subsystems) includes a first attempt at attributes and operations, with complete signatures, as well as any defined relationships.


• Use-Case Realizations: Payroll Exercise Solution, Exercise: Use-Case Design, Part 1.

• Subsystem interface realizations: Payroll Exercise Solution, Exercise: Subsystem Design section.





117


Identify the following:The required navigability for each relationshipAny additional classes to support the relationship designAny associations refined into dependenciesAny associations refined into aggregations or compositionsAny refinements to multiplicityAny refinements to existing generalizationsAny new applications of generalization• Make sure any metamorphosis is

considered

During relationship design, you must look at each relationship for its:

• Type: Need to decide if the relationship is appropriate. In most cases, you will look at each association to decide if it should remain an association or be refined into a dependency relationship. When making this decision, it is important to define the relationship visibility (that is, field, local, global, or parameter).

• Navigability: Is the defined navigability still valid? For two-way/bi-directional relationships, are both directions really needed? (Remember, implementing bi-directional relationships is more expensive.)

• Multiplicity: Is the defined multiplicity still valid? When designing the relationships, you will need to consult both the static and dynamic uses of the relationship (that is, the VOPC and the Use-Case Realization interaction diagrams).

Be sure to note the rationale for your choices. For example, for every association that is refined into a dependency, note the visibility behind it (for example, local, global, parameter).

Examine each of the class diagrams produced up to this point and determine if and where generalization could be used.

Hint: Keep in mind metamorphosis and see if the technique applies.





118


Produce the following:An updated VOPC, including the relationship refinements (generalization, dependency, association)

The Class diagram you produce can include any number of classes, as long as it effectively demonstrates the use of generalization.

If the generalization changes affect Use-Case Realization diagrams, these diagrams should be updated, as well. Not all generalization changes will require Use-Case Realization refinements (however, generalization to support metamorphosis usually do).


• Define Dependencies: 13-52 and 13-53. • Generalization: slides 13-93; 13-94, 13-102.




Exercise 2: Review

119

Exercise 2: Review

Compare your resultsDo your dependencies represent context independent relationships?Are the multiplicities on the relationships correct?Does the inheritance structure capture common design abstractions, and not implementation considerations?Is the obvious commonality reflected in the inheritance hierarchy?

Payroll System

After completing a model, it is important to step back and review your work. Here are some helpful questions:

• Do you dependencies represent context independent relationships? • Are the multiplicities on the relationships correct? • Does the inheritance structure capture common design abstractions, and not

implementation considerations? • Is the obvious commonality reflected in the inheritance hierarchy?






► ► ► Module 14 Database Design

1

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 14: Database Design (Optional)

Topics

Database Design Overview................................................................................. 14-4 Relational Databases and Object Orientation...................................................... 14-7 Object-Relational Framework: Characteristics ................................................... 14-11 What Are Stored Procedures? ........................................................................... 14-19 Review............................................................................................................. 14-23




Objectives: Database Design

2

Objectives: Database Design

Define the purpose of Database Design and where in the lifecycle it is performedExplain how persistent classes map to the data modelLearn how to distribute class behavior to the database

Persistent classes need to be related to tables in the data model. This step will ensure that there is a defined relationship between the design and data model.

This activity assumes the use of a Relational Database (RDBMS).



Module 14 - Database Design

Database Design in Context

3

Database Design in Context[Early





Synthesis

Analyze Behavior


DesignComponents

Design theDatabase

(Optional)

DatabaseDesign

DatabaseDesigner

As you may recall, the above diagram illustrates the workflow that we are using in this course. It is a tailored version of the Analysis and Design core workflow of the Rational Unified Process.

The purpose of this workflow detail is to:

• Identify the persistent classes in the design. • Design appropriate database structures to store the persistent classes. • Define mechanisms and strategies for storing and retrieving persistent data to

meet the system’s performance criteria. The designers responsible for persistent classes need to have an understanding of persistence in general and the persistence mechanisms in specific. Their primary responsibility is to ensure that persistent classes are identified and that these classes use the persistence mechanisms in an appropriate manner. The database designer needs to understand the persistent classes in the design model and so must have a working understanding of object-oriented design and implementation techniques. The database designer also needs a strong background in database concurrency and distribution issues.




Database Design Overview

4

Database Design Overview


DatabaseDesignUse-Case Realization


Analysis Classes Design Classes

Design Model

Data Model

Database Design is performed for each persistent design class.

Purpose:

• To ensure that persistent data is stored consistently and efficiently. • To define behavior that must be implemented in the database. Input Artifacts:

• Supplementary Specifications • Use-Case Realization • Project Specific Guidelines • Data Model • Analysis Class • Design Class • Design Model Resulting Artifacts:

• Data Model




Database Design Steps

5


Map persistent design classes to the data modelDistribute class behavior to the database

This slide shows the major steps of the Database Design activity.

The purpose of Database Design is to ensure that persistent data is stored consistently and efficiently, and to define behavior that must be implemented in the database.

There are other steps in Database Design, but they are outside the scope of this course. The two steps are the only ones that apply to transitioning persistent design elements to the Data Model.





6



In this step, our purpose is to create define and refine the Data Model to support storage and retrieval of persistent classes. This is done only after the design of the persistent classes has stabilized.




Relational Databases and Object Orientation

7

RDBMS and Object Orientation are not entirely compatible

RDBMS • Focus is on data• Better suited for ad-hoc relationships and reporting

application• Expose data (column values)

Object Oriented system• Focus is on behavior• Better suited to handle state-specific behavior where

data is secondary• Hide data (encapsulation)

Relational Databases and Object Orientation

Relational databases and object orientation are not entirely compatible. They represent two different views of the world: In an RDBMS, all you see is data; in an object-oriented system, all you see is behavior. It is not that one perspective is better than the other, but they are different. The object-oriented model tends to work well for systems with complex behavior and state-specific behavior in which data is secondary, or systems in which data is accessed navigationally in a natural hierarchy (for example, bills of materials). The RDBMS model is well suited to reporting applications and systems in which the relationships are dynamic or ad hoc.

The real fact of the matter is that a lot of information is stored in relational databases, and if object-oriented applications want access to that data, they need to be able to read and write to an RDBMS. In addition, object-oriented systems often need to share data with non-object-oriented systems. It is natural, therefore, to use an RDBMS as the sharing mechanism.

While object-oriented and relational design share some common characteristics (an object’s attributes are conceptually similar to an entity’s columns), fundamental differences make seamless integration a challenge. The fundamental difference is that data models expose data (through column values) while object models hide data (encapsulating it behind its public interfaces).




The Relational Data Model

8

The Relational Data Model

Relational model is composed of EntitiesRelations

ORDER LINE ITEM

PRODUCT

Order_Id LineItem_IdDescriptionPriceQuantityProduct_IdOrder_Id

Product_IdNamePrice

lineItem order

products

lineItems

Entity

Relation

Columns

The relational model is composed of entities and relations. An entity may be a physical table or a logical projection of several tables, also known as a view. The figure above illustrates LINEITEM and PRODUCT tables and the various relationships between them.

An entity has columns. Each column is identified by a name and a type. In the figure above, the LINEITEM entity has the columns LineItem_Id (the primary key), Description, Price, Quantity, Product_Id and Order_Id (the latter two are foreign keys that link the LINEITEM entity to the ORDER and PRODUCT entities).

An entity has records or rows. Each row represents a unique set of information that typically represents an object's persistent data.

Each entity has one or more primary keys. The primary keys uniquely identifiy each record (for example, Id is the primary key for LINEITEM table).

Support for relations is vendor-specific. The example illustrates the logical model and the relation between the PRODUCT and LINEITEM tables. In the physical model relations are typically implemented using foreign key and primary key references. If one entity relates to another, it will contain columns that are foreign keys. Foreign key columns contain data that can relate specific records in one entity to another.

Relations have multiplicity (also known as cardinality). Common cardinalities are one to one (1:1), one to many (1:m), many to one (m:1), and many to many (m:n). In the example, LINEITEM has a 1:1 relationship with PRODUCT, while PRODUCT has a 0:m relationship with LINEITEM.




The Object Model

9

The Object Model

The Object Model is composed of Classes (attributes)Associations

LineItem- quantity : Integer- number : Integer1..*

+lineItemsOrder- number : Integer

+order

Product- number : Integer- description : String- unitPrice : Double

1

Software Product- version : Double

Hardware Product- assembly : String

An Object Model contains, among other things, classes. Classes define the structure and behavior of a set of objects, sometimes called object instances. The structure is represented as attributes (data values) and associations (relationships between classes). The figure in the slide illustrates a simple class diagram, showing only attributes (data) of the classes.

An Order has a number (the Order Number), and an association to one or more (1..*) LineItems. Each LineItem has a quantity (the quantity ordered).

The Object Model supports inheritance. A class can inherit data and behavior from another class (for example, SoftwareProduct and HardwareProduct inherit attributes and methods from Product class).




Persistence Frameworks

10

Persistence Frameworks

The challenge:Changes should not break the model

The solution: An object-relational framework that

Encapsulates the physical data storeProvides object translation services

The importance of the framework

30% of development time is spent in accessing an RDBMSMaintenance can be 60% of total cost

Business Object Model

Relational Database

•Compact interfaces•Object-relational translation•Encapsulates data store

The majority of business applications use relational technology as a physical data store. The challenge facing object-oriented application developers is to sufficiently separate and encapsulate the relational database so that changes in the Data Model do not "break" the Object Model, and vice versa. Many solutions exist which let applications directly access relational data. The challenge is in achieving a seamless integration between the Object Model and the Data Model.

Database APIs come in standard flavors (for example, Microsoft's Open Data Base Connectivity API, or ODBC) and are proprietary (native bindings to specific databases). The APIs provide data manipulation language (DML) pass-through services that allow applications to access raw relational data. In object-oriented applications, the data must undergo object-relational translation prior to being used by the application. This requires a considerable amount of application code to translate raw database API results into application objects. The role of the object-relational framework is to generically encapsulate the physical data store and to provide appropriate object translation services.

Application developers spend over 30% of their time implementing relational database access in object-oriented applications. If the object-relational interface is not correctly implemented, the investment is lost. Implementing an object-relational framework captures this investment. The object-relational framework can be reused in subsequent applications, reducing the object-relational implementation cost to less than 10% of the total implementation costs. The most important cost to consider when implementing any system is maintenance. Over 60% of the total costs of a system over its entire life cycle can be attributed to maintenance. A poorly implemented object-relational system is both a technical and financial maintenance nightmare.




Object-Relational Framework: Characteristics

11

Object-Relational Framework: Characteristics

PerformanceDecomposing objects to dataComposing objects from data

Minimize design compromisesLimit changes to object and relational models

Extensibility15%-35% of the framework needs to be designed as an extensible framework

• Performance: Close consideration must be given to decomposing objects into

data and composing objects from data. In systems where data through-put is high and critical, this is often the Achilles heel of an inadequately designed access layer.

• Minimize design compromises: A familiar pattern to object technologists who have built systems that use relational databases is to adjust the object model to facilitate storage into relational systems and to alter the relational model for easier storage of objects. While minor adjustments are often needed, a well designed access layer minimizes both object and relational model design degradation.

• Extensibility: The Access layer is a white-box framework that allows application developers to extend the framework for additional functions. Typically, an Access layer will support 65-85% of an application's data storage requirements without extension. If the access layer is not designed as an extensible framework, achieving the last 15-35% of an application's data storage requirements can be very difficult and costly.




Object-Relational Frameworks: Characteristics (continued)

12

Object-Relational Frameworks: Characteristics (continued)

Documentation of the APISupport for common object-relational mappingsPersistence interfaces

Examples are save, delete, and find

• Documentation: The Access layer is both a black-box component and a white-

box framework. The API of the black-box component must be clearly defined, well documented, and easily understood. As previously mentioned, the Access layer is designed to be extended. An extensible framework must be very thoroughly documented. Classes intended to be subclassed, must be identified. The characteristics of each relevant class's protocol must be specified (for example, public, private, protected, final). Moreover, a substantial portion of the access layer framework's design must be exposed and documented to facilitate extensibility.

• Support for common object-relational mappings: An Access layer should provide support for some basic object-relational mappings without the need for extension.

• Persistence Interfaces: In an object-oriented application, the business model for an object application captures semantic knowledge of the problem domain. Developers should manipulate and interact with objects without having to worry too much about the data storage and retrieval details. A well-defined subset of persistent interfaces (save, delete, find) should be provided to application developers.




Common Object-Relational Services

13

Common Object-Relational Services

Patterns are beginning to emerge for object-relational applications

CORBA Services specification• Persistence• Query• Transactions• Concurrency• Relationships

Refer to the appropriate CORBA specifications for further details.

Common patterns are emerging for object-relational applications. IT professionals who have repeatedly crossed the chasm are beginning to understand and recognize certain structures and behaviors which successful object-relational applications exhibit. These structures and behaviors have been formalized by the high-level CORBA Services specifications (which apply equally well to COM/DCOM-based systems).

The CORBA service specifications that are useful to consider for object-relational mapping are: • Persistence: How objects use a secondary storage medium to maintain their

state across discrete sessions. • Query: Allows applications to interrogate and retrieve objects based on a variety

of criteria. The basic query operations provided by an object-relational mapping framework are “find” and “find unique.”

• Transactions: Enable the definition of an atomic unit of work. In database terminology, it means that the system must be able to apply a set of changes to the database, or it must ensure that none of the changes are applied.

• Concurrency: When an object is accessed simultaneously by many users, the system must provide a mechanism to ensure that modifications to the object in the persistent store occur in a predictable and controlled manner.

• Relationships: When an object is stored, retrieved, transacted, or queried consideration must be given to its related objects.

Refer to the appropriate CORBA specifications for further details.




Mapping Persistent Classes to Tables

14

Student- name : String- address : String- studentID : Long

Mapping Persistent Classes to Tables

In a relational databaseEvery row is regarded as an objectA column in a table is equivalent to a persistent attribute of a class

987 High St.

Address

123456Thomas Stuart

Student_IDName

Object Instance

Attributes from object type

The persistent classes in the Design Model represent the information the system must store. Conceptually, these classes might resemble a relational design (for example, the classes in the Design Model might be reflected in some fashion as entities in the relational schema). As we move from elaboration into construction, however, the goals of the Design Model and the Relational Data Model diverge. The objective of relational database development is to normalize data, whereas the goal of the Design Model is to encapsulate increasingly complex behavior. The divergence of these two perspectives — data and behavior — leads to the need for mapping between related elements in the two models.

In a relational database written in third normal form, every row in the tables — every "tuple" — is regarded as an object. A column in a table is equivalent to a persistent attribute of a class (keep in mind that a persistent class may have transient attributes). So, in the simple case where we have no associations to other classes, the mapping between the two worlds is simple. The data type of the attribute corresponds to one of the allowable data types for columns.

In the example in this slide, the class Student when modeled in the RDBMS would translate to a table called Student, with the columns Name, Address, and Student_ID.




Mapping Associations Between Persistent Objects

15

Mapping Associations Between Persistent Objects

Associations between two persistent objects are realized as foreign keys to the associated objects.

A foreign key is a column in one table that contains the primary key value of associated object

456789678Course_IDNumber

456789AlgebraMath 101NumberDescriptionName

Course Offering table

Course tableCourse- name- description- number

CourseOffering- number : String

0..*

1

Primary Key

Foreign Key

Associations between two persistent objects are realized as foreign keys to the associated objects. A foreign key is a column in one table that contains the primary key value of the associated object.

Assume we have the above association between Course and CourseOffering. When we map this into relational tables, we get a Course table and a Course Offering table. The Course Offering table has columns for attributes listed, plus an additional Course_ID column that contains foreign-key references to the primary key of associated rows in the Course table. For a given Course Offering, the Course_ID column contains the identifier of the Course with which the Course Offering is associated. Foreign keys allow the RDBMS to join related information together.

Note: The Number attribute of the Course class is a string. For optimal performance, it is best to convert this to a number in the database schema (queries and joins work faster on numbers than strings, since number comparisons are faster in general than string comparisons).




Mapping Aggregation to the Data Model

16

Mapping Aggregation to the Data Model

Aggregation is also modeled using foreign key relationships

The use of composition implements a cascading delete constraint

Student.- studentID : int

Schedule


0..*

1

Spring 2001123456SemesterStudent_ID

Schedule table

123456Student_ID

Foreign Key

Primary Key

Student table

Aggregation is also modeled using foreign key relationships.

Assume we have the above aggregation between Student and Schedule. (Note: This is modeled as a composition, but remember that composition is a nonshared aggregation).

When we map this into relational tables, we get a Student table and a Schedule table. The Schedule table has columns for attributes listed, plus an additional column for Student_ID that contains foreign-key references to associated rows in the Student table. For a given Schedule, the Student_ID column contains the Student_ID of the Student that the Schedule is associated with. Foreign keys allow the RDBMS to join related information together.

In addition, to provide referential integrity in the Data Model, we would also want to implement a cascading delete constraint, so that whenever the Student is deleted, all of its Schedules are deleted as well.




Modeling Inheritance in the Data Model

17

Modeling Inheritance in the Data Model

A Data Model does not support modeling inheritance in a direct wayTwo options:

Use separate tables (normalized data)Duplicate all inherited associations and attributes (de-normalized data)

The standard relational Data Model does not support modeling inheritance associations in a direct way. A number of strategies can be used to model inheritance:

• Use separate tables to represent the super-class and subclass. Have, in the subclass table, a foreign key reference to the super-class table. In order to “instantiate” a subclass object, the two tables would have to be joined together. This approach is conceptually easier and makes changes to the model easier, but it often performs poorly due to the extra work.

• Duplicate all inherited attributes and associations as separate columns in the subclass table. This is similar to de-normalization in the standard relational Data Model.





18



In this step, our purpose is to determine the behavior of the class that can be distributed to and implemented by the database. This is done only after the design of the persistent classes has stabilized.




What Are Stored Procedures?

19

What Are Stored Procedures?

A stored procedure is executable code that runs under the RDBMSTwo types of stored procedures:

Procedures: Executed explicitly by an applicationTriggers: Invoked implicitly when some database event occurs

Most databases support a stored procedure capability. A stored procedure is executable code that runs within the process space of the database management system. Stored procedures provide the ability to perform database-related actions on the server without having to transfer data across a network. Their judicious use can improve performance of the system.

Stored procedures usually come in two flavors: actual procedures and triggers. Procedures are executed explicitly by an application. They generally have parameters and can provide an explicit return value. Triggers are invoked implicitly when some database event occurs (insert a row, update a row, delete a row, and so on). They have no parameters (because they are invoked implicitly) and do not provide explicit return values.

In database systems that lack constraints, triggers are often used to enforce referential and data integrity. Otherwise, they tend to be used when an event needs to trigger (or cause) another event.




Map Class Behavior to Stored Procedures

20

Map Class Behavior to Stored Procedures

Determine if any operations can be implemented as a stored procedureCandidates:

Operations that deal with persistent data Operations in which a query is involved in a computationOperations that need to access the database to validate data

The Design classes should be examined to see if they have operations that should be implemented using a stored procedure or trigger. Candidates include:

• Any operations that primarily deal with persistent data (creating, updating, retrieving, or deleting it).

• Any operations in which a query is involved in a computation (such as calculating the average quantity and value of a product in inventory).

• Operations that need to access the database to validate data. Remember that improving database performance usually means reducing I/O. As a result, if performing a computation on the DBMS server will reduce the amount of data passed over the network, the computation should probably be performed on the server.

The database designers should work with the designer of the class to discuss how the database can be used to improve performance. The designer will update the operation method to indicate that one or more stored procedures can be or should be used to implement the operation.




Example: Map Class Behavior to Stored Procedures

21

Example: Map Class Behavior to Stored Procedures

Student.

+ getTuition()+ addSchedule()+ getSchedule()+ deleteSchedule()+ hasPrerequisites()# passed()+ getNextAvailID()+ getStudentID()+ getName()+ getAddress()

Class Candidate Operations• getTuition

• addSchedule

• getSchedule

• deleteSchedule

• getStudentID

• getName

• getAddress

The class Student has been designed with a number of operations. The designer and database designer should sit down and determine which operations can be implemented by using a stored procedure.

Candidate operations for the Student class include:

• getTuition • addSchedule • getSchedule • deleteSchedule • getStudentID • getName • getAddress The reason that these operations are considered candidates is that they deal with retrieving, creating, or deleting persistent data.




Checkpoints: Database Design

22

Checkpoints: Database Design

Have all persistent classes been mapped to database structures?Have stored procedures and triggers been defined?Does the persistence mechanism use stored procedures and database triggers consistently?




Review

23

Review: Database Design

What is the purpose of the Database Design?What comprises a relational data model?What are the components of an object model?When mapping persistent classes to tables, what is every row in a table regarded as? What is every column equivalent to?What are stored procedures?






IBM / Rational software

Glossary

Version 2004.06.00

Mastering Object-Oriented Analysis and Design with UML Version: 2004.06.00 Glossary

Revision History Date Version Description Author

June, 1999 V4.2 Initial creation Shawn Siemers

November, 2001 V2002 Final release Shawn Siemers

December, 2002 V2003.06.00 Final release Alex Kutsick

June, 2004 V2004.06.00 Final release Alex Kutsick

© Copyright IBM Corp. 2004 Page 2 of 22


Table of Contents 1. Introduction 6

2. Definitions 6 2.1 Abstract Class 6 2.2 Abstraction 6 2.3 Action 6 2.4 Active Class 6 2.5 Activity 6 2.6 Activity Diagram 6 2.7 Activity State 7 2.8 Actor 7 2.9 Aggregation 7 2.10 Analysis 7 2.11 Analysis Class 7 2.12 Analysis Mechanism 7 2.13 Architectural Mechanism 7 2.14 Architecture 7 2.15 Assembly Connector 8 2.16 Association 8 2.17 Association Class 8 2.18 Attribute 8 2.19 Ball 8 2.20 Behavior 8 2.21 Boundary Class 8 2.22 Choice 8 2.23 Class 8 2.24 Class Diagram 8 2.25 Classifier 9 2.26 Collaboration 9 2.27 Combined Fragment 9 2.28 Communication Diagram 9 2.29 Component 9 2.30 Component Diagram 9 2.31 Composite Structure Diagram 9 2.32 Composition 10 2.33 Concrete Class 10 2.34 Concurrency 10 2.35 Connector 10 2.36 Control Class 10 2.37 Delegation Connector 10 2.38 Dependency 10 2.39 Deployment 10 2.40 Deployment Diagram 10 2.41 Deployment Specification 10 2.42 Deployment View 10 2.43 Derived Attribute 11 2.44 Design 11 2.45 Design Model 11 2.46 Design Mechanism 11 2.47 Device 11



2.48 Encapsulation 11 2.49 Entity Class 11 2.50 Event 11 2.51 Event Occurrence 11 2.52 Execution Environment 12 2.53 Execution Occurrence 12 2.54 Forward Engineering 12 2.55 Frame 12 2.56 Framework 12 2.57 Gate 12 2.58 Generalization 12 2.59 General Ordering 13 2.60 Guard Condition 13 2.61 Hierarchy 13 2.62 Implementation Mechanism 13 2.63 Implementation View 13 2.64 Inheritance 13 2.65 Instance 13 2.66 Interaction 13 2.67 Interaction Diagram 14 2.68 Interaction Fragment 14 2.69 Interaction Occurrence 14 2.70 Interaction Operand 14 2.71 Interaction Overview Diagram 14 2.72 Interface 14 2.73 Iteration 15 2.74 Iteration Expression 15 2.75 Lifeline 15 2.76 Link 15 2.77 Logical View 15 2.78 Manifestation 15 2.79 Message 15 2.80 Method 15 2.81 Modularity 15 2.82 Multiple Inheritance 15 2.83 Multiplicity 15 2.84 Navigability 16 2.85 Node 16 2.86 Object 16 2.87 Object Diagram 16 2.88 Object Lifeline 16 2.89 Object-Orientation (OO) 16 2.90 Object Technology 16 2.91 Operation 16 2.92 Operation Signature 16 2.93 Package 16 2.94 Package Diagram 17 2.95 Package Import 17 2.96 Partitions 17 2.97 Pattern 17 2.98 Polymorphism 17 2.99 Port 18 2.100 Process 18



2.101 Process View 18 2.102 Property 18 2.103 Provided Interface 18 2.104 Realization 18 2.105 Relationship 18 2.106 Required Interface 18 2.107 Responsibility 18 2.108 Reverse Engineering 19 2.109 Role 19 2.110 Scenario 19 2.111 Sequence Diagram 19 2.112 Single Inheritance 19 2.113 Socket 19 2.114 State 19 2.115 State Machine 19 2.116 State Machine Diagram 20 2.117 Stereotype 20 2.118 Stored Procedures 20 2.119 Structured Class 20 2.120 Structure Diagram 20 2.121 Structured Part 20 2.122 Subsystem 20 2.123 Thread 20 2.124 Time Constraint 20 2.125 Timing Diagram 20 2.126 Transaction 20 2.127 Transition 21 2.128 Unified Modeling Language (UML) 21 2.129 Use Case 21 2.130 Use-Case Diagram 21 2.131 Use-Case Model 21 2.132 Use-Case Realization 21 2.133 Use-Case View 21 2.134 Utility Class 21 2.135 Visibility 21 2.136 Visual Modeling 21



Glossary

1. Introduction This document contains definitions for terms used in the Essentials of Visual Modeling and Mastering Object-Oriented Analysis and Design with UML courses. Many of the definitions are from the Rational Unified Process and some are from the Unified Modeling Language Reference Manual, 2nd edition, by James Rumbaugh, Ivar Jacobson, Grady Booch, Addison-Wesley, Boston, 2005. Other information was taken directly from the course materials or paraphrased from the UML User's Guide. Graphics were included where they helped to explain the definition.

2. Definitions

2.1 Abstract Class An abstract class is a class that cannot be instantiated—that is, it may not have direct instances. It is the opposite of a concrete class.

2.2 Abstraction The essential characteristics of an entity that distinguish it from all other kind of entities and thus provide crisply-defined boundaries relative to the perspective of the viewer.

2.3 Action An action is an operation that is associated with a transition. Actions conceptually take an insignificant amount of time to complete, and are considered non-interruptible. Action names are shown on the transition arrow preceded by a slash.

StateA

StateB StateC

entry/ action

event( condition ) / action

2.4 Active Class An active class is a class that “owns” it’s own thread of execution and can initiate control activity, contrasted with passive classes that can only be acted upon. Active classes may execute in parallel (that is, concurrently) with other active classes.

2.5 Activity A unit of work a worker may be asked to perform.

2.6 Activity Diagram An activity diagram shows the decomposition of an activity into its constituents.


Mastering Object-Oriented Analysis and Design with UML Version: 2004.06.00 Glossary 2.7 Activity State

The performance of an activity or step within the workflow.

2.8 Actor Someone or something outside the system or business that interacts with the system or business.

Actor

(f rom Use Case View)

2.9 Aggregation An association that models a whole-part relationship between an aggregate (the whole) and its parts. It is shown by a hollow diamond at the end of the path attached to the aggregate class.

Whole Part

2.10 Analysis The part of the software development process whose primary purpose is to formulate a model of the problem domain. Analysis focuses on what to do; design focuses on how to do it.

2.11 Analysis Class Analysis classes handle primarily functional requirements, and model objects from the "problem" domain.

2.12 Analysis Mechanism An architectural mechanism used early in the design process, during the period of discovery when key classes and subsystems are being identified. Typically analysis mechanisms capture the key aspects of a solution in a way that is implementation independent. Analysis mechanisms are usually unrelated to the problem domain, but instead are "computer science" concepts. They provide specific behaviors to a domain-related class or component, or correspond to the implementation of cooperation between classes and/or components. They may be implemented as a framework. Examples include mechanisms to handle persistence, inter-process communication, error or fault handling, notification, and messaging, to name a few.

2.13 Architectural Mechanism An architectural mechanism represents a common solution to a frequently encountered problem. They may be patterns of structure, patterns of behavior, or both.

2.14 Architecture The highest-level concept of a system in its environment. The architecture of a software system (at a given point in time) is its organization or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces.


Mastering Object-Oriented Analysis and Design with UML Version: 2004.06.00 Glossary 2.15 Assembly Connector

A connector between two elements (parts or ports) in the internal implementation specification of a structured classifier or component.

2.16 Association A relationship that models a bi-directional semantic connection among instances.

2.17 Association Class An association class is a class that is connected to an association. It is a full-fledged class and can contain attributes, operations and other associations. Association classes allow you to store information about the relationship itself. Such information is not appropriate, or does not belong, within the classes at either end of the relationship.

AssociationClass

0..* 0..*

ClassB ClassA

0..* 0..*

2.18 Attribute An attribute defined by a class represents a named property of the class or its objects. An attribute has a type that defines the type of its instances.

2.19 Ball A provided interface relationship shown by a small circle, or a ball, attached to a classifier by a line.

2.20 Behavior The observable effects of an event that includes results.

2.21 Boundary Class A class used to model communication between the system's environments and its inner workings.

2.22 Choice A node in a state machine at which dynamic evaluations of subsequent guard conditions is made.

2.23 Class A class is a description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics.

ClassA

2.24 Class Diagram A diagram that shows a set of classes, interfaces, and collaborations and their relationships; class diagrams address the static design view of a system; a diagram that shows a collection of declarative (static) elements.


Mastering Object-Oriented Analysis and Design with UML Version: 2004.06.00 Glossary 2.25 Classifier

A model element that describes behavioral and structural features. Kinds of classifiers include actor, association, class, collaboration, component, data type, interface, node, signal, subsystem, and use case.

2.26 Collaboration A society of roles and other elements that work together to provide some cooperative behavior that’s bigger than the sum of all its parts; the specification of how an element, such as a use case or an operation, is realized by a set of classifiers and associations playing specific roles and used in a specific way.

2.27 Combined Fragment A construct within an interaction that comprises an operator keyword and one or more interaction operands, each of which is a fragment of an interaction. It is shown as a nested region within a sequence diagram. If the fragment has more than one subfragment, horizontal dashed lines separate them.

2.28 Communication Diagram A communication diagram describes a pattern of interaction among objects; it shows the objects participating in the interaction by their links to each other and the messages they send to each other.

: Actor

: ClassA

3: Message32: Message2

1: Message1

: ClassB

2.29 Component A modular part of a system that hides its implementation behind a set of external interfaces. Within a system, components satisfying the same interfaces may be substituted freely.

2.30 Component Diagram A diagram that shows the definition, internal structure, and dependencies of component types. There is no sharp line between component diagrams and general class diagrams.

2.31 Composite Structure Diagram A composite structure diagram shows the internal structure (including parts and connectors) of a structured classifier or collaboration. It defines the parts of a system and the communication relationships between them.


Mastering Object-Oriented Analysis and Design with UML Version: 2004.06.00 Glossary 2.32 Composition

A composition is a stronger form of association in which the composite has sole responsibility for managing its parts— such as their allocation and deallocation. A filled diamond on the composite end shows it. An object at most may belong to one composition.

PartWhole

2.33 Concrete Class A generalizable element (such as a class) that can be directly instantiated. Of necessity, its implementation must be fully specified. For a class, all its operations must be implemented (by the class or an ancestor).

2.34 Concurrency Concurrency is the tendency for things to happen at the same time in a system.

2.35 Connector The connection of two structured parts within a structured classifier or a collaboration; a specification of an contextual association that applies only in a certain context, such as the objects within a classifier or objects satisfying a collaboration.

2.36 Control Class A class used to model behavior specific to one, or a several use cases.

2.37 Delegation Connector A connector between an external port of a structured class or component and an internal part. Connections to the external port are treated as going to the element at the other end of the delegation connector.

2.38 Dependency A semantic relationship between two things in which a change to one thing (the independent thing) may affect the semantics of the other thing (dependent thing).

2.39 Deployment The assignment of software artifacts to physical nodes during execution.

2.40 Deployment Diagram A diagram that shows the configuration of run-time processing nodes and the artifacts that live on them. A deployment diagram may be at the class level or the instance level.

Work station

Server

2.41 Deployment Specification A detailed specification of the parameters of the deployment of an artifact to a node. A deployment specification is shown as a rectangle symbol with the keyword «deploymentSpec».

2.42 Deployment View A view that shows the nodes in a distributed system, the artifacts that are stored on each node, and the components and other elements that the artifacts manifest.


Mastering Object-Oriented Analysis and Design with UML Version: 2004.06.00 Glossary 2.43 Derived Attribute

An attribute whose value may be calculated based on the value of other attribute(s).

2.44 Design The part of the software development process whose primary purpose is to decide how the system will be implemented. During design, strategic and tactical decisions are made to meet the required functional and quality requirements of a system.

2.45 Design Model An object model describing the realization of use cases; serves as an abstraction of the implementation model and its source code.

2.46 Design Mechanism An architectural mechanism used during the design process, during the period in which the details of the design are being worked-out. They are related to associated analysis mechanisms, of which they are additional refinements. A design mechanism assumes some details of the implementation environment, but it is not tied to a specific implementation (as is an implementation mechanism). For example, the analysis mechanism for inter-process communication may be refined by several design mechanisms for interprocess communication (IPC): shared memory, function-call-like IPC, semaphore-based IPC, and so on. Each design mechanism has certain strengths and weaknesses; the choice of a particular design mechanism is determined by the characteristics of the objects using the mechanism.

2.47 Device A physical computational resource with processing capability upon which artifacts may be deployed for execution. A node annotated with the stereotype <<device>> notates a device.

2.48 Encapsulation The physical localization of features (for example, properties, behaviors) into a single black box abstraction that hides their implementation (and associated design decisions) behind a public interface. Encapsulation is also referred to as information hiding.

2.49 Entity Class A class used to model information that has been stored by the system, and the associated behavior. A generic class reused in many use cases, often with persistent characteristics. An entity class defines a set of entity objects, which participate in several use cases and typically survive those use cases.

2.50 Event An event is an occurrence that happens at some point in time. In a state machine, an event is an occurrence of a stimulus that can trigger a state transition.

Event / TargetObject.event

do/ TargetObject.Event

NewState2

entry/ Action

NewState

2.51 Event Occurrence The occurrence of an event during the execution of a system, e.g., call event, signal event, time event, change event. An event occurrence is not explicitly shown as a separate concept. It is usually shown by the intersection of a message arrow and a lifeline.


Mastering Object-Oriented Analysis and Design with UML Version: 2004.06.00 Glossary 2.52 Execution Environment

A kind of deployment node that represents a particular kind of execution platform, such as an operating system, a workstation engine, a database management system, and so on. Also (and more commonly) used informally to describe the context within which execution of a model occurs. A node annotated with the stereotype <<ExecutionEnvironment>> notates an execution environment.

2.53 Execution Occurrence The execution of an activity, operation, or other behavior unit within an interaction. An execution represents the period during which an object performs a behavior either directly or through a subordinate behavior.

2.54 Forward Engineering The process of transforming a model into code through a mapping to a specific implementation language.

2.55 Frame A diagram is presented as a frame containing graphical contents. The frame names the diagram and establishes its extent. It is drawn as a rectangle with a small pentagon (called the name tag) in the upper left corner.

e

2.56 FramA mic

2.57 GateA conoutsid

2.58 GeneA taxoelemeof the

Fram

ework ro-architecture that provides an incomplete template for applications within a specific domain

nection point in an interaction or interaction fragment for a message that comes from or goes to e the interaction or fragment.

ralization nomic relationship between a more general element and a more specific element. The more specific

nt is fully consistent with the more general element and contains additional information. An instance more specific element can be used where the more general element is allowed.

ClassBClassA

ClassParent



2.59 General Ordering A constraint in an interaction where the time of one event occurrence precedes the time of another event occurrence.

2.60 Guard Condition The guard is expressed as a Boolean constraint on values available to test at the time of messaging, i.e., the guard determines whether a transition may fire.

2.61 Hierarchy Any ranking or ordering of abstractions into a tree-like structure. Kinds: aggregation hierarchy, class hierarchy, containment hierarchy, inheritance hierarchy, partition hierarchy, specialization hierarchy, type hierarchy. (Dictionary of Object Technology, Firesmith, Eykholt, 1995.)

2.62 Implementation Mechanism An architectural mechanism used during the implementation process. They are refinements of design mechanisms, and specify the exact implementation of the mechanism. For example, one particular implementation of the inter-process communication analysis mechanism is a shared memory design mechanism utilizing a particular operating system’s shared memory function calls. Concurrency conflicts (inappropriate simultaneous access to shared memory) may be prevented using semaphores, or using a latching mechanism, which in turn rest upon other implementation mechanisms.

2.63 Implementation View An architectural view that describes the organization of the static software elements (code, data, and other accompanying artifacts) on the development environment, in terms of both packaging, layering, and configuration management (ownership, release strategy, and so on). In the Unified Process it is a view on the implementation model.

2.64 Inheritance The mechanism that makes generalization possible; a mechanism for creating full class descriptions out of individual class segments.

2.65 Instance A concrete manifestation of an abstraction; an entity to which a set of operations can be applied and that has a state that stores the effects of the operations.

2.66 Interaction A specification of how messages are exchanged between objects or other instances over time to perform a task. An interaction is defined in a context, which may be a classifier, a collaboration, or some other grouping of connected parts.


Mastering Object-Oriented Analysis and Design with UML Version: 2004.06.00 Glossary 2.67 Interaction Diagram

A diagram that shows an interaction, consisting of a set of objects and their relationships, including the messages that may be dispatched among them; interaction diagrams address the dynamic view of a system; a generic term that applies to several types of diagrams that emphasize object interactions, including communication diagrams, sequence diagrams, timing diagrams and the interaction overview diagrams. The Interaction Diagram is a generic term for focusing on messaging [interaction] between objects. As such, there is no one graphic for an Interaction Diagram.

2.68 Interaction Fragment A structural piece of an interaction.

2.69 Interaction Occurrence A reference to an interaction within the definition of another interaction.

2.70 Interaction Operand A structural piece of a combined fragment; a subfragment.

2.71 Interaction Overview Diagram A diagram that depicts interactions through a variant of activity diagrams in such a way to promote an overview of the control flow. It focuses on the overview of the flow of control where each node can be an interaction diagram.

2.72 Interface A declaration of a coherent set of public features and obligations; a contract between providers and consumers of services.

Interface

<<Interface>> Subsystem

<<subsystem>>

Subsystem <<subsystem>>

Interface


Mastering Object-Oriented Analysis and Design with UML Version: 2004.06.00 Glossary 2.73 Iteration

A distinct set of activities with a baseline plan and evaluation criteria that results in a release, either internal or external.

2.74 Iteration Expression A specification of the range of number of iterations of a loop.

2.75 Lifeline The lifeline represents the existence of the object at a particular time. You can use a lifeline to model both class and object behavior. Usually, a lifeline represents all objects of a certain class.

2.76 Link A semantic connection among objects; an instance of an association.

2.77 Logical View An architectural view that describes the main classes in the design of the system: major business-related classes, and the classes that define key behavioral and structural mechanisms (persistency, communication, fault-tolerance, user-interface). In the Unified Process, the logical view is a view of the design model.

2.78 Manifestation The physical implementation of a model element as an artifact. A manifestation is shown as a dependency arrow from an artifact to a model element. The keyword «manifest» is placed on the arrow.

2.79 Message The conveyance of information from one object (or other instance) to another as part of an interaction within a context. A message may be a signal or the call of an operation. The sending and the receipt of a message are event occurrences.

2.80 Method (1) A regular and systematic way of accomplishing something; the detailed, logically ordered plans or procedures followed to accomplish a task or attain a goal. (2) UML 1.1: The implementation of an operation, the algorithm, or the procedure that effects the results of an operation.

2.81 Modularity 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.

2.82 Multiple Inheritance A semantic variation of generalization in which an object may belong directly to more than one class.

2.83 Multiplicity A specification of the range of allowable cardinalities that a set may assume.

ClassA ClassB

0..1 0..2, 5


Mastering Object-Oriented Analysis and Design with UML Version: 2004.06.00 Glossary 2.84 Navigability

The navigability property on a role indicates that it is possible to navigate from a associating class to the target class using the association.

2.85 Node A run-time physical object that represents a computational resource, generally having at least memory and often processing capability. Run-time artifacts may be deployed on nodes.

Work station

2.86 Object An entity with a well-defined boundary and identity that encapsulates state and behavior. State is represented by attributes and relationships, behavior is represented by operations and methods. An object is an instance of a class.

2.87 Object Diagram A diagram that encompasses objects and their relationships at a given point in time. An object diagram may be considered a special case of a class diagram or a communication diagram.

2.88 Object Lifeline A line in a sequence diagram that represents the existence of an object over a period of time.

2.89 Object-Orientation (OO) The Rational Unified Process supports object-oriented techniques. Each model is object-oriented. Rational Unified Process models are based on the concepts of objects and classes and the relationships among them, as they use the UML as its common notation.

2.90 Object Technology A set of principles (abstraction, encapsulation, polymorphism) guiding software construction, together with languages, databases, and other tools that support those principles. (Object Technology - A Manager’s Guide, Taylor, 1997.)

2.91 Operation A service that can be requested from an object to effect behavior.

2.92 Operation Signature The name and parameters of an operation.

2.93 Package A general-purpose mechanism for organizing elements into groups, establishing ownership of elements, and providing unique names for referencing elements.

PackageA



2.94 Package Diagram A diagram that depicts how model elements are organized into packages and the dependencies among them, including package imports and package extensions.

2.95 Package Import A directed relationship that adds the names of elements to a namespace.

2.96 Partitions The organization of activities into distinct regions. Organize activities in a model according to their responsibility—for example, group all the activities handled by one business organization. Partitions are separated by lines in the diagram.

2.97 Pattern A scheme for describing design fragments or collections of class templates so that they can be configured and reused.

2.98 Polymorphism Polymorphism is the ability to define a single interface with multiple implementations.


Mastering Object-Oriented Analysis and Design with UML Version: 2004.06.00 Glossary 2.99 Port

A structural feature of a classifier that encapsulates interaction between the contents of the classifier and its environment. A port is shown as a small square straddling the boundary of a classifier rectangle. The name of the port is placed near the square.

2.100 Process (1) Any thread of control that can logically execute concurrently with other processes. (2) A set of

partially ordered steps intended to reach a goal; in software engineering the goal is to build a software product or to enhance an existing one; in process engineering, the goal is to develop or enhance a process model; corresponds to a business use case in business engineering.

2.101 Process View An architectural view that describes the concurrent aspect of the system: tasks (processes) and their interactions.

2.102 Property A named value denoting a characteristic of an element.

2.103 Provided Interface An interface that declares the services that a classifier offers to provide to anonymous requestors. A provided interface relationship is shown by a small circle, or a ball, attached to a classifier by a line. Alternately, a provided interface can be shown using realization notation.

2.104 Realization A semantic relationship between classifiers, in which one classifier specifies a contract that another classifier guarantees to carry out.

2.105 Relationship An abstract concept that specifies some kind of connection between elements. Examples of relationships include associations and generalizations.

2.106 Required Interface A required interface is the complementary relationship of a provided interface where a classifier requires the services described in the interface. A required interface relationship is shown by a small half circle, or a socket, attached to a classifier by a line. Alternately, a required interface can be shown using dependency notation.

2.107 Responsibility A contract or obligation of a type or class.


Mastering Object-Oriented Analysis and Design with UML Version: 2004.06.00 Glossary 2.108 Reverse Engineering

The process of transforming code into a model through a mapping from a specific implementation language.

2.109 Role The behavior of an entity participating in a particular context. Role names are not underlined when only a role name is needed and no instance reference is implied.

Department Employee +Department Head

10..*

2.110 Scenario A described use-case instance, a subset of a use case.

2.111 Sequence Diagram A diagram that describes 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.

: Actor : Employee : Department

1: Message1

2: Message2

3: Message3

2.112 Single Inheritance A semantic variation of generalization in which a child may have only one parent.

2.113 Socket A required interface relationship is shown by a small half circle, or a socket, attached to a classifier by a line.

2.114 State A condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event.

2.115 State Machine A specification of the sequences of states that an object or an interaction goes through in response to events during its life, together with its responsive effects (action and activity). A state machine is attached to a source class, collaboration, or method and specifies the behavior of the instances of the source element.


Mastering Object-Oriented Analysis and Design with UML Version: 2004.06.00 Glossary 2.116 State Machine Diagram

A state machine diagram shows a state machine, that is, a behavior that specifies the sequences of states that an object goes through during its life in response to events, together with its responses and actions.

Event /TargetObject.event

entry/ Action

NewState

do/ TargetObject.Event

NewState2

2.117 Stereotype A meta-classification of an element. Stereotypes have semantic implications which can be specified for every specific stereotype value.

2.118 Stored Procedures A stored procedure is executable code that runs under the RDBMS. Stored procedures provide the ability to perform database-related actions on the server without having to transfer data across a network.

2.119 Structured Class A class containing parts or roles that form its structure and realize its behavior.

2.120 Structure Diagram A form of diagram that depicts the elements in a specification that is irrespective of time. Class diagrams and component diagrams are examples of structure diagrams.

2.121 Structured Part Within a structured classifier, an element that represents an object or set of objects within a contextual relationship.

2.122 Subsystem A large unit of decomposition for a system. It is modeled as a stereotype of component with the keyword <<subsystem>>.

2.123 Thread An independent computation executing within an the execution environment and address space defined by an enclosing operating system process.

2.124 Time Constraint Expressed as a time interval, it can refer to a single event occurrence or to the time interval between two occurrences.

2.125 Timing Diagram An interaction diagram that shows the change in state or condition of a lifeline over linear time. The most common usage is to show the change in state of an object over time in response to accepted events or stimuli. It is an optional diagram designed to specify the time constraints on messages sent and received in the course of an interaction.

2.126 Transaction Transactions define a set of operation invocations that are atomic: either all or none of them are performed.


Mastering Object-Oriented Analysis and Design with UML Version: 2004.06.00 Glossary 2.127 Transition

A transition is a change from an originating state to a successor state as a result of some stimulus.

2.128 Unified Modeling Language (UML) A language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.

2.129 Use Case A use case defines a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor. A use-case class contains all main, alternate flows of events related to producing the 'observable result of value'. Technically, a use-case is a class whose instances are scenarios.

2.130 Use-Case Diagram A diagram that shows the relationships among actors and use cases within a system.

2.131 Use-Case Model A model of what the system is supposed to do and the system environment.

2.132 Use-Case Realization A use-case realization describes how a particular use case is realized within the design model, in terms of collaborating objects.

2.133 Use-Case View An architectural view that describes how critical use cases are performed in the system, focusing mostly on architecturally significant components (objects, tasks, nodes). In the Unified Process, it is a view of the use-case model.

2.134 Utility Class A class that contains a collection of free subprograms.

2.135 Visibility How a name can be seen and used by others.

2.136 Visual Modeling A way of thinking about problems using models organized around real-world ideas.




Additional OOAD/UML Resources

Rational University Curriculum Paths Rational University has compiled a description of the role of the system analyst, the designer and the Enterprise architect. The following outline describes their activities and what is needed to succeed. To help you achieve your training goals, various curriculum paths reference available instructor and web-based training courses at Rational University.

System Analyst: The System Analyst role leads and coordinates requirements and use-case modeling by outlining the system's functionality and delimiting the system. For example, establishing the actors and use cases and how they interact.

• Responsible for eliciting and writing the requirements of the software project.

• At a senior level, responsible for the requirements management plan, use-case modeling guidelines and other requirements guidelines for the whole project.

Activities performed by this role:

• Develop vision.

• Elicit stakeholder requests.

• Manage dependencies between requirements.

• Maintaining the glossary.

• Find Use cases and actors; structure the use case model.

• Detail the use cases and supplementary specifications. What they need to succeed:

• To effectively elicit, organize and document the software requirements in the system.

• To understand how to use business-modeling artifacts as an input to system definition.

• An in-depth knowledge of requirements management.

• A quick, focused introduction to using and setting up RequisitePro.

• An in-depth knowledge of how to write a clear statement of requirements.

• To effectively capture their requirements using use cases or as declarative statements.

Curriculum Path:

http://www.ibm.com/services/learning/ites.wss/us/en?pageType=page&contentID=a0000460

REF-1



Designer: The Designer role defines the responsibilities, operations, attributes, and relationships of one or several classes, and determines how they will be adjusted to the implementation environment. In addition, the Designer role may have responsibility for one or more design packages, or design subsystems, including any classes owned by the packages or subsystems.

Activities they perform:

• Refine requirements of the use case; supplement the use case descriptions with information needed to understand internal system behavior.

• Refine requirements on the operations of design classes.

• Identify the classes that perform a use case's flow of events.

• Identify the responsibilities, attributes, and associates of the classes.

• Distribute the use-case behavior to those classes using use-case realizations.

• Note usage or architectural mechanisms. What they need to succeed: A solid working knowledge of:

• Use-case modeling techniques.

• System requirements.

• Software design techniques, including object-oriented analysis and design techniques, and the Unified Modeling Language.

• Technologies with which the system will be implemented.

Curriculum Path: Rose: http://www.ibm.com/services/learning/ites.wss/us/en?pageType=page&contentID=a0000463 XDE: http://www.ibm.com/services/learning/ites.wss/us/en?pageType=page&contentID=a0000462

REF-2

http://www.rational.com/university/paths/design_rose.jsp



Enterprise Architect: Enterprise Architects define and build the packages, subsystems, and interfaces for enterprise systems. This role "owns" the overall design of the enterprise system. Could also be known as Sr. Software Engineer, System Architect, or Member of Technical Staff

What They Do:

• Responsible for translating software requirements into a logical packages, subsystems, and interfaces.

• Work with XDE.

• Work with ClearCase and/or ClearQuest.

• Work with specific designer tools (XDE). Activities They Perform:

• Define the packages, subsystems, and interfaces for the system.

• Use analysis and design mechanisms to facilitate design of the system.

• Use configuration management tools to manage their assets. What They Need to Succeed:

• A working knowledge of the capabilities and operation of their design tools.

• A working knowledge of the capabilities and operation of Rational Software tools (including XDE and SCM tools).

• An understanding of the best practices for software development.

• An understanding of Enterprise architecture, architecture patterns, and design patterns.

• An understanding of modeling and testing.

Curriculum Path:


REF-3



General Software Development Code Complete - A Practical Handbook of Software Construction, McConnell, S., Microsoft Press, 1993.

Dynamics of Software Development, McCarthy, J., Microsoft Press, 1995.

The Mythical Man-Month, Brooks, F.P., Jr., Addison-Wesley, 1995.

Object-Oriented Software Development Best of Booch: Designing Strategies, Booch, G., and Eykholt, E., editor, SIGS Books & Multimedia, 1996.

Designing Object-Oriented Software, Wiener, L., Wilkerson, B., and Wirfs-Brock, R., Prentice Hall, 1990.

Dictionary of Object Technology, Eykholt, E., and Firesmith, D., SIGS Books, 1995.

Object-Oriented Analysis and Design with Applications, Booch, G., Benjamin/ Cummings, 1994.

Object Oriented Design Heuristics, Riel, Arthur J., Addison-Wesley, 1996.

Object-Oriented Modeling and Design, Rumbaugh, J., and others, Prentice Hall, 1991.

Object-Oriented Software Development, Lorenz, M., Prentice Hall, 1993.

Object-Oriented Software Engineering, Jacobson, I., and others, Addison-Wesley, 1992.

“OMT Insights: Perspectives on Modeling”, Rumbaugh, J., Journal of Object-Oriented Programming, SIGS Books & Multimedia, 1996.

The Rational Unified Process, Philippe Krutchen, Addison Wesley Longman, Inc., 1998.

Using CRC Cards, Wilkinson, N., SIGS Books, 1995.

UML The Object Primer: Agile Model-Driven Development with UML 2.0, Scott Ambler, Cambridge University Press, 2004.

Real-Time UML: Developing Efficient Objects For Embedded Systems, Douglas, B. Powel, Addison Wesley Longman, Inc., 1998.

UML in a Nutshell: A Desktop Quick Reference, Si Alhir, Sinan, O’Reilly & Associates, Inc., 1998.

The Unified Modeling Language User Guide, Booch, G. and others, Addison-Wesley, 2003.

The Unified Modeling Language Reference Manual – Second Edition, James Rumbaugh, Ivar Jacobson, Grady Booch, Addison-Wesley, 2004.

UML Bible, Pender, T., Wiley Publishing, Inc., 2004.

UML Distilled—Third Edition, Fowler, Martin, Addison Wesley Longman Inc., 1997.

UML Toolkit, Eriksson, H., Penker, M., Lyons, B., and Fado, D., Wiley Publishing, Inc., 2004.

Unified Method for Object-Oriented Development (documentation set, v0.8), Booch, G. and Rumbaugh, J., Rational Software Corp., 1995.

REF-4


Architecture Software Architecture in Practice, Bass, Ken, Bass, Len, Clements, Paul, and Kazman, Rick, Addison-Wesley, 1998.

“The 4+1 View Model of Architecture”, Kruchten, P, IEEE Software, November 1995.

“Foundations for the Study of Software Architecture," Perry, D.E., and Wolf, A.L., ACM Soft. Eng. Notes, Oct. 1992.

Systems Architecting: Creating and Building Complex Systems, Rechtin, E., Prentice Hall, 1991.

Software Architecture—Perspectives on an Emerging Discipline, Garlan, D., and Shaw, M., Prentice Hall, 1996.

Computer Architecture: A Quantitative Approach, Second Edition, Goldberg, D., Hennessy, J., and Patterson, D, Morgan Kaufman Publishers, 1996.

Patterns Analysis Patterns: Reusable Object Models, Fowler, M., Addison-Wesley, 1996.

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design, Larman, C., Prentice Hall Press, 1997.

Design Patterns: Elements of Reusable Object-Oriented Software, Gamma, E., and others, Addison-Wesley, 1995

Pattern-Oriented Software Architecture - A System of Patterns, Buschmann, F, Meunier, R., Rohnert, H., Sommerlad, P., and Stahl, M., John Wiley and Sons, 1996.

Project Management Object Solutions, Booch, G., Addison-Wesley, 1996.

Software Project Management: A Unified Framework, Royce, Walker, Addison-Wesley, 1998.

Metrics Object-Oriented Software Metrics, Kidd, J., and Lorenz, M., Prentice Hall, 1994.

User Interface Design Designing Object-Oriented User Interfaces, Collins, D., Benjamin/Cummings, 1995.

Object-Oriented GUI Application Development, Lee, G., Prentice-Hall, 1993.

Distribution The Essential Client/Server Survival Guide, Second Edition, Edwards, J., Harkey, D., and Orfali, R., John Wiley & Sons, 1997.

The Essential Distributed Objects Survival Guide, Edwards, J., Harkey, D., and Orfali, R., John Wiley & Sons, 1995.

REF-5


Object Database The Object Database Handbook, Barry, D., John Wiley & Sons, New York, NY, 1996

COM/OLE Understanding Active X and OLE, Chappel, David, Microsoft Press, 1996.

David Chappel’s Web site at http://www.chappellassoc.com

Inside COM, Rogerson, D., Microsoft Press, 1997.

COM’s home page: http://www.microsoft.com/cominfo/

CORBA Advanced Java Development for Enterprise Applications, Berg, Clifford J., Prentice Hall, 1998.

CORBA Fundamentals and Programming, Siegel, J., John Wiley & Sons, 1996.

Instant CORBA, Edwards, Jeri, Harkey, Dan, and Orfali, Robert, John Wiley & Sons, 1997.

For information on other books, see the Rational Unified Process recommended reading list at: http://www.rational.com/uml/?SMSESSION=NO

REF-6

http://www.rational.com/uml/?SMSESSION=NO