Ooad With Uml2.0

DEV475 Mastering Object-Oriented Analysis and Design with UML 2.
0
Student Guide, Volume 1
IBM Rational University
DEV475 Mastering Object-Oriented Analysis and Design with UML 2.0

Student Guide, Volume 1 Part No.
IBM Corporation Rational University DEV475 Mastering Object-Oriented Analysis and Design with UML 2.0 Student Manual, Volume 1 Version 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, PureCoverage, 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 registered trademarks of Microsoft Corporation. Java and all Java-based marks, among others, are trademarks or registered trademarks of Sun Microsystems 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 Software 18880 Homestead Road Cupertino, CA 95014-0721 USA
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 highlevel 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
Michael.Lang@us.ibm.com
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 Managers 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
IBM Software Group
Mastering Object-Oriented Analysis and Design with UML 2.0 Module 0: About This Course
Topics
Course Objectives ................................................................................................ 0-3 Prerequisites......................................................................................................... 0-6 Rational University Curriculum ............................................................................. 0-7
Copyright IBM Corp. 2004

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
0-1
Mastering Object-Oriented Analysis and Design with UML 2.0
Introductions
Introductions
Your organization Your role Your background, experience
Object technology experience Software development experience Implementation language experience
Your expectations for this course
0-2

Module 0 - About This Course
Course Objectives 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 model Use the Unified Modeling Language (UML) to represent the design model Apply 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.

0-3
Course Objectives (continued)
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 design Define basic design considerations, including the use of patterns
The concentration will be on those activities that are performed by the objectoriented designer. Architectural concepts will be introduced and discussed, as they drive the design, but this is not an architecture course.
0-4

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

0-5
Prerequisites 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 entity
Prerequisites can be achieved through attendance in Essentials of Visual Modeling with UML or equivalent experience
0-6

Rational University Curriculum Rational University Curriculum

Curriculum Flow: Designer
Path 1
DEV110 Principles of Modeling 2 hours DEV111 Principles of UC Modeling with UML 2 hours DEV112 Principles of Analysis I 2 hours DEV113 Principles of Analysis II 2 hours DEV160 Principles of Modeling Behavior 2 hours
Instructor-led Web-based Optional
OR Path 2
DEV275 Essentials of Visual Modeling with UML 1 day DEV475 Mastering Object Oriented Analysis & Design with UML 4 days
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.

0-7
Rational University Curriculum

Curriculum Flow: Enterprise Architect
Path 1
DEV110 Principles of Modeling 2 hours DEV111 Principles of UC Modeling with UML 2 hours DEV112 Principles of Analysis I 2 hours DEV113 Principles of Analysis II 2 hours
OR Path 2
DEV275 Essentials of Visual Modeling with UML 1 day DEV475 Mastering Object Oriented Analysis & Design with UML 4 days
0-8


Curriculum Flow: System Analyst
REQ310 Essentials of Rational RequisitePro REQ480 Management with Use Cases 3 days 5 hours DEV110 Principles of Modeling 2 hours
OR
REQ370 Essentials of Rational RequisitePro 1 day
OR
DEV275 Essentials of Visual Modeling with UML 1 day

0-9
Course Materials
Course Materials
Student Manual, Books 1, 2, and 3 Additional Information Appendix Exercise Workbook Payroll Exercise Solution
10
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.
0 - 10

Other Sources of Information
Other Sources of Information

Rational Unified Process
http://www.ibm.com/developerworks/rational/pro ducts/rup
Rational Web Site

http://www.ibm.com/software/rational/
Rational developerWorks
http://www.ibm.com/developerworks/
Rational Developer Domain

http://www.ibm.com/developerworks/rational/
11
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 IBMs resource for developers.

0 - 11
Logistics
Logistics
Morning 2-Fifteen-minute breaks Lunch 1 Hour Afternoon 2-Fifteen-minute breaks
12
0 - 12

Module 1 Best Practices of Software Engineering
IBM Software Group
Mastering Object-Oriented Analysis and Design with UML 2.0 Module 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

1-1
Mastering Object-Oriented Design and Analysis
Objectives: Best Practices
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.
1-2

Module 1 - Best Practices of Software Engineering
Symptoms of Software Development Problems
Symptoms of Software Development Problems

9 User or business needs not met 9 Requirements not addressed 9 Modules not integrating 9 Difficulties with maintenance 9 Late discovery of flaws 9 Poor quality of end-user experience 9 Poor performance under load 9 No coordinated team effort 9 Build-and-release issues
3

1-3
Trace Symptoms to Root Causes
Trace Symptoms to Root Causes

Symptoms
Needs not met Requirements churn Modules do notfit fit dont Hard to maintain Late discovery Poor quality Poor performance Colliding developers Build-and-release
Root Causes
Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Undetected inconsistencies Poor testing Subjective assessment Waterfall development Uncontrolled change Insufficient automation
Best Practices
Develop Iteratively Manage Requirements Use Component Architectures Model Visually Visually (UML) (UML) Model Continuously Verify Verify Quality Quality Continuously Manage Change
By treating these root causes, you will eliminate the symptoms. By eliminating the symptoms, youll 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.
1-4

Best Practices Reinforce Each Other
Best Practices Reinforce Each Other

Best Practices
Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
5
Ensures users are involved as requirements evolve Validates architectural decisions early on Addresses complexity of design/implementation incrementally Measures quality early and often Evolves baselines incrementally
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.

1-5
Practice 1: Develop Iteratively Develop Iteratively

Iterative development produces an executable
3. Requirements 1. Initial Planning 2. Planning Management Environment (on-going) 8. Evaluation 7. Deployment
Each iteration results in an executable release
4. Analysis & Design 5. Implementation 6. Test
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 projects 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.
1-6

Practice 2: Manage Requirements Managing Requirements

Ensures that you solve the right problem build the right system by taking a systematic approach to eliciting 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

1-7
Practice 3: Use Component Architectures Use Component Architectures

Software architecture needs to be:
Component-based
Reuse or customize components Select from commercially available components Evolve existing software incrementally
Resilient
Meets current and future requirements Improves extensibility Enables reuse Encapsulates system dependencies
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 systems 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).
1-8

Purpose of a Component-Based Architecture
Purpose of a Component-Based Architecture

Basis for reuse
Component reuse Architecture reuse
Component-based architecture with layers
Basis for project management

Planning Staffing Delivery
Applicationspecific Businessspecific Middleware Systemsoftware
Intellectual control
Manage complexity Maintain integrity
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.

1-9
Practice 4: Model Visually Model Visually (UML)

Captures structure and behavior Shows how system elements fit together Keeps design and implementation consistent Hides or exposes details as appropriate Promotes unambiguous communication
The UML provides one language for all practitioners.
10
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 teams ability to manage software complexity.
1 - 10

Visual Modeling with the Unified Modeling Language

Visual Modeling with the Unified Modeling Language
Multiple views Precise syntax and semantics
Use-Case Diagrams Class Diagrams Object Diagrams
Static Diagrams
Sequence Diagrams
Communication Diagrams
Models
Component Diagrams
Dynamic Diagrams
State Machine Diagrams
Activity Diagrams
11
Deployment 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.

1 - 11
Practice 5: Continuously Verify Quality Continuously Verify Quality

Software problems are 100 to 1000 times more costly to find and repair after deployment
Cost to Repair Software

Cost
Cost of Lost Opportunities Cost of Lost Customers
Inception
Elaboration
12
Construction
Transition
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.
1 - 12

Testing Dimensions of Quality
Testing Dimensions of Quality

Usability
Test application from the perspective of convenience to the end user.
Functionality
Test the accurate workings of each usage scenario.
Reliability
Test that the application behaves consistently and predictably.
Supportability
Test the ability to maintain and support the application under production use.
13
Performance
Test the online response under average and peak loading.
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 users 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.

1 - 13
Practice 6: Manage Change Manage Change

To avoid confusion, have:
Secure workspaces for each developer Automated integration/build management Parallel development
Workspace Management
Configuration Management is more than just check-in and check-out
Process Integration Build Management
Parallel Development
14
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.
1 - 14

Manage Change (continued)
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
15
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.

1 - 15
Rational Unified Process Implements Best Practices
Rational Unified Process Implements Best Practices
Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
Best Practices
16
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 todays 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.
1 - 16

Achieving Best Practices
Achieving Best Practices

Iterative approach Guidance for activities and artifacts Process focus on architecture Use cases that drive design and implementation Models that abstract the system
17
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.

1 - 17
A Team-Based Definition of Process
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 changed requirements
Software Engineering Process
New or changed system
18
1 - 18

Process Structure - Lifecycle Phases
Process Structure - Lifecycle Phases

The Rational Unified Process has four phases:
Inception Define the scope of the project Elaboration Plan the project; specify features and baseline architecture Construction Build the product Transition Transition the product into the end-user community
Inception Elaboration Time Construction Transition
19
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.

1 - 19
Bringing It All Together: The Iterative Approach
Bringing It All Together: The Iterative Approach

In an iteration, you walk through all disciplines.
Disciplines group activities logically.

20
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.
1 - 20

Summary
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.
21

1 - 21
1 - 22

Module 2 Concepts of Object Orientation
IBM Software Group
Mastering Object-Oriented Analysis and Design with UML 2.0 Module 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

2-1
Objectives: Concepts of Object Orientation
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
2-2

Module 2 - Concepts of Object Orientation
Review: Why Model?
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.
3
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 youve made. Models are valuable tools in the long term because they give hard information on design decisions. You dont need to rely on someones memory.

2-3
Four Principles of Modeling 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.
2-4

Review: Basic Principles of Object Orientation
Review: Basic Principles of Object Orientation
Object Orientation
Encapsulation
Abstraction
Modularity
There are four basic principles of object orientation. They are: Abstraction Encapsulation Modularity Hierarchy

Hierarchy
2-5
Review: Example: Abstraction
Review: Example: Abstraction
Student
Professor
Course Offering (9:00 AM, Monday-Wednesday-Friday)

6
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.
2-6

Review: Encapsulation Illustrated
Review: Encapsulation Illustrated

Professor Clark needs to be able to teach four classes in the next semester.
Su bm
Professor Clark
Ac ce pt Co ur se Of
alG ra de s( )
i tF
in
fer
Name: J Clark Employee ID: 567138 HireDate: 07/25/1991 Status: Tenured Discipline: Finance MaxLoad: 4
ing ()
tM Se
SetMaxLoad(4)
d() oa axL
7
TakeSabbatical()
The key to encapsulation is an objects 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 objects 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.

2-7
Review: Example: Modularity
Review: Example: Modularity

For example, break complex systems into smaller modules.
Billing System
Course Catalog System Course Registration 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
2-8

Review: Example: Hierarchy
Review: Example: Hierarchy

Increasing abstraction Asset
BankAccount
Security
RealEstate
Decreasing abstraction
Savings
Checking
Stock
Bond
Elements at the same level of the hierarchy should be at the same level of abstraction.
9
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.

2-9
Review: What Is an Object?
Review: What Is an Object?

An object is 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, methods, and state machines.
Operations Attributes
Object
10
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 objects state. Operations represent the behavior of the object. Object behavior and state are discussed in the next few slides.
2 - 10

Review: What Is a Class?
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()
11
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 classs 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.

2 - 11
Representing Classes in the UML Review: Representing Classes in the UML

A class is represented using a rectangle with compartments.
Professor
- name - employeeID : UniqueID - hireDate - status - discipline - maxLoad + submitFinalGrade() + acceptCourseOffering() + setMaxLoad() + takeSabbatical() + teachClass()
Professor J Clark
12
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.
2 - 12

Review: The Relationship Between Classes and Objects

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 Torpie
Professor
Professor Meijer
Professor Allen
13
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 realworld 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.

2 - 13
Class Relationships Review: Class Relationships

The semantic connection between classes
~ Grady Booch
Class diagrams may contain the following relationships:

Association Aggregation Composition Generalization Dependency Realization
14
OR OR OR
The next several slides will explain and define each of these relationships.
2 - 14

What Is Navigability?
What Is Navigability?
Indicates that it is possible to navigate from a associating class to the target class using the association
RegistrationController
Schedule
CourseOffering
15
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.

2 - 15
Review: What Is an Association?

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
Student
Schedule
Course
16
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.
2 - 16

Review: What Is Multiplicity?
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
+ instructor 0..1 0..*
CourseOffering
17
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.

2 - 17
Review: Multiplicity Indicators
Review: Multiplicity Indicators

Unspecified Exactly One Zero or More Zero or More One or More Zero or One (optional scalar role) Specified Range Multiple, Disjoint Ranges
18
1 0..* * 1..* 0..1 2..4 2, 4..6
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.
2 - 18

Review: What Is Aggregation?

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.

Student 1 0..1 Schedule
19
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.

2 - 19
What Is 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. It is shown by a diamond filled adornment on the opposite end.
Student 1 0..* Schedule
20
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
2 - 20

What is a Structured Class? What is a Structured Class?

A structured class contains parts or roles that form its structure and realize its behavior
Describes the internal implementation structure
The 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
21
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.

2 - 21
Structured Class Notation
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.
connector
partA : CompositionPart
parts
22
partB : SharedPart
2 - 22

Class Diagram versus Structure Diagram
Class Diagram versus Structure Diagram

Class Diagram Structure Diagram
Student
Student
shared : Schedule [0..*]
shared
0..*
0..*
comp
Schedule
Schedule
comp : Schedule [0..*]
23

2 - 23
Example: Structure Diagram
Example: Structure Diagram

Course Registration System
: StudentManagementSystem
: BillingSystem
: CourseCatalogSystem
24
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.
2 - 24

Review: What Is Generalization?
Review: What Is Generalization?

A relationship among classes where one class shares the structure and/or behavior of one or more classes Defines a hierarchy of abstractions in which a subclass inherits from one or more superclasses
Single inheritance Multiple inheritance
Is an is a kind of relationship
25
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).

2 - 25
Relationships: Dependency
Relationships: Dependency
A relationship between two model elements where a change in one may cause a change in the other Non-structural, using relationship Dependency
relationship
Class
Client
Supplier Dependency relationship
Component
The <<use>> stereotype is implicit and does not need to be shown.
Client
Supplier Dependency relationship
Package
ClientPackage
SupplierPackage
26
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.
2 - 26

Relationships: Realization
Relationships: Realization
One classifier serves as the contract that the other classifier agrees to carry out, found between:
Interfaces and the classifiers that realize them
Component
InterfaceName
<<interface>>
Class
<<interface>>
InterfaceName
<<interface>>
<<subsystem>>
Subsystem
InterfaceName
Use cases and the collaborations that realize them

Collaboration UseCase
27
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.

2 - 27
Review: What Is Polymorphism?

The ability to hide many different implementations behind a single interface
Manufacturer A
Manufacturer B
Manufacturer C
OO Principle: Encapsulation
Remote Control
28
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.
2 - 28

What Is an Interface? 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.
29
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.

2 - 29
Example: A Provided Interface
Example: A Provided Interface

Elided/Iconic Representation (ball)
Remote Sensor Manufacturer A
Manufacturer B
Manufacturer C
Canonical (Class/Stereotype) Representation
Manufacturer A <<interface>> RemoteSensor
Manufacturer B
Manufacturer C
30
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: Elide: to pass over; omit; ignore. Canonical: authorized; recognized; accepted.
2 - 30

Example: A Required Interface
Example: A Required Interface

Remote Control
Remote Sensor
Elided/Iconic Representation (socket)
<<interface>>
Remote Control
Remote Sensor
Canonical (Class/Stereotype) Representation
31

2 - 31
Example: Connecting Interfaces
Example: Connecting Interfaces

Manufacturer A
Remote Control
Remote Sensor
Manufacturer B
Manufacturer C
Manufacturer A <<interface>> RemoteSensor
Remote Control
Manufacturer B
Manufacturer C
32
2 - 32

What is a Port? 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 internals
A class may have a number of ports

Each port has a set of provided and required interfaces
33
Since the port is a structural element, its 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.

2 - 33
Port Notation
Port Notation
A port is shown as a small square with the name placed nearby.
portName
Ports may be public, protected or private

34
2 - 34

Port Types
Port Types
Ports can have different implementation types
Service Port - Is only used for the internal implementation of the class Behavior Port - Requests on the port are implemented directly by the class Relay Port Requests on the port are transmitted to internal parts for implementation
35
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.

2 - 35
Example: Structure Diagram with Ports
Example: Structure Diagram with Ports

Structured Class Name
Behavior Port
Service Port Relay Port
partA
partB
36
2 - 36

Review: Diagram Depiction
Review: Diagram Depiction

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.
<heading>
<contents area>
37
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

2 - 37
What Are Notes?
What Are Notes?

A comment that is added to include more information on the diagram May be added to any UML element A dog eared rectangle May be anchored to an element with a dashed line
There can be up to one MaintainScheduleForm per user session.
MaintainScheduleForm
38
2 - 38

Review 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?
39

2 - 39
2 - 40

Module 3 Requirements Overview
IBM Software Group
Mastering Object-Oriented Analysis and Design with UML 2.0 Module 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

3-1
Objectives: Requirements Overview
Objectives: Requirements Overview

Describe the basic Requirements concepts and how they affect Analysis and Design Demonstrate 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.
3-2

Module 3 - Requirements Overview
Requirements Overview Topics

Introduction Key Concepts Use-Case Model Glossary Supplementary Specifications Checkpoints
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.

3-3
Requirements in Context
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.
3-4

Relevant Requirements Artifacts
Relevant Requirements Artifacts

Use-Case Model
Glossary Actors Use Cases
...
Use-Case Specifications
5
Supplementary Specification
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 UseCase 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.

3-5
Case Study: Course Registration Problem Statement
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.
3-6


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.

3-7
What Is System Behavior? 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.
3-8

Major Concepts in Use-Case Modeling
Major Concepts in Use-Case Modeling

An actor represents anything that interacts with the system.
Actor
A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor.
Use Case
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.

3-9

10
3 - 10

Review: What Is a Use-Case Model?
Review: What Is a Use-Case Model?

A model that describes a systems functional requirements in terms of use cases A model of the systems intended functionality (use cases) and its environment (actors)
View Report Card
Register for Courses Student Login
11
A Use-Case Model describes a systems 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, its 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.

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

Review: What Are the Benefits of a Use-Case Model? Communication Identification Verification
Use Case
Identification Verification
Communication
End User
Domain Expert
Users
12
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. Establishes the requirements for the system interfaces. Ensures that the development team understands the requirements.
Identification of system users and what the system should do: Verification that all requirements have been captured: 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.
3 - 12

Review: How Would You Read This Diagram?
Review: How Would You Read This Diagram?

View Report Card
Course Catalog
Register for Courses
Maintain Professor Information
Student
Login Maintain Student Information
Registrar
Select Courses to Teach Close Registration
Professor
Submit Grades
Billing System
13
Answer the following questions: 1. 2. 3. 4. Which use cases can a student perform? A professor? The Course Catalog? If Charlie is a student and professor, which use cases can he execute? Describe the functionality of this system. 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?

3 - 13
Use-Case Specifications Use-Case Specifications

Name Brief description Flow of Events Relationships Activity diagrams Use-Case diagrams Special requirements Pre-conditions Post-conditions Other diagrams
14
Use-Case Model
Actors Use Cases
...
Use-Case Specifications
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.
3 - 14

Use-Case Flow of Events
Use-Case Flow of Events

Has one normal, basic flow Several alternative flows
Regular variants Odd cases Exceptional flows for handling error situations
15
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. 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."
Guidelines for the flow of events. Specify that the content must:

3 - 15
What Is a Scenario?
What Is a Scenario?
A scenario is an instance of a use case.
16
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.
3 - 16

What Is an Activity Diagram? 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.
Activity2
Activity1
Activity3
17
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.

3 - 17
Example: Activity Diagram
Example: Activity Diagram

Concurrent Threads
Select Course
Decision
[ delete course ]
Activity/Action
Delete Course
[ add course ]
Synchronization Bar (Fork) Guard Condition

Check Schedule Check Pre-requisites
[ checks completed ]
[ checks failed ]
Synchronization Bar (Join) Transition
Assign to Course Update Schedule
Resolve Conflicts
18
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.
3 - 18

Partitions
Partitions
Sales Fulfillment
Determine Need
Take Order
Fill Order Setup Payment
Deliver Order
19
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.

3 - 19

20
3 - 20

Glossary Glossary
Course Registration System Glossary
1. 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.
Glossary
21
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. Copyright IBM Corp. 2004
3 - 21
Case Study: Glossary
Case Study: Glossary

Review the Glossary provided in the Course Registration Requirements Document
Glossary
22
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.
3 - 22


23

3 - 23
Supplementary Specification Supplementary Specification

Functionality Usability Reliability Performance Supportability Design constraints
24
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.
3 - 24

Example: Supplementary Specification
Example: Supplementary Specification

Review the Supplementary Specification provided in the Course Registration Requirements Document.
Course Registration Requirements Document
25
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.

3 - 25

26
3 - 26

Checkpoints: Requirements: Use-Case Model
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?
27
...
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.

