student guide

DEV275 Essentials of Visual Modeling with UML 2.0Student Guide

IBM Rational University

DEV275 Essentials of Visual Modeling with UML 2.0Student GuidePart No. 800-027076-000

IBM CorporationRational University DEV275 Essentials of Visual Modeling with UML 2.0Student ManualVersion 2004.06.00

June 2004

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

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

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

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

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

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

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

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

Printed in the United States of America.

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

Contents

Module 0 About This Course 0-1 Intended Audience and Prerequisites ............................................................. 0-3 Course Objectives.......................................................................................... 0-4

Module 1 Introduction to Object Technology 1-1 What Is Object Technology? .......................................................................... 1-4 Where Is Object Technology Used? ............................................................... 1-8

Module 2 Principles of Visual Modeling 2-1 What Is a Model?........................................................................................... 2-4 Four Principles of Modeling ......................................................................... 2-11 What Is the UML?........................................................................................ 2-17 A Language Is Not Enough to Build a System................................................ 2-25

Module 3 Concepts of Object Orientation 3-1 What Is an Object? ........................................................................................ 3-4 Basic Principles of Object Orientation .......................................................... 3-10 What Is a Class? ........................................................................................... 3-20 The Relationship Between Classes and Objects ............................................ 3-23 What Is a Package? ...................................................................................... 3-35

Module 4 Use-Case Modeling 4-1 Major Concepts in Use-Case Modeling........................................................... 4-8 Use Cases and Actors................................................................................... 4-12 What Is an Activity Diagram? ....................................................................... 4-15

Module 5 Interaction Diagrams 5-1 What is an Interaction Diagram? .................................................................... 5-5 What Is a Sequence Diagram?........................................................................ 5-9 What Is a Communication Diagram? ............................................................ 5-18 Sequence and Communication Diagram Similarities..................................... 5-24

Module 6 Class Diagrams 6-1 What Is a Class Diagram? ............................................................................... 6-4 What Is an Association?................................................................................ 6-10 What Is an Aggregation?............................................................................... 6-16 Review: What Is Generalization?.................................................................. 6-19

Module 7 Other UML Diagrams 7-1 What Are State Machine Diagrams? ............................................................... 7-6 What Is a Deployment Diagram?.................................................................. 7-15 What Is a Node? .......................................................................................... 7-16

Glossary

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 is personally responsible for ensuring that there is a high-level of consistency throughout this course.

Gary Bastoky of Rational University for his graphics support.

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

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

mailto:[email protected]

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

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

Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Addison-Wesley, 1995.

Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition, Nicholas Kassem, Enterprise Team, Sun Microsystems, 2000.

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

Enterprise Java with UML, CT Arrington, Wiley Computer Publishing, 2001.

Fundamentals of Object-Oriented Design, Meilir Page-Jones, Addison-Wesley, 2001.

Mastering Enterprise Java Beans and the Java 2 Platform, Enterprise Edition, Ed Roman, Wiley Computer Publishing, 1999.

Meta Fax, 09/15/97.

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

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

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

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

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

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

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

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

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

► ► ► Module 0 About This Course

1

IBM Software Group

®

Essentials of Visual Modeling with UML 2.0Module 0: About This Course

Topics

Intended Audience and Prerequisites.................................................................... 0-3 Course Objectives ................................................................................................ 0-4

© Copyright IBM Corp. 2004 0 - 1

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

Essentials of Visual Modeling with UML 2.0

Introductions

2

Introductions

Your organizationYour roleYour background, experience

Object technology experienceSoftware development experience

Your expectations for this course

0 - 2 © Copyright IBM Corp. 2004


Module 0 - About This Course

Intended Audience and Prerequisites

3

Intended Audience and Prerequisites

Intended AudienceSoftware developers who are making the paradigm shift to visual modelingSoftware managers who need to better understand object technology Data modelers who need to better communicate with object modelers

PrerequisiteA desire to learn about visual modeling

The assumption here is that those attending this class work for a software company.




Course Objectives

4

Course Objectives

After completing this course, you will be able to:

Define the history and current application of object technology.Explain what the UML represents.Explain abstraction, encapsulation, modularity, and hierarchy.Describe the physical structure of a class.Identify the relationship between a class and an object.Define polymorphism and generalization.




Rational University Curriculum

5

Rational University CurriculumCurriculum Flow:Designer

Instructor-led Web-basedOptional

DEV275Essentials of Visual Modeling with UML

1 day

DEV110Principles of

Modeling

2 hours

OR

Path 1

DEV111Principles of UC Modeling

with UML

2 hours

DEV113Principles of Analysis II

2 hours

DEV112Principles of

Analysis I

2 hours

Path 2

DEV475Mastering Object

OrientedAnalysis &

Design with UML4 days

DEV160Principles of

Modeling Behavior

2 hours

The above courses are the courses that Rational University offers. As you can see for each major software development team role, Rational University offers a professional development course.





6

Rational University CurriculumCurriculum Flow:Enterprise Architect


Path 1

DEV111Principles of UC Modeling

with UML

2 hours

DEV113Principles of Analysis II

2 hours

DEV112Principles of

Analysis I

2 hours

Path 2OR

DEV110Principles of

Modeling

2 hours

DEV275Essentials of Visual Modeling with UML

1 day

DEV475Mastering Object

OrientedAnalysis &

Design with UML4 days





7

Rational University CurriculumCurriculum Flow:System Analyst


REQ480Management

with Use Cases

3 days

OR

REQ370Essentials of

Rational RequisitePro

1 day

REQ310Essentials of

Rational RequisitePro

5 hours

OR

DEV110Principles of

Modeling

2 hours

DEV275Essentials of

Visual Modeling with

UML

1 day




Course Materials

8

Course Materials

Student Manual

The Student Manual contains copies of the slides as well as detailed Student Notes.




Other Sources of Information

9

Other Sources of Information

Rational Web sitehttp://www-306.ibm.com/software/rational/

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

UML Resource Centerhttp://www-306.ibm.com/software/rational/uml/

Rational Edgehttp://www-106.ibm.com/developerworks/rational/rationaledge/

• 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 developer Works, a customer-only site is IBM’s resource for developers.

• The UML Resource Center provides additional UML resources like Whitepapers and recommended reading. It facilitates newsgroups and information about services and training.

• The Rational Edge is a free new e-zine dedicated to the practitioners and decision-makers in the Rational community. Brought to you monthly by Rational Software, this publication will help you use Rational products and services to their very best advantage, and develop high-quality software at the speed today's marketplace demands.




Logistics

10

Logistics

Morning2 Fifteen minute breaks

Lunch 1 HourAfternoon2 Fifteen minute breaks



► ► ► Module 1 Introduction to Object Technology

1

IBM Software Group

®

Essentials of Visual Modeling with UML 2.0Module 1: Introduction to Object Technology

Topics

What Is Object Technology?................................................................................. 1-4 Where Is Object Technology Used?...................................................................... 1-8




Objectives

2

Objectives

Define object technology and show its strengths.Explain the history of object technology.Discuss how object technology is used today.



Module 1 - Introduction to Object Technology

Where Are We?

3

Where Are We?

What is object technology?Where is object technology used today?




What Is Object Technology?

4

What Is Object Technology?

A set of principles (abstraction, encapsulation, polymorphism) guiding software construction, together with languages, databases, and other tools that support those principles. (Object Technology - A Manager’s Guide, Taylor, 1997.)

• Object technology is used for creating models that reflect a specific domain using

the terminology of the domain. • Models created using object technology should be easy to create, change,

expand, validate, and verify. • Systems built using object technology are flexible to change, have well-defined

architectures, and have the opportunity to create and implement reusable components.

• Models created using object technology are conveniently implemented in software using object-oriented programming languages.

• Object technology is not just a theory, but a well-proven technology used in a large number of projects and for building many types of systems.

• Successful implementation of object technology requires a method that integrates a development process and a modeling language with suitable construction techniques and tools. (UML Toolkit, Eriksson and Penker, 1997.)




The Strengths of Object Technology

5

The Strengths of Object Technology

Reflects a single paradigmFacilitates architectural and code reuseReflects real world models more closelyEncourages stabilityIs adaptive to change

So what’s the big deal about object technology? Why has the software industry made such a noticeable shift to object-oriented languages like Java? Much of the answer has to do with the strengths of object technology. There are some people who believe that object technology is a passing fad and will quickly go away, while others believe that object technology is the silver bullet that answers all software development problems. The truth is that the answer probably lies somewhere in between. Object technology is a powerful and challenging way to develop software. The result of this hard work can be a software system that:

• Reflects a single paradigm. It provides a consistent language that can be applied for both system and business engineering.

• Facilitates architectural and code reuse by clearly articulating the major components and the critical interfaces between them.

• Reflects real world models more closely. The objects themselves often correspond to phenomena in the real world that the system is to handle.

• Is more stable, a change to the system can be localized to a small part of the system.

• Is adaptive to change -a small change in requirements does not mean massive changes to the system.




The History of Object Technology

6

Major object technology milestones

Simula

1967

C ++

Late 1980s

Smalltalk

1972

Java

1991

The UML

1996

UML 2

2004

The History of Object Technology

• Object technology is not a new idea. It has been around for over 30

years. Below is a brief history of the major milestones in the history of object technology.

• In 1967, Simula was designed and became the first language to use objects and classes.

• In 1972, Alan Kay and others at Xerox PARC created Smalltalk whose roots were tied to Simula. In 1980, Smalltalk became the first commercial release of an object-oriented programming environment.

• Bjarne Stroustrop, the originator of the C language, released C++ to the public in the late 1980’s. C++ was not an entirely new language, but an extension of C abilities.

• In 1991, James Gosling created a language named Oak that was the predecessor to Java. It was created because his development team at Sun Microsystems was writing software for information appliances. He found that C++ was too complex and insecure for the job. Therefore, he created the Oak language.

• UML 2.0 replaces UML version 1.4. Released in 2004, the Object Management Group (OMG) developed two complementary specifications called the Infrastructure and Superstructure specification. The Infrastructure defines the foundational language constructs required for UML 2.0 and serves as an architectural foundation. The Superstructure defines the user level constructs. Together, they constitute a complete specification for the UML 2.0 modeling language.




Where Are We?

7

Where Are We?

What is object technology?Where is object technology used today?




Where Is Object Technology Used?

8

Where Is Object Technology Used?

Client/Server Systems and Web Development

Object technology allows companies to encapsulate business information in objects and helps to distribute processing across the Internet or a network.

Object technology allows companies to encapsulate business information in objects and helps to distribute processing across the Internet or a network. Enterprise development environments such as Sun’s J2EE and Microsoft’s .Net technologies use objects as the basis for their technology.




Where Is Object Technology Used? (continued)

9

Where Is Object Technology Used? (continued)

Real-time systemsObject technology enables real-time systems to be developed with higher quality and flexibility.

4

Object technology is used in the following industries and software applications:

Telecommunications – circuit switching systems, wireless systems, transmission systems, satellite systems, fault management, call/connection control, and protocol development.

Data communications – LAN hub switches, multi-protocol routers, packet switching & frame relay, ATM switching systems, connection control, node management, fault management, and protocol development.

Defense and aerospace – command and control systems, missile control systems, defense simulators, cockpit control systems, air traffic control systems, target tracking, distributed computer modeling, man machine interface control, communication modes and control, redundancy management.

Industrial control – office equipment, factory control systems, multi-processor high speed printers, automotive systems, PWB and IC water fabrication, device control, system management, distributed process control, machine position control, bandwidth allocation.




Differences Between OO and Structured Design

10

Differences Between OO and Structured Design

Object-orientation (OO)Melds the data and data flow process together early in the lifecycleHas a high level of encapsulationPromotes reuse of code differentlyPermits more software extensibility

In the world of structured design, there has always been an uneasy relationship between the data model in an entity-relationship diagram and the dataflow diagram. The dataflow process and the data meet in some places, but in not others, they miss each other altogether. Object-orientation (OO) melds the data and dataflow process together early in the lifecycle. In object-orientation, concern yourselves with defining the static and dynamic views of the system (Jones, p.65).

Object-orientation has a very high level of encapsulation associated with it. Data, operations, and entire classes can be encapsulated. Structured programming relies upon data structures, sophisticated algorithms, and elaborate relationships between procedure and data (Jones, p.65).

Object-orientation promotes reuse of code at the class level rather than at the level of the individual subroutine (Jones, p. 66).

The goal of extensible software is to share a solution that most closely fits the problem. By doing this, you can ensure that a small requirements change doesn’t require major modifications to your system. Because object orientation is built using classes that are abstractions of actual business objects, OO techniques come closer to permitting software extensibility than structured design.




Discussion

11

Discussion

What is your perception of object technology?What do you perceive as object technology’s strengths? Its weaknesses?Why are you making the shift to object technology?



► ► ► Module 2 Principles of Visual Modeling

1

IBM Software Group

®

Essentials of Visual Modeling with UML 2.0Module 2: Principles of Visual Modeling

Topics

What Is a Model? ................................................................................................. 2-4 Four Principles of Modeling................................................................................ 2-11 What Is the UML? .............................................................................................. 2-17 A Language Is Not Enough to Build a System....................................................... 2-25




Objectives

2

Objectives

Describe the importance of visual modeling and the role of Model Driven Architecture.Define the four principles of visual modeling.Explain what the Unified Modeling Language (UML) represents.Define the type of process that best relates to the UML.



Module 2 - Principles of Visual Modeling

Where Are We?

3

Where Are We?

What is modeling?Four principles of visual modelingThe UMLProcess and visual modeling




What Is a Model?

4

What Is a Model?

A model is a simplification of reality.

According to Grady Booch, IBM Fellow, a model provides the blueprints of a system. Models may encompass detailed plans, as well as more general plans that give a 30,000-foot view of the system under construction. A good model includes those elements that are not relevant to the given level of abstraction. Every system may be described from different aspects using different models, and each model is therefore a semantically closed abstraction of the system. A model may be structural, emphasizing the organization of the system, or it may be behavioral, emphasizing the dynamics of the system.




Why Model?

5

Why Model?

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

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

According to Booch in The Unified Modeling Language User Guide, modeling achieves four aims: 1. Models help you to visualize a system, as you want it to be. A model helps the

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

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

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

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




The Importance of Modeling

6

The Importance of Modeling

Paper Airplane Fighter Jet

Less Important More Important

You can take a piece of paper and a paper clip, and, in a few minutes, have a paper airplane that entertains your kids. If it isn’t built just right, you can always start over and build another airplane.

Would it be smart for you to build a fighter jet in the same way? That is, start with some steel, nuts, bolts, and wiring and go right to work. Of course not. You’re building an airplane that costs millions of dollars, and the cost of failure is high. You’re also be part of a much larger team, needing blueprints and models to effectively communicate with one another. (The Unified Modeling Language User Guide, Booch, 1999.)




