1. Unit II
Static Modelling

2. Introduction to software design, design methods- procedural / structural and object oriented, Requirement Vs Analysis Vs Architecture Vs Design Vs Development 4+1 Architecture, case study of transferring requirement to design, UP, COMET use case based software life cycle, Introduction to UML -Basic building blocks, Reusability, Use case modeling, Use case template
Case study – Transferring requirements into design using advanced tool

3. Introduction to software Design
Design Methods: Procedural and Structural Design methods,Object Oriented design method,
Unfied modeling
Language overview, Static and Dynamic Modeling
Advance Use case, Class,State,Sequence Diagrams

4. Class Diagrams
Gives an overview of a system by showing its classes and the relationships among them.
Class diagrams are static
they display what interacts but not what happens when they do interact
Also shows attributes and operations of each class
Good way to describe the overall architecture of system components

5. Class Diagram Perspectives
We draw Class Diagrams under three perspectives
Conceptual
Software independent
Language independent
Specification
Focus on the interfaces of the software
Implementation
Focus on the implementation of the software

6. Classes – Not Just for Code
Table zone2price
Enumeration getZones()
Price getPrice(Zone)
TariffSchedule
Name
zone2price
getZones()
getPrice()
TariffSchedule
Attributes
Signature
Operations
TariffSchedule
A class represent a concept
A class encapsulates state (attributes) and behavior (operations).
Each attribute has a type.
Each operation has a signature.
The class name is the only mandatory information.

7. Class diagrams are one of the most fundamental diagram types in UML
Class diagrams are one of the most fundamental diagram types in UML. They are used to capture the static relationships of your software. in other words, how things are put together.

8. When writing software you are constantly making design decisions.
What classes hold references to other classes, which class "owns" some other class, and so on. Class diagrams provide a way to capture this "physical" structure of a system.

9. UML suggests that the class name:
Start with a capital letter
Be centered in the top compartment
Be written in a boldface font
Be written in italics if the class is abstract (see "Abstract Classes")

10. Simple class representation

11. An instance of Car
Figure shows an instance of a class Car named Toyota. Note that in this figure, we have hidden the empty compartments.

12. Attributes
Details of a class (the color of a car, the number of sides in a shape, etc.) are represented as attributes . Attributes can be simple primitive types (integers, floating-point numbers, etc.) or relationships to other, complex objects (see "Relationships").
An attribute can be shown using two different notations: Inlined or relationships between classes. In addition, notation is available to show such things as multiplicity, uniqueness, and ordering.

13. Inline Attribute
To represent an attribute within the body of a class, place the attribute in the second compartment of the class.
UML refers to Inline attributes as attribute notation . Inlined attributes use the following notation:
visibility / name : type multiplicity = default
{property strings and constraints }
visibility ::= {+|-|#|~}
multiplicity ::= [lower..upper]

14. visibility
Indicates the visibility of the attribute. Use the following symbols: +, -, #, or ~ for
public, private, protected, or package, respectively . /
Indicates the attribute is derived . A derived attribute is simply one that can be
computed from other attributes of the class.
name
Is a noun or short phrase naming the attribute. Typically the first letter is lowercase, and the first letter of each subsequent word is capitalized.
type
Is the type of the attribute as another classifier, typically a class, interface, or built-in type like int.
multiplicity

15. Specifies how many instances of the attribute's type are referenced by this attribute. Can be absent (meaning multiplicity of 1), a single integer, or a range of values specified between square brackets separated by "..". Use * as the upper bound to represent the upper limit or * on its own to mean zero or more. See "Multiplicity."
Default
Is the default value of the attribute.
property strings
Is a collection of properties, or tags, that can be attached to attributes. These are
typically context-specific and denote such things as ordering or uniqueness. They are surrounded by {} and separated by commas.
constraints
Are one or more restrictions placed on an attribute. They may be natural language or use a formal grammar such as the OCL. See "Constraints."

17. Attribute using relationship notation

18. Derived Attribute
The derived notation, which is the leading forward slash (/), can be used as an indicator to the implementer that the attribute may not be strictly necessary. For example, let's say you
modeled a bank account with a simple class named Account. This class stores the current
balance as a floating-point number named balance. To keep track of whether this account is
overdrawn, you add a boolean named overdrawn. Whether the account is overdrawn is really
based on whether the balance is positive, not the boolean you added. You can indicate this to
the developer by showing that overdrawn is a derived attribute, with its state based on
balance.

19. Attribute Multiplicity
Multiplicity examples

20. Ordering
An attribute with a multiplicity greater than 1 can be specified to be ordered . If the attribute
is ordered, the elements must be stored sequentially.

21. Uniqueness
In addition to being ordered, an attribute with multiplicity greater than 1 may be required to
be unique . If an attribute is required to be unique, each element of this attribute must be
unique. By default, attributes with multiplicity greater than 1 are unique , meaning there can
be no duplicates in the elements this attribute holds.

22. Attribute Properties
In addition to the properties associated with multiplicity, an attribute may have a number of properties set to convey additional information to the reader of the diagram. The common properties defined by UML are:
1) readOnly
Specifies that the attribute may not be modified once the initial value is set.
2) Union
Specifies that the attribute type is a union of the possible values for this attribute
3) subsets <attribute-name>
Specifies that this attribute type is a subset of all the valid values for the given
attribute.
4) redefines <attribute-name>
Specifies that this attribute acts as an alias for the given attribute.