3 - 27
Checkpoints: Requirements: Actors
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?
28
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.
3 - 28

Checkpoints: Requirements: Use-Cases
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?
29
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.

3 - 29
Checkpoints: Requirements: Use-Case Specifications
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?
30
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.
3 - 30

Checkpoints: Requirements: Glossary
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?
31
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.

3 - 31
Review 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?
32
3 - 32

Exercise: Payroll Requirements Document
Exercise: Payroll Requirements Document

Given the following Payroll Requirements artifacts:
Problem statement Glossary Supplementary Specification Use-Case Model main diagram
Review the given Requirements artifacts, noting any questions, issues, inconsistencies.
33
This exercise is based on the Payroll Requirements document, which is found in the Exercise Workbook. See the workbooks 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.

3 - 33
3 - 34

Module 4 Analysis and Design Overview
IBM Software Group
Mastering Object-Oriented Analysis and Design with UML 2.0 Module 4: Analysis and Design Overview
Topics
Analysis Versus Design.......................................................................................... 4-6 Analysis and Design Workflow............................................................................ 4-12 Review............................................................................................................... 4-19

4-1
Objectives: Analysis and Design Overview
Objectives: Analysis and Design Overview

Review the key Analysis and Design terms and concepts Introduce the Analysis and Design process, including roles, artifacts and workflow Explain 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.
4-2

Module 4 - Analysis and Design Overview
Analysis and Design in Context
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 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).
The Analysis and Design Discipline is related to other process disciplines.

4-3
Analysis and Design Overview
Analysis and Design Overview
Use-Case Model
Analysis and Design
Design Model
Glossary
Architecture Document Supplementary Specification Data Model

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

Analysis & Design Overview Topics

Key Concepts Analysis 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.

4-5
Analysis Versus Design Analysis Versus Design

Analysis
Focus on understanding the problem Idealized design Behavior System structure Functional requirements A small model
Design
Focus on understanding the solution Operations and attributes Performance Close to real code Object lifecycles Nonfunctional requirements A large model
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.
4-6

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

Analysis and Design Are Not Top-Down or Bottom-Up
Analysis and Design
Top Down
Subsystems
Use Cases
Analysis Classes
Bottom Up
(Define a middle level)
Design Classes
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 topdown question cannot be solved.

4-7
What Is Architecture?
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 composed Behavior as specified in collaborations among those elements Composition of these structural and behavioral elements into larger subsystems Architectural style that guides this organization
Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational (derived from Mary Shaw)
8
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.
4-8

Architecture Constrains Design and Implementation
Architecture Constrains Design and Implementation

Architecture involves a set of strategic design decisions, rules or patterns that constrain design and construction.
Code Implementation Design Architecture
Architecture decisions are the most fundamental decisions, and changing them will have significant effects.
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 architects 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).

4-9
Software Architecture: The 4+1 View Model
Software Architecture: The 4+1 View Model
Logical View
Analysts/Designers
Structure
Implementation View
Programmers
Software management
Use-Case View
End-user Functionality
Process View
Deployment View
System engineering
System integrators
Performance, scalability, throughput
System topology, delivery, installation, communication
10
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.
4 - 10


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

4 - 11
Analysis and Design Workflow Analysis and Design Workflow

[Early Elaboration Iteration] [Inception Iteration (Optional)]
Define a Candidate Architecture
Perform Architectural Synthesis
Analysis
Analyze Behavior
(Optional) Refine the Architecture
Design
Design Components
Design the Database
12
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.
4 - 12

Analysis and Design Activity Overview
Analysis and Design Activity Overview
Architect
Designer
13
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.

4 - 13
Software Architects Responsibilities
Software Architects Responsibilities

The Software Architect leads and coordinates technical activities and artifacts.
Analysis Model Architect
Design Model
Implementation Model
Deployment Model
14
Reference Architecture
Software Architecture Document
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.
4 - 14

Designers Responsibilities
Designers Responsibilities
The designer must know usecase modeling techniques, system requirements, and software design techniques.
Designer
Use-Case Realization
Package
Class/Subsystems
15
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 Understand the architecture of the system, as represented in the Software Architecture Document.
In addition, the designer must:

4 - 15
Review: Analysis and Design Is Use-Case Driven
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.
Check Balance
Customer
Withdraw Money
16
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 users 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.
4 - 16

What Is a Use-Case Realization?
What Is a Use-Case Realization?

Use-Case Model Design Model
Use Case
Sequence Diagrams
Use Case
Class Diagrams
17
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 UseCase 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.

4 - 17
Analysis and Design in an Iterative Process
Analysis and Design in an Iterative Process

Start of iteration
Use Case A Scenarios 1 & 2
Use Case B Scenario 1
Use Case A Scenario 3
Use-Case Realization A Use-Case Realization A

End of iteration
Use-Case Realization B Iteration n + 1

18
Iteration n
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 usecase realization that describes how a particular use case will be realized.
4 - 18

Review 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?
19

4 - 19
4 - 20

Module 5 Architectural Analysis
IBM Software Group
Mastering Object-Oriented Analysis and Design with UML 2.0 Module 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

5-1
Objectives: Architectural Analysis
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 relationships Key abstractions Analysis 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.
5-2

Module 5 - Architectural Analysis
Architectural Analysis in Context
Architectural Analysis in Context

[Early Elaboration Iteration] [Inception Iteration (Optional)] Architecture Analysis
Architect
Analyze Behavior (Optional)
Refine the Architecture
Design Components
Design the Database
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 projects 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.

5-3
Architectural Analysis Overview Architectural Analysis Overview
Glossary
Software Architecture Doc
Reference Architecture
Vision Document
Architectural Analysis Project-Specific Guidelines Design Model
Use-Case Model
4
Deployment Model
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. Use-Case Model Supplementary Specifications Glossary Design Model Reference Architecture Vision Document Project Specific Guidelines Software Architecture Document Software Architecture Document Design Model Deployment Model
Input Artifacts:
Resulting Artifacts:
5-4

Architectural Analysis Steps

Key Concepts Define the High-Level Organization of the model Identify Analysis mechanisms Identify Key Abstractions Create Use-Case Realizations Checkpoints
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.

5-5
Review: What Is Architecture: The 4+1 View Model
Review: What Is Architecture: The 4+1 View Model
Logical View
Analysts/Designers
Structure
Implementation View
Programmers
Software management
Use-Case View
Process View
Deployment View
System engineering
System integrators
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.
5-6

Review: What Is a Package?
Review: What Is a Package?

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

To organize the model under development. As a unit of configuration management.
7
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.

5-7
Package Relationships: Dependency Package Relationships: Dependency

Packages can be related to one another using a dependency relationship.
Dependency relationship
Client Package
Supplier Package
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.
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.
5-8

Avoiding Circular Dependencies
Avoiding Circular Dependencies

A A Hierarchy should be acyclic
B A
C B A' C
Circular dependencies make it impossible to reuse one package without the other.
9
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.

5-9

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.
5 - 10

Patterns and Frameworks Patterns and Frameworks

Pattern
Provides a common solution to a common problem in a context
Analysis/Design pattern
Provides a solution to a narrowly-scoped technical problem Provides a fragment of a solution, or a piece of the puzzle
Framework
Defines the general approach to solving the problem Provides a skeletal solution, whose details may be Analysis/Design patterns
11
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 elses. 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.

5 - 11
What Is a Design Pattern?
What Is a Design Pattern?

A design pattern is a solution to a common design problem.
Describes a common design problem Describes the solution to the problem Discusses the results and trade-offs of applying the pattern
Design patterns provide the capability to reuse successful designs.

Template Parameters
Pattern Name
Parameterized Collaboration
Structural Aspect
12
Behavioral Aspect
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.
5 - 12

What Is an Architectural Pattern?
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 Layers Model-view-controller (M-V-C) Pipes and filters Blackboard
13
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.

5 - 13
Typical Layering Approach
Typical Layering Approach

Specific functionality
Application
Distinct application subsystems that make up an application contains the value adding software developed by the organization.
Business-Specific
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.
Middleware
General functionality
System Software
14
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 interoperating 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. 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.
This slide shows a sample architecture with four layers:
5 - 14

Example: Layers
Example: Layers
Application Presentation Session Transport Network Data Link Physical
Layer 7
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.
Layer 6
Layer 5
Layer 4
Layer 3
Layer 2
Layer 1
15
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.

5 - 15
Layering Considerations
Layering Considerations
Level of abstraction
Group elements at the same level of abstraction
Separation of concerns
Group like things together Separate disparate things Application vs. domain model elements
Resiliency
Loose coupling Concentrate on encapsulating change User interface, business rules, and retained data tend to have a high potential for change
16
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.
5 - 16

Modeling Architectural Layers
Modeling Architectural Layers

Architectural layers can be modeled using stereotyped packages. <<layer>> stereotype
<<layer>>
Package Name
17
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.

5 - 17
What Are Stereotypes? 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.
<<stereotypename>>
Stereotype
Class
18
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.
5 - 18

Example: High-Level Organization of the Model
Example: High-Level Organization of the Model

<<layer>>
Application
<<layer>>
Business Services
19
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 businessspecific elements that are used in several applications, not necessarily just this one.

5 - 19

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.
5 - 20

What Are Architectural Mechanisms?
What Are Architectural Mechanisms?

Required Functionality
realized by client classes using
Implementation Environment
constrained by
Mechanisms
responsible for
COTS Products Databases IPC Technology, etc.
Use-Case Model
Architect
21
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.

5 - 21
Architectural Mechanisms: Three Categories Architectural Mechanisms: Three Categories

Architectural Mechanism Categories
Analysis mechanisms (conceptual) Design mechanisms (concrete) Implementation mechanisms (actual)
22
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 domainrelated 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.
5 - 22

Why Use Analysis Mechanisms?
Why Use Analysis Mechanisms?

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.
Oh no! I found a group of classes that has persistent data. How am I supposed to design these things if I dont even know what database we are going to be using?
That is why we have a persistence analysis mechanism. We dont know enough yet, so we can bookmark it and come back to it later.
23
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. Copyright IBM Corp. 2004
5 - 23
Sample Analysis Mechanisms
Sample Analysis Mechanisms

Persistency Communication (IPC and RPC) Message routing Distribution Transaction management Process control and synchronization (resource contention) Information exchange, format conversion Security Error detection / handling / reporting Redundancy Legacy Interface
24
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.
5 - 24

Examples of Analysis Mechanism Characteristics
Examples of Analysis Mechanism Characteristics

Persistency mechanism
Granularity Volume Duration Access mechanism Access frequency (creation/deletion, update, read) Reliability Latency Synchronicity Message size Protocol
25
Inter-process Communication mechanism
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.

5 - 25
Example: Analysis Mechanism Characteristics (continued)

Example: Analysis Mechanism Characteristics (continued)
Legacy interface mechanism
Latency Duration Access mechanism Access frequency Data granularity User granularity Security rules Privilege types
Security mechanism
Others
26
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
5 - 26

Describing Analysis Mechanisms

Collect all analysis mechanisms in a list Draw a map of classes to analysis mechanisms Identify characteristics of analysis mechanisms Model using collaborations
Classes
Flight Persistency
Analysis Mechanisms
Aircraft
Mission
Communication
Schedule Parsing Route Authentication Load
27
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.

5 - 27
Example: Course Registration Analysis Mechanisms
Example: Course Registration Analysis Mechanisms

Persistence Distribution
Security
Legacy Interface
28
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.
5 - 28


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.

5 - 29
What Are Key Abstractions? What Are Key Abstractions?

A key abstraction is a concept, normally uncovered in Requirements, that the system must be able to handle Sources for key abstractions
Domain knowledge Requirements Glossary Domain Model, or the Business Model (if one exists)
30
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.
5 - 30

Defining Key Abstractions
Defining Key Abstractions

Define analysis classes Model analysis classes and relationships on class diagrams
Include a brief description of an analysis class
Map analysis classes to necessary analysis mechanisms
31
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.

5 - 31
Example: Key Abstractions
Example: Key Abstractions

Professor Student
Schedule
CourseCatalog
CourseOffering
Course
32
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.
5 - 32


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

5 - 33
Review: What is a Use-Case Realization?
Review: What is a Use-Case Realization?

Use Case
Sequence Diagrams
Use Case
Class Diagrams
34
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 UseCase 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.
5 - 34

The Value of Use-Case Realizations The Value of Use-Case Realizations

Provides traceability from Analysis and Design back to Requirements The Architect creates the Use-Case Realization
Requirements (Use-Case Model) Analysis & Design (Design Model)
Use Case
Use-Case realization
35
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.

5 - 35

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.)
5 - 36

Checkpoints
Checkpoints
General
Is the package partitioning and layering done in a logically consistent way? Have the necessary analysis mechanisms been identified?
Packages
Have we provided a comprehensive picture of the services of the packages in upper-level layers?
37
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, UseCase Analysis.

5 - 37
Checkpoints (continued)
Classes
Have 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.?
38
A well-structured class provides a crisp abstraction of something drawn from the vocabulary of the problem domain or the solution domain.
5 - 38

Review 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?
39

5 - 39
Exercise: Architectural Analysis
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
40
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.
5 - 40

Exercise: Architectural Analysis (continued)

Identify the following:
The key abstractions
41
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

5 - 41

Produce the following:
Class diagram containing the key abstractions Class diagram containing the upper-level architectural layers and their dependencies
42
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
5 - 42

Exercise: Review
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?
43

5 - 43
5 - 44

Module 6 Use-Case Analysis
IBM Software Group
Mastering Object-Oriented Analysis and Design with UML 2.0 Module 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

6-1
Objectives: Use-Case Analysis
Objectives: Use-Case Analysis

Explain the purpose of Use-Case Analysis and where in the lifecycle it is performed Identify the classes which perform a usecase flow of events Distribute the use-case behavior to those classes, identifying responsibilities of the classes Develop Use-Case Realizations that model the collaborations between instances of the identified classes
2
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.
6-2

Module 6 - Use-Case Analysis
Use-Case Analysis in Context
Use-Case Analysis in Context

Analyze Behavior
Designer
Use-Case Analysis
(Optional)
Design Components
Design the Database
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.

6-3
Use-Case Analysis Overview Use-Case Analysis Overview
Glossary
Project Specific Guidelines
Supplementary Specifications
Use-Case Analysis
Analysis Model
Use-Case Model
4
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 UseCase Analysis in Architectural Analysis. Purpose To identify the classes that perform a use cases 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.
6-4

Use-Case Analysis Steps

Supplement the Use-Case Description For each Use-Case Realization
Find Classes from Use-Case Behavior Distribute Use-Case Behavior to Classes
For each resulting analysis class

Describe Responsibilities Describe Attributes and Associations Qualify Analysis Mechanisms
Unify Analysis Classes Checkpoints

5
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 usecase 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-5



6
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 wellunderstood. In those cases, the original use-case flow of events should be updated (for example, iterate back to the Requirements discipline).
6-6

Supplement the Use-Case Description
Supplement the Use-Case Description
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.
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 actors 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.

6-7
Use-Case Analysis Steps Use-Case Analysis Steps



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.
6-8

Review: Class
Review: Class
An abstraction Describes a group of objects with common:
Properties (attributes) Behavior (operations) Relationships Semantics Class Name
Attributes Operations
Professor name ProfessorId : 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. The first section contains the class name. The second section shows the structure (attributes). The third section shows the behavior (operations).
A class is comprised of three sections:

6-9
Review: Use-Case Realization

Use Case
Sequence Diagrams
Use Case
Class Diagrams
10
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 UseCase 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 classs 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.
6 - 10

Analysis Classes: A First Step Toward Executables
Analysis Classes: A First Step Toward Executables
Use Cases
Analysis Classes
Design Elements
Source Code
Exec
Use-Case Analysis
11
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.

6 - 11
Find Classes from Use-Case Behavior Find Classes from Use-Case Behavior
The complete behavior of a use case has to be distributed to analysis classes
12
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.
6 - 12

What Is an Analysis Class?
What Is an Analysis Class?

<<boundary>> System boundary <<control>> Use-case behavior coordination <<entity>> System information
<<boundary>> System boundary <<entity>> System information
13
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.

6 - 13
What Is a Boundary Class?
What Is a Boundary Class?

Intermediates between the interface and something outside the system Several Types
User interface classes System interface classes Device interface classes
One boundary class per actor/use-case pair

Analysis class stereotype
Environment dependent.
14
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 classesClasses that intermediate communication with human users of the system. System interface classesClasses 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 classesClasses 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.
6 - 14

The Role of a Boundary Class
The Role of a Boundary Class
<<control>> Actor 1 <<boundary>> <<boundary>> Actor 2
<<entity>>
<<entity>>
Model interaction between the system and its environment.

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

6 - 15
Example: Finding Boundary Classes
Example: Finding Boundary Classes

One boundary class per actor/use case pair
Student
Course Catalog
RegisterForCoursesForm
CourseCatalogSystem
16
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.
6 - 16

Guidelines: Boundary Class
Guidelines: Boundary Class

User Interface Classes
Concentrate on what information is presented to the user Do NOT concentrate on the UI details
System and Device Interface Classes

Concentrate on what protocols must be defined Do NOT concentrate on how the protocols will be implemented
Concentrate on the responsibilities, not the details!

17
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 userinterface 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.

6 - 17
What Is an Entity Class?
What Is an Entity Class?

Key abstractions of the system
Use Case Business-Domain Model
Architectural Analysis Abstractions
Glossary
Environment independent.
18
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.
6 - 18

The Role of an Entity Class
The Role of an Entity Class
<<entity>>
<<entity>>
Store and manage information in the system.

19
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).

6 - 19
Example: Finding Entity Classes
Example: Finding Entity Classes

Use use-case flow of events as input Key abstractions of the use case Traditional, filtering nouns approach
Underline noun clauses in the use-case flow of events Remove redundant candidates Remove vague candidates Remove actors (out of scope) Remove implementation constructs Remove attributes (save for later) Remove operations
20
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.
6 - 20

Example: Candidate Entity Classes
Example: Candidate Entity Classes

Register for Courses (Create Schedule)
CourseOffering
Schedule
Student
21
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.

6 - 21
What Is a Control Class?
What Is a Control Class?

Use-case behavior coordinator
More complex use cases generally require one or more control cases
Use Case
Use-case dependent. Environment independent.

22
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.
6 - 22

The Role of a Control Class
The Role of a Control Class
<<entity>>
<<entity>>
Coordinate the use-case behavior.

23
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-casespecific 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 UseCase 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.

6 - 23
Example: Finding Control Classes
Example: Finding Control Classes

In general, identify one control class per use case.
As analysis continues, a complex use cases control class may evolve into more than one class
Student Register for Courses Course Catalog System
24
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.
6 - 24

Example: Summary: Analysis Classes
Example: Summary: Analysis Classes
Student
Course Catalog System
CourseCatalogSystem
Student
Schedule
CourseOffering
25
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.

6 - 25

Supplement the Use-Case Descriptions For each Use-Case Realization


26
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 UseCase 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
6 - 26

Distribute Use-Case Behavior to Classes Distribute Use-Case Behavior to Classes

For each use-case flow of events:
Identify analysis classes Allocate use-case responsibilities to analysis classes Model analysis class interactions in Interaction diagrams Use-Case Realization
Sequence Diagrams Use Case

27
Class Diagrams
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.

6 - 27
Guidelines: Allocating Responsibilities to Classes
Guidelines: Allocating Responsibilities to Classes

Use analysis class stereotypes as a guide
Boundary Classes Behavior that involves communication with an actor Entity Classes Behavior that involves the data encapsulated within the abstraction Control Classes Behavior specific to a use case or part of a very important flow of events
28
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).
6 - 28

Guidelines: Allocating Responsibilities to Classes (cont.)
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 data If 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
29
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.

6 - 29
The Anatomy of Sequence Diagrams
The Anatomy of Sequence Diagrams

Client Object
:Client
Supplier Object Message

:Supplier
Object Lifeline
1: PerformResponsibility
Reflexive Message
Execution Occurrence
Event Occurrence
1.1: PerformAnother Responsibility
Hierarchical Message Numbering

ref
Interaction Occurrence
30
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.
6 - 30

Example: Sequence Diagram
Example: Sequence Diagram

: Student : RegisterForCoursesForm : RegistrationController : CourseCatalogSystem : Course Catalog
1: // create schedule( ) 2: // get course offerings( ) Create a new schedule A list of the available course offerings for this semester are displayed A blank schedule is displayed for the students to select offerings 3: // get course offerings(forSemester) 4: // get course offerings( ) 5: // display course offerings( )
6: // display blank schedule( )
ref ref
Select Offerings Submit Schedule
31
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 RegistrationControllers 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.

6 - 31
The Anatomy of Communication Diagrams
The Anatomy of Communication Diagrams
Client Object
Link
Supplier Object
:Client PerformResponsibility
:Supplier
Message
32
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.
6 - 32

Example: Communication Diagram
Example: Communication Diagram

