Static Modeling

 Static Modeling is modeling of the system not during

the run time.
 It is used to represent the static constituents of a
Software such as :
[Link],
[Link],
[Link] and
[Link] relationship with each other.
 This type of modeling is more structural than behavioral.
[Link] Diagram – These diagrams are used to represent
the static elements such as :
a. Classes
b. Attributes
c. Relationship between classes

[Link] Diagram – These diagrams are used to

represent the instance of the static elements.
 It also represent the properties of particular instance of
a class.
The purpose of the class diagram can be summarized as:

 Analysis and design of the static view of an application.

 Describe responsibilities of a system.

 Base for component and deployment diagrams.

 An analysis class represents an abstraction of one or several
classes and or subsystems in the system’s design
Characteristics
 Focus on handling functional requirements
 Define behavior as responsibility, not operations
 Define conceptual attributes from problem domain

Categories of analysis level classes

1. Boundary class
2. Control class
3. Entity class
1. Boundary classes
 Responsibility:
◦ Model interaction between the system and its actors
◦ Model the parts of the system that depend on its actors
◦ Clarify and collect the requirements on the system’s
boundaries
◦ Isolate user interfaces with the system’s internal
structure
 Each boundary class should be related to at least one
actor
2. Entity classes
 Responsibility
◦ Model information that is long-lived and often persistent
◦ Model information and associated behavior of some
phenomenon or concept (e.g. individual, real-life object, real-
life event)
 An entity object encapsulates its persistent data as
attributes and behaviors or operations to manipulate the
data.
[Link] classes
 Responsibility
o Model dynamics of the system, including coordination,
sequencing, transactions and control of other objects
o Encapsulate control related to a use case
o Represent business logic, complex derivation and calculations
 A control object coordinates the main actions and
control flow of a use case, and delegate work to other
(boundary, entity, as well as control) objects
 The set of design classes refine analysis classes and
providing design detail that enables classes to execute a
software infrastructure that supports business solutions.
 There are 5 different types of design classes
1. User interface classes define abstraction that mandatory
for human-computer interaction [HCI]. In cases, HCI
occurs within the context of metaphor, and design classes
for the interface may be visible representations of
elements of metaphor.
2. Business domain classes are often refinements of
analysis classes defined earlier. The class identifies the
attributes that are required to implement some elements
of the business domain.
[Link] classes implement lower-level business
Preoccupation need to manage business domain
classes.

[Link] classes represent the data stores that will

persist beyond the execution of software.

[Link] classes implement software management

and control function that permits the system to operate
and convey within its computing environment and with
the outside world
 RUP (Rational Unified Process) is a software
development process for object-oriented models. It is
also known as the Unified Process Model.
 It tells you step by step what you should do to develop
software
 It is created by Rational corporation and is designed
and documented using UML.
 This process is included in IBM Rational Method
Composer (RMC) product.
1. Inception
2. Elaboration
3. Construction
4. Transition
5. Production
1. Inception –
o Communication and planning are the main ones.

o Identifies the scope of the project using a use-case model

allowing managers to estimate costs and time required.
o Customers’ requirements are identified and then it becomes
easy to make a plan for the project.
o The project plan, Project goal, risks, use-case model, and
Project description, are made.
2. Elaboration –
o Planning and modeling are the main ones.

o A detailed evaluation and development plan is carried out and

diminishes the risks.
o Revise or redefine the use-case model (approx. 80%), business
case, and risks.
3. Construction –
◦ The project is developed and completed.
◦ System or source code is created and then testing is done.
◦ Coding takes place.
4. Transition –
◦ The final project is released to the public.
◦ Transit the project from development into production.
◦ Update project documentation.
◦ Beta testing is conducted.
5. Production –
◦ The final phase of the model.
◦ The project is maintained and updated accordingly.
Advantages:
o It provides good documentation, it completes the
process in itself.
o It provides risk-management support.
o It reuses the components, and hence total time duration
is less.
Disadvantages:
o Team of expert professional is required, as the process
is complex.
o Complex and not properly organized process.
o More dependency on risk management.
 Class responsibility collaborator provides a simple way to
