Alhir Guide to Applying the UML

1. Auflage 2006
ISBN: 978-0-387-21513-6
Verlag: Springer US
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Englisch, 431 Seiten

Reihe: Springer Professional Computing

Guide to Successfully Applying the UML offers a tool-independent and process-independent roadmap for successfully applying the Unified Modeling Language (UML). The UML is a modeling language for specifying, visualizing, constructing, and documenting the artifacts of a system-intensive process. It was originally conceived by Rational Software Corporation and three of the most prominent methodologists in the information systems and technology industry: Grady Booch, James Rumbaugh, and Ivar Jacobson.

The language has gained significant industry support from various organizations via the UML Partners Consortium and has been submitted to and approved by the Object Management Group as a standard.This book works in concordance with references to offer a suite of practical real-world examples to help novice and expert users of the UML to understand the whole language (holistically and cohesively), including rules of usage and principles of composition, style guidelines, and a roadmap for successfully applying the UML. The examples are presented in a "fairly intuitive/evolutionary" manner that demonstrate the key concepts of the UML and help readers explore the wide range of uses of the UML.  

Autoren/Hrsg.

Alhir, Sinan Si

Inhaltsverzeichnis

1;Contents;7
2;Preface;13
3;1 Introduction to the Unified Modeling Language (UML);22
3.1;1.1. What is the Unified Modeling Language (UML)?;22
3.2;1.2. The Unified Modeling Language (UML) and Process or Methodology;24
3.3;1.3. History of the Unified Modeling Language (UML);26
3.4;1.4. Effectively and Successfully Applying the Unified Modeling Language (UML);30
4;2 Modeling;33
4.1;2.1. Languages;33
4.1.1;2.1.1. ALPHABETS;34
4.1.2;2.1.2. WORDS;34
4.1.3;2.1.3. SENTENCES;35
4.1.4;2.1.4. PARAGRAPHS;35
4.1.5;2.1.5. SECTIONS;38
4.1.6;2.1.6. DOCUMENTS;39
4.1.7;2.1.7. OTHER ELEMENTS;39
4.2;2.2. Systems and Contexts;44
4.2.1;2.2.1. DOMAINS OR SPACES;44
4.2.2;2.2.2. SYSTEMS;44
4.2.3;2.2.3. ARCHITECTURES;45
4.2.4;2.2.4. MODELS;47
4.2.5;2.2.5. ARCHITECTURAL VIEWS;51
4.2.6;2.2.6. DIAGRAMS;52
4.3;2.3. Modeling Mechanisms;54
4.3.1;2.3.1. PERSPECTIVES;55
4.3.2;2.3.2. LEVELS OF ABSTRACTION;57
4.3.3;2.3.3. DICHOTOMIES;58
4.3.4;2.3.4. EXTENSION MECHANISMS;59
4.4;2.4. Processes and Methodologies;60
4.4.1;2.4.1. DEVELOPMENT CYCLES AND PHASES;61
4.4.2;2.4.2. ITERATION CYCLES AND PHASES;63
4.4.3;2.4.3. ITERATION PHASE DETAILS;65
4.4.4;2.4.4. HEURISTICS;67
4.5;2.5. The Value of Processes and Methodologies;73
4.5.1;2.5.1. THE QUESTION;73
4.5.2;2.5.2. FINE CUISINE AND SYSTEMS DEVELOPMENT;74
4.5.3;2.5.3. THE ROADMAP;77
4.5.4;2.5.4. THE ANSWER;80
5;3 Object Orientation;82
5.1;3.1. Principles of Object Orientation;82
5.1.1;3.1.1. ABSTRACTION;82
5.1.2;3.1.2. ENCAPSULATION;84
5.1.3;3.1.3. GENERALIZATION;86
5.1.4;3.1.4. POLYMORPHISM;87
5.2;3.2. Structural (Static) Concepts;87
5.2.1;3.2.1. CLASS AND OBJECT DIAGRAMS;87
5.2.2;3.2.2. USE-CASE DIAGRAMS;108
5.2.3;3.2.3. COMPONENT DIAGRAMS;111
5.2.4;3.2.4. DEPLOYMENT DIAGRAMS;112
5.3;3.3. Behavioral (Dynamic) Concepts;114
5.3.1;3.3.1. SEQUENCE AND COLLABORATION DIAGRAMS;116
5.3.2;3.3.2. STATE DIAGRAMS;125
5.3.3;3.3.3. ACTIVITY DIAGRAMS;129
5.4;3.4. Object-Oriented Systems;132
5.4.1;3.4.1. PACKAGES;133
5.4.2;3.4.2. TEMPLATES;135
5.4.3;3.4.3. PATTERNS AND FRAMEWORKS;136
5.4.4;3.4.4. SYSTEMS;138
6;4 The Roadmap;144
6.1;4.1. The Unified Modeling Language (UML) Sentence;145
6.1.1;4.1.1. COLLABORATING AND INTERACTING SYSTEMS;145
6.1.2;4.1.2. SERVICES;145
6.1.3;4.1.3. SERVICE REALIZATIONS;147
6.1.4;4.1.4. THE UNIFIED MODELING LANGUAGE (UML) SENTENCE;149
6.2;4.2. The Roadmap Space;151
6.2.1;4.2.1. PERSPECTIVES AND LEVELS OF ABSTRACTION;151
6.2.2;4.2.2. CARTESIAN PRODUCT;151
6.2.3;4.2.3. THE ROADMAP SPACE;153
6.3;4.3. The General Roadmap;156
6.3.1;4.3.1. PERSPECTIVES AND LEVELS OF ABSTRACTION;156
6.3.2;4.3.2. PROCESS DISCIPLINES;158
6.3.3;4.3.3. THE GENERAL ROADMAP;159
6.4;4.4. Detailed and Notational Roadmap;161
6.4.1;4.4.1. CONCEPTUAL ELEMENTS;161
6.4.2;4.4.2. MECHANISMS;165
6.4.3;4.4.3. THE ROADMAP;167
6.4.4;4.4.4. A ROADMAP EXAMPLE;175
6.5;4.5. Applying the Roadmap;203
6.5.1;4.5.1. HEAVYWEIGHT AND LIGHTWEIGHT APPROACHES;204
6.5.2;4.5.2. HEURISTICS;205
7;5 Use-Case (User) Modeling;207
7.1;5.1. Use-Case Diagrams;207
7.1.1;5.1.1. ACTORS;207
7.1.2;5.1.2. USE CASES;209
7.1.3;5.1.3. ACTOR RELATIONSHIPS;215
7.1.4;5.1.4. USE-CASE RELATIONSHIPS;217
7.2;5.2. Applying Use-Case Diagrams;226
7.2.1;5.2.1. THE CONSTRUCT;227
7.2.2;5.2.2. REQUIREMENTS;229
7.2.3;5.2.3. UNIFICATION;232
8;6 Structural (Static) Modeling;233
8.1;6.1. Class Diagrams;233
8.1.1;6.1.1. CLASSIFIERS;233
8.1.2;6.1.2. RELATIONSHIPS;252
8.2;6.2. Object Diagrams;268
8.2.1;6.2.1. CLASSIFIER INSTANCES;268
8.2.2;6.2.2. RELATIONSHIP INSTANCES;272
8.3;6.3. Applying Class and Object Diagrams;273
8.3.1;6.3.1. CONCEPTUAL ELEMENTS;274
8.3.2;6.3.2. MECHANISMS;275
8.3.3;6.3.3. THE CONSTRUCT;275
8.3.4;6.3.4. ANALYSIS;278
8.3.5;6.3.5. DESIGN;283
8.3.6;6.3.6. VALIDATION;291
8.3.7;6.3.7. UNIFICATION;297
9;7 Behavioral (Dynamic) Modeling;298
9.1;7.1. Sequence Diagrams;298
9.1.1;7.1.1. CLASSIFIER ROLES;300
9.1.2;7.1.2. INTERACTIONS;301
9.1.3;7.1.3. LIFELINES;304
9.1.4;7.1.4. ACTIVATIONS;307
9.1.5;7.1.5. MESSAGES AND STIMULI;307
9.2;7.2. Collaboration Diagrams;310
9.2.1;7.2.1. ASSOCIATION ROLES;311
9.2.2;7.2.2. COLLABORATIONS;313
9.2.3;7.2.3. MESSAGES AND STIMULI;315
9.2.4;7.2.4. BEHAVIORAL ORGANIZATION;321
9.3;7.3. Statechart Diagrams;328
9.3.1;7.3.1. STATES;328
9.3.2;7.3.2. TRANSITIONS;331
9.3.3;7.3.3. SUBMACHINES;336
9.4;7.4. Activity Diagrams;337
9.4.1;7.4.1. ACTION STATES;337
9.4.2;7.4.2. SWIMLANES;339
9.4.3;7.4.3. FLOWS;339
9.5;7.5. Applying Sequence, Collaboration, Statechart, and Activity Diagrams;341
9.5.1;7.5.1. SEQUENCE DIAGRAMS;342
9.5.2;7.5.2. COLLABORATION DIAGRAMS;342
9.5.3;7.5.3. STATE DIAGRAMS;343
9.5.4;7.5.4. ACTIVITY DIAGRAMS;346
10;8 Component (Implementation) Modeling;347
10.1;8.1 Component Diagrams;347
10.1.1;8.1.1. ARTIFACTS;348
10.1.2;8.1.2. COMPONENTS;349
10.1.3;8.1.3. COMPONENT RELATIONSHIPS;352
10.2;8.2. Applying Component Diagrams;353
10.2.1;8.2.1. THE CONSTRUCT;353
10.2.2;8.2.2. IMPLEMENTATION;354
10.2.3;8.2.3. UNIFICATION;355
11;9 Deployment (Environment) Modeling;356
11.1;9.1. Deployment Diagrams;356
11.1.1;9.1.1. NODES;357
11.1.2;9.1.2. NODE RELATIONSHIPS;357
11.2;9.2. Applying Deployment Diagrams;360
11.2.1;9.2.1. THE CONSTRUCT;361
11.2.2;9.2.2. DEPLOYMENT;361
11.2.3;9.2.3. UNIFICATION;362
12;10 Extension Mechanisms;364
12.1;10.1. Architecture of the Unified Modeling Language (UML);364
12.1.1;10.1.1. THE FOUR-LAYER METAMODELING ARCHITECTURE;365
12.1.2;10.1.2. THE UNIFIED MODELING LANGUAGE (UML) METAMODEL;369
12.2;10.2. Stereotypes;371
12.2.1;10.2.1. DECLARATION;371
12.2.2;10.2.2. APPLICATION;375
12.3;10.3. Properties;379
12.3.1;10.3.1. CONSTRAINTS;379
12.3.2;10.3.2. TAG DEFINITIONS AND TAGGED VALUES;380
12.4;10.4. Profiles;382
13;11 The Object Constraint Language (OCL);385
13.1;11.1. What is the Object Constraint Language (OCL)?;385
13.2;11.2. Expressions;386
13.2.1;11.2.1. INVARIANTS;387
13.2.2;11.2.2. PRECONDITIONS AND POSTCONDITIONS;388
13.2.3;11.2.3. PACKAGE STATEMENTS;390
13.2.4;11.2.4. LET EXPRESSIONS AND DEFINITION CONSTRAINTS;391
13.3;11.3. Properties;391
13.3.1;11.3.1. CLASSIFIERS AND INSTANCES;394
13.3.2;11.3.2. ASSOCIATIONS AND LINKS;395
13.3.3;11.3.3. CLASSIFIER- AND INSTANCE-SCOPED PROPERTIES;396
13.4;11.4 The Standard Object Constraint Language (OCL) Types;397
13.4.1;11.4.1. BASIC TYPES;398
13.4.2;11.4.2. COLLECTION TYPES;402
13.5;11.5. The Standard Object Constraint Language (OCL) Package;410
14;References;412
15;Index;416
16;More eBooks at www.ciando.com;0