5: // display course offerings( ) 6: // display blank schedule( ) : Course Catalog 4: // get course offerings( )
: RegisterForCoursesForm : CourseCatalogSystem
2: // get course offerings( ) 3: // get course offerings(forSemester)
1: // create schedule( )
: RegistrationController
: Student
33
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.

6 - 33
One Interaction Diagram Is Not Good Enough
One Interaction Diagram Is Not Good Enough

Basic Flow Alternate Flow 1 Alternate Flow 2 Alternate Flow 3
AF3 AF1 AF2 Alternate Flow 4 Alternate Flow 5 Alternate Flow n
34
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). 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.
Examples of optional flows include the following:
You can use either Communication or Sequence diagrams.
6 - 34

Communication Diagrams vs. Sequence Diagrams
Communication Diagrams vs. Sequence Diagrams

Show relationships in addition to interactions Better for visualizing patterns of collaboration Better for visualizing all of the effects on a given object Easier to use for brainstorming sessions
Sequence Diagrams
Show the explicit sequence of messages Better for visualizing overall flow Better for real-time specifications and for complex scenarios
35
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 realtime 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.

6 - 35



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.
6 - 36

Describe Responsibilities Describe Responsibilities

What are responsibilities? How do I find them?
Interaction Diagram
:Client // PerformResponsibility :Supplier
Class Diagram
Supplier // PerformResponsibility
37
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 '//'.

6 - 37
Example: View of Participating Classes (VOPC) Class Diagram

Example: View of Participating Classes (VOPC) Class Diagram
<<boundary>> RegisterForCoursesForm // display course offerings() // display blank schedule() // create schedule()
<<control>> RegistrationController // get course offerings()
<<boundary>> CourseCatalogSystem // get course offerings()
38
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.
6 - 38

Maintaining Consistency: What to Look For
Maintaining Consistency: What to Look For

In order of criticality
Redundant responsibilities across classes Disjoint responsibilities within classes Class with one responsibility Class with no responsibilities Better distribution of behavior Class that interacts with many other classes
39
Examine classes to ensure they have consistent responsibilities. When a classs 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.

6 - 39



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.
6 - 40

Review: What Is an Attribute?
Review: What Is an Attribute?

<<stereotype>>
ClassName
Attribute : Type = InitValue Attribute : Type = InitValue Attribute : Type = InitValue
<<entity>> CourseOffering number : String = "100" startTime : Time endTime : Time days : Enum numStudents : Int
attribute
In analysis, do not spend time on attribute signatures.

41
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).

6 - 41
Finding Attributes
Finding Attributes
Properties/characteristics of identified classes Information retained by identified classes Nouns that did not become classes
Information whose value is the important thing Information that is uniquely "owned by an object Information that has no behavior
42
Sources of possible attributes: Domain knowledge Requirements Glossary Domain Model Business Model
Attributes are used instead of classes where: Only the value of the information, not it's location, is important The information is uniquely "owned" by the object to which it belongs; no other objects refer to the information. The information is accessed by operations that only get, set, or perform simple transformations on the information; the information has no "real" behavior other than providing its value. If, on the other hand, the information has complex behavior, or is shared by two or more objects, the information should be modeled as a separate class. Attributes are domain-dependent. (An object model for a system includes those characteristics that are relevant for the problem domain being modeled.) 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.
6 - 42


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
<<entity>> Student <<entity>> Schedule <<entity>> Course
43
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.

6 - 43
Finding Relationships
Finding Relationships
Communication Diagram
:Client PerformResponsibility :Supplier
Link Client Supplier
Class Diagram
Client
0..* 0..*
Supplier
PerformResponsibility()
Association
Relationship for every link!

44
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.
6 - 44


A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts
Whole/aggregate Part
<<entity>> Student
<<entity>> Schedule 0..*
0..2 CourseOffering
<<entity>>
0..*
45
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.

6 - 45
Association or Aggregation? Association or Aggregation?

If two objects are tightly bound by a whole-part relationship
The relationship is an aggregation.
Car Door
0..2,4
If two objects are usually considered as independent, although they are often linked
The relationship is an association.
Car Door
0..2,4
When in doubt, use association.

46
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.
6 - 46

What Are Roles? What Are Roles?

The face that a class plays in the association
<<entity>> CourseOffering Instructor <<entity>> Professor Department Head <<entity>> Department
Role Name
<<entity>> Course
Prerequisites
47
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.

6 - 47
What Does Multiplicity Mean?
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?
<<entity>> CourseOffering
0..*
<<entity>> Course
0..* Prerequisites 0..3
48
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.
6 - 48

Example: Multiple Associations
Example: Multiple Associations

primaryCourses
<<entity>> Schedule
alternateCourses
<<entity>> Schedule
add student to remove student from
Multiple associations must reflect multiple roles.

49
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 Students Schedule and the CourseOffering.

6 - 49
Example: VOPC: Finding Relationships
Example: VOPC: Finding Relationships

<<boundary>> RegisterForCoursesForm 1 1 0..1 <<control>> RegistrationController
currentSchedule <<entity>> Student 1 0..* <<entity>> Schedule 0..1 primaryCourses 0..* 0..4 <<entity>> CourseOffering
50
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.
6 - 50




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

6 - 51
Review: Why Use Analysis Mechanisms?
Review: Why Use Analysis Mechanisms?

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.
Oh no! I found a group of classes that has persistent data. How am I supposed to design these things if I dont even know what database we are going to be using?
That is why we have a persistence analysis mechanism. We dont know enough yet, so we can bookmark it and come back to it later.
52
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.
6 - 52


Collect all analysis mechanisms in a list Draw a map of the client classes to the analysis mechanisms Identify characteristics of the analysis mechanisms
53
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.

6 - 53
Example: Describing Analysis Mechanisms
Example: Describing Analysis Mechanisms

Analysis class to analysis mechanism map
Analysis Class Student Schedule CourseOffering Course RegistrationController Analysis Mechanism(s) Persistency, Security Persistency, Security Persistency, Legacy Interface Persistency, Legacy Interface Distribution
54
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.
6 - 54

Example: Describing Analysis Mechanisms (continued)

Example: Describing Analysis Mechanisms (continued) Analysis mechanism characteristics Persistency for Schedule class:
Granularity: 1 to 10 Kbytes per product Volume: up to 2,000 schedules Access frequency Create: 500 per day Read: 2,000 access per hour Update: 1,000 per day Delete: 50 per day Other characteristics
55
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.

6 - 55



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.
6 - 56

Unify Analysis Classes Unify Analysis Classes

RegisterFor CoursesForm Registration Controller Course Catalog System RegisterFor CoursesForm
Registration Controller
Student Course Offering Schedule
Student Course Offering Course Catalog System
CloseRegistration Form
Course Catalog System
Schedule CloseRegistration Controller

Billing System
Close Registration
Billing System
CloseRegistration Student Controller
Course Offering
Schedule
57
CloseRegistration 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.

6 - 57
Evaluate Your Results
Evaluate Your Results
Glossary
Design Model
Use-Case Model
Analysis Classes
58
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.
6 - 58




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

6 - 59
Checkpoints: Analysis Classes
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?
60
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.
6 - 60

Checkpoints: Use-Case Realizations
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?
61
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.

6 - 61
Review 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?
62
6 - 62

Exercise: Use-Case Analysis
Exercise: Use-Case Analysis

Use-Case Model, especially the use-case flows of events
Exercise Workbook: Payroll Requirements, Use-Case Model section
Key abstractions/classes
Payroll Exercise Solution, Architectural Analysis section
The Supplementary Specification

Exercise Workbook: Payroll Requirements, Supplementary Specification section
The possible analysis mechanisms

Exercise Workbook: Payroll Architecture Handbook, Architectural Mechanisms, Analysis Mechanisms section
63
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.

6 - 63
Exercise: Use-Case Analysis (continued)

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 case Analysis class attributes and relationships
64
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
6 - 64


Produce the following for a particular use case:
Use-Case Realization Interaction diagram for at least one of the usecase flows of events VOPC class diagram, containing the analysis classes, their stereotypes, responsibilities, attributes, and relationships Analysis class to analysis mechanism map
65
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. Refer to the following slides if needed: 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

6 - 65
Exercise: Review
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
66
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?
6 - 66



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
IBM Software Group
Mastering Object-Oriented Analysis and Design with UML 2.0 Module 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

7-1
Objectives: Identify Design Elements
Objectives: Identify Design Elements

Define the purpose of Identify Design Elements and demonstrate where in the lifecycle it is performed Analyze interactions of analysis classes and identify Design Model elements
Design classes Subsystems Subsystem 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.
7-2

Module 7 - Identify Design Elements
Identify Design Elements in Context
Identify Design Elements in Context

Analyze Behavior Identify Design Elements Architect (Optional)
Design Components
Design the Database
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.

7-3
Identify Design Elements Overview Identify Design Elements Overview
Identify Design Elements

Design Model
Analysis Model
4
The architect performs Identify Design Elements, once per iteration. Purpose To analyze interactions of analysis classes to identify Design Model elements Supplementary Specifications Project Specific Guidelines Software Architecture Document Analysis Classes Analysis Model Design Model Design Model elements Classes Packages Subsystems Input Artifacts
Resulting Artifacts
7-4

Identify Design Elements Steps

Identify classes and subsystems Identify subsystem interfaces Update the organization of the Design Model Checkpoints
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.

7-5

Identify classes and subsystems Identify subsystem interfaces Identify reuse opportunities Update the organization of the Design Model Checkpoints
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.
7-6

From Analysis Classes to Design Elements
From Analysis Classes to Design Elements

Analysis Classes
<<boundary>>
Design Elements
<<control>>
<<subsystem>>
Subsystem
<<entity>>
<<boundary>>
<<subsystem>>
Subsystem
Many-to-Many Mapping
7
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.

7-7
Identifying Design Classes Identifying Design Classes

An analysis class maps directly to a design class if:
It is a simple class It represents a single logical abstraction
More complex analysis classes may

Split into multiple classes Become a package Become 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-tomany 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.
7-8

Review: Class and Package
Review: Class and Package

What is a class?
A description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics
Class Name
What is a package?
A general purpose mechanism for organizing elements into groups A model element which can contain other model elements
Package Name
9
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.

7-9
Group Design Classes in Packages
Group Design Classes in Packages

You can base your packaging criteria on a number of different factors, including:
Configuration units Allocation of resources among development teams Reflect the user types Package C Represent the existing products and services the system uses Package B
Package A
10
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.
7 - 10

Packaging Tips: Boundary Classes
Packaging Tips: Boundary Classes

If it is likely the system interface will undergo considerable changes If it is unlikely the system interface will undergo considerable changes
Boundary classes placed in separate packages

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

7 - 11
Packaging Tips: Functionally Related Classes
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 class Removal of one class impacts the other class Two objects interact with a large number of messages or have a complex 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 interact with, or are affected by changes in the same actor
12
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.
7 - 12

Packaging Tips: Functionally Related Classes (continued)

Packaging Tips: Functionally Related Classes (continued)
Criteria for determining if classes are functionally related (continued):
Two classes have relationships between each other One 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 package An optional and a mandatory class should not be placed in the same package
13
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.

7 - 13
Package Dependencies: Package Element Visibility
Package Dependencies: Package Element Visibility

PackageA
A + Class A1 + Class A2 + Class A3
PackageB Public visibility Private visibility

+ Class B1 - Class B2
Only public classes can be referenced outside of the owning package
14
In Architectural Analysis, we discussed package dependencies. Now lets 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 packages 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.
7 - 14

Package Coupling: Tips
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
15
X
A
Upper Layer Lower Layer
X
B
X = Coupling violation
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.

7 - 15
Example: Registration Package
Example: Registration Package

MainStudentForm 1 0..1 <<boundary>> RegisterForCoursesForm 1 1 <<control>> RegistrationController MainRegistrarForm 1 0..1 <<boundary>> CloseRegistrationForm
1 <<control>> CloseRegistrationController
16
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.
7 - 16

Example: University Artifacts Package: Generalization

Example: University Artifacts Package: Generalization
<<entity>> Student
<<entity>> ScheduleOfferingInfo
<<entity>> FulltimeStudent
<<entity>> ParttimeStudent
<<entity>> PrimaryScheduleOfferingInfo
17

7 - 17
Example: University Artifacts Package: Associations
Example: University Artifacts Package: Associations
<<entity>> Student 1
0..*
<<entity>> Schedule 0..*
0..*
primaryCourses 0..4
alternateCourses 0..2 <<entity>> 0..* Course 0..* Prerequisites
<<entity>> instructor <<entity>> Professor CourseOffering 0..1 0..* 0..* 0..* 1 CourseOfferingList
18
7 - 18

Example: External System Interfaces Package
Example: External System Interfaces Package
<<Interface>> IBillingSystem
<<Interface>> ICourseCatalogSystem
19
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.

7 - 19
Review: Subsystems and Interfaces

Realizes one or more interfaces that define its behavior
<<interface>> Interface Name <<subsystem>> Subsystem Name
Interface
Realization (Canonical form)
Subsystem
Interface Name
<<subsystem>> Subsystem Name
Realization (Elided form)
20
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-toone. An interface can be realized by multiple classifiers, and a classifier can realize multiple interfaces. Realization is a semantic relationship between two classifiers. One classifier serves as the contract that the other classifier agrees to carry out. 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.
7 - 20

Subsystems and Interfaces (continued)
Subsystems and Interfaces (continued)

Subsystems :
Completely encapsulate behavior Represent an independent capability with clear interfaces (potential for reuse) Model multiple implementation variants
<<subsystem>> SubsystemA ClassA1 <<Interface>> InterfaceK X() W() ClassB1 W() Y()
21
ClassA2 X() <<subsystem>> SubsystemB ClassB2 X() ClassB3 Z()
W()
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).

7 - 21
Packages versus Subsystems
Packages versus Subsystems

Subsystems
Provide behavior Completely encapsulate their contents Are easily Client Class replaced
ClassB1 <<subsystem>> Subsystem A ClassB2
Packages
Dont provide behavior Dont completely encapsulate their contents May not be easily replaced
Package B
Encapsulation is the key!

22
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).
7 - 22

Subsystem Usage
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 unchanged deployed across a set of distributed computational nodes changed 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 resources represent existing products or external systems in the design (e.g. components) Subsystems raise the level of abstraction.
23
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.

7 - 23
Identifying Subsystems Hints
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.
24
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.
7 - 24

Candidate Subsystems
Candidate Subsystems
Analysis classes which may evolve into subsystems: Classes providing complex services and/or utilities Boundary classes (user interfaces and external system interfaces) Existing products or external systems in the design (e.g., components): Communication software <<subsystem>> Subsystem A Database access support Types and data structures <<subsystem>> Common utilities Subsystem B Application-specific products
<<subsystem>> Subsystem C
25
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. 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)
Examples of products the system uses that you can represent by a subsystem include:
Interfaces and subsystems provide the necessary decoupling between interface and implementation to model (in Design) what components do for Implementation.

7 - 25
Identifying Subsystems
Identifying Subsystems
Superman Class
<<control>>
ClassA
X() W()
<<Interface>>
InterfaceK X() W()
<<subsystem>> SubsystemA ClassA1 X() ClassA2 W()
26
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.
7 - 26


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.

7 - 27
Identifying Interfaces Identifying Interfaces

Purpose To identify the interfaces of the subsystems based on their responsibilities Steps Identify 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.
Stable, well-defined interfaces are key to a stable, resilient architecture.
28
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.
7 - 28

Interface Guidelines
Interface Guidelines
Interface name
Reflects role in system
Interface description
Conveys responsibilities
Operation definition
Name should reflect operation result Describes what operation does, all parameters and result
Interface documentation
Package supporting info: sequence and state diagrams, test plans, etc.
29
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.

7 - 29
Example: Design Subsystems and Interfaces
Example: Design Subsystems and Interfaces

Analysis
<<boundary>> BillingSystem
Design
<<subsystem>> Billing System
//submit bill()
IBillingSystem
submitBill(forTuition : Double, forStudent : Student)
<<boundary>> CourseCatalogSystem //get course offerings()
<<subsystem>> Course Catalog System
ICourseCatalogSystem
getCourseOfferings(forSemester : Semester, forStudent : Student) : CourseOfferingList initialize()
All other analysis classes map directly to design classes.

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

Example: Analysis-Class-To-Design-Element Map
Example: Analysis-Class-To-Design-Element Map

Analysis Class
CourseCatalogSystem BillingSystem All other analysis classes map directly to design classes
Design Element
CourseCatalogSystem Subsystem BillingSystem Subsystem
31
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.

7 - 31
Modeling Convention: Subsystems and Interfaces
Modeling Convention: Subsystems and Interfaces
CourseCatalogSystem
<<subsystem>>
+ initialize () + getCourseOfferings ()
Interfaces start with an I

+ getCourseOfferings () + initialize () <<interface>>
CourseCatalogSystem
<<subsystem>>
32
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.
7 - 32

Example: Subsystem Context: CourseCatalogSystem
Example: Subsystem Context: CourseCatalogSystem

<<control>> <<control>>
CloseRegistrationController
+ // is registration open?() + // close registration() 0..1 +courseCatalog 1 <<Interface>>
Required interface defined
+ getCurrentSchedule() + deleteCurrentSchedule() + submitSchedule() + saveSchedule() + getCourseOfferings() + setSession() + <<class>> new() + getStudent()
+ getCourseOfferings ( for Semester: Semester ) + initialize ()
Provided interface defined
CourseOfferingList
+ new() + add()
CourseCatalogSystem
33
<<subsystem>>
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.

7 - 33
Example: Subsystem Context: Billing System
Example: Subsystem Context: Billing System

<<control>>
CloseRegistrationController
+ // is registration open?() + // close registration()
0..1 + Biller 1 <<entity>>
IBillingSystem
+ submitBill(forStudent : Student, forTuition : double)
<<Interface>> 1
Student
<<subsystem>>
BillingSystem
+ submitBill(forStudent : Student, forTuition : double)
34
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.
7 - 34


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.

7 - 35
Identify Reuse Opportunities Identification of Reuse Opportunities

Purpose
To identify where existing subsystems and/or components can be reused based on their interfaces.
Steps
Look for similar interfaces Modify new interfaces to improve the fit Replace candidate interfaces with existing interfaces Map the candidate subsystem to existing components
36
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.
7 - 36

Possible Reuse Opportunities
Possible Reuse Opportunities

Internal to the system being developed
Recognized commonality across packages and subsystems
External to the system being developed

Commercially available components Components from a previously developed application Reverse engineered components
are Softw
37
are Softw
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.

7 - 37
Reuse Opportunities Internal to System
Reuse Opportunities Internal to System

?
38
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.
7 - 38


ClassB ClassA Y() Z() Y() Z() ClassC ClassD Y() Z() Y() Z() Y() Z() ClassC ClassE Y() Z()
39
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.

7 - 39
Review: Typical Layering Approach
Review: Typical Layering Approach

Specific functionality
Application
Distinct application subsystems that make up an application contains the value adding software developed by the organization.
Business-Specific
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.
Middleware
General functionality
System Software
40
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.
7 - 40

Layering Considerations Layering Considerations

Visibility Dependencies only within current layer and below Volatility Upper layers affected by requirements changes Lower layers affected by environment changes Generality More abstract model elements in lower layers Number of layers Small system: 3-4 layers Complex system: 5-7 layers
Goal is to reduce coupling and to ease maintenance effort.
41
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 lowerlayer 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.

7 - 41
Design Elements and the Architecture
Design Elements and the Architecture

Layer 1
Layer 2
Layer 3
42
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.
7 - 42

Example: Architectural Layers
Example: Architectural Layers

<<layer>> Application
<<layer>> Business Services
Necessary because the Application Layer must have access to the core distribution mechanisms provided with Java RMI.
<<layer>> Middleware
Base Reuse
global
43
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.

7 - 43
Partitioning Considerations
Partitioning Considerations
Coupling and cohesion User organization Competency and/or skill areas System distribution Secrecy Variability
Try to avoid cyclic dependencies.

44
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 (applicationspecific 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.
7 - 44

Example: Partitioning
Example: Partitioning
A
Package A
Package B
45
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).

7 - 45
Example: Application Layer
Example: Application Layer
Registration
46
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.
7 - 46

Example: Application Layer Context
Example: Application Layer Context

<<layer>> Application Registration
<<layer>> Business Services External System Interfaces Security
Secure Interfaces
GUI Framework
47
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.

7 - 47
Example: Business Services Layer
Example: Business Services Layer

<<subsystem>> BillingSystem <<subsystem>> CourseCatalogSystem
External System Interfaces Security ObjectStore Support GUI Framework <<subsystem>> Security Manager Secure Interfaces
48
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.
7 - 48

Example: Business Services Layer Context
Example: Business Services Layer Context

<<subsystem>> BillingSystem
<<subsystem>> CourseCatalogSystem
External System Interfaces Security ObjectStore Support GUI Framework <<subsystem>> Security Manager Secure Interfaces
com.odi java.sql
49
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.

7 - 49
Example: Middleware Layer
Example: Middleware Layer
<<layer>> Middleware com.odi