Software Teams Often Do Not Model

7

Software Teams Often Do Not Model

Many software teams build applications approaching the problem like they were building paper airplanes

Start coding from project requirementsWork longer hours and create more codeLacks any planned architectureDoomed to failure

Modeling is a common thread to successful projects

If defense contractors want to build fighter jets for the government, they need to achieve a certain balance between the desires of the military with the realities of aerospace engineering. They also want to treat their employees professionally, never placing them at risk or driving them so hard that they burn out.

Curiously, many software development organizations begin wanting to build complex software systems, but approach the problem as though they were building a paper airplane.

With the increasing demand to build more complex software in shorter time, development teams often retreat to the only thing they know how to do well - pound out lines of code. Developers start working longer hours and frequently produce code with a requirements document as their only source of input. However, there eventually comes a time when the application collapses due to the lack of a well thought-out architecture. Consequently, many of these software projects result in failure.




Model Driven Architecture (MDA)

8

Model Driven Architecture (MDA)

An approach to using models in software development

Separate the specification of the operation of a system from the details of the way that system uses the capabilities of its platform.• specifying a system independently of the

platform that supports it• specifying platforms• choosing a particular platform for the system• transforming the system specification into one

for a particular platform

The Model-Driven Architecture prescribes certain kinds of models to be used, how those models may be prepared, and the relationships of these different models.

It’s termed model-driven because this provides a means for using models to guide the understanding, design, construction, deployment, operation, maintenance and modification.

The architecture of a system is the specification of the parts and connectors of the system and the rules for the interactions of the parts using the connectors.




MDA Viewpoints

9

MDA Viewpoints

Computational Independent Model (CIM)Focus is on environment of the system and requirements for the system

Platform Independent Model (PIM)Focus is on system operation, independent of platform

Platform Specific Model (PSM)Focus is on detailed usage of system on specific platform

A viewpoint on a system is the process of suppressing selected detail to establish a simplified model, in order to focus on particular concerns within that system.

A CIM does not show details of the structure of systems and is sometimes called a domain model. The vocabulary used in its specification is familiar to the practitioners of the domain in question. The CIM plays an important role in bridging the gap between those that are experts in the domain and its requirements, and those that are experts in the design and construction of the artifacts that together satisfy the requirements.

A PIM exhibits a specified degree of platform independence so as to be suitable for use with a number of different platforms. A very common technique for achieving this independence is to target a system model for a technology-neutral virtual machine. A virtual machine is defined as a set of parts and services (communications, scheduling, naming, etc.), which are defined independently of any specific platform and which are realized in platform-specific ways on different platforms.

A PSM combines the specifications in the PIM with the details that specify how that system uses a particular type of platform.




Where Are We?

10


Where Are We?




Four Principles of Modeling

11

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.




Principle 1: The Choice of Model is Important

12

Design ModelProcess Model

Principle 1: The Choice of Model is Important

The models you create profoundly influence how a problem is attacked and how a solution is shaped.

In software, the models you choose greatly affect your world view.Each world view leads to a different kind of system.

Deployment Model

The right models illuminate the most difficult development problems, offering insight that you could not gain otherwise. The wrong models mislead you, causing you to focus on irrelevant issues.

In software, the models you choose can greatly affect your world view. If you build a system through the eyes of a database developer, you’ll likely end up with entity-relationship models that push behavior into stored procedures and triggers. If you build a system through the eyes of an object-oriented developer, you’ll end up with a system that has its architecture centered around many classes and patterns of interaction that direct how those classes work together.

Each world view leads to a different kind of system with different costs and benefits. (The Unified Modeling Language User Guide, Booch, 1999.)




Principle 2: Levels of Precision May Differ

13

Principle 2: Levels of Precision May Differ

Every model may be expressed at different levels of precision.

The best kinds of models let you choose your degree of detail, depending on:• Who is viewing the model. • Why they need to view it.

View for DesignersView for Customers

If you are building computer chips, sometimes you need a 30,000-foot view. For example, you need your investors to visualize the end product. Other times, you need to get down to the level of the circuits.

When developing a GUI system, a quick and dirty executable model of the user interface may be all you need to communicate your intentions. Other times, when you are dealing with cross-system interfaces of network bottlenecks, you need to model down to the bit level. In either case, the best models are those that let you choose your degree of detail, depending on who is doing the viewing and why they need to view it. (The Unified Modeling Language User Guide, Booch, 1999.)




Principle 3: The Best Models Are Connected to Reality

14

Principle 3: The Best Models Are Connected to Reality

All models simplify reality.A good model reflects potentially fatal characteristics.

A physical model of a building that doesn’t respond the same way as the real materials has limited value. It’s best to have models that have a clear connection to reality. Where that connection is weak, you need to know exactly how those models are divorced from the real world.

All models simplify reality. The trick is to be sure that your simplifications don’t mask any important details. A good model reveals any potentially fatal flaws in design. (The Unified Modeling Language User Guide, Booch, 1999.)




Principle 4: No Single Model Is Sufficient

15

Principle 4: No Single Model Is Sufficient

No single model is sufficient. Every non-trivial system is best approached through a small set of nearly independent models.

Create models that can be built and studied separately, but are still interrelated.

Process View Deployment View

Logical View

Use-Case View

Implementation View

End-userFunctionality

ProgrammersSoftware management

Performance, scalability, throughputSystem integrators System topology, delivery,

installation, communication

System engineering

Analysts/DesignersStructure

The key phrase is “nearly independent,” meaning that models can be built and studied separately, but are still interrelated.

To understand the architecture of object-oriented systems, you need several complementary and interlocking views. An architectural view can be defined as 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.

Each of the views below may have structural and behavioral aspects. Together, they represent the blueprints of a software system.

• Use-case view exposing the requirements of the system • Logical view capturing the vocabulary of the problem space and the solution

space • Process view modeling the distribution of the system’s processes and threads • Implementation view addressing the physical realization of the system • Deployment view focusing on system engineering issues To address these different needs, Rational has defined the “4+1 view” architecture model.

Remember that not all systems require all views. The number of views is dependent on the system you’re building. For example, a single processor does not require a deployment view or a small program does not require an implementation view and so on.




Where Are We?

16


Where Are We?




What Is the UML?

17

What Is the UML?

The UML is a language for• Visualizing• Specifying• Constructing• Documenting

the artifacts of a software-intensive system.

The software systems that you develop today are more complex than the human mind can comprehend. This is why you model systems. Your model selection profoundly influences how you attack the problem and shape the solution.

No single model is sufficient. Every complex system is best approached through a small set of nearly independent models.

Therefore, to increase comprehension, a common language like the Unified Modeling Language (UML) is used to express models.

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




The UML Is a Language for Visualizing

18

The UML Is a Language for Visualizing

Communicating conceptual models to others is prone to error unless everyone involved speaks the same language.There are things about a software system you can’t understand unless you build models.An explicit model facilitates communication.

Typically, projects and organizations develop their own language for modeling systems, making it difficult for outsiders and new team members to understand what is going on.

Communicating these conceptual models to others is prone to error unless everyone involved speaks the same language. The UML offers a set of symbols that represents well-defined semantics. One developer can write a model in the UML, and another developer can interpret that model unambiguously.

There are things about a software system you can’t understand unless you build models that transcend the textual programming language. For example, the meaning of a class hierarchy can be inferred, but not directly grasped, by staring at the code for all the classes in the hierarchy. The UML is a graphical language that addresses this problem.

If the developer who cut the code never wrote down the models, the information would be lost forever. At best, the information would only be partially recoverable from the implementation after the developer has moved on. Writing models in the UML addresses this issue. An explicit model facilitates communication. (The Unified Modeling Language User Guide, Booch, 1999.)




The UML Is a Language for Specifying

19

The UML Is a Language for Specifying

The UML builds models that are precise, unambiguous, and complete.

In this context, specifying means to build models that are precise, unambiguous, and complete. In particular, the UML addresses the specification of all the important analysis, design, and implementation decisions that must be made to develop and deploy software-intensive systems. (The Unified Modeling Language User Guide, Booch, 1999.)




The UML Is a Language for Constructing

20

The UML Is a Language for Constructing

UML models can be directly connected to a variety of programming languages.

Maps to Java, C++, Visual Basic, and so onTables in a RDBMS or persistent store in an OODBMSPermits forward engineeringPermits reverse engineering

The UML is not a visual programming language. However, models using the UML can be directly connected to a variety of programming languages, making it possible to map from a model in the UML to a programming language or even to a database.

If it is best expressed graphically, it is done graphically in the UML. If it is best expressed textually, it is done in the programming language.

This mapping permits forward engineering: the generation of code from a UML model to a programming language. Reverse engineering is also possible: the reconstruction of a model from implementation back into the UML.




The UML Is a Language for Documenting

21

The UML Is a Language for Documenting

Use Case Diagram

Actor A

Use Case 1

Use Case 2

Use Case 3

Actor B

Class Diagram

GrpFile

read( )

open( )

create( )

f illFile( )

rep

Repository

name : char * = 0

readDoc( )

readFile ( )

(fro m Persistence)

FileMg r

fetchDoc( )

sortByName( )

DocumentLi st

add( )

del ete( )

Document

name : int

docid : int

numField : int

get( )

open( )

close( )

read( )

sortFil eList ( )

create( )

fillDocument( )

fList

1

FileList

add( )

delete( )1

File

read( )

read( ) fi ll the

code..

Sequence Diagram

user

mainWnd fileMgr :

FileMgr

repositorydocument :

Document

gFile

1: Doc view request ( )

2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

6: fillDocument ( )

7: readFile ( )

8: fillFile ( )

9: sortByName ( )

Æ¯Á¤¹®¼- ¿¡ ëÇÑ º ±â ¦ »ç¿ëÀÚ°¡ ¿äÃ»ÇÑ´Ù.

È-À Ï°ü¸®À Ú´Â À Ð¾î¿Â

¹®¼ -ÀÇ Á ¤º ¦ ÇØ ç ¹® ¼- °´Ã¼¿¡ ¼³Á¤À» ¿äÃ»ÇÑ´Ù.

È - é °´Ã ¼´Â ÀÐ¾îµéÀ Î

° ´Ã¼µé¿ ¡ ëÇØ ÀÌ § º° ·Î Á ¤·ÄÀ» ½ÃÄÑ È- é¿¡

º¸ ¿©ÁØ´Ù.

The UML addresses documentation of system architecture, requirements, tests, project planning, and release management.

Deployment Diagram

Window95

¹®¼-°ü¸® Å ¬¶óÀÌ¾ðÆ®.EXE

Windows

NT

¹®¼ -°ü¸® ¿£Áø.EX E

Windows

NT

Windows95

Solaris

ÀÀ ¿ë¼-¹ö.EXE

AlphaUNIX

IBM

Mainfra me

µ¥ÀÌÅ º£ÀÌ½º¼- ¹ö

Windows95

¹®¼-°ü¸® ¾ÖÇÃ¸ ´

ºÐ»ê È¯°æÀÇ ÇÏµå¿þ¾î¹× ³×Æ® ¿÷À ·ÎÀÇ Á¤º ½Ã½ºÅ Û ¿¬°á ð µ- À©µµ ¿ì 95 : Å¬¶óÀÌ¾ðÆ®

- À©µµ ¿ì NT: ÀÀ¿ë¼ -¹ö

- À ´Ð½ º ¸Ó ½Å: ÀÀ ¿ë ¼-¹ö ¹× µ¥À ÌÅ ¼- ¹ö, Åë½Å ¼- ¹ö- IBM ¸Þ ÀÎÇÁ·¹ÀÓ: µ¥ÀÌÅ ¼-¹ö, Åë½Å ¼-¹ö

Project artifacts are critical in controlling, measuring, and communicating about a system during its development and after its deployment.

The UML addresses the documentation of a system’s architecture and all of its details. The UML also provides a language for expressing requirements and for tests. Finally, the UML provides a language for modeling the activities of project planning and release management. (The Unified Modeling Language User Guide, Booch, 1999.)

This slide does not represent all the diagrams defined in the UML specification. For example, there is no graphic presented here for a composite structure diagram or a timing diagram. Composite structure is a more advanced modeling concept that is not covered in this course. The timing diagram is new to UML2 and will be introduced in a later module.




History of the UML

22

History of the UML

UMLPartners’ Expertise

UML 1.0(Jan. ‘97)

UML 1.1(Sept. ‘97)

UML 1.5(March, ‘03)

UML 2.0(2004)

Other Methods

Booch ‘91 OMT - 1OOSE

Booch ’93 OMT - 2

Public FeedbackUnified Method 0.8

(OOPSLA ’95)

UML 0.9(June ‘96)

UML 0.91(Oct. ‘96)

and

The UML 2.0 is defined by two complementary specifications, the Infrastructure and the Superstructure. The UML infrastructure defines foundational concepts that can be used in part or entirely by other specifications. The UML superstructure defines the complete UML. The superstructure specification is self contained and you won’t have to read the infrastructure specification unless you are concerned about configuring other specifications in parallel to UML.

The UML metamodel (a description of a model) is divided into two main packages, structure and behavior with two supporting packages, auxiliary elements and profiles.

• The structure package defines the static structure of the UML. • The behavior package defines the dynamic structure of the UML. Each package is described by a chapter in the superstructure specification document.




Inputs to the UML

23

Inputs to the UML

FusionOperation descriptions, message numbering

Before and after conditions

Meyer

HarelState charts

Wirfs-BrockResponsibilities

EmbleySingleton classes, High-level view

OdellClassificationObject lifecycles

Shlaer- Mellor

Gamma, et.alFrameworks, patterns, notes

BoochRumbaugh Jacobson

Selic, Gullekson, WardROOM (Real-Time Object-Oriented Modeling)

UML development included incorporating ideas from numerous other methodologists. The main challenge was to construct an approach that was simple, yet allowed the modeling of a broad range of systems. The conceptual framework was established quickly, but the notational semantics took more time.

Active collaboration with other industry leaders has brought unique expertise and experience into the UML effort. The UML effort was supported by a cross-section of the industry. Partners in the UML effort included HP, ICON Computing, IBM, I-Logix, Intellicorp, MCI Systemhouse, Microsoft, ObjecTime, Oracle, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software, Taskon, and Unisys. These partners provided contributors, reviewers, and advocates for the standardization efforts.

In the end, a modeling language was created that has already withstood the test of widespread use in the industry and the scrutiny of international standardization efforts.




Where Are We?

24


Where Are We?




A Language Is Not Enough to Build a System

25

A Language Is Not Enough to Build a System

ModelingLanguage

UnifiedProcess