23. Constraints
Constraints represent restrictions placed on an element. They may be natural language or use a formal grammar such as the OCL; however, they must evaluate to a boolean expression.
You typically show constraints between curly braces ({}) after the element they restrict, though they may be placed in a note and linked to the element using a dashed line.
You can name a constraint by specifying the name followed by a colon (:) before the boolean expression. This is frequently used to identify constraints on an operation.

25. Operations
Operations are features of classes that specify how to invoke a particular behavior. For example, a class may offer an operation to draw a rectangle on the screen or count the number of items selected in a list. UML makes a clear distinction between the specification of how to invoke a behavior
You place operations in a separate compartment with the following syntax
visibility name ( parameters ) : return-type {properties}
where parameters are written as:
direction parameter_name : type [ multiplicity ]= default_value { properties }

26. Example operations on a class

27. Visibility: Indicates the visibility of the operation
Visibility: Indicates the visibility of the operation. Use the following symbols: +, -, #, or ~ for public, private, protected, or package, respectively
Name:
Is a short phrase naming the operation
return-type:Is the type of information the operation will return, if any.
Properties:
Specifies contrains and properties associated with the system .these are optional .
parameter_name :
Is a noun or noun phrase naming the parameter. Typically the parameter name starts with a lowercase letter, with any subsequent words starting with a capital letter.

28. Type:
This is typically another class, interface, collection, or primitive type.
Multiplicity :
Specifies how many instances of the parameter's type are present

29. default_value:Specifies the default value of this parameter
Properties:
Specifies any parameter-related properties and is specified between curly braces.

30. Operation Constraints
An operation may have several constraints associated with it that help define how the operation interacts with the rest of the system. Together, constraints on an operation establish a contract that an implementation of the operation must obey.
Constraints on an operation follow the usual constraint notation
1)Precondition
2) Postcondition
3)Body Condition
4) Query operations
5) Exceptions

31. Precondition
An optional condition specifying the assumptions about the state of the system before the operation begins execution.

32. Postcondition
An optional condition specifying a relationship between the state of the system before and after the operation's execution.

33. Post conditions

34. Body condition Body conditions for operations
An operation may have a bodyCondition that constrains the return value. The bodyCondition is separate from the post condition because the bodyCondition may be replaced by methods of subclasses of the owning class.
Body conditions for operations

35. Query operations Example query operations
An operation may be declared as a query operation if the implementation of the operation doesn't modify the owning class in any way. In practice, modelers often use the query property to indicate a method that doesn't change any meaningful attribute of an object

36. Exceptions

37. Static Operations
Operations typically specify behavior for an instance of a class You indicate an operation is static by underlining the operation signature

38. Abstract Classes
An abstract class is typically a class that provides an operation signature, but no implementation.
You show a class is abstract by writing its name in italics.