Map
(from com.odi)
java.sql
DriverManager
(from com.odi)
Session
(from com.odi)
Connection
(from com.odi)
Transaction
(from com.odi)
Database
(from com.odi)
Statement
(from com.odi)
ResultSet
(from com.odi)
50
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.
7 - 50


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

7 - 51
Checkpoints
Checkpoints
General 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? Layers Are there more than seven layers? Subsystems Is subsystem partitioning done in a logically consistent way across the entire model?
52
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.
7 - 52

Packages Are 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?
53
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.

7 - 53
Classes
Does 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?
54
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.
7 - 54

Review 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?
55

7 - 55
Exercise: Identify Design Elements
Exercise: Identify Design Elements 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
56
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. References to the givens: 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.
7 - 56

Exercise: Identify Design Elements (continued)
Exercise: Identify Design Elements (continued)

Design classes, subsystems, their interfaces and their relationships with other design elements Mapping from the analysis classes to the design elements The 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)
57
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.

7 - 57

For each subsystem, an interface realization class diagram Table mapping analysis classes to design elements Table listing design elements and their owning package
58
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
7 - 58

Exercise: Review
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
59
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?

7 - 59
7 - 60

Module 8 Identify Design Mechanisms
IBM Software Group
Mastering Object-Oriented Analysis and Design with UML 2.0 Module 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

8-1
Objectives: Identify Design Mechanisms
Objectives: Identify Design Mechanisms

Define the purpose of the Identify Design Mechanisms activity and explain when in the lifecycle it is performed Explain what design and implementation mechanisms are and how they map from Analysis mechanisms Describe 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.
8-2

Module 8 - Identify Design Mechanisms
Identify Design Mechanisms in Context
Identify Design Mechanisms in Context

Analyze Behavior Identify Design Mechanisms Architect (Optional)
Design Components
Design the Database
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.

8-3
Identify Design Mechanisms Overview Identify Design Mechanisms Overview
Identify Design Mechanisms
Design Model
Analysis Class
4
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. Supplementary Specifications Software Architecture Document Analysis Class Design Model Design Model elements Classes Packages Subsystems Software Architecture Document
Input Artifacts
Resulting Artifacts
8-4

Identify Design Mechanisms: Steps

Categorize clients of analysis mechanisms Document 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.

8-5

Categorize clients of analysis mechanisms Documenting 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-tobe 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.
8-6

Review: Patterns and Frameworks
Review: Patterns and Frameworks

Pattern
Provides a common solution to a common problem in a context
Analysis/Design Pattern
Provides a solution to a narrowly scoped technical problem Provides a fragment of a solution, or a piece of the puzzle
Framework
Defines the general approach to solving the problem Provides a skeletal solution, whose details may be analysis/design patterns
7
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 elses. 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 domainspecific frameworks that are intended to be customized (such as Peoplesoft, SanFransisco, Infinity, and SAP). SAP is a framework for manufacturing and finance.

8-7
What Is a Design Pattern? What Is a Design Pattern?

A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonlyrecurring structure of communicating components that solves a general design problem within a particular context.
Erich Gamma et al. 1994. Design PatternsElements of Reusable Object-Oriented Software
Template Parameters
Pattern Name
8
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.
8-8

Examples of Pattern Usage
Examples of Pattern Usage

Pattern Command
(behavioral pattern)
Example
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 Create GUI objects (buttons, scrollbars, windows, etc.) independent of the underlying OS: the application can be easily ported to different environments 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) 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
Abstract factory
(creational pattern)
Proxy
(structural pattern)
Observer
(behavioral pattern)

8-9
Detailing the Command Pattern
Detailing the Command Pattern

Application
+menu
1 0..*
Menu
MenuItem
- label : String + Clicked()
Command
+items
+cmd + Process()
cmd.Process();
10
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();
8 - 10

Detailing the Command Pattern (continued)

Application AskUser(); DoOpen(); OpenCommand
+ Process()
+cmd +menu
1 0..*
Menu
MenuItem
- label : String + Clicked()
Command
+ Process()
+items
cmd.Process();
11
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();

8 - 11

1. OpenCommand( )
myapp
ocmd : OpenCommand
Initialization
2. AddItem("Open...",ocmd) 3. MenuItem("Open...", ocmd) aNewItem : MenuItem

3. AskUser( ) 4. DoOpen( )
menu
The user selects the Open menu item

A user
1. Clicked( ) theMenuItem
2. Process( ) cmd : Command
12
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).
8 - 12


OpenCommand Application AskUser(); DoOpen();
+ Process() + OpenCommand() - AskUser() - DoOpen()
+menu
Menu
+ AddItem(s : String, c : Command)
MenuItem
0..* - label : String
+items + Clicked()
+ MenuItem(s : String, c : Command)
Clicked(): cmd.Process();
MenuItem(): cmd = c; label = s;

1
+cmd Command
+ Process()
13
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.

8 - 13

app
Application CloseCommand
OpenCommand
gui
Menu MenuItem
com
Command
14
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.
8 - 14

Representing Design Patterns in UML
Representing Design Patterns in UML

A design pattern is a parameterized collaboration:
Client Invoker ConcreteCommand <<role>>
The parameters (stereotype <<role>>) of the collaboration
Client
<<role>>
Command
ConcreteCommand + Process()
<<role>>
Invoker
Command + Process()
15
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.

8 - 15
Describing Analysis Mechanisms Describing Analysis Mechanisms

Collect all analysis mechanisms in a list Draw a map of the client classes to the analysis mechanisms
Analysis Class Student Schedule CourseOffering Course RegistrationController Analysis Mechanism(s) Persistence, Security Persistence, Security Persistence, Legacy Interface Persistence, Legacy Interface Distribution
Identify characteristics of the Analysis mechanisms

16
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.
8 - 16

Categorize Analysis Mechanisms
Categorize Analysis Mechanisms

Purpose
To refine the information gathered on the analysis mechanisms
Steps
Identify the clients of each analysis mechanism Identify characteristic profiles for each analysis mechanism Group clients according to their use of characteristic profiles Proceed bottom up and make an inventory of the implementation mechanisms that you have at your disposal
17
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, databasebased, distributed, and so forth.

8 - 17

Categorize clients of analysis mechanisms Documenting architectural mechanisms
18
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-athand 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.
8 - 18

Design and Implementation Mechanisms
Design and Implementation Mechanisms

Analysis Mechanism (Conceptual) Design Mechanism (Concrete)
Legacy Data
Implementation Mechanism (Actual)
Persistency
RDBMS
New Data
JDBC
Persistency Distribution
OODBMS
ObjectStore
Remote Method Invocation (RMI)
Java 1.2 from Sun
19
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 interprocess 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.

8 - 19
Review: Documenting Architectural Mechanisms
Review: Documenting Architectural Mechanisms

Architectural mechanisms can be treated as patterns (i.e., parameterized collaboration)
Template Parameters
Pattern Name
Structural Aspect
Behavioral Aspect
Documented in Design Guidelines

20
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.
8 - 20

Review: Course Registration Analysis Mechanisms
Review: Course Registration Analysis Mechanisms

Persistence Distribution
Security
Legacy Interface
21
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.

8 - 21
Mechanism: Persistency: RDBMS: JDBC
Mechanism: Persistency: RDBMS: JDBC

Persistence characteristics:
Granularity Volume Duration Access mechanism Access frequency (creation/deletion, update, read) Reliability
Note: JDBC is the standard Java API for talking to a SQL database.
22
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?
8 - 22

Example: Persistency: RDBMS: JDBC
Example: Persistency: RDBMS: JDBC

<<role>> PersistencyClient
(from SamplePersistency Client)
Roles to be filled by the designer applying the mechanism
<<role>> PersistentClassList
(from SamplePersistentClass)
new() add(c: PersistentClass) <<role>> DBClass create() : PersistentClass read(searchCriteria : String) : PersistentClassList update(c : PersistentClass) delete(c : PersistentClass) 1 1 0..* 0..* <<role>> PersistentClass
(from SamplePersistentClass)
getData() setData() command() new() DriverManager

(from java.sql)
1 Statement
(from java.sql)
getConnection(url, user, pass) : Connection
ResultSet
(from java.sql)
Connection
(from java.sql)
getString() : String
executeQuery(sql : String) : ResultSet executeUpdate(sql : String) : int
createStatement() : Statement
23
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.

8 - 23
Example: Persistency: RDBMS: JDBC: Initialize
Example: Persistency: RDBMS: JDBC: Initialize

: DBClass : DriverManager
1. getConnection(url, user, pass)
24
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.
8 - 24

Example: Persistency: RDBMS: JDBC: Create
Example: Persistency: RDBMS: JDBC: Create

: PersistencyClient : DBClass : PersistentClass : Connection : Statement 1. create( ) 1.1. New() 1.2. getData( ) 1.3. createStatement( )
1.4. executeUpdate(String)
25
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.

8 - 25
What Is a Combined Fragment? 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 Object
:Client
Supplier Object
:Supplier
interaction operand
26
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.
8 - 26

What is an Interaction Operand?
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.
27
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.

8 - 27
What is an Interaction Expression?
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 values A guard condition, enclosed in square brackets, can be included on a lifeline.
Client Object
:Client
Supplier Object Interaction Expression

:Supplier
loop (range) [guard exp]

1: PerformResponsibility
28
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.
8 - 28

Example: Persistency: RDBMS: JDBC: Read
Example : Persistency: RDBMS: JDBC: Read

: PersistencyClient : DBClass : Connection : Statement : ResultSet : PersistentClassList : PersistentClass 1. read(string) 1.1. createStatement( ) The criteria used to access data for the persistent class loop [for each class from execute query] 1.5. new() 1.2. executeQuery(string) 1.4. new( ) Create a list to hold all retrieved data Returns a Statement The SQL statement built by the DBClass using the given criteria is passed to executeQuery() 1.3 // executeQuery()
loop [for each attribute in class] 1.6. getString( ) 1.7. setData( )
1.8. add(PersistentClass)
29
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.

8 - 29
Example: Persistency: RDBMS: JDBC: Update
Example: Persistency: RDBMS: JDBC: Update

: PersistencyClient : DBClass : PersistentClass : Connection : Statement
1. update(PersistentClass) 1.1. getData( ) 1.2. createStatement( )
1.3. executeUpdate(string)
execute SQL statement
30
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 DBClasss 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.
8 - 30

Example: Persistency: RDBMS: JDBC: Delete
Example: Persistency: RDBMS: JDBC: Delete

: PersistencyClient : DBClass : Connection : Statement
1. delete(PersistentClass)
1.1. createStatement( )
execute SQL statement
1.2. executeUpdate(string)
31
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.

8 - 31
Incorporating JDBC: Steps
Incorporating JDBC: Steps

1. Provide access to the class libraries needed to implement JDBC Provide java.sql package 2. Create the necessary DBClasses Assign one DBClass per persistent class 3. Incorporate DBClasses into the design Allocate to package/layer Add relationships from persistency clients 4. Create/Update interaction diagrams that describe: Database initialization Persistent class access: Create, Read, Update, Delete
Deferred
32
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.
8 - 32

Example: Incorporating JDBC
Example: Incorporating JDBC

Sample Persistency Client Package
java.sql
DriverManager
(from java.sql)
Connection
(from java.sql)
Statement
(from java.sql)
ResultSet
(from java.sql)
33
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).

8 - 33
Review 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.
34
8 - 34

Module 9 Describe the Run-Time Architecture
IBM Software Group
Mastering Object-Oriented Analysis and Design with UML 2.0 Module 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

9-1
Objectives: Describe the Run-time Architecture
Objectives: Describe the Run-time Architecture

Define the purpose of the Describe the Run-time Architecture activity and when in the lifecycle it is performed Demonstrate how to model processes and threads Explain how processes can be modeled using classes, objects and components Define 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.
9-2

Module 9 - Describe the Run-Time Architecture
Describe the Run-time Architecture in Context
Describe the Run-time Architecture in Context

Analyze Behavior Describe the Run-time Architecture (Optional)
Architect
Design Components
Design the Database
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.

9-3
Describe the Run-time Architecture Overview Describe the Run-time Architecture Overview
Describe the Run-time Architecture
Design Model
The architect performs the Describe the Run-time Architecture, once per iteration. Purpose To analyze concurrency requirements, to identify processes, identify interprocess communication mechanisms, allocate inter-process coordination resources, identify process lifecycles, and distribute model elements among processes. Supplementary Specifications Design Model Software Architecture Document Software Architecture Document Design Model
Input Artifacts
Resulting Artifacts
9-4

Key Concepts: The Process View
Key Concepts: The Process View
Logical View
Analysts/Designers
Structure
Implementation View
Programmers
Software management
Use-Case View
Process View
Deployment View
System engineering
System integrators
The Process View is an architecturally significant slice of the processes and threads of the Design Model.
5
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.

9-5
What Is Concurrency? What Is Concurrency?

Example of concurrency at work:
Parallel roads require little coordination Two-way roads require some coordination for safe interaction Intersections 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.
9-6

Why Are We Interested in Concurrency?
Why Are We Interested in Concurrency?

Software might need to respond to seemingly random externally generated events Performing tasks in parallel can improve performance if multiple CPUs are available
Example: Startup of a system
Control of the system can be enhanced through concurrency

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

9-7
Realizing Concurrency: Concurrency Mechanisms
Realizing Concurrency: Concurrency Mechanisms

To support concurrency, a system must provide for multiple threads of control Common 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
8
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 SUNs Solaris and Microsofts Windows NT.
9-8

Describe the Run-time Architecture Steps

Analyze concurrency requirements Identify processes and threads Identify process lifecycles Map processes onto the implementation Distribute 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.

9-9

10
9 - 10

Concurrency Requirements
Concurrency Requirements
Concurrency requirements are driven by:
The degree to which the system must be distributed. The degree to which the system is eventdriven. 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.

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

9 - 11
Example: Concurrency Requirements
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 concurrently If a course offering becomes full while a student is building a schedule including that offering, the student must be notified Risk-based prototypes have found that the legacy course catalog database cannot meet our performance needs without some creative use of mid-tier processing power
12
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.
9 - 12


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.

9 - 13
Key Concepts: Process and Thread
Key Concepts: Process and Thread

Process
Provides heavyweight flow of control Is stand-alone Can be divided into individual threads
Thread
Provides lightweight flow of control Runs in the context of an enclosing process
14
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.
9 - 14

Identifying Processes and Threads Identifying Processes and Threads

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
15
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).

9 - 15
Modeling Processes
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 <<process>> ComponentName
This course will model processes and threads using Class Diagrams.
16
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 arent 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.
9 - 16

Example: Modeling Processes: Class Diagram
Example: Modeling Processes: Class Diagram

<<process>> CourseCatalogSystemAccess
1 1
<<thread>> CourseCache
dependency
<<process>> CourseRegistrationProcess
composition
<<thread>> OfferingCache
<<process>> StudentApplication
17
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.

9 - 17

18
Now that we have identified processes and threads, we must determine when those processes and threads are created and destroyed.
9 - 18

Creating and Destroying Processes and Threads Creating and Destroying Processes and Threads
Single-process architecture
Process creation takes place when the application starts Process destruction takes place when the application ends
Multi-process architecture
New processes are typically created from the initial process that was created when the application was started Each process must be individually destroyed
Note: The Course Registration System utilizes a multi-process architecture.
19
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.

9 - 19
Example: Create Processes and Threads
Example: Create Processes and Threads

: CourseCatalogSystem Access : CourseCache : OfferingCache
1: createThread
2: createThread
Creation of threads during application startup.

20
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.
9 - 20


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.

9 - 21
Mapping Processes onto the Implementation Mapping Processes onto the Implementation
Processes and threads must be mapped onto specific implementation constructs Considerations
Process coupling Performance requirements System process and thread limits Existing threads and processes IPC resource availability
22
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.
9 - 22


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.

9 - 23
Design Element Allocation
Design Element Allocation

Instances of a given class or subsystem must execute within at least one process
They may execute in several processes
Student Application Process
MainStudentForm
24
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.
9 - 24

Design Elements-to-Processes Considerations
Design Elements-to-Processes Considerations

Based on:
Performance and concurrency requirements Distribution requirements and support for parallel execution Redundancy and availability requirements
Class/subsystem characteristics to consider:

Autonomy Subordination Persistence Distribution
25
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.

9 - 25
Design Elements-to-Processes Strategies Design Elements-to-Processes Strategies

Two Strategies (used simultaneously) Inside-Out Group elements that closely cooperate and must execute in the same thread of control Separate 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-In Define a separate thread of control for each external stimulus Define a separate server thread of control for each service Reduce number of threads to what can be supported
26
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. 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.
Outside-In
9 - 26

Modeling the Mapping of Elements to Processes
Modeling the Mapping of Elements to Processes

Class diagrams
Active classes as processes/threads
<<process>> Process Name <<thread>> Thread Name
Composition relationships from processes/threads to classes

<<process>> Process Name Class Name
Composition relationships from processes/threads to subsystems

<<process>> Process Name <<subsystem>> Subsystem Name
27
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 topmost element has relationships with unless they are in different threads.

9 - 27
Process Relationships
Process Relationships
Process relationships must support design element relationships
<<process>> Process Y ClassB
0..*
supports
1
<<process>> ProcessX
ClassA
28
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.
9 - 28

Example: Register for Course Processes
Example: Register for Course Processes

<<process>> StudentApplication 1 <<process>> CourseRegistrationProcess 1 <<process>> CourseCatalogSystemAccess 1
1 MainStudentForm
(from Registration)
1 <<subsystem>> CourseCatalogSystem
(from CourseCatalogSystem)
0..1 1 <<boundary>> RegisterForCoursesForm

(from Registration)
1 1 <<control>> RegistrationController
(from Registration)
+courseCatalog 0..* 1
(from External System Interfaces)
29
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.

9 - 29
Example: Register for Course Processes (continued)
Example: Register for Course Processes (continued)
<<thread>> OfferingCache
1
<<entity>> CourseOffering 1 0..*

(from University Artifacts)
1 <<process>> CourseCatalogSystemAccess 1
<<thread>> 1 CourseCache
0..*
<<entity>> Course
30
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.
9 - 30

Checkpoints: Describe the Run-time Architecture
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?
31

9 - 31
Review 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?
32
9 - 32

Exercise: Describe the Run-time Architecture

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
33
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. References to the givens: 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.

9 - 33
Exercise: Describe the Run-time Architecture (continued)

Exercise: Describe the Run-time Architecture (continued) Identify the following:
Process relationships
34
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. Refer to the following slides if needed: Key Concept: Processes and Threads 9-14 Modeling Processes 9-16 Example: Modeling Processes: Class Diagram 9-17
9 - 34


Class diagram showing the: Processes Mapping of classes and subsystems to processes Process relationships
35
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. Refer to the following slides if needed: Modeling the Mapping of Elements to Processes 9-27 Process Relationships 9-28 Example: Register for Courses Processes 9-29 and 9-30

9 - 35
Exercise: Review
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?
36
Payroll System
After completing a model, it is important to step back and review your work. Some helpful questions are the following: 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?
9 - 36

Module 10 Describe Distribution
IBM Software Group
Mastering Object-Oriented Analysis and Design with UML 2.0 Module 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

10 - 1
Objectives: Describe Distribution
Objectives: Describe Distribution

Explain the purpose of the Describe Distribution activity and when in the lifecycle it is performed Describe how the functionality of the system can be distributed across physical nodes Model the distribution decisions of the system in the Deployment Model Articulate 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.
10 - 2

Module 10 - Describe Distribution
Describe Distribution in Context
Describe Distribution in Context

Describe Distribution
Architect
Design Components
Design the Database
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.

10 - 3
Describe Distribution Overview Describe Distribution Overview
Describe Distribution
Deployment Model
Implementation Model Design Model

4
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 Software Architecture Document Deployment Model
Resulting Artifacts
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.
10 - 4

Key Concepts: The Deployment View
Key Concepts: The Deployment View
Logical View
Implementation View
Analysts/Designers
Structure
Programmers
Software management
Use-Case View
Process View
Deployment View
System engineering
System integrators
The Deployment View is an architecturally significant slice of the Deployment Model.

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

10 - 5
Why Distribute?
Why Distribute?
Reduce processor load Special processing requirements Scaling concerns Economic concerns Distributed 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 nave 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.
10 - 6

Distribution Patterns
Distribution Patterns
Client/Server
3-tier Fat Client Fat Server Distributed 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.

10 - 7
Client/Server Architectures
Client/Server Architectures
Thinner client, thicker server
Client A
Application Business Object Services Business Object Engine
Client B
Application DCOM CORBA Beans ADO/R Business Object Server COM MTS Beans ETS
Client C
WWW Browser
Web Server
HTML CGI ASP Java
Business Object Services Business Object Engine
Database Server(s)
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 Webbased application. You will look at each of these distribution strategies in more detail.
10 - 8

Client/Server: Three-Tier Architecture
Client/Server: Three-Tier Architecture

Client B
Application
Application Services
DCOM CORBA Beans ADO/R Business Object Server COM MTS Beans ETS
Business Services
Database Server(s)
Data Services
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.

