Lecture#02, building blocks of uml ASE

lineking 5,322 views 38 slides Aug 31, 2013
Slide 1
Slide 1 of 38
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23
Slide 24
24
Slide 25
25
Slide 26
26
Slide 27
27
Slide 28
28
Slide 29
29
Slide 30
30
Slide 31
31
Slide 32
32
Slide 33
33
Slide 34
34
Slide 35
35
Slide 36
36
Slide 37
37
Slide 38
38

About This Presentation

No description available for this slideshow.


Slide Content

Building Blocks of UML By: ALTAF HUSSAIN

Building Blocks of the UML… The vocabulary of the UML encompasses three kinds of building blocks: Things/ Elements Relationships Diagrams Things are the abstractions that are first-class citizens in a model; relationships tie these things together, diagrams group interesting collections of things.

UML Basics Elements Relationships Diagrams Dependency Association Generalization Realization Static Diagrams Dynamic Diagrams Class Interface Collaboration Use Case Active Class Component Node Interaction State Machine Note Packages Class Diagram Object Diagram Component Diagram Deployment Diagram Activity Diagram Collaboration Diagram Sequence Diagram State Diagram Use Case Diagram

THINGS in UML… There are four kind of things in the UML… Structural Things Behavioral Things Grouping Things Annotational Things These things are the basic object-oriented building blocks of the UML. You use them to write well-formed models.

Structural Things… These are nouns of UML models. These are the mostly static parts of a model, representing elements that are either conceptual or physical. There are seven kind of structural things: Class Interface Collaboration Use Case Active Class Component Node

Class… Class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. A class implements one or more interfaces. Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations.

Interface… Interface is a collection of operations that specify a service of a class or components. An interface therefore describes the externally visible behavior of that elements. It represents a complete behavior of a class or component or only a part of that behavior. It defines a set of operation specifications (that is, their signatures) but never a set of operation implementations. Graphically, it is rendered as a circle together with its name. It rarely stands alone. Rather it is typically attached to a class or components that realizes it.

Collaboration… Collaboration defines an interaction and is a society of roles and other elements that work together to provide some cooperative behavior that is bigger than the sum of all elements. Collaboration have structural as well as behavioral dimensions. A class might participate in several collaborations. They represent the implementation of patterns that make a system. It is rendered as an ellipse with dash lines usually includes only its name.

Use Case… A use case is a description of set of sequence of actions that a system performs and yields an observable result of value to a particular actor. A use case is used to structure the behavioral things in a model. A use case is realized by a collaboration. Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name.

Active Class… Active class is a class whose objects own one or more processes or threads and therefore can initiate control activity. An active class is just like a class except its objects represents the elements whose behavior is concurrent with other elements. Graphically, its rendered like a class but with a heavy lines…

Component… Component is a physical and replaceable part of a system that confirms to and provide the realization of a set of interfaces. In a system we find different deployment components: COM+ components, Java beans, components that are part of deployment process like source code files. A component typically represents the physical packaging of a system or otherwise logical elements like classes, and interfaces. Its graphically presented a rectangle with tab including its name…

Node… Node is a physical element that exists at runtime and represents a computational resource, generally having at least some memory and, often processing capability A set of components may reside on a node and may also migrate from node to node. It is graphically, rendered as a cube including its name….

Behavioral Things… These are verbs of UML models. These are the dynamic parts of a UML model, representing behavior over time and space. There are two kind of behavioral things: Interaction State Machine

Interaction… Interaction is a behavior comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose. The behavior of a set of objects or an individual operation may be specified with the interaction. An interaction involves a number of other elements including messages, action sequence( the behavior invoked by a message) and links (the connection between objects). Graphically it is rendered as directed line including name of the operation.

State Machine… State machine is a behavior that specifies the sequences of states an object or interaction goes through during its lifetime in response to events, together with the responses to those events. The behavior of a class or collaboration of classes may be specified with a state machine. A state machine involves a number of other elements, including states, transitions (the flow from state to state), events (things that trigger transition), and activities (the response to a transition). Graphically a state is rendered as round rectangle , usually includes name & its substates , if any…

Interaction & State Machine… These two elements – interaction and state machine – are the basic behavioral things that you may include in a UML model. Semantically these elements are usually connected to various structural elements primarily classes, collaborations, and objects

Grouping Things… Grouping things are the organizational part of UML models. These are the boxes into which a model can be decomposed. In all, there is one primary kind of grouping thing, namely Package .

