UML Weekend Crash Course™ - To Parent Directory

UML Weekend Crash Course™ - To Parent Directory UML Weekend Crash Course™ - To Parent Directory

crnarupa.singidunum.ac.rs
from crnarupa.singidunum.ac.rs More from this publisher
01.01.2015 Views

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.

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.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!