10 - 9
Client/Server: Fat Client Architecture
Client/Server: Fat Client Architecture

Client A
Application
Application Services Business Services
Database Server(s)
Data Services
10
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.
10 - 10

Client/Server: Web Application Architecture
Client/Server: Web Application Architecture

Client C
WWW Browser
Web Server
HTML CGI ASP Java
Application Services Business Services
Database Server(s)
Data Services
11
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).

10 - 11
Peer-to-Peer Architecture
Peer-to-Peer Architecture
Application Application DCOM CORBA Beans ADO/R
Application Services
DCOM CORBA Beans ADO/R
COM MTS
Beans ETS
COM MTS
Beans ETS
Business Services
Data Services
12
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.
10 - 12

Describe Distribution Steps

Define the network configuration Allocate processes to nodes Define the distribution mechanism
13
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.

10 - 13

14
The configuration and topology of the network is modeled in order to make it understandable and check for any inconsistencies.
10 - 14

The Network Configuration The Network Configuration

End-user workstation nodes Headless" processing server nodes Special configurations
Development Test
Specialized processors
15
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.

10 - 15
Review: What Is a Node?
Review: What Is a Node?

Represents a run-time computational resource Types:
Generally has at least memory and often processing capability. Device Physical computational resource with processing capability. May be nested Execution Environment Represent particular execution platforms
<<device>> Device Name
<<device>> Sub Device Name <<exe env>> EE Name
16
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.
10 - 16

Review: What Is a Connector?
Review: What Is a Connector?

A connector represents a:
Communication mechanism Physical medium Software protocol
<<100-T Ethernet>> <<client workstation>> Kiosk
Connector
<<application server>> Server <<RS-232>> <<client workstation>> Console
17
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, RS232). A stereotype may be used to specify the type of connector.

10 - 17
Review: Example: Deployment Diagram
Review: Example: Deployment Diagram
<<client workstation>> PC
0..2000 1 <<Campus LAN>>

<<application server>> Registration Server
1 <<Campus LAN>> 1
<<legacy RDBMS>> Course Catalog
<<Campus LAN>> 1
<<legacy>> Billing System
18
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.
10 - 18


19

10 - 19
Process-to-Node Allocation Considerations Process-to-Node Allocation Considerations

Distribution patterns Response time and system throughput Minimization of cross-network traffic Node capacity Communication medium bandwidth Availability of hardware and communication links Rerouting requirements
20
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 crossnetwork 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
10 - 20

Review: Example: Deployment Diagram with Processes

Review: Example: Deployment Diagram with Processes
<<Campus LAN>> 1
0..2000
1 <<Campus LAN>> 1
<<legacy RDBMS>> Course Catalog
<<application server>> Registration Server CourseCatalogSystemAccess CourseRegistrationProcess BillingSystemAccess
<<Campus LAN>> 1 1
<<legacy>> Billing System
21
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 Runtime Architecture module. Note: No threads are shown in the above diagram, because threads always run in the context of a process.

10 - 21
What is Deployment? 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.
22
10 - 22

Example: Deploying Artifacts to Nodes
Example: Deploying Artifacts to Nodes

<<client workstation>> PC <<process>> StudentApplication
<<client workstation>> PC StudentApplication
<<deploy>>
23
Here are three examples of valid UML 2 artifacts deployed to nodes.

10 - 23
What is Manifestation?
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
24
10 - 24

Example: Manifestation
Example: Manifestation
<<header>> MainStudentForm
<<manifest>> MainStudentForm
<<source>> MainStudentForm
<<manifest>> <<manifest>>
<<deploy>>
25
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.

10 - 25
What is a Deployment Specification?
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
26
10 - 26

Example: Deployment Specification
Example: Deployment Specification

<<header>> MainStudentForm <<manifest>> MainStudentForm
<<source>> MainStudentForm
<<manifest>> <<manifest>>
<<deploy>>
<<deploymentSpec>> StuAppDeploy execution = priority = location =

27
The <<header>> and <<source>> artifacts are an implementation manifestation for the MainStudentForm model element class.

10 - 27

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.
10 - 28

Distribution Mechanism Distribution Mechanism

RMI was chosen as the implementation mechanism for distribution
Analysis Mechanism (Conceptual) Design Mechanism (Concrete)
Implementation Mechanism (Actual)
Distribution
Java 1.2 from Sun
29
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.

10 - 29
Design Mechanisms: Distribution: RMI
Design Mechanisms: Distribution: RMI

Distribution characteristics
Latency Synchronicity Message Size Protocol
30
10 - 30


Lookup(serverURL) Naming Remote
Distributed Class
InvokeOp() Client RemoteStub RemoteSkeleton
InvokeOp() RemoteObject
RMI Transport
Provided for free with RMI for each distributed class.

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

10 - 31
Remote Method Invocation (RMI) (continued)
Remote Method Invocation (RMI) (continued)

Roles to be filled by the designer applying the
One Instance per node
Naming. (from java.rmi)

lookup(name : String) : Remote
mechanism
Remote
(from java.rmi)
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.
SampleDistributedClassClient
<<role>>
<<Interface>> ISampleDistributedClass
doSomething(aParameter : SamplePassedData)
Any Java class that you want to pass as an argument to an operation on a remote interface must realize the Serializable Interface.
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.
UnicastRemoteObject
(from Server)
SamplePassedData
<<role>>
Serializable
(from java.io)
<<role>> SampleDistributedClass
doSomething(aParameter : SamplePassedData)
32
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.
10 - 32

Incorporating RMI: Steps
Incorporating RMI: Steps

1. Provide access to RMI support classes (e.g., Remote and Serializable interfaces, Naming Service)

Deferred
java.rmi and java.io package in Middleware layer Controllers to be distributed are in the Application layer Dependency from the Application to the Middleware layer is needed to access java packages Define interface for class that realizes Remote Have class inherit from UnicastRemoteObject
2. For each class to be distributed:
33
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.

10 - 33
Incorporating RMI: Steps (continued)

3. Have classes for data passed to distributed objects realize the Serializable interface
Core data types are in Business Services layer Dependency from Business Services layer to the Middleware layer is needed to access java.rmi Add the realization relationships Deferred
Out of scope
4. Run pre-processor
34
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, UseCase 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.
10 - 34


5. Have distributed class clients lookup the remote objects using the Naming service
Most Distributed Class Clients are forms Forms are in the Application layer Dependency from the Application layer to the Middleware layer is needed to access java.rmi Add relationship from Distributed Class Clients to Naming Service
6. Create and update interaction diagrams with distribution processing

35
Deferred
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).

10 - 35
Example: Incorporating RMI

<<layer>> Application <<layer>> Business Services
Registration Package (from Application)
University Artifacts (from Business Services)
java.rmi
Java.io
<<interface>> Serializable
(from java.io)
Naming
(from java.rmi)
Server
UnicastRemote Object
(from Server)
<<interface>> remote
(from java.rmi)
36
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.
10 - 36

Checkpoints: Deployment View
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?
37
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.

10 - 37
Review 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?
38
10 - 38

Exercise: Describe Distribution
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
39
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.

10 - 39
Exercise: Describe Distribution (continued)
Exercise: Describe Distribution (continued)

A Deployment diagram depicting: Nodes Connectors What processes run on what nodes
40
Refer to the following slides if needed: What is a Node? 10-16 What is a Connector? 10-17 Example: Deployment Diagram with Processes 10-21
10 - 40

Exercise: Review
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
41
After completing a model, it is important to step back and review your work. Some helpful questions are the following: 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?

10 - 41
10 - 42



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
IBM Software Group
Mastering Object-Oriented Analysis and Design with UML 2.0 Module 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

11 - 1
Objectives: Use-Case Design
Objectives: Use-Case Design

Define the purpose of Use-Case Design and when in the lifecycle it is performed Verify that there is consistency in the usecase implementation Refine the use-case realizations from UseCase 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.
11 - 2

Module 11 - Use-Case Design
Use-Case Design in Context
Use-Case Design in Context

Use-Case Design
Designer
Design Components
Design the Database
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 usecase 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.

11 - 3
Use-Case Design Overview Use-Case Design Overview
Design Subsystems and Interfaces
Analysis Model
Use-Case Design
Design Use-Case Realization
Use case Design Model

4
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. Analysis Model Supplementary Specifications Use cases Analysis use-case realization Design classes Design subsystems Design Model Design use-case realization Interfaces Design use-case realization Design Model
Input Artifacts:
11 - 4

Use-Case Design Steps

Describe interaction among design objects Simplify sequence diagrams using subsystems Describe persistence-related behavior Refine the flow of events description Unify 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.

11 - 5

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.
11 - 6


Use Case
Sequence Diagrams
Use Case
Class Diagrams
7
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 UseCase 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 usecase realization.

11 - 7
Review: From Analysis Classes to Design Elements
Review: From Analysis Classes to Design Elements

Analysis Classes
<<boundary>>
Design Elements
<<control>>
<<subsystem>>
Subsystem
<<entity>>
<<boundary>>
<<subsystem>>
Subsystem
Many-to-Many Mapping
8
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.
11 - 8

Use-Case Realization Refinement
Use-Case Realization Refinement

Identify participating objects Allocate responsibilities among objects Model messages between objects Describe processing resulting from messages Model associated class relationships
Sequence Diagrams
9
Class 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 subsystems 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.

11 - 9
Use-Case Realization Refinement Steps Use-Case Realization Refinement Steps

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
10
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).
11 - 10

Representing Subsystems on a Sequence Diagram
Representing Subsystems on a Sequence Diagram

Interfaces
Represent any model element that realizes the interface No message should be drawn from the interface
Subsystem Component
Represents a specific subsystem Messages can be drawn from the subsystem
Object A Interface Object B Object A Subsystem Component Object B
1: Message 1
2: Message 2
1: Message 1
2: Message 2
Invalid message
11
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.

11 - 11
Example: Incorporating Subsystem Interfaces
Example: Incorporating Subsystem Interfaces

Analysis Classes
<<boundary>> BillingSystem //submit bill()
IBillingSystem
submitBill(forTuition : Double, forStudent : Student)
Design Elements
<<subsystem>> Billing System
<<boundary>> CourseCatalogSystem //get course offerings()
<<subsystem>> Course Catalog System
getCourseOfferings(forSemester : Semester, forStudent : Student) : CourseOfferingList initialize()
All other analysis classes are mapped directly to design classes.

12
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.
11 - 12

Example: Incorporating Subsystems (Before)
Example: Incorporating Subsystems (Before)

Analysis class to be replaced
: RegisterForCoursesForm : RegistrationController : Student 1. // create schedule( ) 1.1. // get course offerings( ) Student wishes to create a new schedule 1.2. // display course offerings( ) A list of the available course offerings for this semester are displayed A blank schedule is displayed for the students to select offerings 1.3. // display blank schedule( ) 1.1.1. // get course offerings(forSemester) : CourseCatalogSystem : Schedule : Student
ref
Select Offerings
ref
Submit Schedule
13
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.

11 - 13
Example: Incorporating Subsystems (After)
Example: Incorporating Subsystems (After)

Replaced with subsystem interface
: RegisterForCoursesForm 1: // create schedule 1.1: // get course offerings Student wishes to create a new schedule A list of the available course offerings for this semester are displayed A blank schedule is displayed for the Student to select offerings 1.2: // display course offerings 1.1.1: getCourseOfferings : RegistrationController : ICourseCatalogSystem : Schedule : Student
1.3: // display blank schedule
ref
Select Offerings
ref
Submit Schedule
14
The above is a fragment of the sequence diagram from the Register for Courses usecase 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.
11 - 14

Example: Incorporating Subsystem Interfaces (VOPC)
Example: Incorporating Subsystem Interfaces (VOPC)

<<boundary>> RegisterForCoursesForm
(from Registration)
Subsystem interface
<<control>> RegistrationController 1
0..* (from Registration) // submit schedule() // display course offerings() // submit schedule() // display schedule() 1 1 // save schedule() // save schedule() // create schedule with offerings() 0..1 // create schedule() // getCourseOfferings() // select 4 primary and 2 alternate offerings() // display blank schedule() 0..1 registrant 0..1
getCourseOfferings() initialize() <<entity>> Schedule currentSchedule 0..1 0..* 0..*

semester // submit() // save() // any conflicts?() // new() 0..*
<<entity>> Student.
- name - address - studentID : int // addSchedule() // getSchedule() // hasPrerequisites() // passed()
1 primaryCourses 0..4
alternateCourses 0..2 <<entity>> CourseOffering

number startTime endTime days // addStudent() // removeStudent() // new() // setData()
15
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.

11 - 15
Incorporating Architectural Mechanisms: Security
Incorporating Architectural Mechanisms: Security

Analysis Class to Architectural-Mechanism Map from Use-Case Analysis
16
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.
11 - 16

Incorporating Architectural Mechanisms: Distribution
Incorporating Architectural Mechanisms: Distribution

Analysis Class to Architectural-Mechanism Map from Use-Case Analysis
17
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.

11 - 17
Review: Incorporating RMI: Steps
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 layer For 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 packages Define interface for class that realizes Remote Have class inherit from UnicastRemoteObject
= Done
18
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.
11 - 18

Review: Incorporating RMI: Steps (continued)

2. Have classes for data passed to distributed objects realize the Serializable interface
Core data types are in Business Services layer Dependency from Business Services layer to Middleware layer is needed to get access to java.rmi Add the realization relationships
3. Run pre-processor out of scope

= Done
19
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.

11 - 19

4. Have distributed class clients look up the remote objects using the Naming service
Most Distributed Class Clients are forms Forms are in Application layer Dependency from Application layer to Middleware layer is needed to get access to java.rmi Add relationship from Distributed Class Clients to Naming Service
5. Create/update interaction diagrams with distribution processing (optional)

= Done
20
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.
11 - 20


Naming
(from rmi) + lookup()
Distributed Class Client

1 1
<<Interface>> IRegistrationController
(from Registration)
<<boundary>> RegisterForCoursesForm (from Registration)
+ getCurrentSchedule(forStudent : Student, forSemester : Semester) : Schedule + deleteCurrentSchedule() + submitSchedule() + saveSchedule() + getCourseOfferings() : CourseOfferingList
Passed Class
<<Interface>> (from rmi) <<Entity>>
Remote
CourseOfferingList
0..1 registrant
(from University Artifacts) 1 0..n
Student
Distributed Class
<<Control>> RegistrationController (from Registration)
0..1 currentSchedule 0..1 0..1
<<Entity>> (from University Artifacts)
Schedule
<<Interface>>
Serializable
(from io)
UnicastRemoteObject
(from server)
21
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.

11 - 21
Example: Incorporating RMI (continued)

<<layer>> Application <<layer>> Business Services
Registration Package (from Application)
java.rmi
Java.io
<<interface>> Serializable
(from java.io)
Naming
(from java.rmi)
Server
UnicastRemote Object
(from Server)
<<interface>> remote
(from java.rmi)
22
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.
11 - 22


Added to support distribution
RegisterForCoursesForm : Naming. :IRegistrationController
1: lookup(string)
Lookup remote object by specifying it's URL
2: doSomething
All calls to the distributed class interface are forwarded to the remote instance.
23
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.

11 - 23

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.
11 - 24

Encapsulating Subsystem Interactions
Encapsulating Subsystem Interactions

Interactions can be described at several levels Subsystem interactions can be described in their own interaction diagrams
Raises the level of abstraction.

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

11 - 25
Guidelines: Encapsulating Subsystem Interactions Guidelines: Encapsulating Subsystem Interactions

Subsystems should be represented by their interfaces on interaction diagrams Messages to subsystems are modeled as messages to the subsystem interface Messages to subsystems correspond to operations of the subsystem interface Interactions within subsystems are modeled in Subsystem Design
<<interface>> :InterfaceA
<<subsystem>>
InterfaceA
MySubsystem
op1()
26
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.
11 - 26

Advantages of Encapsulating Subsystem Interactions
Advantages of Encapsulating Subsystem Interactions

Use-case realizations:
Are less cluttered Can be created before the internal designs of subsystems are created (parallel development) Are more generic and easier to change (Subsystems can be substituted.)
27
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.

11 - 27
Parallel Subsystem Development
Parallel Subsystem Development

Concentrate on requirements that affect subsystem interfaces Outline required interfaces Model messages that cross subsystem boundaries Draw interaction diagrams in terms of subsystem interfaces for each use case Refine the interfaces needed to provide messages Develop each subsystem in parallel
Use subsystem interfaces as synchronization points.
28
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.
11 - 28


29
You will now take a closer look at the incorporation of the persistency mechanism.

11 - 29
Use-Case Design Steps: Describe Persistence-Related Behavior

Use-Case Design Steps: Describe Persistence-Related Behavior
Describe Persistence-Related Behavior

Modeling Transactions Writing Persistent Objects
Reading Persistent Objects
Deleting Persistent Objects
30
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.
11 - 30

Modeling Transactions Modeling Transactions

What is a transaction?
Atomic operation invocations All or nothing Provide consistency
Modeling options
Textually (scripts) Explicit messages
Error conditions
Rollback Failure modes May require separate interaction diagrams
31
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.

11 - 31
Incorporating the Architectural Mechanisms: Persistency

Analysis-Class-to-Architectural-Mechanism Map from Use-Case Analysis
Analysis Class Student Schedule CourseOffering Course RegistrationController Analysis Mechanism(s) Persistency, Security Persistency, Security OODBMS Persistency
Persistency, Legacy Interface RDBMS Persistency, Legacy Interface Persistency Distribution
Legacy persistency (RDBMS ) is deferred to Subsystem Design.

32
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.
11 - 32


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.

11 - 33
Detailed Flow of Events Description Options Detailed Flow of Events Description Options
Annotate the interaction diagrams
: Actor1 : ClassA : ClassB
Script
1: Do Something Scripts can be used to describe 2: Do Something More the details surrounding these messages. Notes can include more information Note about a particular diagram element
34
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.
11 - 34


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.

11 - 35
Design Model Unification Considerations
Design Model Unification Considerations

Model element names should describe their function Merge similar model elements Use inheritance to abstract model elements Keep model elements and flows of events consistent
36
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.
11 - 36

Checkpoints: Use-Case Design
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?
37
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.

11 - 37
Checkpoints: Use-Case Design (continued)
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?
38
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 usecase 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.
11 - 38

Review 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?
39

11 - 39
Exercise: Use-Case Design
Exercise: Use-Case Design

Analysis use-case realizations (VOPCs and interaction diagrams) The analysis class to designelement map The analysis class to analysismechanism map Analysis mechanism to designmechanism map Patterns of use for the architectural mechanisms
40
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 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.
The following are not needed if no mechanisms are being applied:
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.
11 - 40

Exercise: Use-Case Design (continued)

The design elements that replaced the analysis classes in the analysis use-case realizations The architectural mechanisms that affect the use-case realizations The design element collaborations needed to implement the use case The relationships between the design elements needed to support the collaborations
41
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 usecase responsibilities were allocated among analysis classes in Use-Case Analysis, usecase responsibilities must now be reallocated among the defined design elements.

11 - 41

Design use-case realization Interaction diagram(s) per usecase 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
42
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
11 - 42

Exercise: Review
Exercise: Review
Compare your use-case realizations
Have 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?
43
After completing a model, it is important to step back and review your work. Some helpful questions are the following: 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.

11 - 43
11 - 44

Module 12 Subsystem Design
IBM Software Group
Mastering Object-Oriented Analysis and Design with UML 2.0 Module 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

12 - 1
Objectives: Subsystem Design
Objectives: Subsystem Design

Describe the purpose of Subsystem Design and where in the lifecycle it is performed Define the behaviors specified in the subsystem's interfaces in terms of collaborations of contained classes Document the internal structure of the subsystem Determine 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.
12 - 2

Module 12 - Subsystem Design
Subsystem Design in Context
Subsystem Design in Context

Subsystem Design
Designer
Design Components
Design the Database
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.

12 - 3
Subsystem Design Overview Subsystem Design Overview

<<subsystem>>
Subsystem
Design Subsystems and Interfaces
Subsystem Design
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 Design Subsystems and Interfaces Project Specific Guidelines Design Model Design Subsystems and Interfaces Design classes Design Model
Input Artifacts:
12 - 4


A Subsystem: Is a cross between a package and a class Realizes one or more interfaces that define its behavior
<<interface>>
Interface
<<subsystem>>
Subsystem Name
Realization (Canonical form) Interface

<<subsystem>>
Subsystem
Interface Realization (Elided form)

5
Subsystem Name
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. Realization is a semantic relationship between two classifiers. One classifier serves as the contract that the other classifier agrees to carry out. 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).

12 - 5
Subsystem Guidelines
Subsystem Guidelines
Goals
Loose coupling Portability, plug-and-play compatibility Insulation from change Independent evolution
<<subsystem>>
Strong Suggestions
Do not expose details, only interfaces Depend only on other interfaces
<<subsystem>>
<<subsystem>>
Key is abstraction and encapsulation

6
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.
12 - 6

Subsystem Design Steps