Team- BasedDevelopment

The UML provides a standard for the artifacts of development (semantic models, syntactic notation, and diagrams) that must be controlled and exchanged. But the UML is not a standard for the development process.

Despite all its value, you cannot achieve successful development of today’s complex systems solely by using the UML. Successful development also requires employing an equally robust development process.




What Type of Process Most Benefits the UML?

26

What Type of Process Most Benefits the UML?

The UML is largely process independent. A process fully benefits from the UML when the process is:

Use-case drivenArchitecture centricIterative and incremental




A Use-Case Driven Process

27

A Use-Case Driven Process

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

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

Withdraw Money

Customer

Check Balance

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

It’s 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 "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 emphasized that use cases are part of the UML.




An Architecture-Centric Process

28

An Architecture-Centric Process

A system’s architecture is used as a primary artifact for conceptualizing, constructing, managing, and evolving the system under development.Benefits:

Intellectual control over a project to manage its complexity and to maintain system integrity.Effective basis for large-scale reuse.A basis for project management.Assistance in component-based development.

Use cases drive the process end-to-end over the entire lifecycle. The design activities are centered around architecture-centric architecture, or for software-intensive systems, software architecture. The main focus of the early iterations of a architecture-centric process is to produce and validate a software architecture, which in the initial development cycle takes the form of an executable architectural prototype that gradually evolves to become the final system in later iterations.

A complex system is more than the sum of its parts, more than a succession of small independent tactical decisions. It must have some unifying, coherent structure to organize those parts systematically, and provide precise rules on how to grow the system without having its complexity “explode” beyond human understanding. Architecture provides this structure and these rules.

By clearly articulating the major components and the critical interfaces among them, architecture lets you reason about reuse, both internal reuse (the identification of common parts), and external reuse (the incorporation of ready-made, off-the-shelf components). Architecture can also help reuse on a larger scale. That is, the reuse of the architecture itself in the context of a product line that addresses different functionality in a common domain.




An Iterative and Incremental Process

29

An Iterative and Incremental Process

Critical risks are resolved before making large investments. Initial iterations enable early user feedback. Testing and integration are continuous. Objective milestones focus on the short term.Progress is measured by assessing implementations.Partial implementations can be deployed.

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

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

The short-term focus of an iteration is an objective measure of “doneness.” Either a class is included in the build or it’s not. It can’t be 90 percent done. Either a test is executed successfully or it’s not. There is very little room for subjective estimates.

In spite of the best efforts of the development team, not all system features may be complete on the original delivery date. With a waterfall approach, this would usually mean that nothing was ready to be delivered (everything is 90 percent done).

With an iterative approach, most of the system is already fully tested and operational. In many cases, there is value in delivering the partial system on the promised date with the remaining features incorporated at a later time. This can be important when a user has a critical need for some of the new functionality provided by the system or it may help the training and installation process to proceed on schedule. An iterative approach can avoid inconvenient re-planning and re-assignment of resources.




Iterative Development

30

Iterative Development

Earliest iterations address greatest risks.Each iteration produces an executable release, an additional increment of the system.Each iteration includes integration and test.

T I M E

Iteration 1 Iteration 2 Iteration 3

IC

DR

TI

CD

R

TI

CD

R

T

In the diagram above, the following abbreviations are used.

• R Requirements analysis • D Design • C Coding, unit testing • I Implementation • T Subsystem and system test Iterative processes were developed in response to these waterfall characteristics. With an iterative process, apply the waterfall steps iteratively. Instead of developing the whole system at once, select and develop an increment (a subset of system functionality), then another increment, and so on.

Develop the first increment based on risk, with the highest priority risks to be developed first.

To address the selected risk(s), choose a subset of use cases.

Develop the smallest number of use cases that allow objective verification (like a set of executable tests) of the risks that you’ve chosen.

Select the next increment to address the next highest risk, and so on. Thus, you apply the waterfall within each iteration and the system evolves incrementally.




Review

31

Review

What is a model?What are the viewpoints of MDA? Describe each one.What are the four principles of modeling? Describe each one.What is the UML? Describe each of its four benefits.What process characteristics best fit the UML? Describe each characteristic.What is an iteration?



► ► ► Module 3 Concepts of Object Orientation

1

IBM Software Group

®

Essentials of Visual Modeling with UML 2.0Module 3: Concepts of Object Orientation

Topics

What Is an Object?............................................................................................... 3-4 Basic Principles of Object Orientation................................................................. 3-10 What Is a Class?.................................................................................................. 3-20 The Relationship Between Classes and Objects ................................................... 3-23 What Is a Package?............................................................................................. 3-35




Objectives

2

Objectives

Describe abstraction, encapsulation, modularity, and hierarchy.Describe the physical structure of a class.Describe the relationship between a class and an object.Define polymorphism and generalization.



Module 3 - Concepts of Object Orientation

Where Are We?

3

Where Are We?

What is an object?Four principles of OOWhat is a class?Polymorphism and generalizationOrganizing model elements




What Is an Object?

4

Informally, an object represents an entity, either physical, conceptual, or software.

Physical entity

Conceptual entity

Software entity

Truck

Chemical Process

Linked List

What Is an Object?

Objects allow the software developer to represent real-world concepts in their software design. These real-world concepts can represent a physical entity such as a person, truck, or space shuttle.

Objects can be concepts like a chemical process or algorithms.

Object can even represent software entities like a linked list.




A More Formal Definition

5

A More Formal Definition

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

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

Operations

Attributes

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

An object has two key components: attributes and operations.

Attributes and relationships represent an object’s state. Operations represent the behavior of the object.

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




An Object Has State

6

An Object Has StateState is a condition or situation during the life of an object, which satisfies some condition, performs some activity, or waits for some event.The state of an object normally changes over time.

Name: J ClarkEmployee ID: 567138Date Hired: July 25, 1991Status: TenuredDiscipline: FinanceMaximum Course Load: 3 classes

Name: J ClarkEmployee ID: 567138HireDate: 07/25/1991Status: TenuredDiscipline: FinanceMaxLoad: 3

Professor Clark

The state of an object is one of the possible conditions in which an object may exist. State normally changes over time.

The state of an object is usually implemented by a set of properties called attributes, along with the values of the properties and the links the object may have with other objects.

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




An Object Has Behavior

7

An Object Has Behavior

Behavior determines how an object acts and reacts.The visible behavior of an object is modeled by a set of messages it can respond to (operations that the object can perform).

Professor Clark’s behaviorSubmit Final GradesAccept Course OfferingTake SabbaticalSet Max Load

SubmitF

inalG

rade

s()

AcceptCourseOffering()

TakeSabbatical()

Professor Clark

SetMaxLoad()

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

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

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




An Object Has Identity

8

An Object Has Identity

Each object has a unique identity, even if the state is identical to that of another object.

Professor “J Clark” teaches Biology

Professor “J Clark” teaches Biology

In the real world, two people can share the same characteristics: name, birth date, job description. Yet, there is no doubt that they are two individuals with a unique identity.

The same concept holds true for objects. Although two objects may share the same state (attributes and relationships), they are separate, independent objects with their own unique identity.




Where Are We?

9

Where Are We?





Basic Principles of Object Orientation

10

Basic Principles of Object Orientation

Abst

ract

ion

Hier

arch

y

Object Orientation

Enca

psul

atio

n

Mod

ular

ity

There are four basic principles of object orientation:

• Abstraction • Encapsulation • Modularity • Hierarchy




What Is Abstraction?

11

What Is Abstraction?

The essential characteristics of an entity that distinguishes it from all other kinds of entities. Defines a boundary relative to the perspective of the viewer. Is not a concrete manifestation, denotes the ideal essence of something.

Abstraction can be defined as:

Any model that includes the most important, essential, or distinguishing aspects of something while suppressing or ignoring less important, immaterial, or diversionary details. The result of removing distinctions so as to emphasize commonalties. (Dictionary of Object Technology, Firesmith, Eykholt, 1995.)

• Abstraction allows us to manage complexity by concentrating on the essential characteristics of an entity that distinguishes it from all other kind of entities.

• An abstraction is domain and perspective dependent. That is, what is important in one context may not be in another.

• OO allows us to model our system using abstractions from the problem domain (for example, classes and objects).




Example: Abstraction

12

Example: Abstraction

Student Professor

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

The following are examples of abstraction:

• A student is a person enrolled in classes in 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 the days of the week

and the times.




What Is Encapsulation?

13

What Is Encapsulation?

Improves Resiliency

Hides implementation from clients.Clients depend on interface.

Encapsulation can be defined as:

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

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

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

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

• Encapsulation offers two kinds of protection. It protects an object’s internal state from being corrupted by its clients and client code from changes in the object’s implementation.




Encapsulation Illustrated

14

Encapsulation Illustrated

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

SubmitF

inalG

rades

()

AcceptCourseOffering()

TakeSabbatical()

Professor Clark

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

SetMaxLoad(4)

The key to encapsulation is an object’s message interface. The object interface ensures that all communication with the object takes place through a set of predefined operations. Data inside the object is only accessible by the object’s operations. No other object can reach inside 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 makes 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 or variables that are used to define the maximum course load may be increased, but it doesn’t affect the requesting object. It depends on the operation interface for the Professor Clark object.




What Is Modularity?

15

What Is Modularity?

Breaks up something complex into manageable pieces.Helps people understand complex systems.

Modularity can be defined as:

The logical and physical decomposition of things (for example, responsibilities and software) into small, simple groupings (for example, requirements and classes, respectively), which increase the achievements of software-engineering goals. (Dictionary of Object Technology, Firesmith, Eykholt, 1995.)

• Another way to manage complexity is to break something that is large and complex into a set of smaller, more manageable pieces. These pieces can then be independently developed as long as their interactions are well understood.

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




Example: Modularity

16

Example: Modularity

For example, break complex systems into smaller modules. Billing

System

Course Registration System

Course Catalog System

Student Management System

Often, the system under development is too complex to understand. To better understand this, imagine that the system is broken into smaller blocks that are 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 understand the details. Therefore, the development team broke this system into three modular systems, each independent of the others.

• Billing System • Course Catalog System • Student Management System




What Is Hierarchy?

17

What Is Hierarchy?

Decreasing abstraction

Increasingabstraction

Asset

RealEstate

Savings

BankAccount

Checking Stock

Security

Bond

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

Hierarchy can be defined as:

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

• Hierarchy organizes in a particular order or rank (for example, complexity, responsibility, and so on). 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 neither an organizational chart nor 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 into a periodic table.




Representing Objects in the UML

18

Representing Objects in the UML

An object is represented as a rectangle with an underlined name.

J Clark : Professor

: Professor

Named Object

Anonymous Object

Professor J Clark

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

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

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




Where Are We?

19

Where Are We?





What Is a Class?

20

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.

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 abstraction helps us deal with complexity.




A Sample Class

21

A Sample Class

ClassCourse

PropertiesName

LocationDays offeredCredit hours

Start timeEnd time

BehaviorAdd a student

Delete a studentGet course roster

Determine if it is full

The class “Course” is an abstraction of the real-world representation of a college course. The class has properties: name, location, days offered, credit hours, start time, and end time. It also has behavior, like adding and deleting a student to the class, retrieving a current course roster, and determining if the course is full.

The class does not represent a specific course like Algebra 101 or Theatre Arts 102. Rather, it is a description of the types of properties and behavior a typical course may have.




Representing Classes in the UML

22

Representing Classes in the UML

A class is represented using a rectangle with three compartments:

The class name

The structure (attributes)

The behavior (operations)

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

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

The UML notation for a class permits you to see an abstraction apart from any specific programming language, which lets you emphasize the most important parts about an abstraction – its name, attributes, and operations.

Graphically, a class is represented by a rectangle.

The UML represents public visibility with a plus (+) symbol and private visibility with a minus (-) symbol.




The Relationship Between Classes and Objects

23

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

Professor Meijer

Professor Torpie

Professor Allen

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

A class defines an object. 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 and the object is the run-time instance of that class.

Modeling is from real-world objects. Software objects are based on the real-world objects, but exist only in the context of the system.

Use real-world objects, abstract out what you don't care about. Then, take these abstractions and go through the process of classification 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 you originally started with.

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




What Is an Attribute?

24

What Is an Attribute?

An attribute is a named property of a class that describes the range of values that instances of the property may hold.

A class may have any number of attributes or no attributes at all.

Attributes

Student- name- address- studentID- dateOfBirth

An Attribute can be defined as:

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

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

• An attribute defined by a class represents a named property of the class or its objects. An attribute defines the type of its instances.

• An attribute has a type, which tells us what kind of attribute it is. Typical attributes are integer, Boolean, real, and enumeration. These are called primitive types. An attribute does not need to be a primitive type though.




Attributes in Classes and Objects

25

Attributes in Classes and Objects

Class

Objects

Student- name- address- studentID- dateOfBirth

:Student- name = “M. Modano”- address = “123 Main St.”- studentID = 9- dateOfBirth = “03/10/1967”

:Student- name = “D. Hatcher”- address = “456 Oak Ln.”- studentID = 2- dateOfBirth = “12/11/1969”

At the class level, the Student class attributes indicate that the Students have names, addresses, studentIDs, and a date of birth.

At the object level, the attributes indicate the values for the name, address, studentID, and date of birth.

Only the class instance (objects) should be able to change the value of the attributes.

The state of an object is defined by the value of its attributes and the existence of links to other objects.




What Is an Operation?

26

What Is an Operation?

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.A class may have any number of operations or none at all.

Operations

Student

+ get tuition()+ add schedule()+ get schedule()+ delete schedule()+ has prerequisites()

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. • An operation can either be a command or a question. A question should never

change the state of the object. Only a command can change the state of the object.

• An operation is described with a return-type, name, and zero or more parameters. Together, the return-type, name, and parameters are called the signature of the operation.

• The outcome of the operation depends on the current state of the object. Often, but not always, invoking an operation on an object changes the object’s data or state.




Where Are We?

27

Where Are We?





What Is Polymorphism?

28

What Is Polymorphism?

The ability to hide many different implementations behind a single interface.

Manufacturer AManufacturer B Manufacturer C

OO Principle:Encapsulation

Remote Control

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

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




Example: Polymorphism

29

Example: Polymorphism

Stock Bond Mutual Fund

getCurrentValue()

financialInstrument.getCurrentValue()

getCurrentValue()

getCurrentValue()

In this example, a requesting object would like to know the current value of a financial instrument. However, the current value for each financial instrument is calculated in a different fashion. The stock needs to determine the current asking price in the financial market that it is listed under. The bond needs to determine the maturity timelines and interest rates. A mutual fund needs to check the day’s closing price from the fund management company.

In a non object-oriented development environment, you would write code that may look something like this:

