UML Weekend Crash Course⢠- To Parent Directory
UML Weekend Crash Course⢠- To Parent Directory UML Weekend Crash Course⢠- To Parent Directory
SESSION 24 Modeling the Development Environment Session Checklist ✔ Explaining the purpose and function of packages ✔ Defining the package notation ✔ Creating a Package diagram for the case study Throughout the development process, you create a wide variety of diagrams to gather requirements, research those requirements, and ultimately describe the software you want to generate. Without a tool to organize all those work products, the job can quickly become confusing and overwhelming. Packages are the UML tool for organizing the diagrams and other work products of the project. Describing the Purpose and Function of Packages A package is modeled with a folder icon like the three packages in Figure 24-1. Also illustrated in Figure 24-1 is the fact that packages may be used for three distinct purposes. In one role, they may be used to organize any and all of the diagrams that you create during the project. You can place the diagrams into various packages just like you would place files into various directories on your computer. You name the directories and packages to indicate the purpose of the contained files. Figure 24-1 illustrates this role with the package on the left, a package of deliverables for Project A7, Phase 1. Packages may contain any of the logical model elements you’ve learned so far, such as Use Case diagrams, Sequence diagrams, Class diagrams, and even other packages. In fact, most modeling tools provide a navigation mechanism based on packages that look and function exactly like a directory structure. Because this use of packages is so general, you may use virtually any stereotype with it to explain how you are using the particular package.
246 Sunday Morning Project A7 Phase 1 role 1 directory Receiving role 2 subsystem Order tracking role 3 model Receiving Order tracking Alternative notations Figure 24-1 Three uses for packages: directories, subsystems, and models In the second role, the package can represent a subsystem, like the Receiving subsystem in Figure 24-1. A subsystem is a UML-defined stereotype that identifies a cohesive subset of the total system. For example, the Inventory Control System might be organized into a Receiving subsystem and a Shipping subsystem, among others. Elements placed in a subsystem type of package are, by default, visible only within the package. However, the visibility of individual model elements within the package may be defined as public, private, or protected. Every subsystem package must have at least one public interface (that is, at least one class with a public interface). The third use of packages is called a model. A model is also a UML-defined stereotype, similar to a subsystem in that it contains a cohesive set of elements of the system. The difference is that the model focuses on a topic or type of behavior within the system. For example, information about the Order Tracking topic of the third package in Figure 24-1 will very likely appear in most of the Inventory Control subsystems. Also, because the model is focused on one topic, it will not contain any system elements that do not help explain the topic. Packages Provide a Namespace All these package types provide a separate namespace for the model elements contained within them, including other packages. Naming elements within a package requires two pieces of information: the element name and the element type. For example, a package may contain something called Product of type Class and something called Product of type Statechart diagram. Names must be unique across elements of the same type within a package but do not have to be unique across different types. A package could not contain two items called Product that are both of type Class. Model elements in different packages may have the same name. But whenever the two elements are used together, they must be qualified with the owning package name. A fully qualified element name uses the notation package :: element, for example Receiving :: Product and Shipping :: Product.
- Page 217 and 218: 194 Saturday Evening Scenario 1 Get
- Page 219 and 220: 196 Saturday Evening pointing towar
- Page 221 and 222: 198 Saturday Evening :OrderFullfill
- Page 223 and 224: 200 Saturday Evening Scenario 5, in
- Page 226 and 227: SESSION 20 Modeling the Dynamic Vie
- Page 228 and 229: Session 20—Modeling the Dynamic V
- Page 230 and 231: Session 20—Modeling the Dynamic V
- Page 232 and 233: Session 20—Modeling the Dynamic V
- Page 234: Session 20—Modeling the Dynamic V
- Page 238 and 239: Part V — Sunday Morning Session 2
- Page 240 and 241: SESSION 21 Applying the Basic State
- Page 242 and 243: Session 21—Applying the Basic Sta
- Page 244 and 245: Session 21—Applying the Basic Sta
- Page 246 and 247: Session 21—Applying the Basic Sta
- Page 248: Session 21—Applying the Basic Sta
- Page 251 and 252: 228 Sunday Morning receivePmt(amt)[
- Page 253 and 254: 230 Sunday Morning Figure 22-4 repr
- Page 255 and 256: 232 Sunday Morning A substate is a
- Page 257 and 258: 234 Sunday Morning Monitor when tem
- Page 260 and 261: SESSION 23 Applying the Extended St
- Page 262 and 263: Session 23—Applying the Extended
- Page 264 and 265: Session 23—Applying the Extended
- Page 266 and 267: Session 23—Applying the Extended
- Page 270 and 271: Session 24—Modeling the Developme
- Page 272 and 273: Session 24—Modeling the Developme
- Page 274 and 275: Session 24—Modeling the Developme
- Page 276 and 277: Session 24—Modeling the Developme
- Page 278 and 279: SESSION 25 Modeling the Static View
- Page 280 and 281: Session 25—Modeling the Static Vi
- Page 282 and 283: Session 25—Modeling the Static Vi
- Page 284 and 285: Session 25—Modeling the Static Vi
- Page 286 and 287: SESSION 26 Modeling the Static View
- Page 288 and 289: Session 26—Modeling the Static Vi
- Page 290 and 291: Session 26—Modeling the Static Vi
- Page 292 and 293: Session 26—Modeling the Static Vi
- Page 294 and 295: Session 26—Modeling the Static Vi
- Page 296 and 297: PART # V Sunday Morning Part Review
- Page 299 and 300: PART VI Sunday Afternoon Session 27
- Page 301 and 302: 278 Sunday Afternoon design, and mo
- Page 303 and 304: 280 Sunday Afternoon :User :Web Br
- Page 305 and 306: 282 Sunday Afternoon studied Java p
- Page 307 and 308: 284 Sunday Afternoon and time. A JS
- Page 310 and 311: SESSION 28 Analysis and Architectur
- Page 312 and 313: Session 28—Analysis and Architect
- Page 314 and 315: Session 28—Analysis and Architect
- Page 316 and 317: Session 28—Analysis and Architect
SESSION<br />
24<br />
Modeling the Development<br />
Environment<br />
Session Checklist<br />
✔ Explaining the purpose and function of packages<br />
✔ Defining the package notation<br />
✔ Creating a Package diagram for the case study<br />
Throughout the development process, you create a wide variety of diagrams to gather<br />
requirements, research those requirements, and ultimately describe the software you<br />
want to generate. Without a tool to organize all those work products, the job can<br />
quickly become confusing and overwhelming. Packages are the <strong>UML</strong> tool for organizing the<br />
diagrams and other work products of the project.<br />
Describing the Purpose and Function of Packages<br />
A package is modeled with a folder icon like the three packages in Figure 24-1. Also illustrated<br />
in Figure 24-1 is the fact that packages may be used for three distinct purposes. In<br />
one role, they may be used to organize any and all of the diagrams that you create during<br />
the project. You can place the diagrams into various packages just like you would place files<br />
into various directories on your computer. You name the directories and packages to indicate<br />
the purpose of the contained files. Figure 24-1 illustrates this role with the package on<br />
the left, a package of deliverables for Project A7, Phase 1.<br />
Packages may contain any of the logical model elements you’ve learned so far, such as<br />
Use Case diagrams, Sequence diagrams, Class diagrams, and even other packages. In fact,<br />
most modeling tools provide a navigation mechanism based on packages that look and function<br />
exactly like a directory structure. Because this use of packages is so general, you may<br />
use virtually any stereotype with it to explain how you are using the particular package.