Modeling Composite States

Composite states contains one or more Statechart diagrams.
they are 2 types

1. Mutually exclusive states - embedding a Statechart diagram inside of a state.
2. Concurrent states - divides a state into two or more regions. Each region contains a Statechart diagram. Each region executes independently and at the same time as the other regions.

A composoite state is also called a superstate. It contains a set of specialized states called substates.
A superstate may be modeled as a state icon with one additional feature, a composite icon that consists of two small horizontally aligned rounded-rectangles connected by a line. The icon indicates that the state can be expanded to reveal more details.


Figure 10-33: An elided superstate icon (left) and the expanded superstate icon (right).

Modeling mutually exclusive substates.
A composite state (superstate) may be decomposed into two or more substates. The substates resides within a graphic compartment below the name and internal transition compartments.



Figure 10-34: Mutually exclusive substates displayed in a graphic compartment within a superstate.

Modeling concurrent substates
The regions are divided using a dashed line within the graphic compartment.


Figure 10-35: Composite state with concurrent regions.

Submachine States
Submachine state is a subclass of the Composite State.
Within a composite state, the submachine state maybe referenced in the same manner that a class would call a subroutine or a function on another class.
The containing state icon models the reference to the submachine state by adding the keyword "include" followed by a slash and the name of the submachine state.

Transitions to and from composite substates


Figure 10-38: Initial state refers to a specific substate.

Exiting the superstate can be accomplished in multiple ways. An object may leave the superstate regardless of the current substate, leave from a specific substate, or exit at the completion of all activities within the superstate.


Figure 10-39: Leaving a superstate.



Figure 10-40: Exiting a superstate from a specific substate.

Stubbed transitions
Stub states represent only the entry and exit points for a submachine state.
Each stub is drawn as a line with the substate name as the label.
A stub used as an entry point is a stub with one or more transition arrows pointing to it. A stub used as an exit point is a stub state with one or more arrows coming out of it.


Figure 10-42: Modeling an exit stub state.


Transitions to and from concurrent states.

Concurrent states introduce the need to coordinate simultaneous behaviors, including synchronization, split of control, and merge of control.

1.Split of control and merge of control.

Split of control means that based on a single transition, you want to proceed with many tasks concurrently. Split of control is shown by a single transition dividing into multiple arrows, each pointing to different substates.
The regions execute independently of one another.



Figure 10-44: Split of control and merge of control using the synchronization bar.


Merge of control- based on the completion of a number of transitions, you want to proceed with a single task. A merge is the opposite of a split.

2. Synch states

Figure 10-45: Using sync states to coordinate behaviors across regions.


When state B1 is completed, it trasitions to a split point. At split point a transition is send to a sync state, modeled as a circle containig an asterisk(*). The transition to C2 has to wait for the completion of both B1 and C1, even though B1 is not in the same region.

3. Multiple transitions out of a superstate

There are three ways that the object can exit the composite state.



Figure 10-46: Multiple ways to exit a composite state with concurrent substates.

1. Some type of interrupt event, such as T1.
2. All three substate regions could run to completion.
3. A specific event, such as T2.

Deriving a Statechart diagram from Sequence diagrams

Events trigger transitions between states. States capture the condition of an object during the period of time between events.


Figure 10-25: A basic Sequence diagram with events and transitions.

The states of the object is defined by the values of one or more of its attributes.


Figure 10-26: Mapping a Sequence diagram to a Statechart diagram.

Modeling a Statechart diagram

State - of an object is simply its current condition. That condition is reflected in the values of the attributes that describe the object.
Scope of the Statechart is the entire life of one object.
Statechart models the events that trigger a transition(change) from one state to another state.
An event or action corresponds to a message sent to the object asking or telling it to do something .
Describes the life of one object in terms of the events that trigger changes in the object's state. It identifies both the external events and internal events that can change the object's state.
we can derive a Statechart diagram from the interactions on a Sequence diagram.

Modeling object states and events
A simple state is modeled as a rounded rectangle with the state name inside.

Initial state - of an object is modeled as a solid dot with an arrow pointing to the first state.



Figure 10-2: Initial state notation.
final state - is modeled as a bull's-eye, a dot within a circle.

Modeling events and transitions
An event on a Statechart diargam corresponds to a message on a Sequence diagram.
Event notation is a label on an arrow connecting one state to another state, using a solid line with a stick arrowhead.

Within a Statechart diagram. an object doesn't need to know who send the event.
An object is only responsible for how it responds to the event.

Modeling change events


Figure 10-8: Deriving new states from the event parameters.




Figure 10-9: Revised Statechart diagram that improves cohesion and coupling.


Modeling a guard condition


Figure 10-10: Modeling a guard condition.