Distribute subsystem behavior to subsystem elements Document subsystem elements Describe subsystem dependencies Checkpoints
7
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.

12 - 7

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.
12 - 8

Subsystem Responsibilities Subsystem Responsibilities

Subsystem responsibilities defined by interface operations
Model interface realizations
Interface may be realized by

Internal class behavior Subsystem behavior
<<interface>>
ICourseCatalogSystem getCourseOfferings () Initialize ()

<<subsystem>>
CourseCatalogSystem getCourseOfferings () Initialize ()

9
Subsystem responsibility
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.

12 - 9
Distributing Subsystem Responsibilities
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 operation Class diagram(s) containing the required design element relationships Revisit Identify Design Elements Adjust subsystem boundaries and dependencies, as needed
10
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 subsystems 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.)
12 - 10

What Are Gates? What Are Gates?

A connection point in an interaction for a message that comes into or goes outside the Input gate interaction.
A point on the boundary of the Output gate sequence diagram The name of the connected message is the name of the gate
11
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.

12 - 11
Subsystem Interaction Diagrams
Subsystem Interaction Diagrams

: Client Subsystem : Supplier Subsystem
performResponsibility( )
Internal subsystem interactions
Black box view of subsystems

12
All elements on a diagram should represent the same level of abstraction.
12 - 12

Internal Structure of Supplier Subsystem
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.
Supplier Subsystem
: Subsystem Manager
: Design Element1
: Design Element2
13

12 - 13
Modeling Convention: Internal Subsystem Interaction
Modeling Convention: Internal Subsystem Interaction

sd PerformResponsibility : Subsystem Manager performResponsibility( ) : Design Element1 doThis( ) doThat( ) thisAgain( ) thatAgain( ) : Design Element2
White box view of Supplier Subsystem

14
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.
12 - 14

Example: CourseCatalogSystem Subsystem in Context
Example: CourseCatalogSystem Subsystem in Context

: RegisterForCoursesForm 1: // create schedule 1.1: // get course offerings Student wishes to create a new schedule A list of the available course offerings for this semester are displayed A blank schedule is displayed for the Student to select offerings 1.3: // display course offerings 1.1.1: getCourseOfferings : RegistrationController : CourseCatalogSystem : Schedule : Student
Subsystem
1.5: // display blank schedule
ref
Select Offerings
ref
Submit Schedule
Legacy RDBMS Database Access

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

12 - 15

Analysis-Class-to-Architectural-Mechanism Map from Use-Case Analysis
Analysis Class Student Schedule CourseOffering Course RegistrationController Analysis Mechanism(s) Persistency, Security Persistency, Security OODBMS Persistency
Persistency, Legacy Interface RDBMS Persistency, Legacy Interface Persistency Distribution
OODBMS Persistency was discussed in Use-Case Design

16
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.
12 - 16

Review: Incorporating JDBC: Steps
Review: Incorporating JDBC: Steps

1. Provide access to the class libraries needed to implement JDBC Provide java.sql package 2. Create the necessary DBClasses One DBClass per persistent class Course Offering persistent class => DBCourseOffering
= Done
17
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.

12 - 17
Review: Incorporating JDBC: Steps (continued)
Review: Incorporating JDBC: Steps (continued)

3. Incorporate DBClasses into the design Allocate to package/layer DBCourseOffering placed in CourseCatalogSystem subsystem Add relationships from persistency clients Persistency clients are the CourseCatalogSystem subsystem clients 4. Create/Update interaction diagrams that describe: Database initialization Persistent class access: Create, Read, Update, Delete
18
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.
12 - 18

Review: Persistency: RDBMS: JDBC: Read
Review : Persistency: RDBMS: JDBC: Read

: PersistencyClient : DBClass : Connection : Statement : ResultSet : PersistentClassList : PersistentClass 1. read(string) 1.1. createStatement( )
The criteria used to access data for the persistent class
Returns a Statement
1.2. executeQuery(string) 1.4. new( )
The SQL statement built by the DBClass using the given criteria is passed to executeQuery() 1.3 // executeQuery()
loop [for each class from execute query] 1.5. new()
Create a list to hold all retrieved data
loop [for each attribute in class] 1.6. getString( ) 1.7. setData( )
1.8. add(PersistentClass)
19

12 - 19
Example: Local CourseCatalogSystem Subsystem Interaction

Example: Local CourseCatalogSystem Subsystem Interaction
Subsystem
sd getCourseOfferings
persistencyClient :CourseCatalog System getCourse Offering() //execute Query() dbClass :DBCourse Offering : Connection : Statement : ResultSet persistent ClassList : Course OfferingList persistent Class : Course Offering
: Course Catalog
ref JDBC Read
20
12 - 20

Example: Billing System Subsystem In Context
Example: Billing System Subsystem In Context

subsystem interface
: CloseRegistration : Registrar Form : CloseRegistration Controller : ICourseCatalog System : Course Offering : Schedule : Student. : Ibilling System 1. // close registration( ) 1.1. // is registration open?( ) 2. // close registration( )
Retrieve a list of course offerings for the current semester Close registration for each course offering
2.1. getCourseOfferings(Semester) Repeat twice this is for simplicity; realistically, an indefinite number of iterations could occur) Finally commit or cancel the course offering once all leveling has occurred Send student and tuition to the Billing System, which will do the actual billing to the student for the schedule. 2.2. // close registration( )
If the maximum number of selected primary courses have not been committed, select alternate course offerings).
2.3. // level( ) 2.4. // close( ) Currently assuming tuition based on number of offerings taken and certain attributes of students. If different offerings get different prices this will change slightly.
2.5. getTuition( ) 2.6. submitBill(Student, double)
subsystem responsibility
21
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.

12 - 21
Example: Local BillingSystem Subsystem Interaction
Example: Local BillingSystem Subsystem Interaction

Subsystem
Billing System Client : BillingSystem : StudentBillingTransaction : Student :BillingSystemInterface : Billing System
1. submitBill(Student, double) Retrieve the information that must be included on the bill
1.1. create(Student, double)
1.1.1. // get contact info( )
1.2. submit(StudentBillingTransaction) 1.2.1. // open connection( ) 1.2.2. // process transaction( ) 1.2.3. // close connection( )
22
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.
12 - 22


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

12 - 23
Example: CourseCatalogSystem Subsystem Elements

Example: CourseCatalogSystem Subsystem Elements
Subsystem Component
getCourseOfferings(forSemester : Semester) : CourseOfferingList <<subsystem >> CourseCatalogSystem getCourseOfferings(forSemester : Semester) : CourseOfferingList
Subsystem Interface
CourseOfferingList
DBCourseOfferring create() : CourseOffering read(searchCriteria : string) : CourseOfferingList
new() add() 1 0..* DriverManager

(from java.sql)
1 1 Connection
(from java.sql)
<<Entity>> CourseOffering
Statement
(from java.sql)
ResultSet
(from java.sql)
getConnection(url, user, pass) : Connection
new() setData()
createStatement()
executeQuery() executeUpdate()
getString()
24
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.
12 - 24

Example: Billing System Subsystem Elements
Example: Billing System Subsystem Elements

<<Interface>> IBillingSystem
submitBill()
StudentBillingTransaction create(forStudent : Student, forAmount : double)
Subsystem Interface
<<subsystem>> BillingSystem submitBill(forStudent : Student, forTuition : double) 1 <<Entity>> Student
// get contact info()
Subsystem Component
0..1 BillingSystemInterface submit(theTransaction : StudentBillingTransaction)
25
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.

12 - 25

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.
12 - 26

Subsystem Dependencies: Guidelines Subsystem Dependencies: Guidelines

Subsystem dependency on a subsystem
<<subsystem>> <<subsystem>>
Client Support
Server
Server Support
Flexible, Preferred
Subsystem dependency on a package

Supporting Types
<<subsystem>>
Use with care
Client Support
27
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 dependedon package.

12 - 27
Example: CourseCatalogSystem Subsystem Dependencies

Example: CourseCatalogSystem Subsystem Dependencies
<<subsystem>> CourseCatalogSystem (from Business Services)
External System Interfaces (from Business Services)
java.sql (from Middleware)
28
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.
12 - 28

Example: BillingSystem Subsystem Dependencies
Example: BillingSystem Subsystem Dependencies
<<subsystem>>
BillingSystem
(from Business Services)
External System Interfaces (from Business Services)
29
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.

12 - 29

30
Now we will discuss the kinds of things you should look for when reviewing the results of Subsystem Design.
12 - 30

Checkpoints: Design Subsystems
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?
31
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.

12 - 31
Review Review: Subsystem Design

What is the purpose of Subsystem Design? What are gates? Why should dependencies on a subsystem be on the subsystem interface?
32
12 - 32

Exercise: Subsystem Design
Exercise: Subsystem Design

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

12 - 33
Exercise: Subsystem Design (continued)

Identify the following for a particular subsystem(s):
The design elements contained within the subsystem and their relationships The applicable architectural mechanisms The interactions needed to implement the subsystem interface operations
34
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 (thats 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.
12 - 34


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)
35
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.

12 - 35
Exercise: Review
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?
36
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.
12 - 36

Module 13 Class Design
IBM Software Group
Mastering Object-Oriented Analysis and Design with UML 2.0 Module 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

13 - 1
Objectives: Class Design
Objectives: Class Design

Define the purpose of Class Design and where in the lifecycle it is performed Identify additional classes and relationships needed to support implementation of the chosen architectural mechanisms Identify and analyze state transitions in objects of state-controlled classes Refine 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).
13 - 2

Module 13 - Class Design
Class Design in Context
Class Design in Context

Class Design
Designer
Design Components
Design the Database
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. UseCase 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.

13 - 3
Class Design Overview Class Design Overview

Design Use-Case Realization Analysis Use-Case Realization
Class Design
Design Classes
Analysis Classes
4
Design Model
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. Supplementary Specifications Project Specific Guidelines Analysis Classes Analysis use-case realization Design classes Design Model Design use-case realization Design classes Design Model
Input Artifacts:
The detailed steps performed during this activity are summarized on the next page, and described in the remainder of this module.
13 - 4

Class Design Steps
Class Design Steps

Create Initial Design Classes Define Operations Define Methods Define States Define Attributes Define Dependencies Define Associations Define Internal Structure Define Generalizations Resolve Use-Case Collisions Handle Nonfunctional Requirements in General Checkpoints
5
The Class Design steps that you will address in this module are listed above.

13 - 5
Class Design Steps
Class Design Steps

Create Initial Design Classes Define Operations Define Methods Define States Define Attributes Define Dependencies Define Associations Define Internal Structure Define Generalizations Resolve Use-Case Collisions Handle Non-Functional Requirements in General Checkpoints
6
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.
13 - 6

Class Design Considerations Class Design Considerations

Class stereotype
Boundary Entity Control
Applicable design patterns Architectural mechanisms

Persistence Distribution etc.
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.

13 - 7
How Many Classes Are Needed?
How Many Classes Are Needed?

Many, simple classes means that each class Encapsulates less of the overall system intelligence Is more reusable Is easier to implement A few, complex classes means that each class Encapsulates a large portion of the overall system intelligence Is less likely to be reusable Is more difficult to implement
A class should have a single well-focused purpose. A class should do one thing and do it well!
8
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.
13 - 8

Strategies for Designing Boundary Classes
Strategies for Designing Boundary Classes

User interface (UI) boundary classes
What user interface development tools will be used? How much of the interface can be created by the development tool?
External system interface boundary classes

Usually model as subsystem
MainWindow
<<subsystem>>
SubWindow
MainForm Button DropDownList
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.

13 - 9
Strategies for Designing Entity Classes
Strategies for Designing Entity Classes

Entity objects are often passive and persistent Performance requirements may force some re-factoring
Analysis
<< Entity >> FatClass - privateAttr - commonlyUsedAttr1 - commonlyUsedAttr2 - rarelyUsed1 - rarelyUsed2
Design
FatClass - privateAttr + getCommonlyUsedAttr1() + getCommonlyUsedAttr2() + getRarelyUsedAtt1() + getRarelyUsedAtt2()
0..1
FatClassDataHelper - commonlyUsedAttr1 - commonlyUsedAttr2
FatClassLazyDataHelper - rarelyUsedAttr1 - rarelyUsedAttr2
10
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 wed 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.
13 - 10

Strategies for Designing Control Classes
Strategies for Designing Control Classes

What happens to Control Classes?
Are they really needed? Should they be split?
How do you decide?

Complexity Change probability Distribution and performance Transaction management
11
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.

13 - 11
Define Operations Class Design Steps

12
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.
13 - 12

Operations: Where Do You Find Them?
Operations: Where Do You Find Them?

Messages displayed in interaction diagrams
: ClassA : ClassB : ClassA : ClassB
1 : //Perform Responsibility
1 : performResponsibility (): result
Other implementation dependent functionality

Manager functions Need for class copies Need to test for equality
13
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.)

13 - 13
Name and Describe the Operations
Name and Describe the Operations

Create appropriate operation names
Indicate the outcome Use client perspective Are consistent across classes
Define operation signatures

operationName([direction]parameter : class,..) : returnType Direction is in (default), out or inout Provide short description, including meaning of all parameters
14
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 USERs 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.
13 - 14

Guidelines: Designing Operation Signatures
Guidelines: Designing Operation Signatures

When designing operation signatures, consider if parameters are:
Passed by value or by reference Changed by the operation Optional Set to default values In valid parameter ranges
The fewer the parameters, the better Pass objects instead of data bits
15
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.

13 - 15
Operation Visibility
Operation Visibility
Visibility is used to enforce encapsulation May be public, protected, or private
Private operations
Public operations
Protected operations
16
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 its 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.
13 - 16

How Is Visibility Noted?
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 ()
17
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

13 - 17
Scope
Scope
Determines number of instances of the attribute/operation
Instance: one instance for each class instance Classifier: one instance for all class instances
Classifier scope is denoted by underlining the attribute/operation name

Class1
- classifierScopeAttr - instanceScopeAttr + classifierScopeOp () + instanceScopeOp ()
18
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.
13 - 18

Example: Scope
Example: Scope
Student
- name - address - studentID - 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
19
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.

13 - 19
Example: Define Operations
Example: Define Operations

<<Interface>>
+ submitSchedule() + saveSchedule() + getCourseOfferings() : CourseOfferingList + getCurrentSchedule ( [in] forStudent : Student, [in] forSemester : Semester) : Schedule + deleteCurrentSchedule() + new ( [in] forStudentID : String) + getStudent ( [in] anID : int) : Student
0..* 1
+ getCourseOfferings() + initialize()
0..1
+ registrant 0..1 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
20
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.
13 - 20

Define Methods Class Design Steps

21
Once the operations have been defined, some additional information may need to be documented for the class implementers.

13 - 21
Define Methods
Define Methods
What is a method? Describes operation implementation Purpose Define special aspects of operation implementation Things to consider: Special algorithms Other objects and operations to be used How attributes and parameters are to be implemented and used How relationships are to be implemented and used
22
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. How parameters are to be implemented. Any special algorithms to be used.
More specific requirements may concern:
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.
13 - 22

Define States Class Design Steps

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

13 - 23
Define States
Define States
Purpose
Design how an objects state affects its behavior Develop state machines to model this behavior
Things to consider:
Which objects have significant state? How to determine an objects possible states? How do state machines map to the rest of the model?
24
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 objects states and an objects operations.
13 - 24

What is a State Machine?
What is a State Machine?

A directed graph of states (nodes) connected by transitions (directed arcs) Describes the life history of a reactive object
Guard Condition Event
State1
Activity
State2
Event(args)[guard condition]/activity
Transition State State
25
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.

13 - 25
Pseudo States
Pseudo States
Initial state
The state entered when an object is created Mandatory, can only have one initial state Initial State
State1
Choice
Dynamic evaluation of subsequent guard conditions Only first segment has a trigger
Choice
Final state
Indicates the objects end of life Optional, may have more than one
26
Final State
State2
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 is optional. More than one final state may exist. A final state is indicated by a bulls eye.
A final state indicates the end of life for an object
13 - 26

Identify and Define the States
Identify and Define the States

Significant, dynamic attributes
The maximum number of students per course offering is 10
numStudents < 10 numStudents > = 10
Open
Closed
Existence and non-existence of certain links

Professor
0..1 0..*
Link to Professor exists
Link to Professor doesnt exist
Assigned
Unassigned
CourseOffering
27
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 preconditions 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.

13 - 27
Identify the Events
Identify the Events

Look at the class interface operations
CourseOffering
+ addProfessor() + removeProfessor()
0..* 0..1
Professor
Events: addProfessor, removeProfessor
28
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.
13 - 28

Identify the Transitions
Identify the Transitions

For each state, determine what events cause transitions to what states, including guard conditions, when needed Transitions describe what happens in response to the receipt of an event
CourseOffering
+ addProfessor() + removeProfessor() 0..* 0..1
Professor
Unassigned
removeProfessor
addProfessor
Assigned
29
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.

13 - 29
Add Activities
Add Activities
Entry
Executed when the state is entered
StateA
Entry/anAction
Do
Ongoing execution
StateB
Do/anActivity
Exit
Executed when the state is exited
StateC
Exit/someAction
30
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.
13 - 30

Example: State Machine
Example: State Machine

addStudent / numStudents = numStudents + 1 / numStudents = 0 Unassigned closeRegistration cancel close removeProfessor cancel [ numStudents = 10 ] cancel Full close[ numStudents < 3 ] close Canceled do/ Send cancellation notices removeStudent [numStudents >0]/ numStudents = numStudents - 1
addProfessor
addStudent / numStudents = numStudents + 1 Assigned
[ numStudents = 10 ]
closeRegistration [ has Professor assigned ]
closeRegistration[ numStudents >= 3 ] close[ numStudents >= 3 ]
Committed do/ Generate class roster
removeStudent[ numStudents > 0] / numStudents = numStudents - 1

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

13 - 31
Example: State Machine with Nested States and History

Example: State Machine with Nested States and History
superstate
/ numStudents = 0 Open closeRegistration close Closed Canceled do/ Send cancellation notices cancel Full close
Unassigned
substate
remove a professor add a professor
cancel close[ numStudents < 3 ] [ numStudents = 10 ]
closeRegistration [ has Professor assigned ]
Assigned addStudent / numStudents = numStudents + 1 H
closeRegistration[ numStudents >= 3 ]
Committed do/ Generate class roster
close[ numStudents >= 3 ]
removeStudent[ numStudents > 0] / numStudents = numStudents - 1

32
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.
13 - 32

Which Objects Have Significant State?
Which Objects Have Significant State?

Objects whose role is clarified by state transitions Complex use cases that are state-controlled It is not necessary to model objects such as:
Objects with straightforward mapping to implementation Objects that are not state-controlled Objects with only one computational state
33
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.

13 - 33
How Do State Machines Map to the Rest of the Model?

How Do State Machines Map to the Rest of the Model?
Events may map to operations Methods should be updated with state-specific information States are often represented using attributes
This serves as input into the Define Attributes step
CourseOffering
- numStudents + addStudent()
Open
addStudent / numStudents = numStudents + 1
Closed
[numStudents<10]
[numStudents>=10]
34
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.
13 - 34

Define Attributes Class Design Steps

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

13 - 35
Attributes: How Do You Find Them?
Attributes: How Do You Find Them?

Examine method descriptions Examine states Examine any information the class itself needs to maintain
36
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.
13 - 36

Attribute Representations
Attribute Representations
Specify name, type, and optional default value attributeName : Type = Default Follow naming conventions of implementation language and project Type should be an elementary data type in implementation language Built-in data type, user-defined data type, or user-defined class Specify visibility Public: + Private: Protected: #
37
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.

13 - 37
Derived Attributes
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 needed When you must trade-off runtime performance versus memory required
38
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.
13 - 38

Example: Define Attributes
Example: Define Attributes

<< interface >>
0..1 0..1 0..1
+ currentSchedule 0..1 + registrant 1 0..*
Schedule
- semester : Semester 0..* 0..*
Student
- name - address - nextAvailID : int - studentID : int - dateOfBirth : Date 0..2 + alternateCourses 0..4 + primaryCourses
CourseOffering
- number : String = 100 - startTime : Time - endTime : Time - day : String - /numStudents : int = ()
39
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.

13 - 39
Exercise 1: Class Design

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
40
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.
13 - 40

Exercise 1: Class Design (continued)

Attributes, operations, and their complete attribute signatures Attribute and operation scope and visibility Any additional relationships and/or classes to support the defined attributes and attribute signatures Class(es) with significant statecontrolled behavior The important states and transitions for the identified class
41
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.

13 - 41

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
42
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. References to sample diagrams within the course that are similar to what should be produced are: Operations: p.13-20 State machines: p. 13-32 Attributes: p. 13-39
13 - 42

Exercise 1: Review
Exercise 1: Review
Compare your results
Is 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?
43
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 objects attributes, operations, and relationships. Do not read anything extra into the lifetime of the object that cannot be supported by the class structure.

13 - 43
Define Dependencies Class Design Steps

44
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.
13 - 44