IF financialInstrument = Stock THEN

calcStockValue()

ELSEIF financialInstrument = Bond THEN

calcBondValue()

ELSEIF financialInstrument = MutualFund THEN

calcMutualFundValue()

With object technology, each financial instrument can be represented by a class, and each class would know how to calculate its own value. The requesting object simply needs to ask the specific object (for example, Stock) to get its current value. The requesting object does not need to keep track of three different operation signatures. It only needs to know one. Polymorphism allows the same message to be handled in different ways depending on the object that receives it.




What Is Generalization?

30

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.

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 generalized class “is a kind of” the parent class.

• The terms “generalization” and “inheritance” are generally interchangeable, but if you need to distinguish, generalization is the name of the relationship. 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).




Example: Single Inheritance

31


One class inherits from another.

CheckingSavings

Superclass (parent)

Subclasses(children)

Generalization Relationship

AncestorAccount

- balance- name- number

+ withdraw()+ createStatement()

Descendents

The generalization is drawn from the subclass class to the superclass/parent class.

The terms “ancestor” and “descendent” may be used instead of “superclass” and “subclass.”




Example: Multiple Inheritance

32


A class can inherit from several other classes.

Use multiple inheritance only when needed and always with caution!

FlyingThing Animal

HorseWolfBirdHelicopterAirplane

Multiple Inheritance

Multiple inheritance means that a class can inherit several other classes. For example, Bird inherits from both FlyingThing and Animal.

Multiple inheritance is conceptually straight forward and may be needed to model the real world accurately. However, there are potential implementation problems when you use multiple inheritance, as not all implementation languages support it. Thus, be judicious with your use of multiple inheritance. Use it only where it accurately describes the concept and reduces the complexity of your model. Be aware, however, that this representation probably needs to be adjusted in design and implementation.

Generally, a class inherits from only one class.




What Is Inherited?

33

What Is Inherited?

Inheritance leverages the similarities among classes.

A subclass inherits its parent’s attributes, operations, and relationships.A subclass may:

Add additional attributes, operations, relationships.Redefine inherited operations. (Use caution!)

Common attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy.

Generalization is more than finding common attributes, operations, and relationships. It is more about the responsibilities and essence of the classes.




Where Are We?

34

Where Are We?





What Is a Package?

35

A general purpose mechanism for organizing elements into groups.A model element that can contain other model elements.A package can be used:

To organize the model under development.As a unit of configuration management.

What Is a Package?

University Artifacts

A Package can be defined as:

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

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

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

• A package is simply a grouping mechanism. No semantics are defined for its instances. Thus, packages do not necessarily have a representation in implementation, except maybe to represent a directory.

• In the UML, a package is represented as a tabbed folder. • Package diagrams depict dependencies between packages and are now

formalized in UML 2.




A Package Can Contain Classes

36

A Package Can Contain Classes

The package, University Artifacts, contains one package and five classes.


CourseOffering

Schedule

Professor

Course

Student

StudentArtifacts

A package owns its elements and can even own other packages.

Owning is a composite relationship, meaning that the element is declared in the package. If the package is destroyed, the element is destroyed.

Every element is uniquely owned by exactly one package. For example, the package UniversityArtifacts owns the following classes: Course, Student, Schedule, Professor, and Course Offering. If the UniversityArtifacts package is destroyed then all of these classes are also destroyed. If you move the package to a different location in your model (architecturally speaking), then the classes move, too.

A package is an important mechanism for dealing with scale. Without packages, you would end up with large, flat models where all elements would be uniquely named.

Packages help you control the elements that compose your system as they evolve at different rates over time.




Diagram Depiction

37

Diagram Depiction

<heading>

<contents area>

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

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

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

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

This <kind> can be:

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




Review

38

Review

What is an object? What are the four principles of object orientation? Describe each.What is a class? How are classes and objects related?What is an attribute? An operation?Define polymorphism. Provide an example of polymorphism.What is generalization?Why use packages?




Exercise: Principles of Object Orientation

39

Exercise: Principles of Object Orientation

The “OO Quiz Show” RulesEveryone in the class is assigned a number.The instructor displays a question.The instructor calls out a number.If the student answers the question correctly, the class continues to the next question.If the student does not answer the question correctly, the class goes back to the beginning.The game is over when all questions have been answered correctly.



► ► ► Module 3a VM Quiz Show

1

IBM Software Group

®

Essentials of Visual Modeling with UML 2.0Module 3a: VM Quiz Show

© Copyright IBM Corp. 2004 3a - 1



Question

2

Question

Object technology is . . . ?

A. A set of principles guiding software construction.

B. A new theory striving to gain acceptance.C. A dynamic new language by Grady

Booch.D. Based on the principles of abstraction and

modularity.

Answer: A

3a - 2 © Copyright IBM Corp. 2004


Module 3a - VM Quiz Show

Question

3

Question

A model . . .?

A. Is not necessary when team members understand their job.

B. Has to be structural AND behavioral.

C. Is a simplification of reality.D. Is an excuse for building an

elaborate plan.

Answer: C




Question

4

Question

Why do we model?

A. Helps to visualize a systemB. Gives us a template for constructing

a systemC. Documents our decisions D. All of the above

Answer: D




Question

5

Question

The best models are connected to . . .?

A. Java-script codeB. RealityC. C ++D. Issues that tie it to an object-

oriented developer

Answer: B




Question

6

Question

Which project would be least likely to require a model?

A. B.

C. D.

Answer: B




Question

7

Question

Which principles of modeling are correct?

A. The model you create, influences how the problem is attacked.

B. The best kinds of models are those that let you chose your degree of detail.

C. The best models are connected to reality.

D. Create models that are built and studied separately.

Answer: A, B, C and D




Question

8

Question

Views are “slices” of architecture. Which view focuses on structural issues?

A. Use case B. ProcessC. ImplementationD. Logical

Answer: D




Question

9

Question

Which process characteristic is not essential to working with the UML?

A. Iterative and incrementalB. Use-case drivenC. ResilientD. Architecture-centric

Answer: C




Question

10

Question

The state of an object . . .?

A. Is defined by a “state” attribute or set of attributes.

B. Does not normally change over time.C. Is defined by an object’s attributes and

relationships.D. Is the only condition in which an object

may exist.

Answer: C

State of an object is defined by the total of an object’s attributes and links. For example, if Professor Clark’s status changed from tenured to retired, the state of the Professor Clark object changes.




Question

11

Question

The visible behavior of an object is modeled by its . . .?

A. AttributesB. ResponsibilitiesC. OperationsD. Methods

Answer: C

Objects are intended to mirror the concepts that they are modeled after, including behavior.




Question

12

Encapsulation . . . ?

A. Allows direct manipulation of things that have been encapsulated.

B. Is often referred to as information hiding.C. Causes costly and extensive maintenance.D. Causes changes to affect clients during

implementation.

Answer: B

Question




Question

13

Question

What happens when you incorporate modularity into your plan?

A. It reduces something complex into manageable pieces.

B. It builds modules that talk to each other.C. Creates systems too large to understand.D. Parts of your system cannot be

independently developed.

Answer: A




Question

14

Question

A class . . . ?

A. Is an encapsulation of an object.B. Represents the hierarchy of an object.C. Is an instance of an object.D. Is an abstract definition of an object.

Answer: D

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

A class is not an object. It is an abstract definition of an object. It defines the structure and behavior of each object in the class.




Question

15

Question

Polymorphism can be described as?

A. Hiding many different implementations behind one interface

B. InheritanceC. Information placingD. Generalization

Answer: A




Question

16

Question

What phrase best represents a generalization relationship?

A. “Is a part of”B. “Is a kind of”C. “Is a replica of”D. “Is an inheritance of”

Answer: B




Question

17

Question

Which of the following would you use to organize elements into groups?

A. PackageB. ClassC. EncapsulationD. Generalization

Answer: A



► ► ► Module 4 Use-Case Modeling

1

IBM Software Group

®

Essentials of Visual Modeling with UML 2.0Module 4: Use-Case Modeling

Topics

Major Concepts in Use-Case Modeling ................................................................. 4-7 Use Cases and Actors ......................................................................................... 4-11 What Is an Activity Diagram? .............................................................................. 4-14




Objectives

2

Objectives

Describe system behavior and show how to capture it in a model.Demonstrate how to read and interpret:

A use-case diagramAn activity diagram



Module 4 - Use-Case Modeling

Where Are We?

3

Where Are We?

Concepts in use-case modelingUse-case diagramsActivity diagrams




What Is System Behavior?

4

What Is System Behavior?

System behavior is how a system acts and reacts.

It comprises the actions and activities of a system.

System behavior is captured in use cases.Use cases describe the interactions between the system and (parts of) 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 do not specify how the behavior is to be implemented.

The UML specifies a model for communicating system behavior, the use-case model.




What Is a Use-Case Model?

5

What Is a Use-Case Model?

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

View Report Card

Student

Register for Courses

Login

A use-case model describes a system’s functional requirements in terms of use cases. The use-case model is a model of the system's intended functions and its environment and 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.

The customer approves the use-case model. When you have that approval, you know the system is what the customer wants. You can also use the model to discuss the system with the customer during development.

Participants use it 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 review the use cases as a basis for writing the system's user guides.

The architect checks the use-case model to identify architecturally significant functionality.

The manager uses it to plan and follow up on the use-case modeling and also the subsequent design.




What Are the Benefits of a Use-Case Model?

6

What Are the Benefits of a Use-Case Model?

CommunicationIdentificationVerification

End User Domain Expert Users

Verification

Iden

tific

atio

n

Use Case

Communication

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

Communication with the end users and domain experts

• Provide buy-in at an early stage of system development • Insure a mutual understanding of the requirements Identification of system users and what the system should do

• The requirements for the system interfaces Verification that all requirements have been captured

• The development team understands the requirements Actors are the users and any other system that may 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 actor’s needs, ensuring that the system turns out to be what the users expected.




Major Concepts in Use-Case Modeling

7

Major Concepts in Use-Case Modeling

An actor represents anything that interacts with the system.

A use case describes a sequence of events, performed by the system, that yields an observable result of value to a particular actor.

Actor

Use Case

An actor represents a coherent set of roles that one plays when interacting with these use cases. Typically, an actor represents a role that a human, a hardware device, or even another system plays with a system.

A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor. A use case describes what a system does, but it does not specify how it does it.




Where Are We?

8


Where Are We?




What Is an Actor?

9

What Is an Actor?Actors represent roles a user of the system can play.They can represent a human, a machine, or another system. They can actively interchange information with the system.They can be a giver of information. They can be a passive recipient of information.Actors are not part of the system.

Actors are EXTERNAL.

Actor

An Actor can be defined as:

Anything that exchanges data with the system and is external to the system.

• To fully understand the system's purpose you must know who the system is for. Different user types are represented as actors.

• An actor can be a user, external hardware, or another system. An actor may actively interchange information with the system, be a passive recipient of information, or can represent a human, a machine or another system.

• The difference between an actor and an individual system user is that an actor represents a particular class of user rather than an actual user. Several users can play the same role, which means they can be one and the same actor. In which case, each user constitutes an instance of the actor.

• In some situations, only one person plays the role modeled by an actor. For example, there may be only one individual playing the role of system administrator for a rather small system.

• The same user can also act as several actors. That is, the same person can take on different roles.




What Is a Use Case?

10

What Is a Use Case?

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 models a dialogue between one or more actors and the systemA use case describes the actions the system takes to deliver something of value to the actor

A Use-Case can be defined as:

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

• Actions - An action is a computational or algorithmic procedure. It is invoked either when the actor provides a signal to the system or when the system receives a time event. An action may imply signal transmissions to either the invoking actor or other actors. An action is atomic. That is, it is performed either entirely or not at all.

• System performs - The system provides the use case. An actor communicates with a use-case instance of the system.

• An observable result of value - You can put a value on a successfully performed use case. A use case should ensure that an actor can perform a task that has an identifiable value. This is important to determine the correct level or granularity for a use case. Correct level refers to achieving use cases that are not too small. In certain circumstances, you can use a use case as a planning unit that includes individuals playing the role of an actor to the system.

• A particular actor - The actor is key to finding the correct use case because the actor helps to avoid use cases that are too large. As an example, consider a visual modeling tool. There are two actors to this application: a developer, someone who develops systems using the tool as support and a system administrator, someone who manages the tool. Each of these actors has its own demands on the system and requires its own set of use cases.




Use Cases and Actors

11

Use Cases and Actors

A use case models a dialog between actors and the system.A use case is initiated by an actor to invoke a certain functionality in the system.

Actor

AssociationUse Case

It is important to show how actors relate to the use case. Therefore, on finding a use case, establish the actors that interact with it. To do this, you must define an association that helps to clarify the communication between the actor and use case.

Actors may be connected to use cases only by an association. An association between an actor and a use case indicates that the actor and the use case instance of the system communicate with one another, each one able to send and receive messages. The arrow head is optional but it’s commonly used to denote the initiator.




How Would You Read This Diagram?

12

How Would You Read This Diagram?

View Report Card

Student

Register for Courses

Login

Select Courses toTeach

Submit Grades

Professor

Registrar

Billing System

Maintain ProfessorInformation

Maintain StudentInformation

Close Registration

Course Catalog

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

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




Where Are We?

13


Where Are We?




What Is an Activity Diagram?

14

What Is an Activity Diagram?

An activity diagram in the use-case model can be used to capture the activities and actions performed 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.

Activity 1 Activity 3

Activity 2

The workflow of a use case describes that which needs to be done by the system to provide the value the served actor is looking for.

It consists of a sequence of activities and actions 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.




What Is an Activity?

15

What Is an Activity?

A specification of behavior expressed as a flow of execution via sequencing of subordinate units.

Subordinate units include nested activities and ultimately individual actions.

May contain boolean expression constraints when the activity is invoked or exited

<<Precondition>>Boolean constraint

Activity 5<<Postcondition>>Boolean constraint

Activity 4

Activity 2

An activity is notated as an activity diagram. An activity definition is shown as a large rounded border containing a graph of node symbols and flow arrows representing the decomposition of the activity into its constituents. Activity preconditions and postconditions use the note notation with the keywords <<Precondition>> and <<Postcondition>> respectively.

An action is a primitive activity which is the smallest computation that can be expressed. An action is an activity that does something to the state of the system or extracts information from it. An action is drawn as a rectangle with rounded corners. Action preconditions and postconditions use the note notation with the keywords <<localPrecondition>> and <<localPostcondition>> respectively.




Example: Activity Diagram

16

Example: Activity Diagram

SynchronizationBar (Fork)

GuardCondition

SynchronizationBar (Join)

DecisionConcurrent

Threads

Transition

Select Course

[ add course ]

Check Schedule

Check Pre-requisites

