Download presentation
Presentation is loading. Please wait.
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
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.