Define Dependency
Define Dependency
What Is a Dependency?
A relationship between two objects
Client Supplier
Purpose
Determine where structural relationships are NOT required
Things to look for :

What causes the supplier to be visible to the client
45
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.

13 - 45
Dependencies vs. Associations
Dependencies vs. Associations

Associations are structural relationships Dependencies are nonstructural relationships In order for objects to know each other they must be visible
Local variable reference Parameter reference Global reference Field reference
Dependency Association
Supplier1
Supplier2
Client
46
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.
13 - 46

Associations vs. Dependencies in Collaborations
Associations vs. Dependencies in Collaborations

An instance of an association is a link
All links become associations unless they have global, local, or parameter visibility Relationships are context-dependent
Dependencies are transient links with:

A limited duration A context-independent relationship A summary relationship
A dependency is a secondary type of relationship in that it doesn't tell you much about the relationship. For details you need to consult the collaborations.
47
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."

13 - 47
Local Variable Visibility
Local Variable Visibility

The op1() operation contains a local variable of type ClassB
ClassA
+ op1 ( )
ClassB
48
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.
13 - 48

Parameter Visibility
Parameter Visibility
The ClassB instance is passed to the ClassA instance
ClassA
+ op1 ( [in] aParam : ClassB )
ClassB
49
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.

13 - 49
Global Visibility
Global Visibility
The ClassUtility instance is visible because it is global
ClassA
+ op1 ( )
ClassB
+ utilityOp ( )
50
Is the receiver a global? If so, establish a dependency between the sender and receiver classes in a class diagram containing the two classes.
13 - 50

Identifying Dependencies: Considerations
Identifying Dependencies: Considerations

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 dont share the same instance (local visibility) How long does it take to create/destroy? Expensive? Use field, parameter, or global visibility Strive for the lightest relationships possible
51
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.

13 - 51
Example: Define Dependencies (before)
Example: Define Dependencies (before)

RegistrationController + // submit schedule () + // save schedule () + // create schedule with offerings () + // get course offerings () 0..1 0..* 1 <<interface>> ICourseCatalogSystem + getCourseOfferings ( [in] forSemester : Semester) : CourseOfferingList + courseCatalog
0..1
Schedule - semester : Semester 0..1 + submit () + currentSchedule + //save () # any conflicts? () + //create with offerings() 0..* 0..* 0..* 1 alternateCourses + primaryCourses 0..2 0..4 CourseOffering - number : String = "100" - startTime : Time - endTime : Time - day : String + addStudent ( [in] aStudentSchedule : Schedule)
+ removeStudent ( [in] aStudentSchedule : Schedule)
0..1
+ registrant Student
- name - address - StudentID : int + addSchedule ( [in] aSchedule : Schedule ) + getSchedule ( [in] forSemester : Semester ) : Schedule + hasPrerequisites ( [in] forCourseOffering : CourseOffering ) : boolean # passed ( [in] aCourseOffering : CourseOffering ) : boolean
+ new () + setData ()
52
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.
13 - 52

Example: Define Dependencies (after)
Example: Define Dependencies (after)

RegistrationController + // submit schedule () + // save schedule () + // create schedule with offerings () + // get course offerings () 0..1 0..1 <<interface>> ICourseCatalogSystem + getCourseOfferings ( [in] forSemester : Semester) : CourseOfferingList
Global visibility
Schedule - semester : Semester 0..1 + submit () + currentSchedule + //save () # any conflicts? () + //create with offerings() 0..* 0..* 0..* 1 alternateCourses 0..2 0..4
Field visibility
0..1 + registrant Student - name - address - StudentID : int
Field visibility
+ primaryCourses
CourseOffering - number : String = "100" - startTime : Time - endTime : Time - day : String + addStudent ( [in] aStudentSchedule : Schedule)
+ removeStudent ( [in] aStudentSchedule : Schedule)
+ addSchedule ( [in] aSchedule : Schedule ) + getSchedule ( [in] forSemester : Semester ) : Schedule + hasPrerequisites ( [in] forCourseOffering : CourseOffering ) : boolean # passed ( [in] aCourseOffering : CourseOffering ) : boolean
Parameter visibility
53
+ new () + setData ()
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 Students Schedule for the current semester). These instances need to be accessed by more than one of the RegistrationControllers 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.

13 - 53
Define Associations Class Design Steps

54
We now are going to turn our attention to the remaining class associations, adding some Design-level refinements that drive the implementation.
13 - 54

Define Associations
Define Associations
Purpose
Refine remaining associations
Things to look for :

Association vs. Aggregation Aggregation vs. Composition Attribute vs. Association Navigability Association class design Multiplicity design
55
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.

13 - 55
A form of aggregation with strong ownership and coincident lifetimes
The parts cannot survive the whole/aggregate
Whole Part
Whole
Part
Composition
56
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.
13 - 56

Aggregation: Shared vs. Non-shared
Aggregation: Shared vs. Non-shared

Shared Aggregation
Multiplicity > 1 Whole
1..* 0..*
Part
Non-shared Aggregation
Multiplicity = 1 Whole
1 0..*
Multiplicity = 1 Whole
1 0..*
Part
Part
Composition
By definition, composition is non-shared aggregation.

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

13 - 57
Aggregation or Composition?
Aggregation or Composition?
Consideration
Lifetimes of Class1 and Class2
Class1 Aggregation Class1 Composition Class2 Class2
58
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.
13 - 58

Example: Composition
Example: Composition
Student
1 0..*
Schedule
1 1
59
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.

13 - 59
Attributes vs. Composition
Attributes vs. 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
60
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.
13 - 60

Example: Attributes vs. Composition
Example: Attributes vs. Composition

Attribute Student
- name - address - nextAvailID : int - StudentID : int - dateofBirth : Date + addSchedule () + getSchedule () + delete Schedule () + hasPrerequisites () # hasPassed ()
Schedule
- semester : Semester 1 + submit () + //save () 0..* # any conflicts? () + //create with offerings () + new () Composition of + passed ()
separate class
61
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.

13 - 61
Review: What Is Navigability?
Review: What Is Navigability?

Indicates that it is possible to navigate from an associating class to the target class using the association
<<Control>> RegistrationController
Schedule
CourseOffering
62
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.
13 - 62

Navigability: Which Directions Are Really Needed?
Navigability: Which Directions Are Really Needed?

Explore interaction diagrams Even when both directions seem required, one may work
Navigability in one direction is infrequent Number of instances of one class is small
Schedule + primaryCourses CourseOffering
0..* 0..4
?
0..* 0..4

0..* 0..4
63
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 associations 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 (bidirectional) 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.

13 - 63
Example: Navigability Refinement
Example: Navigability Refinement

Total number of Schedules is small, or Never need a list of the Schedules on which the CourseOffering appears
Schedule
0..* + primaryCourses 0..4
CourseOffering
Total number of CourseOfferings is small, or Never need a list of CourseOfferings on a Schedule Total number of CourseOfferings and Schedules are not small Must be able to navigate in both directions
Schedule
0..*
+ primaryCourses 0..4
CourseOffering
Schedule
0..*
CourseOffering
64
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.
13 - 64

Association Class
Association Class
A class is attached to an association Contains properties of a relationship Has one instance per link
<<entity>> ScheduleOfferingInfo - status + // is selected () + // mark as selected () + // mark as cancelled ()
0..* + alternateCourses Schedule 0..*
0..2 CourseOffering
<<entity>> PrimaryScheduleOfferingInfo - grade + // is enrolled in? () + // mark as enrolled in () + // mark as committed ()
65
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 Students 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.

13 - 65
Example: Association Class Design
Example: Association Class Design

0..* + alternateCourses 0..2
Schedule
0..* + primaryCourses 0..4
CourseOffering
PrimaryScheduleOfferingInfo
- grade + // is enrolled in? () + // mark as enrolled in () + // mark as committed ()
Design Decisions
0..* + alternateCourses 0..2
Schedule
CourseOffering
1 - theCourseOffering
1 0..4 - primaryCourseOfferingInfo
0..*
PrimaryScheduleOfferingInfo
- grade + // is enrolled in? () + // mark as enrolled in () + // mark as committed ()
66
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.
13 - 66

Multiplicity Design
Multiplicity Design
Multiplicity = 1, or Multiplicity = 0..1
May be implemented directly as a simple value or pointer No further design is required
Professor 0..1
+ Instructor
0..*
CourseOffering
Multiplicity > 1
Cannot use a simple value or pointer Further design may be required
Needs a container for CourseOfferings
Professor 0..1
+ Instructor
0..*
CourseOffering
67
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.

13 - 67
Multiplicity Design Options
Multiplicity Design Options

Professor
0..1
+ Instructor
0..*
CourseOffering
Explicit Modeling of a Container Class

Professor
Detail Container via Note

List
0..1
0..*
CourseOfferingList
+ Instructor
CourseOffering
Professor
0..1
0..*
CourseOffering
+ Instructor
68
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.
13 - 68

What Is a Parameterized Class (Template)?
What Is a Parameterized Class (Template)?

A class definition that defines other classes Often used for container classes
Some common container classes: Sets, lists, dictionaries, stacks, queues
Formal Arguments ParameterizedClass List
Item
69
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.

13 - 69
Instantiating a Parameterized Class
Instantiating a Parameterized Class
Formal Arguments ParameterizedClass
<<bind>> (ActualArgument)
InstantiatedClass
ActualArgument
70
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.
13 - 70

Example: Instantiating a Parameterized Class
Example: Instantiating a Parameterized Class

Before
CourseOfferingList
1 0..*
CourseOffering
After
Item List
<<bind>> (CourseOffering)
CourseOfferingList
1 0..*
CourseOffering
71
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.

13 - 71
Multiplicity Design: Optionality
Multiplicity Design: Optionality

If a link is optional, make sure to include an operation to test for the existence of the link
Professor
+ isTeaching () : boolean 0..1 0..*
CourseOffering
+ hasProfessor () : boolean
72
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.
13 - 72

Define Internal Structure Class Design Steps

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

13 - 73
What is Internal Structure?
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.
74
13 - 74

Review: What Is a Structured Class?
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 structure
The 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
75
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.

13 - 75
What Is a Connector?
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.
76
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.
13 - 76

Review: What Is a Port?
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 clients
External clients have no visibility to internals
A class may have a number of ports

Each port has a set of provided and required interfaces
77
Since the port is a structural element, its 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.

13 - 77
Review: Port Types
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.
78
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.
13 - 78

Review: Structure Diagram With Ports
Review: Structure Diagram With Ports

Structured Class Name
Behavior Port
Service Port Relay Port Assembly Connector
partA
Delegation Connector
partB
79

13 - 79
Review: Structure Diagram
Review: Structure Diagram

Course Registration System : StudentManagementSystem
: BillingSystem
80
13 - 80

Example: Structure Diagram Detailed
Example: Structure Diagram Detailed

Course Registration System StudentManagementSystem : RegistrationController : MainStudentForm
: BillingSystem
81

13 - 81
Define Generalizations Class Design Steps

Create Initial Design Classes Define Operations Light Define Methods Define States Define Attributes Define Dependencies Define Associations Define Internal Structure Define Generalizations Resolve Use-Case Collisions Handle Non-Functional Requirements in General Checkpoints
82
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.
13 - 82

Review: Generalization
Review: Generalization
One class shares the structure and/or behavior of one or Superclass (Parent) more classes (Ancestor) Is a kind of relationship Generalization In Analysis, use Relationship sparingly
Account + balance + name + number + withdraw () + createStatement ()
Checking
Savings + getInterest ()
Subclasses (Child) (Descendants)
83
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 superclass.

13 - 83
Abstract and Concrete Classes
Abstract and Concrete Classes

Abstract classes cannot have any objects Concrete classes can have objects
Discriminator
Animal
+ communicate ()
Abstract class Abstract operation
Communication
There are no direct instances of Animal
Lion
+ communicate ()
Tiger
+ communicate ()
All objects are either lions or tigers
84
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.
13 - 84

Multiple Inheritance: Problems
Multiple Inheritance: Problems

Name clashes on attributes or operations Repeated inheritance
SomeClass Animal
+ color + getColor ()
FlyingThing
Animal
FlyingThing
Bird
Bird
Resolution of these problems is implementation-dependent.

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

13 - 85
Generalization Constraints
Generalization Constraints
Complete
End of the inheritance tree
Incomplete
Inheritance tree may be extended
Disjoint
Subclasses mutually exclusive Doesnt support multiple inheritance
Overlapping
Subclasses are not mutually exclusive Supports multiple inheritance
86
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.
13 - 86

Example: Generalization Constraints
Example: Generalization Constraints

Asset
{disjoint}
Multiple Inheritance not supported
Bank Account
Real Estate
Security
{disjoint,complete}
{disjoint}
Stock Bond
Savings
Checking
End of inheritance hierarchy
87
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).

13 - 87
Example: Generalization Constraints (continued)
Example: Generalization Constraints (continued)

Multiple inheritance supported {overlapping}
LandVehicle WaterVehicle Vehicle
AmphibiousVehicle
88
This example demonstrates the use of the overlapping constraint. The AmphibiousVehicle class can inherit from both LandVehicle and WaterVehicle, which both inherit from Vehicle.
13 - 88

Generalization vs. Aggregation

Generalization and aggregation are often confused
Generalization represents an is a or kind-of relationship Aggregation represents a part-of relationship
Window Scrollbar
WindowWithScrollbar
Is this correct?
89
The key phrases is a and part of help to determine correct relationship. With inheritance: Keywords is a One object Keywords part of Relates multiple objects
With Aggregation:
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?

13 - 89

Window Scrollbar
WindowWithScrollbar
Window
A WindowWithScrollbar is a Window A WindowWithScrollbar contains a Scrollbar

1 1
WindowWithScrollbar
Scrollbar
90
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.
13 - 90

Generalization: Share Common Properties and Behavior
Generalization: Share Common Properties and Behavior

Follows the is a style of programming Class substitutability
Animal
+ communicate ()
List
+ insertTop ([in] item) + insertBottom ([in] item) + removeTop () + removeBottom () + insert ([in] item, [in] position)
Lion
+ communicate ()
Tiger
+ communicate ()
Stack
Do these classes follow the is a style of programming?

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

13 - 91
Generalization: Share Common Properties and Behavior (cont.)

Generalization: Share Common Properties and Behavior (cont.)
Animal
+ communicate ()
List
Lion
+ communicate ()
Tiger
+ communicate ()
Stack
92
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.
13 - 92

Generalization: Share Implementation: Factoring
Generalization: Share Implementation: Factoring

Supports the reuse of the implementation of another class Cannot be used if the class you want to reuse cannot be changed
List
SequentialContainer
+ insertTop ([in] item) + removeTop ()
List Stack
+ insertBottom ([in] item) + removeBottom () + insert ([in] item, [in] position)
Stack
93
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.

13 - 93
Generalization Alternative: Share Implementation: Delegation

Generalization Alternative: Share Implementation: Delegation
Supports the reuse of the implementation of another class Can be used if the class you want to reuse cannot be changed
List
Stack
+ insertBottom ([in] item) + removeBottom () + insert ([in] item, [in] position) 1 1
Stack
List
94
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.
13 - 94

Implementation Inheritance
Implementation Inheritance
Ancestor public operations, attributes, and relationships are NOT visible to clients of descendent class instances Descendent class must define all access to ancestor operations, attributes, and relationships
List
+ insertTop ([in] item) + insertBottom ([in] item) + removeTop () + removeBottom ()
<<implementation>>
Stack
+ push (item) + pop ()
push() and pop() can access methods of List but instances of Stack cannot
95
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.

13 - 95

The ability to hide many different implementations behind a single interface
Manufacturer A
Manufacturer B
Manufacturer C
96
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.
13 - 96

Generalization: Implement Polymorphism
Generalization: Implement Polymorphism

Animal
+ communicate ()
Lion
+ communicate ()
Tiger
+ communicate ()
Without Polymorphism
if animal = Lion then Lion communicate else if animal = Tiger then Tiger communicate end
With Polymorphism
Animal communicate
97
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.

13 - 97
Polymorphism: Use of Interfaces vs. Generalization
Polymorphism: Use of Interfaces vs. Generalization

Interfaces support implementation-independent representation of polymorphism
Realization relationships can cross generalization hierarchies
Interfaces are pure specifications, no behavior

Abstract base class may define attributes and associations
Interfaces are totally independent of inheritance

Generalization is used to re-use implementations Interfaces are used to re-use behavioral specifications
Generalization provides a way to implement polymorphism

98
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.
13 - 98

Polymorphism via Generalization Design Decisions
Polymorphism via Generalization Design Decisions

Provide interface only to descendant classes?
Design ancestor as an abstract class All methods are provided by descendent classes
Provide interface and default behavior to descendent classes?

Design ancestor as a concrete class with a default method Allow polymorphic operations
Provide interface and mandatory behavior to descendent classes?

Design ancestor as a concrete class Do not allow polymorphic operations
99
When designing the use of generalization to support polymorphism, there are three basic decisions that must be made: Do you want to provide a functions 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 functions 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 functions 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.

13 - 99
What Is Metamorphosis?
What Is Metamorphosis?
Metamorphosis
1. 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. ~ Websters New World Dictionary, Simon & Schuster, Inc.
Metamorphosis exists in the real world. How should it be modeled?
100
13 - 100

Example: Metamorphosis
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 students Full-time students have an expected graduation date but part-time students do not
PartTimeStudent
+ name + address + studentID + maxNumCourses
FullTimeStudent
+ name + address + studentID + gradDate
101

13 - 101
Modeling Metamorphosis: One Approach
Modeling Metamorphosis: One Approach

A generalization relationship may be created
What happens if a part-time student becomes a full-time student?
Student
+ name + address
+ studentID
PartTimeStudent
+ maxNumCourses
FullTimeStudent
+ gradDate
102
13 - 102

Modeling Metamorphosis: Another Approach
Modeling Metamorphosis: Another Approach

Inheritance may be used to model common structure, behavior, and/or relationships to the changing parts
Student
+ name + address + studentID
Student
+ name + address + studentID + changeToFullTime
1 1
Classification
PartTimeStudent
+ maxNumCourses
FullTimeStudent
+ gradDate
PartTimeClassification
+ maxNumCourses
FullTimeClassification
+ gradDate
103
This example shows the before and after with regard to implementing metamorphosis.

13 - 103
Modeling Metamorphosis: Another Approach (continued)

Modeling Metamorphosis: Another Approach (continued)
Metamorphosis is accomplished by the object talking to the changing parts
: StudentManager : Student : PartTimeClassification
1 : changeToFullTime 2 : delete 3 : create
X
: FullTimeClassification
104
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.
13 - 104

Metamorphosis and Flexibility
Metamorphosis and Flexibility

This technique also adds to the flexibility of the model
ResidentInformation
+ dorm + room + roomKeyID
Student
0..1 1
+ name + address + studentID + changeToFullTime
1 1
Classification
PartTimeClassification
+ maxNumCourses
FullTimeClassification
+ gradDate
105
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.

13 - 105
Resolve Use-Case Collisions Class Design Steps

106
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.
13 - 106

Resolve Use-Case Collisions
Resolve Use-Case Collisions

Multiple use cases may simultaneously access design objects Options Use synchronous messaging => first-come firstserve order processing Identify operations (or code) to protect Apply access control mechanisms Message queuing Semaphores (or tokens) Other locking mechanism Resolution is highly dependent on implementation environment
107
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.

13 - 107
Handle Non-Functional Requirements in General Class Design Steps

108
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).
13 - 108

Handle Non-Functional Requirements in General
Handle Non-Functional Requirements in General

Analysis Mechanism (Conceptual) Persistency
Design Mechanism (Concrete) Legacy Data RDBMS
Implementation Mechanism (Actual) JDBC
SomeDesignClass
Persistency
New Data OODBMS
ObjectStore
Design Guidelines
Distribution
Java 1.2 from Sun
109
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

13 - 109
Class Design Steps
Class Design Steps

110
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.
13 - 110

Checkpoints: Classes
Checkpoints: Classes
Clear class names One well-defined abstraction Functionally coupled attributes/behavior Generalizations were made All class requirements were addressed Demands are consistent with state machines Complete class instance life cycle is described The class has the required behavior
111
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.

13 - 111
Checkpoints: Operations
Checkpoints: Operations
Operations are easily understood State description is correct Required behavior is offered Parameters are defined correctly Messages are completely assigned operations Implementation specifications are correct Signatures conform to standards All operations are needed by Use-Case Realizations
112
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.
13 - 112

Checkpoints: Attributes
Checkpoints: Attributes
A single concept Descriptive names All attributes are needed by UseCase Realizations
113
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.

13 - 113
Checkpoints: Relationships
Checkpoints: Relationships
Descriptive role names Correct multiplicities
114
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.
13 - 114

Review 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?
115

13 - 115

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
116
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. References to the givens: Use-Case Realizations: Payroll Exercise Solution, Exercise: Use-Case Design, Part 1. Subsystem interface realizations: Payroll Exercise Solution, Exercise: Subsystem Design section.
13 - 116