Leseproben

CHAPTER 6 Structural (Static) Modeling (p.212)
This chapter provides essential rules, principles, and style guidelines for composing UML structural or static models within the context of the roadmap, including class and object diagrams and their elements. Structural modeling is concerned with modeling the structural or static dimension of a system - the elements and their relationships that constitute a system - and is used for system, subsystem, and class speci.cation within the roadmap to capture in a speci.cation model how the construct will satisfy its requirements. Structural modeling is also used to determine which elements and their relationships collaborate to constitute the construct, and how these elements interact to provide functionality to end users. A speci.cation model consists of class, object, sequence, collaboration, state, and activity diagrams and their model elements. Our goal, in this chapter, is to gain more depth in understanding the UML notation and the roadmap concerning the structural or static aspect of speci.cation models.


6.1. Class Diagrams

A class diagram depicts the static structure of an entity using classi.ers and relationships. An entity is a classiffer, for example, a system, subsystem, or class.
6.1.1. CLASSIFIERS
A classiffer is a concept that de.nes structural features and behavioral features, and has various types of relationships. A feature is a property encapsulated within a model element, an atomic constituent of a model. Structural features de.ne the static features of a model element. Behav ioral features de.ne the dynamic features of a model element. A classiffer may contain other classiffers. It owns its contents and de.nes a namespace, a part of a model in which a name may be uniquely de.ned and used. An element may access any contents of its own namespace or a containing namespace. Specific types of classi.ers include classes, actors, use cases, data types, interfaces, components, nodes, subsystems, and artifacts.

A classiffer is depicted as a vertex or node, including an icon or twodimensional symbol that may contain other elements. Other information is depicted as strings or sequences of characters attached to nodes. A classi.er is named using an optional stereotype or list of stereotypes followed by an optional visibility symbol followed by the classiffer name string followed by an optional property. Not all details of a modeling element need to be depicted on a diagram, only those that are relevant to the purpose of the diagram.

A stereotype is used to classify (brand) or mark a model element so that it may be given a speci.c meaning. A stereotype is depicted as a text string keyword enclosed in guillemets («») or double-angle brackets preceding or above the name of the element. Multiple stereotypes may be applied to an elements depicted vertically one below the other or preceding each other. A user-de.ned icon may be used to signify a stereotype. The guillemets and the stereotype icon may be depicted simultaneously; however only one is required. The icon is placed in the upper right corner near the name of the element, or the entire base model element symbol is collapsed into an icon containing the element name or with the name above or below the icon, and other information contained by the base model element symbol is suppressed. When multiple stereotypes are used for an element, the icons are omitted.