Assign to Course

Resolve Conflicts

Update Schedule

Delete Course

[ checks completed ] [ checks failed ]

[ delete course ]

Activity/Action

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.




Review

17

Review

What is system behavior? What is a use-case model? What are its benefits?What is an actor? A use case?What is an activity diagram?




Exercise

18

Exercise

Given:Use cases, actors and associations

Draw: A use-case diagram

Given:Action states and activity edges

Draw:An activity diagram

1. Draw a use-case diagram using the following elements: • There are four actors on the diagram: Prospective Buyer, E-Mail System, Loan

System, and Credit Reporting System. • There are four use cases on the diagram: Find Realtor, Maintain Personal

Planner, Search for a Home, and Apply for a Loan. • Document the following association;

• Prospective Buyer to Find Realtor • Prospective Buyer to Maintain Personal Planner • Prospective Buyer to Search For A Home • Prospective Buyer to Apply For A Loan • Maintain Personal Planner to E-Mail System • Search for a Home to E-Mail System • Apply for a Loan to Loan System • Apply for a Loan to Credit Reporting System

Study the diagram that you have drawn. What does it say? What doesn’t it say? Describe the functionality that a Prospective Buyer expects from the system? 2. Draw an activity diagram that reflects the following four action states:

Choose Profile, Find Buyer Profile, Log on, and Create New Profile. Starting with Choose Profile, go to Find Buyer Profile; then go from the Find Buyer Profile to Create New Profile, providing a profile does NOT exist. If a profile does exist, you can go to Log on.



► ► ► Module 5 Interaction Diagrams

1

IBM Software Group

®

Essentials of Visual Modeling with UML 2.0Module 5: Interaction Diagrams

Topics

What is an Interaction Diagram?........................................................................... 5-5 What Is a Sequence Diagram? .............................................................................. 5-9 What Is a Communication Diagram?................................................................... 5-18 Sequence and Communication Diagram Similarities ........................................... 5-24




Objectives

2

Objectives

Describe dynamic behavior and show how to capture it in a model.Demonstrate how to read and interpret:

A sequence diagram A communication diagram

Explain the similarities and differences between communication and sequence diagrams.



Module 5 - Interaction Diagrams

Objects Need to Collaborate

3

Objects Need to Collaborate

Objects are useless unless they can collaborate to solve a problem.

Each object is responsible for its own behavior and status.No one object can carry out every responsibility on its own.

How do objects interact with each other?They interact through messages.

Objects need to realize the behavior specified in each use-case scenario. How is this done? The objects must collaborate together to bring about the desired behavior in the system.

Is there a mechanism that allows these objects to work together? There is, and that mechanism is called a message.




Objects Interact with Messages

4

Objects Interact with Messages

A message shows how one object asks another object to perform some activity.

: Car buyer:RegistrationController :CourseCatalogSystem

getCourseOfferings(forSemester)

Message

A message can be defined as:

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

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

• Messages are the mechanism that permits objects to interact with each other. A message is often implemented by a simple activity. For example, one object calls an operation in another. When the activity has been executed, the control is returned to the caller along with a return value.




What is an Interaction Diagram?

5

What is an Interaction Diagram?

Generic term that applies to several diagrams that emphasize object interactions

Sequence DiagramCommunication Diagram

Specialized VariantsTiming DiagramInteraction Overview Diagram




Interaction Diagrams

6


Sequence DiagramTime oriented view of object interaction

Communication DiagramStructural view of messaging objects

Communication Diagrams

Sequence Diagrams

The sequence diagram is a time-oriented view of the interaction between objects to accomplish a behavioral goal of the system. An interaction may be modeled at any level of abstraction within the system design, from subsystem interactions to instance-level interaction for a single operation or activity.

The communication diagram is a structural view of the messaging between objects, taken from the Collaboration diagram concept of UML1.





7


Timing DiagramTime constraint view of messages involved in an interaction

Interaction Overview DiagramHigh level view of interaction sets combined into logic sequence

Timing Diagrams

Interaction Overview Diagrams

The timing diagram is an optional diagram designed to specify the time constraints on messages sent and received in the course of an interaction. This diagram probably has more usefulness in real-time applications where timing is critical.

The interaction overview diagram is a high-level view of the sets of interactions combined into logic sequence, including flow-control logic to navigate between the interactions. Think of this as a cross between a Sequence Diagram, for the interactions sets, and an Activity Diagram, for the logic sequence.




Where Are We?

8

Sequence diagramsCommunication diagramsInteraction diagram comparison

Where Are We?




What Is a Sequence Diagram?

9

What Is a Sequence Diagram?

A sequence diagram is an interaction diagram that emphasizes the time ordering of messages.The diagram shows:

The objects participating in the interaction.The sequence of messages exchanged.

Sequence Diagram

A sequence diagram 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.

In most cases, we use a sequence diagram to illustrate use-case realizations. That is, realizations show how objects interact to perform the behavior of all or part of a use case. One or more sequence diagrams may illustrate the object interactions that enact a use case. A typical organization is to have one sequence diagram for the main flow of events and one sequence diagram for each independent sub-flow of the use case.

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




Example: Sequence Diagram

10

Example: Sequence Diagram

: Student :RegisterForCoursesForm :RegistrationController : Course Catalog:CourseCatalogSystem

1: create schedule( )

5: display course offerings( )

2: get course offerings( )

3: get course offerings(forSemester)

6: display blank schedule( )


Select Offeringsref

You can have objects and actor instances in sequence diagrams, together with messages describing how they interact. The diagram describes what takes place in the participating objects, in terms of activations, and how the objects communicate by sending messages to one another.

You can make a sequence diagram for each variant of a use case's flow of events.

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

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

• Only the RegisterForCoursesForm interacts with the Student actor. • The RegistrationController understands how Students and Schedules are related. • Only the CourseCatalogSystem class interacts with the external legacy Course

Catalog System. Note the inclusion of the actors. This is important as it explicitly models what elements communicate with the “outside world.”




Sequence Diagram Contents: Objects

11

Sequence Diagram Contents: Objects

:RegisterForCoursesForm :RegistrationController SWTSU Catalog : CourseCatalogSystem

Anonymous Objects

Lifelines

Named Object

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 underlined and separated by a colon:

objectname : classname

You can use objects in sequence diagrams in the following ways:

• A lifeline can represent an object. Thus, you can use a lifeline to model both class and object behavior. Usually, a lifeline represents all objects of a certain class.

• An object's class can be unspecified. Normally you create a sequence diagram with objects first and specify their classes later.

• The objects can be unnamed. However, name them if you want to discriminate different objects of the same class.

• Several lifelines in the same diagram can represent different objects of the same class. As stated previously, the objects should be named so that you can discriminate between the two objects.

• A lifeline that represents a class can exist in parallel with lifelines that represent objects of that class. The object name of the lifeline that represents the class can be set to the name of the class.




Sequence Diagram Contents: Actor

12


: Student : Course Catalog

Sequence Diagram Contents: Actor

Actor instances

Normally an actor instance is represented by the first (leftmost) lifeline in the sequence diagram, as the invoker of the interaction. If you have several actor instances in the same diagram, try keeping them either to the leftmost or to the rightmost lifelines.

Don’t show the interaction between actors in a sequence diagram because actors are, by definition, external to the system.




Sequence Diagram Contents: Messages

13

Sequence Diagram Contents: Messages

ReflexiveMessages


2: get course offerings( )3: get course offerings(for Semester)






Message

A message is a communication between objects that conveys information with the expectation that activity will ensue.

In sequence diagrams, a message is shown as a horizontal solid arrow from the lifeline of one object to the lifeline of another object.

For a message from an object to itself, the arrow may start and finish 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 to show the sequence of the message in the overall interaction.

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

A message can be unassigned, meaning that its name is a temporary string that describes the overall meaning of the message. (// is a way to represent responsibilities and is discussed further in the OOAD course.) It is not the name of an operation of the receiving object. You can later assign the message by specifying the operation of the message's destination object. The specified operation then replaces the name of the message.




Sequence Diagram Contents: Execution Occurrence

14



3: get course offerings(for Semester)





Sequence Diagram Contents: Execution Occurrence

Execution Occurrence


The execution occurrence is a tall, thin rectangle that shows the period of time during which an object is performing an action, either directly or through a subordinate procedure.

The top of the rectangle is aligned with the start of the action. The bottom is aligned with its completion.

In earlier UML releases, the execution occurrence was called the focus of control. This changed with UML 2.




Sequence Diagram Contents: Event Occurrence

15








Sequence Diagram Contents: Event Occurrence

Event Occurrence


The event occurrence is the sending or receipt of a message by an object. An event occurrence is not explicitly shown as a separate modeling concept. It is normally shown by the intersection of the message with the lifeline. A message connects two event occurrences on two lifelines.




Sequence Diagram Contents: Interaction Occurrence

16








Sequence Diagram Contents: Interaction Occurrence


Select Offeringsref

Interaction Occurrence

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

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




Where Are We?

17


Where Are We?




What Is a Communication Diagram?

18

What Is a Communication Diagram?

A communication diagram emphasizes the organization of the objects that participate in an interaction.The communication diagram shows:

The objects participating in the interaction.Links between the objects.Messages passed between the objects.

Communication Diagrams

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

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

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

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




Example: Communication Diagram

19

Example: Communication Diagram

: Student

: RegisterForCoursesForm

: RegistrationController : CourseCatalogSystem

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

: Course Catalog1: create schedule( )




You can have objects and actor instances in communication diagrams, together with links and messages describing how they are related and how they interact.

The diagram describes what takes place in the participating objects, in terms of how the objects communicate by sending messages to one another.

You can make a communication diagram for each variant of a use case's flow of events.

The above example shows the communication of objects to support the Register for Courses use case, Create a Schedule sub-flow. It is the “communication diagram equivalent” of the sequence diagram shown earlier.




Communication Diagrams Contents: Objects

20

Communication Diagrams Contents: Objects

Objects


: RegistrationController SWTSU Catalog : CourseCatalogSystem

An object is represented by an object symbol, showing the name of the object and its class underlined, separated by a colon.

objectname : classname

You can use objects in communication diagrams in the following ways:

• An object's class can be unspecified. Normally, you create a communication diagram with objects first and specify their classes later.

• The objects can be anonymous. However, you should name them if you want to discriminate different objects of the same class.




Communication Diagram Contents: Actors

21

Communication Diagram Contents: Actors



: RegistrationController SWTSU Catalog : CourseCatalogSystem

Actors

Normally an actor instance occurs in the communication diagram as the invoker of the interaction.

If you have several actor instances in the same diagram, try to keep them in the periphery of the diagram.

Don’t show the interaction between actors in a communication diagram because actors are, by definition, external to the system.




Communication Diagram Contents: Links and Messages

22

Communication Diagram Contents: Links and Messages

: Student


: RegistrationController : CourseCatalogSystem

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

: Course Catalog1: create schedule( )




Links

Messages

A link is a relationship between objects across which messages can be sent. 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 can be an instance of an association. Or, it can be anonymous, meaning that its association is unspecified.

Message flows are attached to links. A message is a communication between objects that conveys information with the expectation that activity will ensue. In communication diagrams, a message is shown as a labeled arrow placed near a link. That is, 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 to describe the relative sequencing of messages.




Where Are We?

23


Where Are We?




Sequence and Communication Diagram Similarities

24

Sequence and Communication Diagram Similarities

Semantically equivalentCan convert one diagram to the other without losing any information

Model the dynamic aspects of a systemModel a use-case scenario

Because they both derive the same information from the UML’s metamodel; sequence diagrams and communication diagrams are semantically equivalent. As a result, you can take a diagram in one form and convert it to the other without any loss of information.




Sequence and Communication Diagram Differences

25

Sequence and Communication Diagram Differences

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

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

Communication diagrams

Sequence diagrams

• Sequence and communication diagrams express similar information, but show it

in different ways. • Communication diagrams emphasize the structural communication of a society

of objects and show a clearer picture of the pattern of relationships and control that exist among the objects participating in a use case.

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

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

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

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

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

• On sequence diagrams, the time dimension is easier to read, the operations and parameters are easier to present, and the 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, as well as validate the architecture.




Review

26

What is the purpose of an interaction diagram?What is a sequence diagram? A communication diagram?What is a timing diagram? An interaction overview diagram?What are the similarities between sequence and communication diagrams?What are the differences between sequence and communication diagrams?

Review




Exercise

27

Exercise

Given:A set of objects and their links and messages

Produce:A sequence diagramA communication diagram

You are responsible for creating a sequence and communication diagram for the use case or use cases you are modeling.

Remember, an interaction diagram should model one scenario in the use case. If you are going to model multiple scenarios, you’ll need to create an interaction diagram for each scenario. Refer to the following slides if needed. • What Is a Sequence Diagram? slides 9-16 • What Is a Communication Diagram? slides 18-22 Draw sequence and communication diagrams using the following data: 1. The Prospective Buyer actor begins the sequence by requesting the Personal

Planner Profile object (PPF) to maintain a profile. 2. The PPF requests the Personal Planner Controller object (PPC) to maintain a

profile. 3. The PPC sends a message to the Buyer Record object asking it to find the planner

record. 4. The PPF then displays the planner record. 5. The Prospective Buyer updates some information on the profile and asks the PPF

to save the profile information. 6. The PPF takes the new information and requests that the PPC save the profile

information. 7. The PPC asks the Buyer Record to update the record with the latest information

that the actor has provided. 8. The PPC asks the Customer Profile object to create a new profile for the system. Review your models and describe what the information says.



► ► ► Module 6 Class Diagrams

1

IBM Software Group

®

Essentials of Visual Modeling with UML 2.0Module 6: Class Diagrams

Topics

What Is a Class Diagram?...................................................................................... 6-4 What Is an Association? ...................................................................................... 6-10 What Is an Aggregation? ..................................................................................... 6-16 Review: What Is Generalization? ........................................................................ 6-19




Objectives

2

Objectives

Describe the static view of the system and show how to capture it in a model.Demonstrate how to read and interpret a class diagram.Model an association and aggregation and show how to model it in a class diagram.Model generalization on a class diagram.



Module 6 - Class Diagrams

Where Are We?

3

Where Are We?

Class diagramsClass relationships

AssociationAggregationGeneralization




What Is a Class Diagram?

4

What Is a Class Diagram?

Static view of a systemCloseRegistrationForm

+ open()+ close registration()

Student

+ get tuition()+ add schedule()+ get schedule()+ delete schedule()+ has pre-requisites()

Schedule- semester

+ commit()+ select alternate()+ remove offering()+ level()+ cancel()+ get cost()+ delete()+ submit()+ save()+ any conflicts?()+ create with offerings()+ update with new selections()

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

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

CloseRegistrationController

+ is registration open?()+ close registration()

A class diagram shows the existence of classes and their relationships in the logical design of a system. A class diagram may represent all or part of the class structure of a system.

Class diagrams show the static structure of the model, in particular, the things that exist such as classes, their internal structure, and their relationships to other classes. Class diagrams do not show temporal information.

The static view of a system primarily supports the functional requirements of a system.




Class Diagram Usage

5

Class Diagram Usage

When modeling the static view of a system, class diagrams are typically used in one of three ways, to model:

The vocabulary of a systemCollaborationsA logical database schema

Class diagrams allow you to model the vocabulary of your system when you determine the abstractions that are part of, or outside of, the boundaries of your system. Class diagrams specify these abstractions and their responsibilities.

A collaboration is a grouping of classes and other elements that work together to provide a solution that is bigger than the sum of the elements in the collaboration. No class stands alone, but works in collaboration with other elements to carry out some sort of solution. Class diagrams are one way to model these collaborations.

A database schema is similar to the blueprints for the conceptual design of a database. Many of the systems that you’ll design have persistent objects, which means that they have to be stored in a database for later retrieval. You can model schemas for these databases using class diagrams. The UML’s class diagrams are a superset of entity-relationship (E-R) diagrams. However, where typical E-R diagrams focus only on data, class diagrams take it one step further and allow the modeling of behavior, too. Behavior, modeled as operations, are generally turned into triggers or stored procedures on the database.




Example: Class Diagram

6

Example: Class Diagram

Is there a better way to organize class diagrams?

CloseRegistrationForm

LoginForm

Professor

BillingSystem

CloseRegistrationController

RegisterForCoursesForm

Course

CourseCatalogSystem

Student

RegistrationController

CourseOffering

Schedule

It’s not unusual for a system under development to contain hundreds, even thousands of different classes. Managing such large numbers generates its own problems. How can you organize classes and not lose the organization of the model?




Review: What Is a Package?

7

A general purpose mechanism for organizing elements into groups.A model element that can contain other model elements.A package can be used:

To organize the model under developmentAs a unit of configuration management

Review: What Is a Package?


A Package can be defined as:

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

• Models can have hundreds, even thousands, of model elements. The sheer number of these elements can quickly become overwhelming. It’s critical to group model elements into logical collections to keep the model manageable and readable.

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

• A package is simply a grouping mechanism. No semantics are defined for its instances. Thus, packages do not necessarily have a representation in implementation (except perhaps to represent a directory).

• In the UML, a package is represented as a tabbed folder. • Package diagrams depict dependencies between packages and are now

formalized in UML 2.




Example: Registration Package

8

Example: Registration Package

Registration

CloseRegistrationForm CloseRegistrationController

RegisterForCoursesForm RegistrationController

These four classes - CloseRegistrationForm, RegisterForCoursesForm, CloseRegistrationController, and RegistrationController - have all been assigned to the Registration package because they are highly cohesive.




Where Are We?

9



Where Are We?




What Is an Association?

10

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

CourseStudent Schedule

An Association can be defined as:

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

• The way that you show these structural 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 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 second example demonstrates how a course object can be related to another course object.




Example: What Associations Can You Find?

11

Example: What Associations Can You Find?

: CourseOffering

: RegistrationController

: Schedule

: Student

: PrimaryScheduleOfferingInfo

8: any conflicts?( )


2: submit schedule( )

4: submit( )3: save( )

7: still open?( )9: add student(Schedule)

5: is selected?( )10: mark as enrolled in( )

6: has pre-requisites(CourseOffering)

1: submit schedule( )

: Student

Using the information that you just learned, what do you think the class diagram representing this communication diagram looks like?




What Is Multiplicity?

12

What Is Multiplicity?

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

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

Professor CourseOffering0..1 0..*0..1 0..*

instructor

Multiplicity can be defined as:

The number of instances one class relates 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 may have either zero or one Professor object related to it. Conversely, a Professor object may have zero or more Course Offering objects related to it.

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




Multiplicity Indicators

13

Multiplicity Indicators

2..4

0..1

1..*

0..*

1

*

2, 4..6

Unspecified

Exactly One

Zero or More

Zero or More

Zero or One (optional value)

One or More

Specified Range

Multiple, Disjoint Ranges

• 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, and an 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. • Optional value has the multiplicity 0..1.




Example: Multiplicity

14

Example: Multiplicity


CourseOfferingSchedule0..4

0..*Student0..*

1

RegistrationController1

1

1

1

0..1

0..1

0..1

1. Describe the following relationships between: RegisterForCoursesForm

and RegistrationController; Schedule to CourseOffering; and CourseOffering to Schedule. What is the lower and upper bounds for these relationships?

2. Which relationships are mandatory? What do the mandatory relationships tell you about the different classes?

3. How many course offerings can appear on a Schedule? 4. How many students are assigned to each Schedule? 5. Can a Schedule exist without a student? 6. How many schedules can be open on a RegisterForCoursesForm?




Where Are We?

15



Where Are We?




What Is an Aggregation?

16

What Is an Aggregation?

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

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

PartWhole

0..1

1

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 a whole-part relationship between model elements. There are many examples of whole-part relationships: 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 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 when one instance is a part of two other instances. So, the same instance can participate in two different aggregations.




Example: Aggregation

17

Example: Aggregation


CourseOfferingSchedule0..4

0..*Student0..*

1

RegistrationController1

1

1

1

0..1

0..1

0..1

1. Which relationship is an aggregation? 2. How would you read this aggregate relationship? 3. Why is this relationship an aggregate?




Where Are We?

18



Where Are We?




Review: What Is Generalization?

19

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 where a subclass inherits from one or more superclasses.

Single inheritanceMultiple inheritance

Is an “is a kind of” relationship.

Generalization can be defined as:

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

• The subclass may be used where the superclass is used, but not vice versa. The child inherits from the parent.

• Generalization is transitive. You can always test your generalization by applying the “is a kind of” rule. You should always be able to say that your specialized class “is a kind of” the parent class.

• The terms “generalization” and “inheritance” are generally interchangeable, but if you need to distinguish, generalization is the name of the relationship. 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).