Modeling event actions
An action expression is the set of one or more actions triggered by an event.
It considered as an atomic task.
To model the action expression, place a forward slash after the event name followed by the name of the action or actions you want performed.



Figure 10-11: Modeling an event/action pair.

Internal transitions
We can add a internal transitions compartment to name compartment of the state icon. It reveals what the object can do while it is in a given state.


Figure 10-12: The expanded state icon.

The internal trasitions compartment contains information about actions, activities, and internal transitions specific to that state.

Modeling activities
Activities are processes performed within a state. An activity may be a group of separate tasks.


Figure 10-16: The expanded state icon with activities.

These activities will be performed from the time the object enters the state until the object leaves the state or the activity/ies finish.

Modeling Internal transitions
While an object is in a given state it may receive events that do not trigger a change in state, yet do trigger a response. An event that can be handled completely without a change in state is called an internal transition.


Figure 10-17: Internal transition.

There may be any number of internal transitions in a state. Each may have associated action expressions. Simply list them within the internal transitions compartment.

Modeling a Collaboration Diagram

Collaboration diagram uses an Object diagram as its foundation.

Models the messages relative to object structure. Validate the associations between classes or even discover the need for new association.
Sequence numbers are essential. to read the Collaboration diagram, follow the numbered messages to step through the scenario.



Figure 8-17: Collaboration diagram of cancel event scenario modeled in

Active Objects - To identify an active object, the border of the object is highlighted or thickened. In addition, the property keyword {active} may be placed in the object icon.

Multi-objects - set of objects of the same type. You can represent as an object icon on top of another object icon.

Comparing the Sequence and Collaboration Diagrams
The Collaboration diagram uses an Object diagram as its foundation.

1. Draw the objects with only the name compartment, not the attributes.
2. Draw the links between objects.
3. Add a message by placing the message arrow parallel to the link between the two objects.
4. Number the message in its order of execution.

Modeling a sequence diagram

Uses a time-oriented visualization. Illustrate interactions between objects. Model objects and messages between objects. When one object wants to send a message to another object, the second object has to have a way to receive the message. The message must match an interface provided by the second object.

Modeling an object lifeline
The sequence diagram uses two fundamental notation elements
-object lifelines
-messages or stimulus

The object lifeline includes the rectangular object icon and the vertical dashed line below each object. The line is a timeline that runs from the beginning of a scenario at the top of the diagram, to the end of the scenario at the bottom of the diagram.

Modeling a message or stimulus
A message is a definition of some type of communication between objects. It may invoke an operation, raise a signal, or cause the creation or destruction of the target object. A stimulus is an instance of a message.
A message is modeled as an arrow. The type of arrow visually describes the type of message. Messages are placed horizontally between the object lifelines. The relative vertical position on the timelines represents the order in which the messages happen.


Figure 8-3: Messages are placed on the object lifelines to model object interactions. Relative vertical position indicates the order of execution from top to bottom.

If one message is placed on the timeline above a second message, then the first message is sent before the second message.

The tail of the message arrow identifies the sender. The head of the message arrow identifies the receiver.

The return arrow is drawn using a dashed line and a stick arrow to distingush it from the synchronous message arrow.

The syntax for a message is as follows:

predecessors '/' sequence-term iteration [condition] return ':=' operation

stimulus - is an item of communication between two objects. It associated with both a sending and a receiving object. It may invoke an operation, raise a signal, or even cause an object to be created or destroyed. It may include parameters/arguments. It is associated with the procedure that causes it to be sent.
message - stimulus is an instance of a message. Is the specification of a stimulus. Specification includes the roles that the sender object and the receiver object play in the interaction, and the procedure that dispatches the stimulus.
operation - explains the procedure that the message invokes on the receiving object.
signal - A message may raise a signal. It does not require a return from the receiving object.
exception - is a type of signal. Sending out a message containig an object that describes the error condition.

Synchronous Messages - A return is needed, so the sender waits for the return before proceeding with any other activity. Modeled using a solid line and a solid arrowhead
Self-reference message - The sender and the receiver for the message are the same object. The message arrow leaves and come back to the same timeline. The send and return connot be combined into one message.
Asynchronous message - that do not have a return. Modeled using a solid line and a stick arrowhead