39. Relationships Dependency Association Navigability
Naming an association
Multiplicity
Aggregation
Composition
Generalization
Association Classes
Association Qualifiers

40. Dependency
The weakest relationship between classes is a dependency relationship. Dependency between classes means that one class uses, or has knowledge of, another class.
Dependencies are typically read as "...uses a...".
Window's dependency on WindowClosingEvent
"Window uses a WindowClosingEvent."

41. Association
Associations are stronger than dependencies and typically indicate that one class retains a relationship to another class over an extended period of time.
Associations are typically read as "...has a...".

42. Navigability
Shows an association between a class named Window and a class named cursor. Because you can't navigate from an instance of Cursor to an instance of Window,

43. Naming an association
It is common to include a short phrase along with the arrowhead to provide some
context for the association. The phrase used with the association doesn't typically generate
into any form of code representation; it is purely for modeling purposes

44. Naming an association

45. Multiplicity
you can express how many instances of a particular class are involved in a relationship. If you don't specify a value, a multiplicity of 1 is assumed. To show a different value, simply place the multiplicity specification near the owned class.

46. Aggregation
Aggregation is a stronger version of association. Unlike association, aggregation typically implies ownership and may imply a relationship between lifelines. Aggregations are usually
read as "...owns a...".
Window "owns a" Rectangle
For example, if you had a classed named Window that stored its position and size in a Rectangle class, you would say the "Window owns a Rectangle."

47. Composition
Composition represents a very strong relationship between classes, to the point of containment. Composition is used to capture a whole-part relationship. The "part" piece of the relationship can be involved in only one composition relationship at any given time.
The lifetime of instances involved in composition relationships is almost always linked;
A composition relationship is usually read as "...is part of...",
For example, if you say that a window in your system must have a titlebar, you can represent this with a class named Titlebar that "...is
part of..." a class named Window.

48. Generalization
A generalization relationship conveys that the target of the relationship is a general, or less specific, version of the source class or interface.
Generalization relationships are often used to pull out commonality between difference classifiers.
Generalizations are usually read as "...is a...", starting from the more specific class and reading toward the general class.
Cat...is a...Animal" (grammar aside).

49. Association Classes
Often the relationship between two elements isn't a simple structural connection. For example, a football player may be associated with a league by virtue of being on a team. If the association between two elements is complex, you can represent the connection using an association class . An association class is an association that has a name and attributes, like a normal class.

50. Association Qualifiers
Relationships between elements are often keyed, or indexed, by some other value.
A qualifier is typically an attribute of the target element, though this isn't required. You show a qualifier by placing a small rectangle between the association and the source element.
Draw the name of the qualifier (usually the name of an attribute) in the rectangle.
For example. a tax payer by his Social Security number

51. Interfaces
An interface is a classifier that has declarations of properties and methods but no implementations. You can use interfaces to group common elements between classifiers and provide a contract a classifier that provides an implementation of an interface must obey
There are two representations for an interface; which one you should use depends on what you're trying to show. The first representation is the standard UML classifier notation with the
stereotype «interface». Figure shows the Sortable interface.

52. The second representation of an interface is the ball-and-socket notation. This representation shows less detail for the interface but is more convenient for showing relationships to classes.
The interface is simply shown as a ball with the name of the interface written below it.
Classes dependent on this interface are shown attached to a socket matching the interface. Figure
shows the Sortable interface using the ball-and-socket notation.