20


One class inherits from another.

CheckingSavings

Superclass (parent)

Subclasses(children)

Generalization Relationship

Descendents

AncestorAccount

- balance- name- number

+ withdraw()+ createStatement()

The generalization is drawn from the subclass class to the superclass/parent class.

The terms “ancestor” and “descendent” may be used instead of “superclass” and “subclass.”





21


A class can inherit from several other classes.

Use multiple inheritance only when needed and always with caution!

FlyingThing Animal

HorseWolfBirdHelicopterAirplane

Multiple Inheritance

Multiple inheritance means that a class can inherit from several other classes. For example, Bird inherits from both FlyingThing and Animal.

Multiple inheritance is conceptually straight forward and may be needed to model the real world accurately. However, there are potential implementation problems when you use multiple inheritance, and not all implementation languages support it. Thus, be judicious with your use of multiple inheritance. Use it only where it accurately describes the concept you are trying to model and reduces the complexity of your model. Be aware, however, that this representation probably needs to be adjusted in design and implementation.

Generally, a class inherits from only one class.




Review

22

What does a class diagram represent?What benefits do packages provide to the model?Define association, aggregation, and generalization.How do you find associations?What is multiplicity? What information does multiplicity provide the modeler?

Review




Exercise

23

Exercise

Given:A set of classes and their relationships

Draw:A class diagram

Document a class diagram using the following information:

• A class diagram containing the following classes: Personal Planner Profile, Personal Planner Controller, Customer Profile, and Buyer Record.

• Associations drawn using the following information: 1. Each Personal Planner Profile object can be associated with up to one

Personal Planner Controller object. 2. Each Personal Planner Controller object must be related to one Personal

Planner Profile. 3. A Personal Planner Controller object can be associated with up to one Buyer

Record and Customer Profile object. 4. An instance of the Buyer Record class can be related to zero or one Personal

Planner Controller. 5. Zero or one Personal Planner Controller objects are associated with each

Customer Profile instance.



► ► ► Module 7 Other UML Diagrams

1

IBM Software Group

®

Essentials of Visual Modeling with UML 2.0Module 7: Other UML Diagrams

Topics

What Are State Machine Diagrams?...................................................................... 7-6 What Is a Deployment Diagram? ........................................................................ 7-15 What Is a Node?................................................................................................. 7-16




Objectives

2

Objectives

Demonstrate how to read and interpret a:State machine diagramComponent diagram Deployment diagram



Module 7 - Other UML Diagrams

Where Are We?

3

Where Are We?

State machine diagramsComponent diagrams Deployment diagrams




Review: An Object Has State

4

Review: An Object Has StateState is a condition or situation during the life of an object, which satisfies some condition, performs some activity, or waits for some event.The state of an object normally changes over time.

Name: J ClarkEmployee ID: 567138Date Hired: July 25, 1991Status: TenuredDiscipline: FinanceMaximum Course Load: 3 classes

Name: J ClarkEmployee ID: 567138HireDate: 07/25/1991Status: TenuredDiscipline: FinanceMaxLoad: 3

Professor Clark

The state of an object is one of the possible conditions that an object may exist in, and it normally changes over time.

The state of an object is usually implemented by a set of properties called attributes, along with the values of the properties and the links the object may have with other objects.

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




Example: Professor

5

Example: Professor

There are a sequence of events before an instructor becomes a University professor.

Assistant professor (achieves tenure by producing a number of quality publications)Tenure/Associate professor Professor (based on seniority)

The example of someone becoming a college professor serves us well in explaining how a state machine works. When you are hired for a teaching position at the university, you begin as an assistant professor. Based on your successful publication of numerous quality papers, you receive tenure and the title of assistant professor. There is not an automatic time line for becoming an associate professor, it is based on producing and publishing quality papers. However after you have tenure, seniority makes you available for the next available professorship.




What Are State Machine Diagrams?

6

What Are State Machine Diagrams?

A state machine diagram models dynamic behavior.It specifies the sequence of states in which an object can exist:

The events and conditions that cause the object to reach those statesThe actions that take place when those states are reached

Assistant Professor Tenured

A state machine diagram is typically used to model the discrete stages of an object’s lifetime. They show the sequences of state that an object goes through, the events that cause a transition from one state to another, and the actions that result from the state change. State machine diagrams are closely related to activity diagrams.

Each state represents a named condition during the life of an object in which it satisfies some condition or waits for some event. A state machine diagram typically contains one start and multiple end states. Transitions connect the various states on the diagram. Like activity diagrams, decisions, and synchronizations may also appear on state machine diagrams.

State machines are used to model the dynamic behavior of a model element, and more specifically, the event-driven aspects of the system's behavior. State machines are specifically used to define state-dependent behavior, or behavior that varies depending on which state the model element is in. Model elements whose behavior does not vary with the state, do not require state machines to describe their behavior. These elements are typically passive classes whose primary responsibility is to manage data.




Special States

7

Special States

The initial state is the state entered when an object is created.

An initial state is mandatory.Only one initial state is permitted.The initial state is represented as a solid circle.

A final state indicates the end of life for an object.

A final state is optional.A final state is indicated by a bull’s eye.More than one final state may exist.

Applied

The initial state indicates the default starting place for the state machine or sub-state. An initial state is represented as a filled black circle.

The final state indicates the completion of the execution of the state machine or the enclosing state. A final state is represented as a filled black circle surrounded by an unfilled circle.

Initial and final states are actually pseudo-states. Neither may have the usual parts of a normal state, except for a name.




What Are Events?

8

What Are Events?

An event is the specification of a significant occurrence that has a location in time and space.

An event is an occurrence of a stimulus that can trigger a state transition.Example:• Successful publication of numerous papers

TenuredAssistantProfessor

Event

In the context of the state machine, an event can be defined as an occurrence of a stimulus that can trigger a state transition. Events may include signals, calls, the passing of time, or a change in state.

A signal or call may have parameters whose values are available to the transition, including expressions for the guard conditions and action.

It is also possible to have a triggerless transition, represented by a transition with no event trigger. These transitions, also called completion transitions, are triggered implicitly when their source state has completed its action. They are implicitly triggered on the completion of any internal ‘do activity’ in the state.




What Are Transitions?

9

What Are Transitions?

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.Transitions can be labeled with event names.

Transition Event Name

TenuredAssistantProfessor maxPapers

A Transition can be defined as:

A relationship between two states indicating that an object in the first state performs certain actions and enters a second state when a specified event occurs and specified conditions are satisfied. On such a change of state, the transition is said to “fire.” Until the transition fires, the object is said to be in the “source” state. After it fires, it is said to be in the “target” state.

• You can show one or more state transitions from a state as long as each transition is unique. Transitions originating from a state can not have the same event unless there are conditions on the event.

• The icon for a state transition is a line with an arrowhead pointing toward the destination state.

• Label each state transition with the name of at least one event that causes the state transition. You do not have to use unique labels for state transitions because the same event can cause a transition to many different states but it is recommended that they have unique labels.




Example: State Machine

10

Example: State Machine

Hired

AssistantProfessor

Tenured

Professor

Applied

rejected

accepted

Hiatus

H

H

takeSabbatical

retired

maxPapers

seniority

return




Where Are We?

11

Where Are We?





What Is a Component Diagram?

12

What Is a Component Diagram?

A diagram that shows the organizations and dependencies among components

ComponentA

<<component>>

ComponentC

<<component>>

ComponentB

<<component>>

ComponentD

<<component>>

Component diagrams commonly contain:

• Components • Interfaces • Realization, implementation and usage dependencies • Classes • Artifacts • Ports You use component diagrams to model a static view of a system. There is no significant distinction between a component diagram and a general class diagram. Both are examples of structure diagrams which depict elements in a specification that are irrespective of time.

Interfaces and ports are not covered in any detail in this course. Interfaces allow you to encapsulate, or hide, the implementation of a supplier. Ports are a structural notation used for interfaces.




What Is a Component?

13

What Is a Component?

A modular part of a system that hides its implementation behind a set of external interfaces.

Part of a logical or physical systemIt conforms to and provides the physical realization of a set of interfaces.It specifies the physical dependency to interfaces it requires.

Provided InterfaceName

Required InterfaceName

<<component>>Component NameComponentName

<<component>>

Graphically, a component is shown as a rectangle with the keyword «component». Optionally, in the right hand corner, a component icon can be displayed. This icon is a small rectangle with two smaller rectangles protruding from its left hand side. The name of the component (as a type) is placed inside the outer rectangle.

A component is a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces.

A component represents a modular piece of a logical or physical system. Components satisfying the same interfaces may be freely substituted.




Where Are We?

14

Where Are We?





What Is a Deployment Diagram?

15

What Is a Deployment Diagram?