Timed Message - express the timing parameters for the message. for ex. {if you don't get a respose from the event object within 2 seconds, bypass the request and send an error to the user interface}

Iteration - excecute one or more messages in a sequence more than once. An asterisk (*) indicates that the message will execute repeately. You can enclose a conditional statement in square braces([]).

Conditions - A condition is expressed as text enclosed within square braces[]. UML supports the ability to model branching on a descision. This involves drawing a diamond and multiple arrows from the same point on the timeline to multiple destinations.

Modeling activation/focus of control
Activation means that an object is occupied performing a task. Deactivation means that the object is idle, waiting for a message.
To show that an object is active, widen the vertical object lifeline to a narrow rectangle. An object becomes active at the top of the rectangle. An object is deactivated when it finishes its work. This is usually illustrated as a message arrow leaving the object lifeline.

Modeling object creating and destruction
If an object is at the top of the page, means that the object exists when the sequence starts.
If the object is created during the execution of the scenario, it should appear somewhere below the top of the diagram.
To show that an object is terminated, place an X at the point in the object lifeline when the termination occurs. The absence of the X on an object lifeline means that the object lives on after this sequence of events is ended.

Modeling objects, links, Composite Structure diagram, connectors and ports, collaboration

Object diagram is the UML tool for modeling an example.
Class diagram models definitions and rules.

Modeling a test case requires the means to represent specific data, relationships, and behaviors.

Object diagram is ideally suited to model the data and relationships of the test cases.
Interaction diagrams model the behavior. it describe how objects use one another's services.


Modeling objects and links
Object notation
requires the name of the object and the name of the class that describes the object.

format: object-name : class-name

The Class diagram defines the attributes that must be used to define each type of object and the behaviors that each type of object must support.
The Object diagram has only two compartments: name and attribute
The attribute compartment defines only the current value of each attribute.



Figure 7-8: UML object notation for one customer who has placed two orders.


Modeling Composite Structure diagram

models the parts of a class, component, or collaboration, including interaction points(ports) used to access features of the structure.

Collaboration describes a behavior, the resources used to perform the behavior, and the roles the resources assume during the behavior.


The Composite Structure diagram models a class as a large rectangle with the class name in a compartment at the top of the rectangle


Modeling connectors and ports

The small squares at the ends of the connectors model ports, the points of contact between the connector and the object. A Port defines a distinct interaction point on the object.
Set of interfaces defines the port. The sum of the ports and associated services defines the boundary of the object.

Ports come in two types

-signal - if isSignal attribute is true, it may only relay signals.

-service - it defines the services provided by the classifier. if isService is false, the port is not part of the externally published features of the classifier, and it may be changed or deleted without altering the definition of the classifier.


Modeling a collaboration

Represents how elements of the model cooperate to perform some essential behavior. The participating elements may include classes and objects, associations and links, attributes and operations, interfaces, use cases, components, and nodes. The behavior may be a use case, an operation, a collection of operations, or a general mechanism of the system.
One common use for collaborations is to model design patterns.
Within a collaboration, the dependency arrow is called a connector. The connector binds a role to a model element. The collaboration defines the roles.

Modeling Dependency

Dependency represents a client-supplier relationship in which a change to the supplier requires a change to the client.
A dependency is modeled using a dashed arrow between model elements, one or more suppliers.



Figure 6-50: Modeling dependency notation.

Four types of dependency

-abstraction
-binding
-permission
-usage

Modeling Generalization

Generalization and inheritance are used synonymously.

There are 6 fundamental criteria for generalizing classes.

-attribute definitions
-attribute domain of values
-operations(signature)
-methods
-associations
-links

Figure 6-39: Shared target style notation for generalizations.


Model an abstract class
Italizing the name of the class, by providing the {abstract} property in the name compartment.


Constraints

UML predefines four constraints for use on generalization relationships

-Overlapping
-Disjoint
-Complete
-Incomplete

The overlapping constraint allows an instance to derive from multiple classes that are specializations based on different discriminators or powertypes.
The disjoint constraint prevents any overlap.
The complete constraint documents the fact that every possible subclass of a generalization has been identified and modeled.
The incomplete constraint documents the fact that the research on the possible subclasses is not finished.

Modeling Composition

Composition is a strong aggregation. where the life span of the member object depends on the life span of the aggregate. The aggregate has control over the creation and destruction of the member.



Figure 6-35: How to represent a composition relationship in UML.

In project team example the employees are assembled into a project team. But if the team is disbanded, the employees live on.
In theater event example uses composition, the performance would not continue to exist elsewhere on their own.

Modeling Aggregation

In typical association each class remains independent of the other and neither class is superior to the other. They simply communicate.
In Aggregation defines a definite hierarchical relationship. It defines an assembly or configuration of elements to make a larger more complex unit. There has to be a point of control, a boss, one object that represent the interface to the assembly and assumes responsibility for coordinating the behavior of the aggregation.
An aggregation defines configuration so that the collection of objects can be managed as a single unit.


Figure 6-33: How to model an aggregation relationship

Figure 6-33 reads as follows:

-An agent may be a part of no more than one agency, but an agent does not have to be part of an agency (0..1), that is an agent may be independent.

-The agency is always comprised of at least one agent but there may be any number of agents (1..*).

-An agent is considered an employee (role name) of an agency.

-Every agent is constrained by the fact that she must have a current contract in order to be an employee of the agency.

Modeling N-ary Associations

In this scenario more classes are associated.
ex. in order to define a schedule there must be an event, a coordinating venue manager, and a location to host the event.
The diamond symbol in the middle is used to merge the three association ends into one association. The schedule class is an association class that describes the combination as a scheduled item.




Figure 6-31: An n-ary association using the diamond symbol.

Modeling an Association class

Information about an association must be defined as attributes in a class.
An association class defines a type of link between the two classes.



Figure 6-26: Association class captures information about an association.

Modeling an Association

A software application requires a set of resources. To use them you need to describe each resource using a class definition. Classes describes the type of resources, their purpose, and the features that they provide, including attributes and operations.

Relationship explain how they can communicate. UML relationships come in three different types

association
generalization
dependency

Association is a semantic relationship between two model elements. i.e defines the rules that apply to relationships between the objects defined by participating classes.

Generalization is used in the context of inheritance. Defines the organization of information about objects that share the same semantic meaning but which vary in their individual features.

Dependency relationship does not require direct communication. An object relies on fact that another object exists and doing or has done, its job.

The purpose of an association is to establish the reason why two classes of objects need to know about one another, and rules that govern the relationship.
Modeling an association begins by identifying the participating classes.

1. Binary association notation
Associations that use two particiapting classes is called binary association.
Association is a rule that explaints what is allowed.
It documents the rules that govern one relationship between two classes of objects.



Figure 6-1: Association is a type of relationship. A link is an instance, or implementation, of an association.

Association name is in the middle of the line between two classes

an Event is hosted by Venue



Figure 6-3: An association's name uses a verb or verb phrase.



Figure 6-4: Each association represents a separate set of rules.


Association end

To define those roles, UML treats each association end as a separate and distinct entity with its own rules.


Figure 6-5: Association ends define the participation of each type of object.

Each end of the association includes some or all of these defining features;

-Roles
-Interface specifier
-visibility
-multiplicity
-ordering
-constraints
-qualifier
-navigability
-changeability

Roles
How an object participates in the relationship.

UML defines three extension mechanisms:

tagged values
stereotypes
constraints

Constraints are really just strings, you can add as many constraints as you need between the pairs of braces{}. It define which objects are allowed to participate in an association. It placed in an unambiguous place at the end of the association and near the class it applies to.


Figure 6-12: Using constraints to restrict object participation.


Qualifier
It works very much like a key on an indexed file. Provides a means to go directly to the object you want. The qualifier defines an attribute of the referenced objects and uses it as a key to get direct access to a specific object. To model a qualifier you must identify the type of object that wants to use the access, and the type of object that provides the access. The qualifier is placed next to the type of object that want to use it.


Figure 6-13: Using a qualifier to get direct access to an object.
The rectangle containing the qualifier is inserted between the class and the end of the association so that all the other association end notation remains intact.

Navigability
Describes the need for an object to access another object. It modeled with an arrow on the end of the association. Most associations are bi-directional. so, does not show any arrows.



Figure 6-14: Specify navigation by placing an arrow at the end of the association


Changeability
Enables you to specify the operations that are allowed on the links defined by an association. The default changeability is to allow any type of edit-add, change, delete, and move. The predefined options include {frozen}, which means that once the link has been esatablished, it cannot be changed or mved.


Figure 6-15: Modeling the non-default changeability property {frozen}.



Constraints between associations

Handle a situation where two associations are mutually exclusively. ie a venue manager may oversee an event or audit an event, but not both. Draw a dashed line between the two associations. Place the {xor} near the dashed line. It states that only one of the two associations may be instantiated between the pair of objects.


Figure 6-16: Exclusive or constraint on two associations {xor}.


Reflexive association
Most associations are between objects of two different classes. When the participating objects are in two different classes, the association line comes out of one class and into another class.


Derived associations
It using, because when a model becomes large or complex, it can become difficult to navigate to the information you needed.

Modeling a Class

The rules in the class diagram are used to generate code. The code generates objects.

A repository is a shared dictionary.

A change made to a class on one diagram is also made to the class definition in the repository, and is reflected in all diagrams that include that class.

To support definitions for identity, attributes, and operations, a UML class definition provides an icon with three predefined compartments.

The name always resides in the topmost compartment. A class name must be unique within a package. The format for a fully qualified class name is Package_Name::Class_Name.

Stereotype

Identify how a class is used in a design.
1. An entity element describes objects that are part of the subject matter.
2. Control elements typically represent specialized pieces of software that manage the behavior of some part of the application. knows about resources that it needs to manipulate or direct.
3. Utility stereotype represents a named collection of static attributes and operations. There is only one copy and everyone references that one copy. It hold common functionality used throughtout the system.
4. Enumeration stereotype is a user-defined datatype that defines a set of values that don't change(constants).


A class stereotype is not part of the class name and does not generate any code for the class. It bring consistency to the treatment of common elements in UML diagrams.

The stereotype may be applied in either of two forms: the stereotype name in
guillemets («»),

or graphical symbol.
a. entity stereotype represented as a circle on a straight line.
b. control stereotype by a circle "arrow".



Figure 5-9: Four ways to model classes with stereotypes.


Properties
Simple pieces of information about the class. ex.author, development status of the class, last worked, version etc. It specified below the name inside the name compartment. It expressed as a tag-definition/tagged-value pair ex. {author="Tom", Last_updated="09-18-02",Approved}



UML 2.0
Infrastructure is divided into four packages

Abstractions
Basic
Constructs
PrimitiveTypes

The Superstructure relies on the essential concepts defined by the infrastructure to build the concepts for constructing UML diagrams.

The Superstructure is divided into packages

structural
behavioral
supplemental

Port A port is a class gateway to the outside world. One object coded in Java and the other in C++ should not matter. A port can become part of a class definition.


Modeling Visibility

private scope - within a class
package scope - within the same package
public scope - within a system
protected scope - within an inheritance tree

Private -
Package ~
Public +
Protected #

Private visibility -It limits access to objects of the same class.

Package visibility - allows access by other objects in the same package, regardless of the class they belong to.

Public visibility - allows access by objects of all other classes in the defined namespace anywhere in the system.

protected visibility - allows access by subclasses. This is true whether or not the subclasses reside in the same package.



Modeling Multiplicity

Multiplicity specifies the number of values that may be associated with a model element.
a lower value of zero indicates that the item is optional.

Range of values
[6..9] or 6..9 means 6 through 9 incluvely.

specific value
[2]

Range without limit
[1..*] - one or more
[0..*] or [*] - zero or more

set of discrete values
[2,4,7]

Ordering
{isOrdered}

{isUnique} attribute is new in UML 2.0



Modeling an Attribute

Contains definitions for all the information that an object owns.

A UML attribute definiotion includes the following elements.
-Visibility
-Derived(true/false)
-name
-data type
-muliplicity
-default value
-property string
-class-level versus instance level designation

Attribute notation
These attribute definition elements are commonly expressed in a single text string using the following syntax:

[visibility] [/] name [: type] [multiplicity] [=default]
[{property-string}]


Derived - A slash(/) in front of an attribute name identifies the attributes as containing a derived value. The absence of the slash indicates a base value.

Name - The attribute name is required. the name must be unique within the class.

Data type - explains kind of information that can be stored in the attribute.

Property string - express the rules required to guarantee the integrity of the attribute value whenever another object attempt to change it.



Class-level attribute
it also referred as static attributes. Every object of the class may access the value.


Modeling the operation

Operations define behaviors, the services that an object can provide.
It is valid to use stereotypes to label groups of operations according to their usage. The stereotype applies to all operations below it in the list until another stereotype appears or until you reach the end of the compartment.

Operation notation
The UML operation notation defines the elements of a class behavior modeled using the syntax:

[visibility] name ([parameter-list]) ':' [return-result] [{properties}]


Visibility
private(-) Only objects of the same class may call a private operation.
package(~) Only objects owned by the same package may call a package-level operation
public(+) Any object may call a public operation

Name
The combination of the name, parametar list, and return result, often called the signature, must be unique within the class.

Properties
allows to add any additional information about the operation that does not fit into one of the other predefined elements. The property text describes the constraints on the performance of the operation.

Class-level operation
It refers to an operation that is accessible within the class rather than within an object of the class. Class-level operations are also referred to as static operations in some languages. Every object of the class may access the operation. Objects of other classes may access the operation without referring to an instance of the class.

Exceptions
One way to handle exceptions is to return a value to the calling object and let it interpret that value to decide how to respond to success or failure. The most common appreoach is to throw an exception.

Preconditions
Define the terms that the invoking object must meet before the operation is obligated to perform its behavior.

Postconditions
specifies something that must be true after the behavior finishs.

Objects Oriented Concepts

Object
An Object can be a physical entity. An Object may also be intangible, such as a job or class attendance. Each object defines three basic types of information and two types of behavior.

Information
- Its unique Identity
- How to describe itself
- Its current condition, or state.
Behavior
- Wht it can do
- wht can be done to it.

Class
A class is the rules that define the object.

Interface
The Interface is how you communicate to the object and access some of the object's knowledge.

In UML terms, the interface is an opeation, implementation is called the method.

A link is a relationship between two objects.
An association is a relationship between two classes.
A link is an instance of an association.

Associations and links take on three different forms, association, aggregation, and composition.

Association - is a peer-to-peer relationship. One object simply knows about another object. That knowledge is typically stored in the object as a reference. An association is most commonly modeled as a named line between two classes.

Aggregation - Associations can be refined to model a more restrictive type of relationship.

Composition - Aggregation may also be refined to model an even more restrictive relationship called composition.


Defining aggregation
Is a special type of association used to indicate that the participating objects are not just independent objects that know about each other.

To model aggregation on a Class diagram

1. Draw an association (a line) between the class that represents the member or part of the assembly and the class that represents aggregation, the assembly.
2. Draw a hollow diamond on the end of the association that is attached to the aggregate class.

Defining Composition
Composition is used for aggregations in which the life span of the part depends on the life span pf the aggregate object.
The aggregate has control over the creation and destruction of the part.
The member object cannot exist apart from the assembly.

1.Draw this stronger form of aggregation simply by making the aggregation diamond solid (black).

In database applications this type of relationship is reflected in "cascading deletions". When the master record is deleted , then all the related records are deleted. ex Order-Details.


Generalization
Creating a generalization is the process of organizing the features of different types of objects that share the same pupose. ex. Employees of different types Manager, clecks, peons.

A generalization is a description of the features shared by a set of objects.

Super class is a class that contains features that are common to two or more types of objects that share the same purpose.

Sub class is a class that contains some combination of fatures that are unique to a type of objects that is partially defined by a super class.

Abstract class is a class that lacks a complete definition.It do not have methods. Abstract classes must have subclasses that provide mothods have for any unimplemented operations.

Concrete class is a class that has a method for every operation so that it can create objects.

Discriminator is an attribute or rule that describes how you choose the set of subclasses for a superclass.


There are at least five objective criteria we can use to discriminate between objects within the same class

-Attribute type
-Attribute values allowed
-Operation(interface)
-Method(implementation)
-Associations

Defining Polymorphism

Is the ability to dynamically choose the method for an operation at runtime, depending on the type of object responding to the request. A polymorphic operation has a different method in each classs in which it is implemented.

Interface
An interface may only declae operation signatures-the operation details that tell other objects how to invoke the behavior. This typically consits of the name, parametrs, and result.
An interface class is an abstract class with no methods at all.

Cohesion
Cohesion is a measure of hoe well the parts of an object support the same purpose.
High Cohesion means that an object has one well-defined purpose and everything in the object contributes directly to that purpose.

Coupling
Coupling is a measure of the degree of dependency between objects.
Loose coupling means that an object is pretty much free to do its job without a lot of interaction with other objects.

Extensibility mechanism

Refer to stereotypes, tagged values, and costraints.
It provide the ability to customize UML diagrams.

Stereotypes - identify a set of qualities that may appear on a number of diagram elements.
Tagged values - allow you to add new features to an element of the diagram
Constraints - define rules to protect the integrity of a diagram element.

Stereotypes
Certain stereotypes are predefined (Standard elements) in the UML. others may be user defined.

eg. «user interface» or «controller».

Tagged Values
The explicit definition of a property as a name-value pair. The name is referred to as the tag.
Certain tags are predefined.
The purpose of a tagged value is to assign a feature to a model element in addition to those features to model element in addition to those featurs already defined in the metamodel.

eg. author="Tom", project_phase=2

Constraints
Defines a Semantic condition or restriction. some are predefined.

eg. {up to 50 alpha characters, including spaces and punctuation but no special characters}.

Comments
It attach freeform text to any element in the model.
Comments may be attached to individual attributes, operations, associations, messages, objects, anything in a UML model.

Comments are enclosed in a box with a "folder" top right corner.

Profiles
A profile is a means to customize the use of UML for a specific domain or platform.
Profiles use a combination of extension mechanisms to tailor UML notation.

UML Diagrams 2.0

Model Management diagrams

Include Packages, which are used to represent Subsystems, Models, and more.
A package is the UML equivalent of a directory or folder.
It is a place to store diagrams.
when packages are combined in a diagram, it is expressly to model the relationships between the packages.

dependency - a specific type of relationships. It means that one element needs help from another element.
The help may be functionality or data provided by another element.


Structural diagrams

Includes the Class diagram, Object diagram, Composite Structural diagram, Component diagram, Deployment diagram, and the Combined Component and Deployment diagram.

Illustrates the static features of a model.

A Class defines the behaviors that type of object can provide.
An association defines the type of relationships that objects can participate in.
A Deployment diagram models pieces of h/w (and people) that can perform work.
Components define pieces of s/w and procedures that need to be deployed to processors.

Class diagram
Is at the heart of the object modeling process.
It models the definitions of resources essential to the proper operation of the system.
Class diagram models the resources used to build and operate the system.
Resources represent people , materials, information, and behaviors.
A class diagram represented by 3 predefined compartments: name, attribute, and operations.

Class diagram models resources and relationships between resources.

Object diagram
models facts or examples.
It is useful for modeling test cases to see whether the Class diagram is correct and complete.

Composite Structure diagram
It visually represent the parts of a class, component, or collaboration, including the interation points(called ports) used to access features of the structure.
Reveals the design of a complex component.
It also model collaborations.

collaboration - describes a behavior, the resources used to perform the behavior, and the roles the participating resources assume during the behavior.

Component diagram
It represents real software in the implementation environment.
They reveal software configuration issues throught the dependency relashionships.

It models the implementation view.

Deployment diagram
Models the hardware of the implementation environment.
Each node on a Deployment diagram typically represents one type of h/w.
A node may also represent a human being or organizational unit, the function that a function can perform. Nodes are classes in that respect.

Combined Component/Deployment diagram
It shows the components installed on nodes.



Behavioral Diagram
It describe how the resources modeled in the Structural diagrams interact and how they each execute their capabilities.
Includes Use Case diagram, Activity diagram, Interaction diagrams, State machine diagram and Protocol State Machine diagram.

Use Case diagram
Models user's expectation for using the system.
The people and systems that interact with the target system are called actors.

Activity diagram
It models logic-any logic-from workflow to use cases to methods.
It represent the logic required to implement system behaviors.


Interaction diagrams

It includes the Sequence, Communication, Interaction Overview, and Timing diagrams.

Sequence diagram
Identifying interactions between objects over time. ie the messages exchanged between objects.
An interface is an operation signature on the class to which the receiving object belongs.

Communication diagram
They identify the objects that participate in an interaction.

Interaction Overview diagram
model the flow of logic in a series of interactions.
Block of interactions called Interaction Occurances

Timing diagram
provides a view of state changed that emphasizes the importance of time and timing.

State Machime diagram
Represents a single object.
The diagram shows how external stimuli cause changes in the object over its lifetime.

Protocol State Machine diagram
show only the transactions that trigger the state changes.
The State Machine defines what is possible while an event causes a change.
The Protocol State Machine defines what is legal.

Language Architecture UML 2.0

The design principles include

1. Modularity/partitioning - Maximize reuse, isolated, small, well-defined.
2. Layaring - The packages in each layer may also separate model elements to define levels of abstraction within the layer.
3. Extensibility - 2 type of extension, One type uses profiles, Second specialized to create a new lanuage like UML.

UML 2.0 is comprised of two libraries,

1. Infrastructure
   Defines the core metamodel used to define the MOF, UML, CWM and profiles.
2. Superstructure.
   It extends and customizes the infrastructure to define the UML metamodel.
   Defines the elements to make up the modeling notations of the UML.
   These elements created by extending and adding to the basic elements defined in the infrastructure.

Infrastructure library
contains 2 packages

1. Core package
2. Profiles packages

Core package

Provides the foundation on which to build the MOF, UML, CWM, profiles and future languages.
The common metamodel makes possible model interchange via XML Model Interchange(XMI).
Each of the four packages, UML, CWM, MOF and profiles, need help from Core package. They depend on the contents of the Core in order to complete their own sets of definitions.

The Core package contains three other packages, all depend on the data types defined in the PrimitiveTypes package

1. Abstractions
2. Basic
3. Constructs
   

The primitive Types package defines a small set of data types that are userd to specify the core metamodel. The 3 types are Integer, Boolean, and String.

Abstractions package - defines the common concepts needed to build modeling abstract elements such as classifiers, behavioral elements, comments, generalizations, and visibilities.
Basic package - defines the common characteristics of classifiers, classes, data types, and packages.
Constructs package - refines contents of the Abstractions and Basic packages, merging and refining abstract concepts to create a set of common modeling elements. They are implementable concepts with package names like Classes, Attributes, Associations, and Packages.

Profiles package

The Profiles package contains mechanisms to adapt existing metaclasses to a specific subject or platform.

Superstructure(or UML)
defines all the diagramming elements of the UML.
The 3 categories are

1. Structure section defines Class, Object, Composite Structure, Component, Deployment, and Package diagrams.
2. Behavioral section defines Sequence, Interaction Overview, Timing, Communication, and State Machine diagrams, as well as Action Semantics.
3. Supplimental section defines auxilary concepts likw information flows and class templates, and profiles as defined within the UML.

New diagrams added in UML 2.0

• replaced the Collabration diagram with a more limited Communication diagram.
• added new 2 interaction diagrams: the interaction Overview diagram the Timing diagram.
• added the Protocol State Machine.
• added the Composite Structure diagram
• isolated the Activity diagram with its own semantics separate from the State Machine.
  

Diagrams in UML 1.4

defines 9 diagrams

Static/Structural view
models resources used in the construction of the system

1. Class diagram - define resources in terms of their allowed features and relationships.
2. Object diagram - model facts or examples about resources.
3. Component diagram - models the physical pieces of software in a system, including applications, files, user interfaces.
4. Deployment diagram - models the hardware environment, namely processors where components may run.

Dynamic view
includes diagrams that model the behavior of objects in terms of interactions.
Models objects passing messages back and fourth to accomplish a task.

1. Sequence diagram
2. Collaboration diagram
3. Statechart diagram - tracks the changes in an object's state and the reasons for the changes.

Functional view
Drives the requirements for applications.

1. Use Case diagram - models what the users expect to see when they interact with system.
2. Activity diagram - Workflow, use cases, collabrations, and operations all involve logic and may be represented in an Activity diagram.

Language Architecture UML 1.4

Consists of 3 top-level packages and additional specifications for Action Semantics and the Object Constraint Language.

Behavioral Elements
Model Management Packages
Foundation package

Behavioral Elements and Model management packages depends on Foundation package.


Foundation package.

It providing model elements that are required throughout the metamodel.
3 sub-packages

Core elements.
Extension mechanisms.
Data types.

All of the diagram elements in UML derive their basic features from the elements defined in these 3 packages.


Core Package

It contain some classes that cannot be instantiated is called abstract. eg. ModelElement, GeneralizableElement, Classifier.

A class that can be instantiated is called concrete. eg. Core concrete classes include Class, Property, Association.
Other concrete classes include Instance, Operation, Link etc.

1. ModelElement
   It is the definition from which all other modeling metaclasses derive.
   It may have constraints, may be derived, may be stereotyped.
2. GeneralizableElement
   GeneralizableElement contains the features that all the specialized elements have in common. This concept makes it possible to construct a hierachy of elements.
3. Classifier
   Describes a named element with features.
   A classifier is itself a namespace. It can contain other, nested classifiers.
   A classifier declares a collection of features, both structureal and behavioral, like attributes and operations.

Extension Machanisms packages

Provides a means to tailor the use and appearence of existing elements for specific application domains or technologies.

Data Types package

The Data Type package defines a common set of valid data types and enumerations for use in defining the metamodel.

Behavioral Elements packages

Represent how the system works in terms of controlling actions and interactions between elements.
It using different diagrams

collabration diagram.
Use Case diagram.
State Machine.
Activity Graph.

1. collabrations
   Models standard patterns of interactions that appear through the system design.
   Explain how classifiers work together to perform an operation or an interaction between elements.
   Includes 2 key concepts
   
   • The Structure of the participating elements
   • Pattern of messages exchanged between the elements.
   
   
2. Use case diagram - models user interactions with the system.
   
   
3. State machines - models the object lifecycles.
   A State Machine reveals that two key elements are needed to understand and manage the life of the object
   
   • the events that trigger the changes
   • the beheviors that accompany the events and actually make the changes.
   
   
4. Activity graphs - models logic sequence.it is basically old flowchart.
   

Model Management Package

Views of physical system are called models.

Object Constraint Language

Provides the semantics for declaring static requirements for attributes and operations.
eg. a phone number must never be violatedduring the life of the system.

pre-condition - Constraints on an operation define wht must be true in order to invoke the operation.
post-condition - wht must be true when operaton is completed.

Action Semantics

Define the rules that govern the dynamic aspects of a system.
An action is a class that defines a behaviour.
eg. the instance of CreateObjectACtion defines how to create an object.
Actions can be used to define method implementations.

UML Architecture

Unified Modeling Language.

• UML Designed specifically to represent Object-oriented Systems.
• It is visual modeling language.
• It support higher-level development concepts - components, collaborations, frameworks and patterns.

Scope - define everything-modeling, development methodology, project management, systems integration.

Note: UML renamed the flowchart to Activity diagram.

OMG - (Object management Group) is the official steward of the UML standard.

MDA - (Model-Driven Architecture) creates a standard for the creation of implementation-independent models

UML use the MDA approach. MDA separates the business logic and implementation mechanism.

MOF - (Meta-Object Facility) is at the heart of the MDA strategy. It defines the languages used to describe systems and MDA itself. That defines the concepts used to build models.


UML Architecture.
The Four-Layer Metamodel Architecture

The Meta-Model layer defines what a Class is. It also defines an Association.
A Model element is an instance of a metamodel element.