54. Templates
Just as interfaces allow you to provide specifications for objects your class will interact with,
UML allows you to provide abstractions for the type of class your class may interact with. For
example, you can write a List class that can hold any type of object (in C++ this would
probably be a void*, in Java and C# it would probably be an Object)

55. Association class
Example

56. Qualified Association
A qualified association is an association in which an attribute called Qualifier disambiguates the objects for a ‘many’ association’ end.
A qualifier selects among the target objects, reducing the effective multiplicity fro ‘many’ to ‘one’.
Both below models are acceptable but the qualified model adds information.

57. Qualified Association
Example:

58. Generalization/Inheritance
Generalization is the relationship between a class (superclass) and one or more variations of the class (subclasses).
Generalization organizes classes by their similarities and their differences, structuring the descriptions of objects.
A superclass holds common attributes, attributes and associations.
The subclasses adds specific attributes, operations, and associations. They inherit the features of their superclass.
Often Generalization is called a “IS A” relationship
Simple generalization organizes classes into a hierarchy.
A subclass may override a superclass feature (attribute default values, operation) by redefining a feature with the same name.
Never override the signature of methods.

60. Use of generalization Used for three purposes:
Support of polymorphism:
polymorphism increases the flexibility of software.
Adding a new subclass and automatically inheriting superclass behavior.
Structuring the description of objects:
Forming a taxonomy (classification), organizing objects according to their similarities. It is much more profound than modeling each class individually and in isolation of other similar classes.
Enabling code reuse:
Reuse is more productive than repeatedly writing code from scratch.

61. Aggregation
Aggregation is a strong form of association in which an aggregate object is made of constituent parts.
The aggregate is semantically an extended object that is treated as a UNIT in many operations, although physically it is made of several lesser objects.
Aggregation is a transitive relation:
if A is a part od B and B is a part of C then A is also a part of C
Aggregation is an antisymmetric relation:
If A is a part of B then B is not a part of A.

63. Aggregation versus Association
Aggregation is a special form of association, not an independent concept.
Aggregation adds semantic connotations:
If two objects are tightly bound by a part-whole relation it is an aggregation.
If the two objects are usually considered as independent, even though they may often be linked, it is an association. ِ
Discovering aggregation
Would you use the phrase part of ?
Do some operations on the whole automatically apply to its parts?
Do some attributes values propagates from the whole to all or some parts?
Is there an asymmetry to the association, where one class is subordinate to the other?

64. Aggregation versus Composition
Composition is a form of aggregation with additional constraints:
A constituent part can belong to at most one assembly (whole).
it has a coincident lifetime with the assembly.
Deletion of an assembly object triggers automatically a deletion of all constituent objects via composition.
Composition implies ownership of the parts by the whole.
Parts cannot be shared by different wholes.

66. Propagation of operations
Propagation is the automatic application of an operation to a network of objects when the operation is applied to some starting object.
Propagation of operations to parts is often a good indicator of propagation.

67. Aggregation
Aggregation is an association with a “collection-member” relationship
Hollow diamond on
the Collection side
No sole ownership implied
void doSomething() aModule.service();

68. Composition Composition is Aggregation with:
Lifetime Control (owner controls construction, destruction)
Part object may belong to only one whole object
members[0] = new Employee(); …
delete members[0];
Filled diamond on side of the Collection

69. Inheritance Standard concept of inheritance Base Class Derived Class
class B() extends A …

70. UML Multiplicities
Links on associations to specify more details about the relationship
Multiplicities
Meaning
0..1
zero or one instance. The notation n . . m indicates n to m instances.
0..*  or  *
no limit on the number of instances (including none). 1
exactly one instance
1..*
at least one instance

71. UML Class Example

72. Association Details
Can assign names to the ends of the association to give further information +
getName
() :
string
setName () -
calcInternalStuff (
in x :
byte ,
in y
decimal )
Name ID
long #
Salary
double
adfaf
bool
Employee
members
Team
group 1
individual *

73. Static vs. Dynamic Design
Static design describes code structure and object relations
Class relations
Objects at design time
Doesn’t change
Dynamic design shows communication between objects
Similarity to class relations
Can follow sequences of events
May change depending upon execution scenario
Called Object Diagrams

74. Object Diagrams Shows instances of Class Diagrams and links among them
An object diagram is a snapshot of the objects in a system
At a point in time
With a selected focus
Interactions – Sequence diagram
Message passing – Collaboration diagram
Operation – Deployment diagram

75. Object Diagrams Format is Instance name : Class name
Attributes and Values
Example:

76. Objects and Links
Can add association type and also message type

77. Package Diagrams
To organize complex class diagrams, you can group classes into packages. A package is a collection of logically related UML elements
Notation
Packages appear as rectangles with small tabs at the top.
The package name is on the tab or inside the rectangle.
The dotted arrows are dependencies. One package depends on another if changes in the other could possibly force changes in the first.
Packages are the basic grouping construct with which you may organize UML models to increase their readability

78. Package Example
DispatcherInterface
Notification
IncidentManagement

79. More Package Examples

80. State Transition Diagrams
Fancy version of a DFA
Shows the possible states of the object and the transitions that cause a change in state
i.e. how incoming calls change the state
Notation
States are rounded rectangles
Transitions are arrows from one state to another. Events or conditions that trigger transitions are written beside the arrows.
Initial and Final States indicated by circles as in the Activity Diagram
Final state terminates the action; may have multiple final states

81. State Representation
The set of properties and values describing the object in a well defined instant are characterized by
Name
Activities (executed inside the state)
Do/ activity
Actions (executed at state entry or exit)
Entry/ action
Exit/ action
Actions executed due to an event
Event [Condition] / Action ^Send Event

82. Notation for States

83. Simple Transition Example

84. More Simple State Examples

85. State Transition Example
Validating PIN/SSN

86. State Charts – Local Variables
State Diagrams can also store their own local variables, do processing on them
Library example counting books checked out and returned

87. Example:
Draw state machine diagram for Coffee vending machine
Draw state machine diagram for elevator

88. Component Diagrams
Shows various components in a system and their dependencies, interfaces
Explains the structure of a system
Usually a physical collection of classes
Similar to a Package Diagram in that both are used to group elements into logical structures
With Component Diagrams all of the model elements are private with a public interface whereas Package diagrams only display public items.

89. Component Diagram Notation
Components are shown as rectangles with two tabs at the upper left
Dashed arrows indicate dependencies
Circle and solid line indicates an interface to the component

90. Component Example - Interfaces
Restaurant ordering system
Define interfaces first – comes from Class Diagrams

91. Component Example - Components
Graphical depiction of components

92. Component Example - Linking
Linking components with dependencies

93. Deployment Diagrams
Shows the physical architecture of the hardware and software of the deployed system
Nodes
Typically contain components or packages
Usually some kind of computational unit; e.g. machine or device (physical or logical)
Physical relationships among software and hardware in a delivered systems
Explains how a system interacts with the external environment

94. Some Deployment Examples

95. Deployment Example
Often the Component Diagram is combined with the Deployment

96. Package Diagram

97. Package diagrams provide a great way to visualize dependencies between parts of your system and are often used to look for prob example, if you had a class named Timer in a package named Utilities, the fully qualified name for the class is Utilities::Timer. Elements in the same package can refer to each other without qualifying their names.

98. Packages provide a way to group related UML elements and scope their names. For example, you can put all elements having to do with 3D rendering into a package named 3DGraphics.
Package diagrams provide a great way to visualize dependencies between parts of your system and are often used to look for problems or determine compilation order. Nearly all UML elements can be grouped into packages, including packages themselves. Each package has a name that scopes each element in the package

99. Representation
You show a package using a rectangle with a tab attached to the top left. Figure shows
the Utilities package

100. Several classes contained inside the Utilities package

101. Several classes contained inside the Utilities package
Elements owned by a package, shown outside of the
package

102. The second representation uses a solid line pointing from the package to each contained element. You place a circle with a plus sign in it at the end nearest the package to indicate containment.
If you use this representation, you should show the name of the package in the large rectangle rather than in the tab. This notation allows you to show more detail of the packaged elements

103. Visibility
A package may specify visibility information for owned and imported elements, however elements may have only one of two levels of visibility: public or private. Public visibility means the element may be used outside the package (scoped by the package name). Private visibility means the element may be used only by other elements of the same package.
Private visibility is useful for marking utility classes that help implement a subsystem or component you don't want to expose to the rest of the system.
You show public visibility by placing a plus sign before the element name. You show private visibility using a minus sign.

105. Importing and Accessing Packages
When accessing elements in one package from a different package, you must qualify the name of the element you are accessing.

106. To show a package import, you draw a dashed line with an open arrow from the importing package to the imported package. Label this line with the «import» keyword. Figure shows the RoutePlanning package importing the transportation package.
Fig Route Planning importing the Transportation package

107. To specify that imported elements should have private visibility, you use the «access» keyword rather than the «import» keyword. Figure shows the RoutePlanning package importing the TRansportation package and accessing the Algorithms package. If a package imports the RoutePlanning package, both packages can use public elements from
TRansportation, but they can't use anything in Algorithms.
Figure RoutePlanning importing the Transportation package but
accessing only the Algorithms

109. What package import and access actually mean in implementation can vary dramatically depending on your target language. For example, C# and Java have an explicit concept of packages and importing elements from packages. Java developers often import the java.util package into their program so they can reference the Java Vector class without qualifying it.
However, C++ has a somewhat subtler concept of packages, called namespaces. How packages map to an implementation language is often up to the implementer.

110. Merging Packages
You show package merging using a dashed line with an open arrow from the merging package to the merged package. Label this line with the keyword «merge». Figure shows an example of merging two packages
figure ProtocolStateMachines merging the elements from BehavioralStateMachines so it can add to the contained classes

111. The rules for package merge are:
Private members of a package aren't merged with anything.
Classes in the package performing the merge that have the same name and type as classes in the merged package(s) get a generalization relationship to the merged class(es). Note that this can result in multiple inheritance, but UML allows this.
You can still reference any of the original classes by explicitly scoping the class using the original package name.
Classes that exist only in the merged package or the merging package remain unchanged and are added to the merging package.
Subpackages within the merged package are added to the merging package if they don't already exist.

112. If a sub package with the same name already exists in the merging package, another merge is started between the two sub packages.
Any package imports from the merged package become package imports from the merging package. Elements that are imported aren't merged (i.e., aren't given generalization relationships). If an imported element conflicts with an element in the merging package, the merging package's element takes precedence and the imported element must be explicitly qualified.