The required navigability for each relationship Any additional classes to support the relationship design Any associations refined into dependencies Any associations refined into aggregations or compositions Any refinements to multiplicity Any refinements to existing generalizations Any new applications of generalization Make sure any metamorphosis is considered
117
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 bidirectional 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.

13 - 117

An updated VOPC, including the relationship refinements (generalization, dependency, association)
118
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). References to sample diagrams within the course that are similar to what should be produced are: Define Dependencies: 13-52 and 13-53. Generalization: slides 13-93; 13-94, 13-102.
13 - 118

Exercise 2: Review
Exercise 2: Review
Compare your results
Do 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?
119
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?

13 - 119
13 - 120

Module 14 Database Design
IBM Software Group
Mastering Object-Oriented Analysis and Design with UML 2.0 Module 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

14 - 1
Objectives: Database Design
Objectives: Database Design

Define the purpose of Database Design and where in the lifecycle it is performed Explain how persistent classes map to the data model Learn 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).
14 - 2

Module 14 - Database Design
Database Design in Context
Database Design in Context

Design Components
Design the Database
Database Designer
Database Design
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 systems 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.

14 - 3
Database Design Overview Database Design Overview
Analysis Classes
Design Classes
Database Design
Data Model
Design Model
4
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. Supplementary Specifications Use-Case Realization Project Specific Guidelines Data Model Analysis Class Design Class Design Model Data Model
Input Artifacts:
14 - 4

Database Design Steps

Map persistent design classes to the data model Distribute 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.

14 - 5

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.
14 - 6

Relational Databases and Object Orientation Relational Databases and Object Orientation
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)
7
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 objects attributes are conceptually similar to an entitys 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).

14 - 7
The Relational Data Model
The Relational Data Model

Relational model is composed of
Entities Relations
Entity Relation
products lineItems
ORDER
Order_Id
LINE ITEM
LineItem_Id Description Price Quantity Product_Id Order_Id
PRODUCT
Product_Id Name Price
lineItem
order
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.
14 - 8

The Object Model
The Object Model

The Object Model is composed of
Classes (attributes) Associations
Order - number : Integer LineItem +lineItems - quantity : Integer - number : Integer +order 1..* 1 Product - number : Integer - description : String - unitPrice : Double
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).

14 - 9
Persistence Frameworks
Persistence Frameworks
The challenge:
Changes should not break the model
Business Object Model
The solution: An object-relational framework that

Encapsulates the physical data store Provides object translation services
Compact interfaces Object-relational translation Encapsulates data store
The importance of the framework

30% of development time is spent in accessing an RDBMS Maintenance can be 60% of total cost
10
Relational Database
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.
14 - 10

Object-Relational Framework: Characteristics Object-Relational Framework: Characteristics

Performance
Decomposing objects to data Composing objects from data
Minimize design compromises

Limit changes to object and relational models
Extensibility
15%-35% of the framework needs to be designed as an extensible framework
11
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.

14 - 11
Object-Relational Frameworks: Characteristics (continued)

Object-Relational Frameworks: Characteristics (continued) Documentation of the API Support for common object-relational mappings Persistence interfaces
Examples are save, delete, and find
12
Documentation: The Access layer is both a black-box component and a whitebox 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.
14 - 12

Common Object-Relational Services
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.
13
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.

14 - 13
Mapping Persistent Classes to Tables
Mapping Persistent Classes to Tables

In a relational database
Every row is regarded as an object A column in a table is equivalent to a persistent attribute of a class
Student - name : String - address : String - studentID : Long
Attributes from object type Object Instance
Name Thomas Stuart

14
Address 987 High St.
Student_ID 123456
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.
14 - 14

Mapping Associations Between Persistent Objects
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 Course Offering table
CourseOffering - number : String 0..* Course 1 - name - description - number
Number 678
Course_ID 456789
Foreign Key Primary Key
Course table
Name Math 101

15
Description Algebra
Number 456789
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).

14 - 15
Mapping Aggregation to the Data Model
Mapping Aggregation to the Data Model

Aggregation is also modeled using foreign key relationships
The use of composition implements a cascading delete constraint
Student table
Student. - studentID : int 1
Student_ID 123456
Primary Key
0..* Schedule - semester : Semester
Schedule table
Foreign Key
Student_ID 123456
16
Semester Spring 2001
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.
14 - 16

Modeling Inheritance in the Data Model
Modeling Inheritance in the Data Model

A Data Model does not support modeling inheritance in a direct way Two options:
Use separate tables (normalized data) Duplicate all inherited associations and attributes (de-normalized data)
17
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.

14 - 17

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.
14 - 18

What Are Stored Procedures? What Are Stored Procedures?

A stored procedure is executable code that runs under the RDBMS Two types of stored procedures:
Procedures: Executed explicitly by an application Triggers: Invoked implicitly when some database event occurs
19
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.

14 - 19
Map Class Behavior to Stored Procedures
Map Class Behavior to Stored Procedures

Determine if any operations can be implemented as a stored procedure Candidates:
Operations that deal with persistent data Operations in which a query is involved in a computation Operations that need to access the database to validate data
20
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.
14 - 20

Example: Map Class Behavior to Stored Procedures
Example: Map Class Behavior to Stored Procedures

Class
Student. + getTuition() + addSchedule() + getSchedule() + deleteSchedule() + hasPrerequisites() # passed() + getNextAvailID() + getStudentID() + getName() + getAddress()
Candidate Operations
getTuition addSchedule getSchedule deleteSchedule getStudentID getName getAddress
21
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.

14 - 21
Checkpoints: Database Design
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?
22
14 - 22

Review 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?
23

14 - 23
14 - 24

IBM / Rational software
Glossary
Version 2004.06.00
Mastering Object-Oriented Analysis and Design with UML Glossary
Version: 2004.06.00
Revision History
Date June, 1999 November, 2001 December, 2002 June, 2004 Version V4.2 V2002 V2003.06.00 V2004.06.00 Initial creation Final release Final release Final release Description Author Shawn Siemers Shawn Siemers Alex Kutsick Alex Kutsick
Page 2 of 22
Version: 2004.06.00
Table of Contents
1. 2. Introduction Definitions 2.1 Abstract Class 2.2 Abstraction 2.3 Action 2.4 Active Class 2.5 Activity 2.6 Activity Diagram 2.7 Activity State 2.8 Actor 2.9 Aggregation 2.10 Analysis 2.11 Analysis Class 2.12 Analysis Mechanism 2.13 Architectural Mechanism 2.14 Architecture 2.15 Assembly Connector 2.16 Association 2.17 Association Class 2.18 Attribute 2.19 Ball 2.20 Behavior 2.21 Boundary Class 2.22 Choice 2.23 Class 2.24 Class Diagram 2.25 Classifier 2.26 Collaboration 2.27 Combined Fragment 2.28 Communication Diagram 2.29 Component 2.30 Component Diagram 2.31 Composite Structure Diagram 2.32 Composition 2.33 Concrete Class 2.34 Concurrency 2.35 Connector 2.36 Control Class 2.37 Delegation Connector 2.38 Dependency 2.39 Deployment 2.40 Deployment Diagram 2.41 Deployment Specification 2.42 Deployment View 2.43 Derived Attribute 2.44 Design 2.45 Design Model 2.46 Design Mechanism 2.47 Device
6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 8 8 8 8 8 8 8 8 8 8 9 9 9 9 9 9 9 10 10 10 10 10 10 10 10 10 10 10 11 11 11 11 11 Page 3 of 22
Mastering Object-Oriented Analysis and Design with UML Glossary 2.48 2.49 2.50 2.51 2.52 2.53 2.54 2.55 2.56 2.57 2.58 2.59 2.60 2.61 2.62 2.63 2.64 2.65 2.66 2.67 2.68 2.69 2.70 2.71 2.72 2.73 2.74 2.75 2.76 2.77 2.78 2.79 2.80 2.81 2.82 2.83 2.84 2.85 2.86 2.87 2.88 2.89 2.90 2.91 2.92 2.93 2.94 2.95 2.96 2.97 2.98 2.99 2.100 Encapsulation Entity Class Event Event Occurrence Execution Environment Execution Occurrence Forward Engineering Frame Framework Gate Generalization General Ordering Guard Condition Hierarchy Implementation Mechanism Implementation View Inheritance Instance Interaction Interaction Diagram Interaction Fragment Interaction Occurrence Interaction Operand Interaction Overview Diagram Interface Iteration Iteration Expression Lifeline Link Logical View Manifestation Message Method Modularity Multiple Inheritance Multiplicity Navigability Node Object Object Diagram Object Lifeline Object-Orientation (OO) Object Technology Operation Operation Signature Package Package Diagram Package Import Partitions Pattern Polymorphism Port Process
Version: 2004.06.00
11 11 11 11 12 12 12 12 12 12 12 13 13 13 13 13 13 13 13 14 14 14 14 14 14 15 15 15 15 15 15 15 15 15 15 15 16 16 16 16 16 16 16 16 16 16 17 17 17 17 17 18 18 Page 4 of 22
Mastering Object-Oriented Analysis and Design with UML Glossary 2.101 2.102 2.103 2.104 2.105 2.106 2.107 2.108 2.109 2.110 2.111 2.112 2.113 2.114 2.115 2.116 2.117 2.118 2.119 2.120 2.121 2.122 2.123 2.124 2.125 2.126 2.127 2.128 2.129 2.130 2.131 2.132 2.133 2.134 2.135 2.136 Process View Property Provided Interface Realization Relationship Required Interface Responsibility Reverse Engineering Role Scenario Sequence Diagram Single Inheritance Socket State State Machine State Machine Diagram Stereotype Stored Procedures Structured Class Structure Diagram Structured Part Subsystem Thread Time Constraint Timing Diagram Transaction Transition Unified Modeling Language (UML) Use Case Use-Case Diagram Use-Case Model Use-Case Realization Use-Case View Utility Class Visibility Visual Modeling
Version: 2004.06.00
18 18 18 18 18 18 18 19 19 19 19 19 19 19 19 20 20 20 20 20 20 20 20 20 20 20 21 21 21 21 21 21 21 21 21 21
Page 5 of 22
Version: 2004.06.00
Glossary
1. Introduction
This document contains definitions for terms used in the Essentials of Visual Modeling and Mastering ObjectOriented 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.
2.1
Definitions
Abstract Class An abstract class is a class that cannot be instantiatedthat is, it may not have direct instances. It is the opposite of a concrete class. 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. 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.
2.2
2.3
StateA
event( condition ) / action St ateB StateC entry/ action
2.4
Active Class 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 may execute in parallel (that is, concurrently) with other active classes. Activity A unit of work a worker may be asked to perform. Activity Diagram An activity diagram shows the decomposition of an activity into its constituents.
2.5
2.6
Page 6 of 22
Mastering Object-Oriented Analysis and Design with UML Glossary 2.7 Activity State The performance of an activity or step within the workflow.
Version: 2004.06.00
2.8
Actor Someone or something outside the system or business that interacts with the system or business.
Actor
(f rom U se 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. Analysis Class Analysis classes handle primarily functional requirements, and model objects from the "problem" domain. 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. 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. 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.
2.11
2.12
2.13
2.14
Page 7 of 22
Mastering Object-Oriented Analysis and Design with UML Glossary 2.15
Version: 2004.06.00
Assembly Connector A connector between two elements (parts or ports) in the internal implementation specification of a structured classifier or component. Association A relationship that models a bi-directional semantic connection among instances. 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
2.16
2.17
ClassA 0..* 0..*
ClassB
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. Ball A provided interface relationship shown by a small circle, or a ball, attached to a classifier by a line. Behavior The observable effects of an event that includes results. Boundary Class A class used to model communication between the system's environments and its inner workings. Choice A node in a state machine at which dynamic evaluations of subsequent guard conditions is made. Class A class is a description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics.
ClassA
2.19
2.20
2.21
2.22
2.23
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.
Page 8 of 22
Version: 2004.06.00
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. Collaboration A society of roles and other elements that work together to provide some cooperative behavior thats 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.26
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.
1: Message1 : ClassA
: Actor 3: Message3 2: Message2
: 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. 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. 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.
2.30
2.31
Page 9 of 22
Version: 2004.06.00
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.
Whole Part
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). Concurrency Concurrency is the tendency for things to happen at the same time in a system. 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. Control Class A class used to model behavior specific to one, or a several use cases. 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. 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). Deployment The assignment of software artifacts to physical nodes during execution. 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.34
2.35
2.36
2.37
2.38
2.39
2.40
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. 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.
2.42
Page 10 of 22
Version: 2004.06.00
Derived Attribute An attribute whose value may be calculated based on the value of other attribute(s). 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. Design Model An object model describing the realization of use cases; serves as an abstraction of the implementation model and its source code. 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. 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. 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. 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. 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.
NewState2 Event / TargetObject.event NewState entry/ Action do/ TargetObject.Event
2.44
2.45
2.46
2.47
2.48
2.49
2.50
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.
Page 11 of 22
Version: 2004.06.00
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. 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. Forward Engineering The process of transforming a model into code through a mapping to a specific implementation language. 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.
2.53
2.54
2.55
Frame
2.56
Framework A micro-architecture that provides an incomplete template for applications within a specific domain Gate A connection point in an interaction or interaction fragment for a message that comes from or goes to outside the interaction or fragment. Generalization A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific element can be used where the more general element is allowed.
ClassParent
2.57
2.58
ClassA
ClassB
Page 12 of 22
Version: 2004.06.00
2.59
General Ordering A constraint in an interaction where the time of one event occurrence precedes the time of another event occurrence. 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. 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.60
2.61
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 systems 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. 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. Inheritance The mechanism that makes generalization possible; a mechanism for creating full class descriptions out of individual class segments. 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. 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.
2.63
2.64
2.65
2.66
Page 13 of 22
Version: 2004.06.00
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. Interaction Fragment A structural piece of an interaction. Interaction Occurrence A reference to an interaction within the definition of another interaction.
2.68
2.69
2.70
Interaction Operand A structural piece of a combined fragment; a subfragment. 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. Interface A declaration of a coherent set of public features and obligations; a contract between providers and consumers of services.
2.71
2.72
<<Interface>> Interface
<<subsystem>> Subsystem
<<subsystem>> Subsystem Interface
Page 14 of 22
Version: 2004.06.00
Iteration A distinct set of activities with a baseline plan and evaluation criteria that results in a release, either internal or external. Iteration Expression A specification of the range of number of iterations of a loop. 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.74
2.75
2.76
Link A semantic connection among objects; an instance of an association. 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. 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. 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. 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. 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. Multiple Inheritance A semantic variation of generalization in which an object may belong directly to more than one class. Multiplicity A specification of the range of allowable cardinalities that a set may assume.
ClassA ClassB
2.77
2.78
2.79
2.80
2.81
2.82
2.83
0..1
0..2, 5
Page 15 of 22
Version: 2004.06.00
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. 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.
2.85
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. 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. Object Lifeline A line in a sequence diagram that represents the existence of an object over a period of time. 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. 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 Managers Guide, Taylor, 1997.) Operation A service that can be requested from an object to effect behavior. Operation Signature The name and parameters of an operation. Package A general-purpose mechanism for organizing elements into groups, establishing ownership of elements, and providing unique names for referencing elements.
2.87
2.88
2.89
2.90
2.91
2.92
2.93
PackageA
Page 16 of 22
Version: 2004.06.00
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 responsibilityfor 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.
Page 17 of 22
Version: 2004.06.00
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. Process View An architectural view that describes the concurrent aspect of the system: tasks (processes) and their interactions. Property A named value denoting a characteristic of an element. 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. Realization A semantic relationship between classifiers, in which one classifier specifies a contract that another classifier guarantees to carry out. Relationship An abstract concept that specifies some kind of connection between elements. Examples of relationships include associations and generalizations. 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. Responsibility A contract or obligation of a type or class.
2.101
2.102
2.103
2.104
2.105
2.106
2.107
Page 18 of 22
Version: 2004.06.00
Reverse Engineering The process of transforming code into a model through a mapping from a specific implementation language. 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 Head 0..* 1
2.109
Employee
Department
2.110
Scenario A described use-case instance, a subset of a use case. 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.
2.111
: Employee : Actor 1: Message1
: Department
2: Message2 3: Message3
2.112
Single Inheritance A semantic variation of generalization in which a child may have only one parent. Socket A required interface relationship is shown by a small half circle, or a socket, attached to a classifier by a line. 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. 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.
2.113
2.114
2.115
Page 19 of 22
Version: 2004.06.00
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.
NewState entry/ Action Event /TargetObject.event NewState2 do/ TargetObject.Event
2.117
Stereotype A meta-classification of an element. Stereotypes have semantic implications which can be specified for every specific stereotype value. 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. Structured Class A class containing parts or roles that form its structure and realize its behavior.
2.118
2.119
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. Structured Part Within a structured classifier, an element that represents an object or set of objects within a contextual relationship. Subsystem A large unit of decomposition for a system. It is modeled as a stereotype of component with the keyword <<subsystem>>. Thread An independent computation executing within an the execution environment and address space defined by an enclosing operating system process. Time Constraint Expressed as a time interval, it can refer to a single event occurrence or to the time interval between two occurrences. 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. Transaction Transactions define a set of operation invocations that are atomic: either all or none of them are performed.
2.121
2.122
2.123
2.124
2.125
2.126
Page 20 of 22
Version: 2004.06.00
Transition A transition is a change from an originating state to a successor state as a result of some stimulus. Unified Modeling Language (UML) A language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. 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. Use-Case Diagram A diagram that shows the relationships among actors and use cases within a system. Use-Case Model A model of what the system is supposed to do and the system environment. Use-Case Realization A use-case realization describes how a particular use case is realized within the design model, in terms of collaborating objects. 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 usecase model. Utility Class A class that contains a collection of free subprograms. Visibility How a name can be seen and used by others. Visual Modeling A way of thinking about problems using models organized around real-world ideas.
2.128
2.129
2.130
2.131
2.132
2.133
2.134
2.135
2.136
Page 21 of 22
Version: 2004.06.00
Page 22 of 22
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. 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. 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.
Activities performed by this role:
What they need to succeed:
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
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). 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. 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.
Activities They Perform:
What They Need to Succeed:
Curriculum Path: http://www.ibm.com/services/learning/ites.wss/us/en?pageType=page&contentID=a0000468
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, OReilly & 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 DistilledThird 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, AddisonWesley, 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 ArchitecturePerspectives 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, AddisonWesley, 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 Chappels Web site at http://www.chappellassoc.com Inside COM, Rogerson, D., Microsoft Press, 1997. COMs 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

Ooad With Uml2.0

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ooad With Uml2.0

Transféré par

Droits d'auteur :

Formats disponibles

DEV475 Mastering Object-Oriented Analysis and Design with UML 2.

IBM Rational University

DEV475 Mastering Object-Oriented Analysis and Design with UML 2.0

Module 1 Best Practices of Software Engineering

Module 2 Concepts of Object Orientation

Module 3 Requirements Overview

Module 4 Analysis and Design Overview

Module 5 Architectural Analysis

Module 6 Use-Case Analysis

Module 0 About This Course

IBM Software Group

Copyright IBM Corp. 2004

Mastering Object-Oriented Analysis and Design with UML 2.0

Your expectations for this course

Copyright IBM Corp. 2004

Module 0 - About This Course

Course Objectives Course Objectives

Copyright IBM Corp. 2004

Mastering Object-Oriented Analysis and Design with UML 2.0

Course Objectives (continued)

Course Objectives (continued)

Copyright IBM Corp. 2004

Module 0 - About This Course

Copyright IBM Corp. 2004

Mastering Object-Oriented Analysis and Design with UML 2.0

Some experience applying the following techniques in a software development environment

Copyright IBM Corp. 2004

Module 0 - About This Course

Rational University Curriculum Rational University Curriculum

Instructor-led Web-based Optional

Copyright IBM Corp. 2004

Mastering Object-Oriented Analysis and Design with UML 2.0

Rational University Curriculum

Rational University Curriculum

Instructor-led Web-based Optional

Copyright IBM Corp. 2004

Module 0 - About This Course

Rational University Curriculum

Rational University Curriculum

Instructor-led Web-based Optional

Copyright IBM Corp. 2004

Mastering Object-Oriented Analysis and Design with UML 2.0

Copyright IBM Corp. 2004

Module 0 - About This Course

Other Sources of Information

Other Sources of Information

Rational Web Site

Rational Developer Domain

Copyright IBM Corp. 2004

Mastering Object-Oriented Analysis and Design with UML 2.0

Morning 2-Fifteen-minute breaks Lunch 1 Hour Afternoon 2-Fifteen-minute breaks

Copyright IBM Corp. 2004

Module 1 Best Practices of Software Engineering

IBM Software Group

Copyright IBM Corp. 2004

Mastering Object-Oriented Design and Analysis

Objectives: Best Practices

Objectives: Best Practices

Copyright IBM Corp. 2004

Module 1 - Best Practices of Software Engineering

Symptoms of Software Development Problems

Symptoms of Software Development Problems

Copyright IBM Corp. 2004

Mastering Object-Oriented Design and Analysis