The Unified Modeling Language is a language used to specify, visualize, and document models of software systems, including their structure and design. The language was formed by Grady Booch, Ivar Jacobson, and James Rumbaugh11-3 after a critical mass of ideas started forming in the 1990s from their individual work in object-oriented methods. Collectively they defined UML for three reasons:
1. Their methods were evolving toward each other independently
2. To provide stability to the object-oriented modeling language
3. To provide improvements to the language
UML 1.0 was offered by the Object Management Group (OMG) for standardization in January 1997 with the final acceptance of version 1.1 in September 1997. The OMG maintains the UML specification with the latest version found on the OMG website at http://www.uml.org/
In March 2003, the OMG along with the International Council on Systems Engineering (INCOSE) developed a Request for Proposal (RFP) for UML for Systems Engineering. The RFP specified the requirements for extending UML to support the needs of the systems engineering community. SysML™[1] is a general purpose graphical modeling language for specifying, analyzing, designing and verifying complex systems. The system may include hardware, software, information, personnel, procedures, and facilities. SysML represents a subset of UML. The SysML specification was developed with the OMG announcing the adoption of the OMG SysML in July 2006 and the availability of the specification in September 2007. The latest version of the SysML specification can be found at the OMG website at http://www.omg.org/spec/SysML/
11.2.1 Types of Diagrams in the UML- UML 2.4 See (http://www.omg.org/spec/UML/2.4) defines fourteen types of diagrams, divided into two categories:
1. Structure Diagrams, which include:
a. Class Diagram
b. Package Diagram (diagram same for SysML)
c. Object Diagram
d. Component Diagram
e. Composite Structure Diagram
f. Deployment Diagram
2. Behavior Diagrams, which include:
a. Activity Diagram
b. Sequence Diagram (diagram same for SysML)
c. Communication Diagram
d. Interaction Overview Diagram
e. Timing Diagram (optional)
f. Interaction Tables (optional)
g. State Machine Diagram (diagram same for SysML)
h. Use Case Diagram (diagram same for SysML)
Structure diagrams are used to visualize, specify, construct and document the static aspects of a system i.e. no time element). Behavior diagrams are used to visualize, specify, construct and document the dynamic aspects of a system (i.e. time is considered).
Not all diagrams in each category need to be used when defining a software system, just what is needed to communicate how the software system works; how it is built structurally, how it behaves, and what it interacts with. Without both category representations, a software system is not fully defined and can lead to issues when the software system is built. For example, without understanding the timing requirements for a real-time embedded system, software designers may define the software structure to meet all functional requirements of the system, but find out during testing that it does not meet the timing requirements. The software system would need to be re-architected to meet both the functional and timing requirements.
The next sections provide simple examples of some of the UML diagram types including common diagrams with SysML. These are simple examples based on the Digital Camera System first introduced in Chapter 6. Note that the examples are not meant to represent a complete Digital Camera System or to be 100% accurate. They are just representative of the UML diagrams to help understand the basic structure and information they are conveying. There are many books that provide more detailed instructions on how to create these diagrams and on what they are used for when modeling a software system. There are also many Web Sites that provide examples of each diagram type.
11.2.2 Structure Diagrams- Examples of Class Diagrams, Package Diagrams and Deployment Diagrams are Structure Diagrams shown and discussed in this section.
Class Diagram - A class diagram is used to show a set of classes, interfaces, and collaborations and their relationships. Class diagrams provide a static view of the system. Using the Simple Digital Camera System, Figure 11-1 illustrates a possible class diagram based on Take a Digital Picture Use Case .
Figure 11-1 Class Diagram Example for a Simple Digital Camera System
Shutter, LCD, and Storage are all classes within the system that interact with each other and represent real world items that make-up a Digital Camera. Each class contains attributes and operations. Attributes are a named property of a class that describes a range of values that instances of the property may hold; using software terms, a data structure or a variable. An attribute is some piece of information the class needs in order to perform its function. A class may have any number of attributes or none at all. The class Storage has an attribute of imageCount to keep track of the number of images stored and it has three operations indicated, storeImage, incrementImageCount, and isStorageAvailable.
When first identifying classes within a system start with the requirements specification or Use Cases and identify nouns. Alternatively, start with the real world items that make-up the system. All of these are candidates for possible classes. As more is understood about the system, the class diagrams will evolve until the final class diagram for the system is achieved. In modeling a software system, the classes tend to become more abstract and may not have real world counterparts.
The example above does not contain all possible graphic elements that are possible in a class diagram. For more information, see the UML specification at: http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML
Package Diagram- A package is a general-purpose mechanism for organizing elements into groups. Or in other words, it indicates a subsystem or block of functionality within a system and is used to simplify the view of a system in order to understand it better. Figure 11-2 shows a possible package diagram for the Digital Camera System.
Figure 11-2 Package Diagram Example for a Simple Digital Camera System
The package diagram also shows the interactions or relationships between each package. Figure 11-2 illustrates the Camera Controller Package as a depdency on both the Image Acquisition Package and the Storage Device Package. Since packages are a way of abstracting or simplfying the view of a system, each package may contain more packages, class diagrams, use cases, components, etc. until the view is at the lowest level. Well-designed packages group like elements that tend to change together. Well-structured packages are loosely coupled and highly cohesive (See Section 6.6.3 for definitions of coupling and cohesion). The graphic elements used in class diagrams to show relationships are also used in package diagrams. Package diagrams are used to show different views of a system’s architecture.
Deployment Diagram - A deployment diagram shows the configuration of run time processing nodes and the components that live on each node. They are used to illustrate the static deployment view of a software system onto the hardware on which the system executes. Names of the nodes should represent the vocabulary of the hardware in the domain of the system being developed. Nodes represent a physical element and represent a computational resource having at least some memory and processing capability. Figure 11-3 shows a deployment diagram for the Digital Camera System assuming there are three processors in the system.
Figure 11-3 Example Deployment Diagram for a Digital Camera System
For real-time embedded software with only one processor, the deployment diagrams look like context diagrams from the system engineering world. They show the devices with which the processor board is interacting using what are called stereotypes to identify the hardware components. Client/Server and Distributed software systems have more processors on their deployment diagrams and provide the designers with an understanding of where each software component resides on the physical hardware.
The relationships between nodes are typically an association that represents a physical connection (i.e. Ethernet, cPCI bus). For more information on possible types of relationships for deployment diagrams, see the UML specification at: http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML
[1] Systems Modeling Language and SysML are either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries.
No comments:
Post a Comment