113. Variations on Package Diagrams
Structuring a Project with Package Diagram
For example, a project manager might draw a package diagram for a web application such as that shown in Figure

114. Top-level packages defining a web application

115. Use case packages
Use case packages organize the functional behavior of a system during analysis. Figure shows the major functional areas of a content management system. The packages provide understandable terms for team members outside the analyst team.
Managers can discuss the project at an appropriate level of detail without getting bogged down in details. The CMS system shown in Figure comprises packages created for the following reasons:
The complex editing packages separate the preliminary delivery and the advanced delivery from the client-based delivery.
The simple interactions, view and feedback, contain basic, low-risk functions. The reporting has more sophisticated functions.
The search and the user management separate complex functions.

116. Use case packages

117. Direct dependence graph
Directed dependency graphs of the packages in a system reveal nonfunctional issues related
to buildability, testability, and robustness; they provide a guide for several roles in software
development.

118. When all the dependencies flow in one direction, as in Figure 3-10, without any loops or cycles, the graph is acyclic . Acyclic graphs show a project in good health.
Directed dependency graphs can help you avoid problems with build scripts and project testing. Looking at Figure 3-10, you can see that refactoring timer will invalidate testing and potentially break the build of visualizers, threads, controllers, and top; you should thus change the timer package with caution.
Directed dependency graphs can also help you divide project work among different staff members. For example, Figure 3-10 shows no dependencies between threads and visualizers. Thus, different groups of people can work on those two packages without destabilizing each other.

120. Through time, projects evolve, and new dependencies creep in because of misunderstanding
or expediency. Figure 3-11 shows such a case; three bidirectional dependencies ruin the desirable, acyclic nature of the graph: utils now depends on threads. threads now depends on controllers. samplers now depends on tHReads.
The problem here is that the reverse of each dependency already existed in Figure The
result is the tangle of bidirectional arrows in level 1 of Figure 3-11, which contrasts with the
clear flow of arrows in Figure The further result is pain, for the developers, testers, and
likely, managers and users. Changes in threads will confound the team responsible for
controllers and utils, and vice versa because fixes in one require fixes in the code or unit
tests of the others. It may take several iterations until all packages stabilize.[*]

121. Dependency graph of modified JMeter with three cycles