identification and arrangement ( organization ) of class that
are relevant to system or product requirements.
 From the scenario, nouns should become classes, verbs
become responsibilities and collaborators are the other
cards with which the card will interact.
 A CRC model is really a collection of standard
index cards that represent classes. The cards are divided
into three sections.
o Along the top of the card you write the name of the class.
o In the body of the card you list the class responsibilities on
the left and the collaborators on the right.
 A class represents a collection of similar objects. An object is a
person, place, thing, event, or concept that is relevant to the
system at hand.
 The name of the class appears across the top of a CRC card
and is typically a singular noun or singular noun phrase
 Class names should also be simple
 A responsibility is anything that a class knows or does.
 These should be the high-level responsibilities.
 Collaboration takes one of two forms: A request for
information or a request to do something.
 Collaborator Another class that the current class has to
work with to complete its responsibilities
 Could be a class that has information we need
 Could be a class that helps perform a task
 Typically, we list a class as a collaborator if we (the
current class) need to call upon it to help complete our
own responsibilities
Finding Entity Objects
 Some things to look for. These may be candidates for objects,
or they may help identify objects:
◦ Terms that are domain-specific in use cases
◦ Recurring nouns
◦ Real-world entities and activities tracked by system
 Use good naming conventions.
Finding Boundary Objects
 Identify general user interface controls that initiate a use
case
 Identify forms or windows for entering data into a system
 Identify messages used by system to respond to a user
Finding Control Objects
 Control objects can help manage communication and
interaction of other objects. If a use case is complex and
involves many objects, create a control object to manage
the use case
 Identify one control object per actor involved in a use case

 Life span of control object should last through the use case
 Boundary Use Case
Actor Library System

Borrow Employee
Client

Order Title

Fine Remittance

Supervisor
 Actors: A role that a user plays with respect to the system, including human
users and other systems. e.g., inanimate physical objects (e.g. robot); an
external system that needs some information from the current system.

 Use case: A set of scenarios that describing an interaction between a user

and a system, including alternatives.

 System boundary: rectangle diagram representing the boundary between

the actors and the system.
 A class is a description of a set of objects that share the
same attributes, operations, relationships, and
semantics.
 Graphically, a class is rendered as a rectangle, usually
including its name, attributes, and operations in
separate, designated compartments.
 The instances of a class are called objects. ClassName

 Two different objects may have

attributes
identical attribute values

operations
 Modifiers are used to indicate visibility of attributes and
operations.
 ‘+’ is used to denote Public visibility (everyone)
 ‘#’ is used to denote Protected visibility (friends and derived)
 ‘-’ is used to denote Private visibility (no one)

 By default, attributes are hidden and operations are visible.

 Person

name : String
address : Address
birthdate : Date
ssn : Id

Operations describe the class behavior

eat
sleep and appear in the third compartment.
work
play

Software Design (UML)

 PhoneBook

newEntry (n : Name, a : Address, p : PhoneNumber, d : Description)

getPhone ( n : Name, a : Address) : PhoneNumber

You can specify an operation by stating its signature: listing the

name, type, and default value of all parameters, and, in the case of
functions, a return type.
 Class Diagrams show classes and their relationships
Relationships: connections between classes
 Types of UML relationships:
o Association
o Aggregation and Composition
o Generalization
o Dependency
o Realization } not useful for analysis
A dependency indicates a semantic relationship between two or
more elements. The dependency from CourseSchedule to
Course exists because Course is used in both the add and
remove operations of CourseSchedule.

CourseSchedule

Course

add(c : Course)
remove(c : Course)
 OO Relationships: Generalization
A generalization is a relationship between a parent class (superclass) and a child
class (subclass). In this, the child class is inherited from the parent class.