The deployment diagram shows:Configuration of processing nodes at run-timeCommunication links between these nodesDeployed artifacts that reside on them

The purpose of the deployment diagram is to capture the configuration of processing elements, and the connections between processing elements in the system.

The deployment diagram consists of one or more:

• Nodes (processing elements with at least one processor and memory) • Connectors between nodes and/or devices The deployment diagram also maps processes on to these processing elements, allowing the distribution of behavior across nodes to be represented.




What Is a Node?

16

What Is a Node?

Represents a run-time computational resource

Generally has at least memory and often processing capability.

Types:Device• Physical computational

resource with processing capability.

• May be nestedExecution Environment• Represent particular

execution platforms

<<exe env>>EE Name

<<device>>Device Name

<<device>>Sub Device

Name

The essential elements of a deployment diagram are nodes and their connectors. A node is a run-time physical object that represents a computational resource, generally having at least memory and often processing capability as well.

Execution Environment and device are types of node but the UML2 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.




What Is a Connector?

17

What Is a Connector?

A connector represents a:Communication mechanism• Physical medium• Software protocol

<<application server>>Server

<<RS-232>>

<<100-T Ethernet>>

Connector

<<client workstation>>Console

<<client workstation>>Kiosk

Connectors can be drawn between nodes. These connectors represent communication mechanisms and can be described by physical mediums (for example, Ethernet, fiber optic cable) or software protocol (for example, TCP/IP, RS-232). A stereotype may be used to specify the type of connector.




Example: Deployment Diagram

18

Example: Deployment Diagram

<<legacy RDBMS>>Course Catalog

<<Campus LAN>>

<<Campus LAN>><<Campus LAN>>

<<application server>>Registration Server

<<client workstation>>PC

Billing System

<<legacy>>

0..2000

1

1

1

11

Deployment diagrams show the configuration of run-time processing nodes. A deployment diagram may be at the class or instance level.

Deployment diagrams allow you to capture the topology of the system 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 client workstations 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.




Example: Deployment Diagram with Processes

19

Example: Deployment Diagram with Processes

<<legacy RDBMS>>Course Catalog

<<Campus LAN>>

<<Campus LAN>><<Campus LAN>>

<<application server>>Registration Server

<<client workstation>>PC

Billing System

<<legacy>>

CourseCatalogSystemAccessCourseRegistrationProcessBillingSstemAccess

StudentApplication

0..2000

1

1

11

1

The above diagram illustrates a refined deployment view for the Course Registration System.

There are PC client workstations on the campus network. Each running a StudentApplication process.

The main business processing hardware is the Registration Server running the CourseCatlogSystemAccess, CourseRegistrationProcess, and BillingSystemAccess processes. The Registration Server talks to the two machines that host the legacy systems. All nodes are on the campus network.




Review

20

Define state. How do you determine the classes with significant state?What is a state machine diagram? Describe the different parts of the diagram.What is a component diagram?What is the purpose of a deployment diagram?

Review



IBM / Rational software

Glossary

Version 2004.06.00

Essentials of Visual Modeling with UML 2.0 Version: 2004.06.00 Glossary

Revision History Date Version Description Author

June, 1999 V4.2 Initial creation Shawn Siemers

November, 2001 V2002 Final release Shawn Siemers

December, 2002 V2003.06.00 Final release Alex Kutsick

June, 2004 V2004.06.00 Final release Alex Kutsick

© Copyright IBM Corp. 2004 Page 2 of 22


Table of Contents 1. Introduction 6

2. Definitions 6 2.1 Abstract Class 6 2.2 Abstraction 6 2.3 Action 6 2.4 Active Class 6 2.5 Activity 6 2.6 Activity Diagram 6 2.7 Activity State 7 2.8 Actor 7 2.9 Aggregation 7 2.10 Analysis 7 2.11 Analysis Class 7 2.12 Analysis Mechanism 7 2.13 Architectural Mechanism 7 2.14 Architecture 7 2.15 Assembly Connector 8 2.16 Association 8 2.17 Association Class 8 2.18 Attribute 8 2.19 Ball 8 2.20 Behavior 8 2.21 Boundary Class 8 2.22 Choice 8 2.23 Class 8 2.24 Class Diagram 8 2.25 Classifier 9 2.26 Collaboration 9 2.27 Combined Fragment 9 2.28 Communication Diagram 9 2.29 Component 9 2.30 Component Diagram 9 2.31 Composite Structure Diagram 9 2.32 Composition 10 2.33 Concrete Class 10 2.34 Concurrency 10 2.35 Connector 10 2.36 Control Class 10 2.37 Delegation Connector 10 2.38 Dependency 10 2.39 Deployment 10 2.40 Deployment Diagram 10 2.41 Deployment Specification 10 2.42 Deployment View 10 2.43 Derived Attribute 11 2.44 Design 11 2.45 Design Model 11 2.46 Design Mechanism 11 2.47 Device 11



2.48 Encapsulation 11 2.49 Entity Class 11 2.50 Event 11 2.51 Event Occurrence 11 2.52 Execution Environment 12 2.53 Execution Occurrence 12 2.54 Forward Engineering 12 2.55 Frame 12 2.56 Framework 12 2.57 Gate 12 2.58 Generalization 12 2.59 General Ordering 13 2.60 Guard Condition 13 2.61 Hierarchy 13 2.62 Implementation Mechanism 13 2.63 Implementation View 13 2.64 Inheritance 13 2.65 Instance 13 2.66 Interaction 13 2.67 Interaction Diagram 14 2.68 Interaction Fragment 14 2.69 Interaction Occurrence 14 2.70 Interaction Operand 14 2.71 Interaction Overview Diagram 14 2.72 Interface 14 2.73 Iteration 15 2.74 Iteration Expression 15 2.75 Lifeline 15 2.76 Link 15 2.77 Logical View 15 2.78 Manifestation 15 2.79 Message 15 2.80 Method 15 2.81 Modularity 15 2.82 Multiple Inheritance 15 2.83 Multiplicity 15 2.84 Navigability 16 2.85 Node 16 2.86 Object 16 2.87 Object Diagram 16 2.88 Object Lifeline 16 2.89 Object-Orientation (OO) 16 2.90 Object Technology 16 2.91 Operation 16 2.92 Operation Signature 16 2.93 Package 16 2.94 Package Diagram 17 2.95 Package Import 17 2.96 Partitions 17 2.97 Pattern 17 2.98 Polymorphism 17 2.99 Port 18 2.100 Process 18



2.101 Process View 18 2.102 Property 18 2.103 Provided Interface 18 2.104 Realization 18 2.105 Relationship 18 2.106 Required Interface 18 2.107 Responsibility 18 2.108 Reverse Engineering 19 2.109 Role 19 2.110 Scenario 19 2.111 Sequence Diagram 19 2.112 Single Inheritance 19 2.113 Socket 19 2.114 State 19 2.115 State Machine 19 2.116 State Machine Diagram 20 2.117 Stereotype 20 2.118 Stored Procedures 20 2.119 Structured Class 20 2.120 Structure Diagram 20 2.121 Structured Part 20 2.122 Subsystem 20 2.123 Thread 20 2.124 Time Constraint 20 2.125 Timing Diagram 20 2.126 Transaction 20 2.127 Transition 21 2.128 Unified Modeling Language (UML) 21 2.129 Use Case 21 2.130 Use-Case Diagram 21 2.131 Use-Case Model 21 2.132 Use-Case Realization 21 2.133 Use-Case View 21 2.134 Utility Class 21 2.135 Visibility 21 2.136 Visual Modeling 21



Glossary

1. Introduction This document contains definitions for terms used in the Essentials of Visual Modeling and Mastering Object-Oriented Analysis and Design with UML courses. Many of the definitions are from the Rational Unified Process and some are from the Unified Modeling Language Reference Manual, 2nd edition, by James Rumbaugh, Ivar Jacobson, Grady Booch, Addison-Wesley, Boston, 2005. Other information was taken directly from the course materials or paraphrased from the UML User's Guide. Graphics were included where they helped to explain the definition.

2. Definitions

2.1 Abstract Class An abstract class is a class that cannot be instantiated—that is, it may not have direct instances. It is the opposite of a concrete class.

2.2 Abstraction The essential characteristics of an entity that distinguish it from all other kind of entities and thus provide crisply-defined boundaries relative to the perspective of the viewer.

2.3 Action An action is an operation that is associated with a transition. Actions conceptually take an insignificant amount of time to complete, and are considered non-interruptible. Action names are shown on the transition arrow preceded by a slash.

StateA

StateB StateC

entry/ action

event( condition ) / action

2.4 Active Class An active class is a class that “owns” it’s own thread of execution and can initiate control activity, contrasted with passive classes that can only be acted upon. Active classes may execute in parallel (that is, concurrently) with other active classes.

2.5 Activity A unit of work a worker may be asked to perform.

2.6 Activity Diagram An activity diagram shows the decomposition of an activity into its constituents.


Essentials of Visual Modeling with UML 2.0 Version: 2004.06.00 Glossary 2.7 Activity State

The performance of an activity or step within the workflow.

2.8 Actor Someone or something outside the system or business that interacts with the system or business.

Actor

(f rom Use Case View)

2.9 Aggregation An association that models a whole-part relationship between an aggregate (the whole) and its parts. It is shown by a hollow diamond at the end of the path attached to the aggregate class.

Whole Part

2.10 Analysis The part of the software development process whose primary purpose is to formulate a model of the problem domain. Analysis focuses on what to do; design focuses on how to do it.

2.11 Analysis Class Analysis classes handle primarily functional requirements, and model objects from the "problem" domain.

2.12 Analysis Mechanism An architectural mechanism used early in the design process, during the period of discovery when key classes and subsystems are being identified. Typically analysis mechanisms capture the key aspects of a solution in a way that is implementation independent. Analysis mechanisms are usually unrelated to the problem domain, but instead are "computer science" concepts. They provide specific behaviors to a domain-related class or component, or correspond to the implementation of cooperation between classes and/or components. They may be implemented as a framework. Examples include mechanisms to handle persistence, inter-process communication, error or fault handling, notification, and messaging, to name a few.

2.13 Architectural Mechanism An architectural mechanism represents a common solution to a frequently encountered problem. They may be patterns of structure, patterns of behavior, or both.

2.14 Architecture The highest-level concept of a system in its environment. The architecture of a software system (at a given point in time) is its organization or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces.


Essentials of Visual Modeling with UML 2.0 Version: 2004.06.00 Glossary 2.15 Assembly Connector

A connector between two elements (parts or ports) in the internal implementation specification of a structured classifier or component.

2.16 Association A relationship that models a bi-directional semantic connection among instances.

2.17 Association Class An association class is a class that is connected to an association. It is a full-fledged class and can contain attributes, operations and other associations. Association classes allow you to store information about the relationship itself. Such information is not appropriate, or does not belong, within the classes at either end of the relationship.

AssociationClass

0..* 0..*

ClassB ClassA

0..* 0..*

2.18 Attribute An attribute defined by a class represents a named property of the class or its objects. An attribute has a type that defines the type of its instances.

2.19 Ball A provided interface relationship shown by a small circle, or a ball, attached to a classifier by a line.

2.20 Behavior The observable effects of an event that includes results.

2.21 Boundary Class A class used to model communication between the system's environments and its inner workings.

2.22 Choice A node in a state machine at which dynamic evaluations of subsequent guard conditions is made.

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

ClassA

2.24 Class Diagram A diagram that shows a set of classes, interfaces, and collaborations and their relationships; class diagrams address the static design view of a system; a diagram that shows a collection of declarative (static) elements.


Essentials of Visual Modeling with UML 2.0 Version: 2004.06.00 Glossary 2.25 Classifier

A model element that describes behavioral and structural features. Kinds of classifiers include actor, association, class, collaboration, component, data type, interface, node, signal, subsystem, and use case.

2.26 Collaboration A society of roles and other elements that work together to provide some cooperative behavior that’s bigger than the sum of all its parts; the specification of how an element, such as a use case or an operation, is realized by a set of classifiers and associations playing specific roles and used in a specific way.

2.27 Combined Fragment A construct within an interaction that comprises an operator keyword and one or more interaction operands, each of which is a fragment of an interaction. It is shown as a nested region within a sequence diagram. If the fragment has more than one subfragment, horizontal dashed lines separate them.

2.28 Communication Diagram A communication diagram describes a pattern of interaction among objects; it shows the objects participating in the interaction by their links to each other and the messages they send to each other.

: Actor

: ClassA

3: Message32: Message2

1: Message1

: ClassB

2.29 Component A modular part of a system that hides its implementation behind a set of external interfaces. Within a system, components satisfying the same interfaces may be substituted freely.

2.30 Component Diagram A diagram that shows the definition, internal structure, and dependencies of component types. There is no sharp line between component diagrams and general class diagrams.

2.31 Composite Structure Diagram A composite structure diagram shows the internal structure (including parts and connectors) of a structured classifier or collaboration. It defines the parts of a system and the communication relationships between them.


Essentials of Visual Modeling with UML 2.0 Version: 2004.06.00 Glossary 2.32 Composition

A composition is a stronger form of association in which the composite has sole responsibility for managing its parts— such as their allocation and deallocation. A filled diamond on the composite end shows it. An object at most may belong to one composition.

PartWhole

2.33 Concrete Class A generalizable element (such as a class) that can be directly instantiated. Of necessity, its implementation must be fully specified. For a class, all its operations must be implemented (by the class or an ancestor).

2.34 Concurrency Concurrency is the tendency for things to happen at the same time in a system.

2.35 Connector The connection of two structured parts within a structured classifier or a collaboration; a specification of an contextual association that applies only in a certain context, such as the objects within a classifier or objects satisfying a collaboration.

2.36 Control Class A class used to model behavior specific to one, or a several use cases.

2.37 Delegation Connector A connector between an external port of a structured class or component and an internal part. Connections to the external port are treated as going to the element at the other end of the delegation connector.

2.38 Dependency A semantic relationship between two things in which a change to one thing (the independent thing) may affect the semantics of the other thing (dependent thing).

2.39 Deployment The assignment of software artifacts to physical nodes during execution.

2.40 Deployment Diagram A diagram that shows the configuration of run-time processing nodes and the artifacts that live on them. A deployment diagram may be at the class level or the instance level.

Work station

Server

2.41 Deployment Specification A detailed specification of the parameters of the deployment of an artifact to a node. A deployment specification is shown as a rectangle symbol with the keyword «deploymentSpec».

2.42 Deployment View A view that shows the nodes in a distributed system, the artifacts that are stored on each node, and the components and other elements that the artifacts manifest.


Essentials of Visual Modeling with UML 2.0 Version: 2004.06.00 Glossary 2.43 Derived Attribute

