COSC 3351 Software Design. An Introduction to UML (I)

Transcription

1 COSC 3351 Software Design An Introduction to UML (I) This lecture contains material from: Spring 2008 UML The UML is a graphical language for specifying visualizing constructing documenting the artifacts of software systems Added to the list of OMG adopted technologies in November 1997 as UML 1.1 Define an easy-to-learn but semantically rich visual modeling language Include ideas from other modeling languages Incorporate industry best practices Address contemporary software development issues scale, distribution, concurrency, executability, etc. Provide flexibility for applying different processes Enable model interchange and define repository interfaces 1

2 OMG UML Evolution composition (whole-part) relationship UML (planned) UML 2.0 Superstructure 2001 Q4 (planned) UML 2.0 Infrastructure UML 2.0 OCL Q UML 1.4 dependency relationship 1999 UML Editorial revision without significant technical changes. UML (adopted by OMG) UML 1.1 From [Kobryn 01a]. Type of UML diagrams There are different types of UML diagram, each with slightly different syntax rules: use cases. class diagrams. sequence diagrams. package diagrams. state diagrams activity diagrams deployment diagrams. 2

3 Different UML diagrams UML syntax (I) Actors: a UML actor indicates an interface (point of interaction) with the system. Actors may be people, or other systems. Actors used to group and name sets of system interactions. An actor is NOT part of the system. An actor is something external that your system has to deal with. Boxes: boxes are used variously throughout UML to indicate discrete elements, groupings and containment. 3

4 UML syntax (II) Arrows: arrows usually indicate flow, dependency, association or generalization (depending on the type of diagram) Cardinality: applied to arrows, show relative numerical relationships between elements in a model: 1 to 1, 1 to many, etc. UML syntax (III) Constraints: allow notation of arbitrary constraints on model elements. Used, for example, to constrain the value of a class attribute (a piece of data). Stereotypes: allow to extend the semantics of UML with English. A stereotype is usually a word or short phrase that describes what a diagram element does. That is, we mark an element with a word that will remind us of a common (stereotypical) role for that sort of thing. Stereotypes should always be applied consistently (with the same intended meaning in all instances). 4

5 UML diagrams: use cases (I) A use case encodes a typical user interaction with the system. In particular, it: captures some user-visible function. achieves some concrete goal for the user. A complete set of use cases largely defines the requirements for a system: everything the user can see, and would like to do. The granularity of use cases determines the total number of use cases for the system. A clear design depends on showing the right level of detail. A use case maps actors to functions. The actors need not be people. UML diagrams: use cases (II) Use case diagrams are helpful in three areas. determining features (requirements). New use cases often generate new requirements as the system is analyzed and the design takes shape. communicating with clients. Their notational simplicity makes use case diagrams a good way for developers to communicate with clients. generating test cases. The collection of scenarios for a use case may suggest a suite of test cases for those scenarios. 5

6 UML diagrams: use cases (III) Example: Relationships in a news web site UML diagrams: use cases (IV) The notes between << >> marks are stereotypes: identifiers added to make the diagram more informative. Here they differentiate between different roles (ie, different meanings of an arrow in this diagram). 6

7 What is structural modeling? Structural model: a view of a system that emphasizes the structure of the objects, including their classifiers, relationships, attributes and operations. Structural Modeling: Core Elements Construct Description class a description of a set of objects that share the same attributes, operations, methods, relationships and semantics. interface a named set of operations that characterize the behavior of an element. component a modular, replaceable and significant part of a system that packages implementation and exposes a set of interfaces. node a run-time physical object that represents a computational resource. Syntax «interface» 7

8 Structural Modeling: Core Elements (cont d) Construct Description constraint¹ a semantic condition or restriction. Syntax {constraint} ¹ An extension mechanism useful for specifying structural elements. Structural Modeling: Core Relationships Construct Description Syntax association aggregation composition generalization a relationship between two or more classifiers that involves connections among their instances. A special form of association that specifies a whole-part relationship between the aggregate (whole) and the component part. strong association in which the part can belong to only one whole a taxonomic relationship between a more general and a more specific element. 8

9 Structural Modeling: Core Relationships (II) Construct Description Syntax realization dependency Cardinality a relationship between a specification and its implementation. a relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element) * Exactly one Zero or more 1..* One or more Zero or one Specified range Structural Diagram Tour Show the static structure of the model the entities that exist (e.g., classes, interfaces, components, nodes) internal structure relationship to other entities Do not show temporal information Kinds static structural diagrams class diagram object diagram implementation diagrams component diagram deployment diagram 9

10 Class diagrams - example Class diagrams (II) UML class notation is a rectangle divided into three parts: class name, attributes, and operations. Names of abstract classes, such as Payment, are in italics. Relationships between classes are the connecting links. 10

11 Class diagrams (III) Our class diagram has three kinds of relationships. Association: a relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to perform its work. Aggregation: an association in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole. Generalization: an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass. Class diagrams (IV) A navigability arrow on an association shows which direction the association can be traversed or queried. An OrderDetail can be queried about its Item, but not the other way around. The arrow also lets you know who "owns" the association's implementation; in this case, OrderDetail has an Item. Associations with no navigability arrows are bidirectional. The multiplicity of an association end is the number of possible instances of the class associated with a single instance of the other end. Multiplicities are single numbers or ranges of numbers. In our example, there can be only one Customer for each Order, but a Customer can have any number of Orders. 11

12 Class Diagrams (V) Associations in which an object is part of a whole are aggregations. Composition is a strong association in which the part can belong to only one whole -- the part cannot exist without the whole. Composition is denoted by a filled diamond at the whole end. This diagram shows that a BoxOffice belongs to exactly one MovieTheater. Destroy the MovieTheater and the BoxOffice goes away! The collection of Movies is not so closely bound to the MovieTheater. Class information: visibility and scope The illustration uses the following UML conventions. Static members are underlined. Instance members are not. The operations follow this form: <access specifier> <name> ( <parameter list>) : <return type> The parameter list shows each parameter type preceded by a colon. Access specifiers appear in front of each member. 12