Supertype Example: Customer

Regular Loyalty
Customer Customer

Subtype1 Subtype2
-Inheritance is a required feature of object orientation
-Generalization expresses a parent/child relationship among related classes.
- Used for abstracting details in several layers
 Represent relationship between instances of classes
 Student enrolls in a course
 Courses have students
 Courses have exams
 Etc.

 Association has two ends

 Names
 Role names (e.g. enrolls)
 Multiplicity (e.g. One course can have many students)
 Navigability (unidirectional, bidirectional)
 student
1 *
University Person

0..1 *
employer teacher

Multiplicity
Role
Symbol Meaning
1 One and only one
Role
0..1 Zero or one
“A given university groups many people; some
M..N From M to N (natural language) act as students, others as teachers. A given
* From zero to any positive integer student belongs to a single university; a given
0..* From zero to any positive integer teacher may or may not be working for the
university at a particular time.”
1..* From one to any positive integer
 * 4
Student Course
has enrolls

Class Student {
Course enrolls[4];
}

Class Course {
Student have[];
}
 OO Relationships: Composition

Whole Class
Class W Association
Models the part–whole relationship

Class P1 Class P2
Composition
The composition is a subset of aggregation. It
portrays the dependency between the parent and its
Part Classes child, which means if one part is deleted, then the
Example other part also gets discarded. It represents a
whole-part relationship.
Example:
A number of different chess boards: Each square
belongs to only one board. If a chess board is
thrown away, all 64 squares on that board go as
well.
 Container Class
Class C
Aggregation:
 Expresses a relationship among
AGGREGATION
instances of related classes.
 An aggregation specifies a
Class E1 Class E2
whole-part relationship between
an aggregate (a whole) and a
Containee Classes constituent part, where the part
can exist independently from the
Example Bag
aggregate.
 Aggregations are denoted by a
hollow-diamond adornment on
Apples Milk the association.
Composition is really a strong form of Association
Components have only one owner
Components cannot exist independent of their owner
Components live or die with their owner
E.g. Each car has an engine that can not be shared with
other cars.

Aggregations
May form "part of" the association, but may not be essential to
it. They may also exist independent of the aggregate. E.G.
Apples may exist independent of the bag.
 In UML models, a constraint is an extension mechanism
that enables you to refine the semantics of a UML model
element.
 A constraint refines a model element by expressing a
condition or a restriction to which the model element must
conform.
 An example of a constraint is a condition such as an
attribute having a specific value.
 A constraint must be enforced in the design of a system.
 You specify the condition or restriction in the body of the
constraint.
 A constraint is displayed as text enclosed in braces ({}) and
appears in a rectangle with a folded upper-right corner.
You can write the body of a constraint in the following languages:
 Natural languages such as English ,Programming languages such as Java,
Mathematical notations, Object Constraint Language (OCL)
A class diagram describing the sales order system is given below.
 Object diagrams are derived from class diagrams so object
diagrams are dependent upon class diagrams.
 Object diagrams represent an instance of a class diagram. The
basic concepts are similar for class diagrams and object
diagrams.
 Object diagrams also represent the static view of a system but
this static view is a snapshot of the system at a particular
moment.
 The customer object (C) is associated with three order objects (O1, O2,
and O3). These order objects are associated with special order and
normal order objects (S1, S2, and N1). The customer has the following
three orders with different numbers (12, 32 and 40) for the particular
time considered.
 For orders, the values are 12, 32, and 40 which implies that the objects
have these values for a particular moment when the instance is
captured.
 The same is true for special order and normal order objects which have
number of orders as 20, 30, and 60. If a different time of purchase is
considered, then these values will change accordingly.
It can be said that object diagrams are used for −
 Making the prototype of a system.

 Modeling complex data structures.

 Understanding the system from practical perspective.

 Package diagram is used to simplify complex class