An attribute whose value may be calculated based on the value of other attribute(s).

2.44 Design The part of the software development process whose primary purpose is to decide how the system will be implemented. During design, strategic and tactical decisions are made to meet the required functional and quality requirements of a system.

2.45 Design Model An object model describing the realization of use cases; serves as an abstraction of the implementation model and its source code.

2.46 Design Mechanism An architectural mechanism used during the design process, during the period in which the details of the design are being worked-out. They are related to associated analysis mechanisms, of which they are additional refinements. A design mechanism assumes some details of the implementation environment, but it is not tied to a specific implementation (as is an implementation mechanism). For example, the analysis mechanism for inter-process communication may be refined by several design mechanisms for interprocess communication (IPC): shared memory, function-call-like IPC, semaphore-based IPC, and so on. Each design mechanism has certain strengths and weaknesses; the choice of a particular design mechanism is determined by the characteristics of the objects using the mechanism.

2.47 Device A physical computational resource with processing capability upon which artifacts may be deployed for execution. A node annotated with the stereotype <<device>> notates a device.

2.48 Encapsulation The physical localization of features (for example, properties, behaviors) into a single black box abstraction that hides their implementation (and associated design decisions) behind a public interface. Encapsulation is also referred to as information hiding.

2.49 Entity Class A class used to model information that has been stored by the system, and the associated behavior. A generic class reused in many use cases, often with persistent characteristics. An entity class defines a set of entity objects, which participate in several use cases and typically survive those use cases.

2.50 Event An event is an occurrence that happens at some point in time. In a state machine, an event is an occurrence of a stimulus that can trigger a state transition.

Event / TargetObject.event

do/ TargetObject.Event

NewState2

entry/ Action

NewState

2.51 Event Occurrence The occurrence of an event during the execution of a system, e.g., call event, signal event, time event, change event. An event occurrence is not explicitly shown as a separate concept. It is usually shown by the intersection of a message arrow and a lifeline.


Essentials of Visual Modeling with UML 2.0 Version: 2004.06.00 Glossary 2.52 Execution Environment

A kind of deployment node that represents a particular kind of execution platform, such as an operating system, a workstation engine, a database management system, and so on. Also (and more commonly) used informally to describe the context within which execution of a model occurs. A node annotated with the stereotype <<ExecutionEnvironment>> notates an execution environment.

2.53 Execution Occurrence The execution of an activity, operation, or other behavior unit within an interaction. An execution represents the period during which an object performs a behavior either directly or through a subordinate behavior.

2.54 Forward Engineering The process of transforming a model into code through a mapping to a specific implementation language.

2.55 Frame A diagram is presented as a frame containing graphical contents. The frame names the diagram and establishes its extent. It is drawn as a rectangle with a small pentagon (called the name tag) in the upper left corner.

e

2.56 FramA mic

2.57 GateA conoutsid

2.58 GeneA taxoelemeof the

Fram

ework ro-architecture that provides an incomplete template for applications within a specific domain

nection point in an interaction or interaction fragment for a message that comes from or goes to e the interaction or fragment.

ralization nomic relationship between a more general element and a more specific element. The more specific

nt is fully consistent with the more general element and contains additional information. An instance more specific element can be used where the more general element is allowed.

ClassBClassA

ClassParent



2.59 General Ordering A constraint in an interaction where the time of one event occurrence precedes the time of another event occurrence.

2.60 Guard Condition The guard is expressed as a Boolean constraint on values available to test at the time of messaging, i.e., the guard determines whether a transition may fire.

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

2.62 Implementation Mechanism An architectural mechanism used during the implementation process. They are refinements of design mechanisms, and specify the exact implementation of the mechanism. For example, one particular implementation of the inter-process communication analysis mechanism is a shared memory design mechanism utilizing a particular operating system’s shared memory function calls. Concurrency conflicts (inappropriate simultaneous access to shared memory) may be prevented using semaphores, or using a latching mechanism, which in turn rest upon other implementation mechanisms.

2.63 Implementation View An architectural view that describes the organization of the static software elements (code, data, and other accompanying artifacts) on the development environment, in terms of both packaging, layering, and configuration management (ownership, release strategy, and so on). In the Unified Process it is a view on the implementation model.

2.64 Inheritance The mechanism that makes generalization possible; a mechanism for creating full class descriptions out of individual class segments.

2.65 Instance A concrete manifestation of an abstraction; an entity to which a set of operations can be applied and that has a state that stores the effects of the operations.

2.66 Interaction A specification of how messages are exchanged between objects or other instances over time to perform a task. An interaction is defined in a context, which may be a classifier, a collaboration, or some other grouping of connected parts.


Essentials of Visual Modeling with UML 2.0 Version: 2004.06.00 Glossary 2.67 Interaction Diagram

A diagram that shows an interaction, consisting of a set of objects and their relationships, including the messages that may be dispatched among them; interaction diagrams address the dynamic view of a system; a generic term that applies to several types of diagrams that emphasize object interactions, including communication diagrams, sequence diagrams, timing diagrams and the interaction overview diagrams. The Interaction Diagram is a generic term for focusing on messaging [interaction] between objects. As such, there is no one graphic for an Interaction Diagram.

2.68 Interaction Fragment A structural piece of an interaction.

2.69 Interaction Occurrence A reference to an interaction within the definition of another interaction.

2.70 Interaction Operand A structural piece of a combined fragment; a subfragment.

2.71 Interaction Overview Diagram A diagram that depicts interactions through a variant of activity diagrams in such a way to promote an overview of the control flow. It focuses on the overview of the flow of control where each node can be an interaction diagram.

2.72 Interface A declaration of a coherent set of public features and obligations; a contract between providers and consumers of services.

Interface

<<Interface>> Subsystem

<<subsystem>>

Subsystem <<subsystem>>

Interface


Essentials of Visual Modeling with UML 2.0 Version: 2004.06.00 Glossary 2.73 Iteration

A distinct set of activities with a baseline plan and evaluation criteria that results in a release, either internal or external.

2.74 Iteration Expression A specification of the range of number of iterations of a loop.

2.75 Lifeline The lifeline represents the existence of the object at a particular time. You can use a lifeline to model both class and object behavior. Usually, a lifeline represents all objects of a certain class.

2.76 Link A semantic connection among objects; an instance of an association.

2.77 Logical View An architectural view that describes the main classes in the design of the system: major business-related classes, and the classes that define key behavioral and structural mechanisms (persistency, communication, fault-tolerance, user-interface). In the Unified Process, the logical view is a view of the design model.

2.78 Manifestation The physical implementation of a model element as an artifact. A manifestation is shown as a dependency arrow from an artifact to a model element. The keyword «manifest» is placed on the arrow.

2.79 Message The conveyance of information from one object (or other instance) to another as part of an interaction within a context. A message may be a signal or the call of an operation. The sending and the receipt of a message are event occurrences.

2.80 Method (1) A regular and systematic way of accomplishing something; the detailed, logically ordered plans or procedures followed to accomplish a task or attain a goal. (2) UML 1.1: The implementation of an operation, the algorithm, or the procedure that effects the results of an operation.

2.81 Modularity The logical and physical decomposition of things (for example, responsibilities and software) into small, simple groupings (for example, requirements and classes, respectively), which increase the achievements of software-engineering goals.

2.82 Multiple Inheritance A semantic variation of generalization in which an object may belong directly to more than one class.

2.83 Multiplicity A specification of the range of allowable cardinalities that a set may assume.

ClassA ClassB

0..1 0..2, 5


Essentials of Visual Modeling with UML 2.0 Version: 2004.06.00 Glossary 2.84 Navigability

The navigability property on a role indicates that it is possible to navigate from a associating class to the target class using the association.

2.85 Node A run-time physical object that represents a computational resource, generally having at least memory and often processing capability. Run-time artifacts may be deployed on nodes.

Work station

2.86 Object An entity with a well-defined boundary and identity that encapsulates state and behavior. State is represented by attributes and relationships, behavior is represented by operations and methods. An object is an instance of a class.

2.87 Object Diagram A diagram that encompasses objects and their relationships at a given point in time. An object diagram may be considered a special case of a class diagram or a communication diagram.

2.88 Object Lifeline A line in a sequence diagram that represents the existence of an object over a period of time.

2.89 Object-Orientation (OO) The Rational Unified Process supports object-oriented techniques. Each model is object-oriented. Rational Unified Process models are based on the concepts of objects and classes and the relationships among them, as they use the UML as its common notation.

2.90 Object Technology A set of principles (abstraction, encapsulation, polymorphism) guiding software construction, together with languages, databases, and other tools that support those principles. (Object Technology - A Manager’s Guide, Taylor, 1997.)

2.91 Operation A service that can be requested from an object to effect behavior.

2.92 Operation Signature The name and parameters of an operation.

2.93 Package A general-purpose mechanism for organizing elements into groups, establishing ownership of elements, and providing unique names for referencing elements.

PackageA



2.94 Package Diagram A diagram that depicts how model elements are organized into packages and the dependencies among them, including package imports and package extensions.

2.95 Package Import A directed relationship that adds the names of elements to a namespace.

2.96 Partitions The organization of activities into distinct regions. Organize activities in a model according to their responsibility—for example, group all the activities handled by one business organization. Partitions are separated by lines in the diagram.

2.97 Pattern A scheme for describing design fragments or collections of class templates so that they can be configured and reused.

2.98 Polymorphism Polymorphism is the ability to define a single interface with multiple implementations.


Essentials of Visual Modeling with UML 2.0 Version: 2004.06.00 Glossary 2.99 Port

A structural feature of a classifier that encapsulates interaction between the contents of the classifier and its environment. A port is shown as a small square straddling the boundary of a classifier rectangle. The name of the port is placed near the square.

2.100 Process (1) Any thread of control that can logically execute concurrently with other processes. (2) A set of

partially ordered steps intended to reach a goal; in software engineering the goal is to build a software product or to enhance an existing one; in process engineering, the goal is to develop or enhance a process model; corresponds to a business use case in business engineering.

2.101 Process View An architectural view that describes the concurrent aspect of the system: tasks (processes) and their interactions.

2.102 Property A named value denoting a characteristic of an element.

2.103 Provided Interface An interface that declares the services that a classifier offers to provide to anonymous requestors. A provided interface relationship is shown by a small circle, or a ball, attached to a classifier by a line. Alternately, a provided interface can be shown using realization notation.

2.104 Realization A semantic relationship between classifiers, in which one classifier specifies a contract that another classifier guarantees to carry out.

2.105 Relationship An abstract concept that specifies some kind of connection between elements. Examples of relationships include associations and generalizations.

2.106 Required Interface A required interface is the complementary relationship of a provided interface where a classifier requires the services described in the interface. A required interface relationship is shown by a small half circle, or a socket, attached to a classifier by a line. Alternately, a required interface can be shown using dependency notation.

2.107 Responsibility A contract or obligation of a type or class.


Essentials of Visual Modeling with UML 2.0 Version: 2004.06.00 Glossary 2.108 Reverse Engineering

The process of transforming code into a model through a mapping from a specific implementation language.

2.109 Role The behavior of an entity participating in a particular context. Role names are not underlined when only a role name is needed and no instance reference is implied.

Department Employee +Department Head

10..*

2.110 Scenario A described use-case instance, a subset of a use case.

2.111 Sequence Diagram A diagram that describes a pattern of interaction among objects, arranged in a chronological order; it shows the objects participating in the interaction by their "lifelines" and the messages that they send to each other.

: Actor : Employee : Department

1: Message1

2: Message2

3: Message3

2.112 Single Inheritance A semantic variation of generalization in which a child may have only one parent.

2.113 Socket A required interface relationship is shown by a small half circle, or a socket, attached to a classifier by a line.

2.114 State A condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event.

2.115 State Machine A specification of the sequences of states that an object or an interaction goes through in response to events during its life, together with its responsive effects (action and activity). A state machine is attached to a source class, collaboration, or method and specifies the behavior of the instances of the source element.


Essentials of Visual Modeling with UML 2.0 Version: 2004.06.00 Glossary 2.116 State Machine Diagram

A state machine diagram shows a state machine, that is, a behavior that specifies the sequences of states that an object goes through during its life in response to events, together with its responses and actions.

Event /TargetObject.event

entry/ Action

NewState

do/ TargetObject.Event

NewState2

2.117 Stereotype A meta-classification of an element. Stereotypes have semantic implications which can be specified for every specific stereotype value.

2.118 Stored Procedures A stored procedure is executable code that runs under the RDBMS. Stored procedures provide the ability to perform database-related actions on the server without having to transfer data across a network.

2.119 Structured Class A class containing parts or roles that form its structure and realize its behavior.

2.120 Structure Diagram A form of diagram that depicts the elements in a specification that is irrespective of time. Class diagrams and component diagrams are examples of structure diagrams.

2.121 Structured Part Within a structured classifier, an element that represents an object or set of objects within a contextual relationship.

2.122 Subsystem A large unit of decomposition for a system. It is modeled as a stereotype of component with the keyword <<subsystem>>.

2.123 Thread An independent computation executing within an the execution environment and address space defined by an enclosing operating system process.

2.124 Time Constraint Expressed as a time interval, it can refer to a single event occurrence or to the time interval between two occurrences.

2.125 Timing Diagram An interaction diagram that shows the change in state or condition of a lifeline over linear time. The most common usage is to show the change in state of an object over time in response to accepted events or stimuli. It is an optional diagram designed to specify the time constraints on messages sent and received in the course of an interaction.

2.126 Transaction Transactions define a set of operation invocations that are atomic: either all or none of them are performed.


Essentials of Visual Modeling with UML 2.0 Version: 2004.06.00 Glossary 2.127 Transition

A transition is a change from an originating state to a successor state as a result of some stimulus.

2.128 Unified Modeling Language (UML) A language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.

2.129 Use Case A use case defines a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor. A use-case class contains all main, alternate flows of events related to producing the 'observable result of value'. Technically, a use-case is a class whose instances are scenarios.

2.130 Use-Case Diagram A diagram that shows the relationships among actors and use cases within a system.

2.131 Use-Case Model A model of what the system is supposed to do and the system environment.

2.132 Use-Case Realization A use-case realization describes how a particular use case is realized within the design model, in terms of collaborating objects.

2.133 Use-Case View An architectural view that describes how critical use cases are performed in the system, focusing mostly on architecturally significant components (objects, tasks, nodes). In the Unified Process, it is a view of the use-case model.

2.134 Utility Class A class that contains a collection of free subprograms.

2.135 Visibility How a name can be seen and used by others.

2.136 Visual Modeling A way of thinking about problems using models organized around real-world ideas.


student guide

Documents

prior written

personal planner

nt va lu

ge tc ur

pc client

clark teaches

conceptually

copyright