Package… Package is a general purpose machine for organizing elements into groups. Structural things, behavioral things, and even other grouping things may be placed in a package. Unlike components (which exists at runtime, a package is purely conceptual (meaning that it exists only at development time) Graphically rendered as tabbed folder having its name and sometimes its contents.

Annotational Things… Annotational things are the explanatory parts of UML models. These are the components you may apply to describe, and remark about any element in a UML model. There is one primary kind of annotational thing called Note. A Note is simply a symbol for rendering constraints and comments attached to an element or collection of elements. Graphically it is rendered as a rectangle with a dog-ear corner, together with a textual or graphical comments.

RELATIONSHIPS in UML… There are four kind of relationships in the UML… Dependency Association Generalization Realization These are the basic relational blocks of UML.

Dependency… Dependency is a semantic relationship between two things in which a change to one thing (the independent thing) may affect the semantics of the other thing (the dependent thing). Graphically rendered as dashed line, possibly directed and occasionally with a label.

Association… Association is structural relationship that describes a set of links, a link being a connection among objects. Aggregation is a special kind of association, representing a structural relationship between a whole and its parts. Graphically rendered as a solid line, possibly directed, occasionally including a label, and often containing other adornments such as multiplicity and role name.

Generalization… This is a specialization/ generalization relationship in which objects of the specialized element (the child) are suitable for objects of the generalized element (the parent). In this way, the child shares the structure and behavior of the parent. Graphically rendered as solid line with a hollow arrowhead pointing to the parent.

Realization… This is semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out. We can find realization relationship at two places: between interfaces and classes or components that realize them, and between use cases and the collaborations that realize them. Graphically rendered as a cross between a generalization and dependency relationship.

Relationships in UML These four elements are the basic relational things that may include in a UML model. There are variations on these four such as refinement, trace, include and extend (for dependencies)

DIAGRAMS in UML Modeling something means to create the simplification of reality to better understand the system to be developed. Using the UML, we build our models from basic building blocks such as classes, interfaces, collaborations, components, nodes, dependencies, generalizations and associations. Diagrams are the means by which we plot and view these building blocks. Diagram is a graphical presentations of a set of elements, most often rendered as a connected graph of vertices (things) and arcs (relationships).

Diagrams in UML… Diagrams are used to visualize your system from different perspective. Because no complex system can be understood in its entirely from one perspective, the UML defines a number of diagrams to focus on different aspects of system independently. System is collection of subsystems organized to accomplish a purpose and described by a set of models, possibly from different viewpoints.

Diagrams in UML… UML has two types of diagrams: Structural Diagrams: there are four UML structural diagrams to visualize, specify, construct and document the static aspects of a system. Just as the static aspects of a house encompass the existence and placements of such things as wall, doors, pipes, windows and vents etc. so too to the static aspects of a software system encompass the existence and placement of such things as classes, interfaces, collaborations, components and nodes etc. there are following four structural UML diagrams. Class Diagram Object Diagram Component Diagram Deployment Diagram

Diagrams in UML… 2. Behavioral Diagrams: there are five UML behavioral diagrams to visualize, specify, construct, and document the dynamic aspects of a system. Dynamic aspects of a system as representing its changing parts. Just as dynamic aspects of a house encompass ariflow and traffic through the rooms of a house, so too do the dynamic aspects of a software system encompass such things as the flow of messages over time and physical movements of components across network. Following five are the UML behavioral diagrams. Use Case Diagram Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram

Class Diagram… Class diagram shows a set of classes, interfaces, and collaborations and their relationships. These are the most common diagram found in modeling object-oriented systems. Class diagram address the static design view of a system. Class diagram having active classes address the static process view of a system.

Object Diagram… An object diagram shows a set of objects and their relationships. Object diagram shows the static snapshots of the things found in class diagram. These diagrams address the static design view or static process view of a system as do class diagram, but from the perspective of real or prototypical cases.

Component Diagram… Component diagram shows the organization and dependencies among a set of components. Components diagram shows the static implementation view of a system. They are related to class diagram in that a component typically maps to one or more classes, interfaces, or collaborations.

Deployment Diagram… Deployment diagram shows the configuration of runtime processing nodes and the components that live on them. Deployment diagram shows the static deployment view of an architecture. They are related to component in that a node typically encloses on or more components.

Use Case Diagram… A use case diagram shows a set of use cases and actors (a special type of class) and their relationships. Use case diagram shows the static use case view of a system. These diagrams are especially important in organizing and modeling the behaviors of a system.

Interaction Diagram… Both sequence and collaboration diagrams are a kind of interaction diagrams. These diagrams consists of a set of objects and their relationships, including the messages that may be dispatched among them. These diagrams show the dynamic view of a system. Sequence diagram emphasizes the time-ordering of messages and collaboration diagram emphasizes on structural organization of the objects that send or receive messages. These both are isomorphic; means you can take one and transform into other one.

State chart Diagram… State chart diagram shows a state machine, consisting of states, transitions, events and activities. This diagram shows the dynamic view of a system. They are especially important in the modeling the behavior of an instance, class, or collaboration and emphasize the event-ordered behavior of an object, which is especially useful in modeling reactive systems.

Activity Diagram… Activity diagram is a special type of state chart diagram that shows the flow of activity to activity within a system. This diagram shows a set of activities, the sequential or branching flow from activity, and objects that act and are acted upon. Activity diagram shows the dynamic view of a system. They are especially important in modeling the function of a system and emphasize the flow of control among objects.