diagrams, you can group classes into packages. A package
is a collection of logically related UML elements.
 The diagram below is a business model in which the classes
are grouped into packages:
1. Packages appear as rectangles with small tabs at the top.
2. The package name is on the tab or inside the rectangle.
3. The dotted arrows are dependencies.
4. One package depends on another if changes in the other
could possibly force changes in the first.
 There are few constraints while using package diagrams, they are as
follows.
o Package name should not be the same for a system, however classes inside
different packages could have the same name.
o Packages can include whole diagrams, name of components alone or no
components at all.
o Fully qualified name of a package has the following syntax.
 Packages can be represented by the notations with some
examples shown below:

 There are two sub-types involved in dependency. They are

<<import>> & <<access>>.
When to Use Packages?
 To create an overview of a large set of model elements

 To organize a large model

 To group related elements

 Component diagrams are used to visualize the organization
and relationships among components in a system. These
diagrams are also used to make executable systems.
 component diagrams are used to visualize the physical
components in a system. These components are libraries,
packages, files, etc.
 Component diagrams are used to describe the physical
artifacts of a system. This artifact includes files, executable,
libraries, etc
 Component diagrams are used during the implementation
phase of an application. However, it is prepared well in
advance to visualize the implementation details.
 Before drawing a component diagram, the following artifacts
are to be identified clearly :
o Files used in the system.
o Libraries and other artifacts relevant to the application.
o Relationships among the artifacts.
 Component diagrams can be used to −
o Model the components of a system.
o Model the database schema.
o Model the executables of an application.
o Model the system's source code.
 Following is a component diagram for order management
system. Here, the artifacts are files. The diagram shows the
files in the application and their relationships.
 A composite structure diagram is a UML structural diagram
that contains classes, interfaces, packages, and their
relationships, and that provides a logical view of all, or part of
a software system.
 It shows the internal structure (including parts and connectors)
of a structured classifier or collaboration.
 Purpose of Composite Structure Diagram:
o Composite Structure Diagrams allow the users to "Peek
Inside" an object to see exactly what it is composed of.
o The internal actions of a class, including the relationships of
nested classes, can be detailed.
o Objects are shown to be defined as a composition of other
classified objects.
Composite Structure Diagram at a Glance
o Composite Structure Diagrams show the internal parts of a
class.
o Parts are named: partName:partType[multiplicity]

o Aggregated classes are parts of a class but parts are not

necessarily classes, a part is any element that is used to make
up the containing class.
 Class diagram-

Composite Structure
Diagram-
Basic structure entities of Composite Structure Diagram:
 Collaboration: describes a structure of collaborating parts (roles). A
collaboration is attached to an operation or a classifier through a
Collaboration Use.
 Parts: is a diagram element that represents a set of one or more
instances that a containing structured classifier owns. A part
describes the role of an instance in a classifier.
 Port: defines the interaction point between a classifier instance and
its environment or between the behavior of the classifier and its
internal parts.
 Interface: Composite Structure diagram supports the ball-and-
socket notation for the provided and required interfaces. Interfaces
can be shown or hidden in the diagram as needed.
 Connector: A line that represents a relationship in a model.
 Deployment diagrams are used to visualize the
topology of the physical components of a system,
where the software components are deployed.
 Component diagrams are used to describe the
components and deployment diagrams shows how they
are deployed in hardware.
 A deployment diagram consists of nodes. Nodes are
nothing but physical hardware used to deploy the
application.
 Following is the example of deployment view of order
management system. Here, we have shown nodes as −
o Monitor
o Modem
o Caching server
o Server
 The application is assumed to be a web-based application,
which is deployed in a clustered environment using server
1, server 2, and server 3.
 The user connects to the application using the Internet. The
control flows from the caching server to the clustered
environment.
Deployment diagrams can be used −
o To model the hardware topology of a system.

o To model the embedded system.

o To model the hardware details for a client/server system.

o To model the hardware details of a distributed application.