OCL3_10_05.pptx

Sanjivani Rural Education Society’s
Sanjivani College of Engineering, Kopargaon-423603
(An Autonomous Institute Affiliated to Savitribai Phule Pune University, Pune)
NAAC ‘A’ Grade Accredited, ISO 9001:2015 Certified
Department of Information Technology
(NBA Accredited)
Mr. N. L. Shelake
Assistant Professor

Software Engineering Modeling and Design
Object Oriented Design Mr. N. L. Shelake Department of Information Technology
OBJECT ORIENTED DESIGN
 Object Oriented Design Process Designing Business Layer : Object Oriented Constraints
Language (OCL),
 Designing Business Classes : The Process, Designing Well Defined Class Visibility, Attribute
 Refinement, Method Design Using UML Activity Diagram, Packaging and Managing Classes.
 Designing Access Layer: Object Relational Systems, Object Relation Mapping, Table Class
Mapping, Table –Inherited Classes Mapping,
 Designing the Access Layer Classes: The Process,
 Designing View Layer : View Layer Classes Design, Identifying View Classes by Analyzing
Use Cases, Macro-Level Design Process, Prototyping the User Interface Component and
Deployment Design using Component and Deployment Diagram

Object Constraint Language
 UML is a graphical language with a set of rules and semantics.
 The rules and semantics of the UML are expressed in English, in a form
known as object Constraint language.
 Object constraint language is a specification language that uses simple
logic for specifying the properties of a system.
 The Object Constraint Language (OCL) is a declarative language
describing rules applying to Unified Modeling Language (UML) models
developed at IBM and is now part of the UML standard.

 Initially, OCL was merely a formal specification language extension for
UML
 The Object Constraint Language is a precise text language that provides
constraint and object query expressions on any MOF (Meta Object
Facility) model or meta-model that cannot otherwise be expressed by
diagrammatic notation
 OCL is a descendant of Syntropy, a second-generation object-oriented
analysis and design method.

 OCL statements are constructed in four parts:
 a context that defines the limited situation in which the statement is valid
 a property that represents some characteristics of the context (e.g., if the
context is a class, a property might be an attribute)
 an operation (e.g., arithmetic, set-oriented) that manipulates or qualifies a
property, and
 keywords (e.g., if, then, else, and, or, not, implies) that are used to
specify conditional expressions.
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology

Constraint OCL Equivalent
The age of a person is not negative. context Person inv: self.age >=0
The first registration of a car can
not be before it is built.
context Auto inv:
self.registration>=self.construction
Year

 Item.Selector.
 The selector is the name of an attribute in the item. The result is the value of
the attribute;
 For example, John.age (the age is an attribute of the Object John, and
John.age represents the value of the attribute)
 Item.Selector [qualifier-value]
 The selector indicates a qualified association that qualifies the item. The
result is the related object selected by the qualifier; for example, array
indexing as a form of qualification; for example, Jhon.Phone[2], assuming
Jhon has several phones.

 Set -> select (Boolean-expression).
 The Boolean expression is written in terms of objects within the set.
 The result is the subset of objects in the set for which the Boolean
expression is true;
 For example, company.employee -> salary > 30000.
 This represents employees with salaries over $30,000

OCL is not an action for UML
 OCL can’t define an operation other than a query operation
 OCL can’t change the value of a model element
 OCL can’t be used to specify business rules dynamically at runtime.
 OCL equipped modeling tools to generate code based an OCL
expressions
 OCL is a part of OCUP (OMG certified UML professional)

Designing Classes
 Three layer architecture
 view layer
 business layer
 access layer
 View layer is the only exposed objects of an application with which users
can interact.
 Represents the set of operations in the business that users must perform to
complete their tasks.
 Business or Access layer are more independent of their environment
whereas in view layer that is not the case

Designing Classes
Introduction
 OOD requires taking the objects identified during object-oriented analysis
and designing classes to represent them
 Object oriented development require that you think in terms of classes
 Main benefit of this approach is that classes organize related properties
into units that stand on their own
 You must translate the attributes and operations into system
implementations

Designing Classes
Introduction
 Need to decide where in the class tree, new classes will go.
 Many object-oriented programming lang. and development environments
Such as Smalltalk, C++ or PowerBuilder, come with several built-in class
libraries
 Goal in using these systems should be to reuse rather than create anew.
 Similarly, if you design your classes with reusability in mind, you will gain
a lot in productivity and reduce the time for developing new applications

Designing Classes : the process
Which consist of the following activities:
 Apply design axioms to design classes, their attributes, methods,
associations, structures and protocols
 Refine and complete the static UML class diagram by adding details to that
diagram
 Refine attributes
 Design methods and the protocols by utilizing a UML activity diagram to
represent the method’s algorithm
 Refine the associations between classes (if required)

Designing Classes : the process
Which consist of the following activities:
 Refine the class hierarchy and design with inheritance (if required)
 Iterate and refine

Class Visibility : Designing well-defined
public, private and protected protocols
 In designing methods or attributes for classes, you are confronted with
two problems
 Protocol or interface to class operations and its visibility
 How it is implemented
 It is important in OOD to define the public protocol between the associated
classes in the application
 Set of msgs that class of certain generic type must understand, although
interpretation and implementation of each msg is up to the individual class

Class Visibility
 Private protocol of the class, includes messages that normally should not
be sent from other objects; it is accessible only to operations of that class
 Only the class itself can use the method
 Public protocol define the stated behavior of the class as a citizen in a
population and is important information for users as well as future
descendants, so it is accessible to all classes
 If the methods or attributes can be used by the class itself or its subclasses,
a protected protocol can be used
 In protected protocol , subclasses the can use the method in addition to the
class itself

Class Visibility
 Public protocols define the functionality and external messages of an
object; private protocols define the implementation of an object

Private and protected protocol Layers: Internal
 Items in these layers define the implementations of the object.
 Apply design axioms and corollaries, Corollary 1 (uncoupled design with
less information content)
 To decide what should be private: what attributes? What methods?
 Highly cohesive objects can improve coupling because only a minimal
amount of essential information need to be passed between objects.

Public protocol Layer: External
 Items in this layer define the functionality of the object.
 Good Design allows for Polymorphism
 Not all protocol should be public; again apply design axioms and corollaries

Design classes : Refining attributes
 Attributes identified must be refined during implementation
 In analysis phase the name of the attribute was sufficient
 In design phase, detailed information must be added to the model
 Main goal of this to refine existing attributes (identified in analysis)or add
attributes that can elevate the system into implementation

Attributes Types
 Single- value attributes
 Multiplicity or multivalue attribute
 Reference to another object, or instance connection
UMLAttributes Presentation
Visibility name : type-expression = initial value
 + public visibility
 # protected visibility
 - private visibility

Attributes Types
 Single- value attributes
 Attributes represent the state of an object.
 When the state of the object changes, these changes are reflected in the
value of attributes
 Most common attribute type
 It has only one value or state
 Example – such as name, address or salary

Attributes Types
 Multiplicity or Multivalue attribute
 Attributes is the opposite of the single value attribute, as its name implies
 It can have a collection of many values at any point in time
 Example – if we want to keep track of the names of people who have
called a customer support line for help, we must use the multivalue
attributes

Attributes Types
 Reference to another object, or instance connection
 Attributes are required to provide the mapping needed by an object to
fulfill its responsibilities
 Instance connection model association
 Example – A person might have one or more bank accounts. A person
has zero to many instance connections to Accounts. Similarly, account
can be assigned to one or more persons (i.e. joint account) therefore an
account also has zero to many instance connections to Person(s).

UMLAttributes Presentation
Where visibility is one of the following:
 + public visibility (accessibility to all classes)
 # protected visibility (accessibility to subclasses & operations of the class)
 - private visibility (accessibility only to operations of the class)
 TypeExpression – language dependent specification of the implementation
 Initial Value – lang. dependent expression for initial value of newly created
 Eg +size:length=100
 OCL can be used during the design phase to define the class attributes.
 Following is the attribute presentation suggested by UML
visibility name : type-expression = initial value

Refining Attributes for the ViaNet bank objects
A more complete UML class diagram for the ViaNet
bank System
Class ATMMachine
 #addres:String (The address for this ATM Machine)
 #State:String (The state of operation for this ATM Machine, Such as
running, off, idle, out of Service, Out of Money)

Designing Methods and Protocols
 To specify the algorithm for methods identified
 Some formal structure such as UML activity diagrams with an OCL
description, they can be converted programming language manually or in
automated fashion
 Class provide several types of methods
 Constructor : Method that creates instance of the class
 Destructor : Method can destroy instances
 Conversion method : method that converts a value from one unit of
measure to another

 Main goal of this activity is to specify the algorithm for methods identified
so far.
 Some formal structure such as UML activity diagrams with an OCL
description, they can be converted programming language manually or in
automated fashion
 Constructor : Method that creates instance of the class
 Destructor : Method can destroy instances
 Conversion method : method that converts a value from one unit of
measure to another

 Copy method : method that copies the contents of one instance to
another instance
 Attribute set : method that sets the values of one or more attributes
 Attribute get : method that returns the values of one or more attributes
 I/O methods : methods that provide or receive data to or from a device
 Domain specific : method specific to the application

 Corollary 1 : uncoupled design with less information conetent
 In designing methods and protocols you must minimize the complexity of
message connections and keep as low as possible the number of messages
sent and received by an object
 Goal should be to maximize cohesiveness among objects and software
components to improve coupling, because only a minimal amount of
essential information should be passed between components
 Abstraction leads to simplicity and straightforwardness and same time
increase class versatility

 The requirement of simplification, while retaining functionality, seems to
lead to increased utility, here are Five rules
 If it looks messy, then it’s probably a bad design
 If it is too complex, then it’s probably a bad design
 If it is too big, then it’s probably a bad design
 If people don’t like it, then it’s probably a bad design
 If it doesn’t work, then it’s probably a bad design

UML Operation Presentation
Visibility name : (parameter-list) : return-type-expression
Where visibility is one of the following:
 + public visibility (accessibility to all classes)
 # protected visibility (accessibility to subclasses & operations of the class)
 - private visibility (accessibility only to operations of the class)
 Name is the name of operation
 Parameter-list : list of parameters separated by commas,
 Return-type-expression : lang. dependent specification
 +getName():aName
 +getAccountNumber (account:type) : account Number

Example

Account Class Deposit Method
 An amount to be deposited is sent to an account object and used as an
argument to the deposit service.
 The account adjusts its balance to its current balance plus the deposit
amount.
 The object records the deposit by creating a transaction object containing
the date and time, posted balance, and transaction type and amount.
 We have discovered another method, update client

Package and Managing Classes
 A package groups and manages the modeling elements, such as classes their
associations, and their structures.
 Packages themselves may be nested within other package.
 A package may contain both other packages and ordinary model elements
 UML package is grouping of model elements
 It can organize the modeling elements including classes

Package and Managing Classes
 some packages may contain groups of classes and their relationships,
subsystems or models
 A package provides a hierarchy of different system components and can
reference other packages
 For example, the bank system can be viewed as a package that contains
other packages such as account package, client package and so on
 Classes can be packaged based on the services they provide or grouped into
the business classes, access classes and view classes as shown fig.

Access Layer : Object Storage and Object Interoperability
 A DBMS is set of programs that enables the creation and maintenance of a
collection of related data.
 A DBMS and associated program access, manipulate, protect and manage
the data.
 The fundamental purpose of a DBMS is to provide a reliable, persistent data
storage facility and the mechanism for efficient, convenient data access and
retrieval.
 A database is supposed to represent a real-world situation as completely and
accurately as possible

 Persistence refers to the ability of some objects to outlive the programs that
created them
 Object lifetimes can be short as far local objects or long for objects stored
indefinitely in a database.
 Most OOL do not support serialization or object persistence, which is the
process of writing or reading an object to and from a persistent storage
medium, such as a disk file.
 Persistence objects do not support query or interactive user interface
facilities, as found in fully supported OODBMS.

 Introduces the issues regarding object storage, relational and object-
oriented database management systems, object interoperability and other
technologies.
 We then look at current trends to combine object and relational systems to
provide a very practical solutions to object storage.
 We conclude the with a discussion on how to design the access layer
objects.

Database Management Systems
 A DBMS is set of programs that enables the creation and maintenance of a
collection of related data.
 DBMS Contains not only the data but a complete definition of the data
formats it manages
 This description is known as the schema or meta-data
 Contains a complete definition of the data formats, such as data structures,
types and constraints.

Database Models
 A database Model is a collection of logical constructs used to represent the
data structure and data relationships within the database.
 Database models grouped into conceptual and implementation models
 The conceptual model is concerned with what is represented in the database
 The implementation model is concerned with how it is represented
 Hierarchical Model
 Network Model
 Relational Model

Relational Models
 Has the simplest, most uniform structure and is the most commercially
widespread
 Primary concept in this database model is the relation
 The columns of each table are attributes that define the data or value domain
for entries in that column
 The rows of each table are tuples representing individual data object being
stored
 A relational table should have only one primary key
 A Primary Key is combination of one or more attributes whose value
unambiguously locates each row in the table.

Relational Model

Object oriented Databases
 OODBMS allows to representation and storage of data in the form of
objects
 Own identity or object-ID
 A large number of different datatypes
 A large number of relationships between the objects
 Objects with complex behaviours

Object Relational Systems
 Even though many applications increasingly are developed in an object
oriented programming technology,
 chances are good that the data those applications need to access live in a
very different universe- a relational database.
The introduction of OOP creates a fundamental mismatch between
the programming model (Object) and the way in which existing
data are stored (relational tables)
 To resolve the mismatch, a mapping tool between the application objects
and the relational data must be established

 Creating an object model from an existing relational database layout
(schema) often is referred to as reverse engineering
 Conversely, creating a relational schema from an existing object model
often is referred to as forward engineering
 In practice, over the life cycle of an application, forward and reverse engg.
both need to be combined in an iterative process to maintain the relationship
between the object and relational data representations
 Tools that can be used to establish the object-relational mapping processes
have begun to emerge.

The main process in relational and object integration is defining
the relationship between the table structures(schema) in the
relational database with classes (representing classes) in the
object model.
 Sun’s Java Blend is an example of such tool
 Java Blend allows the developer access to relational data as Java objects,
thus avoiding the mismatch between the relational and object data models.
 Java Blend also has mapping capabilities to define Java classes from
relational tables or relational tables from the java classes

Object Relational Mapping
 The schema is made up of tables, consisting of rows and columns, where
each column has a name and a simple data type
 In object model, the counterpart to a table is a class (or classes), which has a
set of attributes (properties or data members).
 Object classes describe behavior with methods
 A tuple (row) of a table contains data for a single entity that correlates to an
object (instance of class) in an OO system.

Object-Relation Mapping
 A stored procedure is a module of precompiled SQL code maintained
within the databases that executes on the server to enforce rules the business
has set about the data.
 The mappings essential to object and relational integration are between a
table and a class, between columns and attributes, between a row and an
object, and between a stored procedure and a method
 How relational data maps to and from application objects
 Table-class mapping
 Table-Multiple classes mapping
 Table-inherited classes mapping
 Tables-inherited classes mapping

Object-Relation Mapping
 In addition to mapping column values, the tool must be capable of
interpretation of relational foreign keys.
 The tool must describe both how the foreign key can be used to navigate
among classes and instances in the mapped object model and how
referential integrity is maintained.
 Referential Integrity means making sure that dependent tables’s foreign key
contains a value that refers to an exiting valid tuple in another relation.

Table-Class Mapping
 Table-class mapping is simple one to one mapping of a table to a class and
the mapping of columns in the table to properties in a class
 In this mapping, a single table is mapped to a single class
 In such mapping it is common to map all the columns to properties
 However, this is not required and it may be more efficient to map only those
columns for which an object model is required by the application
Cost Color Make Model
Car
Cost
Color
Make
model

Table-Class Mapping
 Each row in the table represents an object instance and each column in the
table corresponds to an object attribute.
 This kind of mapping provides a literal translation between a relational data
representation an application
 It is apperaling in its simplicity
Cost Color Make Model
Car
Cost
Color
Make
model

Table-Multiple Classes Mapping
Name Address custID empID
Employee
Name
Address
empID
Customer
Name
Address
custID
Table-multiple classes mapping. The custID column provides the
discriminant. if the value for custID is null, an Employee instance is
created at run time; otherwise, a customer instance is created
 A single table maps to multiple noninheriting classes
 Two or more distinct, noninheriting classes have properties that are mapped
to columns in a single table

Table-Inherited Classes Mapping
 In table-inherited classes mapping, a single table maps to many classes that
have a common superclass.
 This mapping allows the user to specify the columns to be shared among the
related classes.
 The super class may be either abstract or instantiated

Name Address Ssn Wage Salary
Employee
Name
ssn
Address
HourlyEmployee
wage
 Table-inherited classes mapping. Instance of SalariedEmployee can be
created for any row in the person table that has a non null value for the
salary column. If salary is null, the row is represented by an
HourlyEmployee instance.
SalariedEmployee
salary
Table-inherited classes mapping

Table-Inherited Classes Mapping
 Which allows the translation of is-a relationship that exist among tables in
the relational schema into class inheritance relationships that exist among
tables in the relational schema into class inheritance relationships in the
object model.
 In a relational database, an is-a relationship often is modeled by primary key
that acts as a foreign key to another table
 In a object model, is-a is another term for an inheritance relationship
 By using the inheritance relationship in the object model, the mapping can
express a richer and clearer definition of the relationship than is possible in
the relational schema

Tables-Inherited Classes Mapping
Name Address Ssn Salary
Person
ssn
Name
Address
Employee
Dept
Salary
Customer
Company
Name Address Ssn
Name Address company
Person Table
Employee Table
Customer Table

Designing Access Layer Classes
 We studied DBMS, distributed objects, OODBMS relational-object
systems
 The main idea behind creating an access layer is to create a set of classes
that know how to communicate with the place where data actually reside
 Regardless of where the data actually reside, whether it be a file, relational
database, mainframe, Internet and so on
 The access classes must be able to translate any data-related requests
from the business layer into the appropriate protocol for data access

 These classes also must be able to translate the data retrieved back into the
appropriate business objects
 The access layer’s main responsibility is to provide a link between business
or view objects and data storage
 Three-layer architecture, in essence, is similar to three-tier architecture
 The view layer corresponds to the client tier
 The business layer to the application server tier
 The access layer to the database tier

 The access layer performs two major tasks:
 Translate the request
 The access layer must be able to translate any data-related requests from
the business layer into the appropriate protocol for data access
 For example, if customer number 55552 needs to be retrieved, the access
layer must be able to create the correct SQL statement and execute it
 Translate the results
 The access layer also must be able to translate the data retrieved back
into the appropriate business objects and pass those objects back into the
business layer

 The main advantages of this approach is that the design is not tied to any
database engine or distributed object technology
 Easily can switch from one database to another with no major changes to the
user interface or business layer objects
 Access layer classes provide easy migration to emerging distributed object
technology, such as CORBA and DCOM
 These classes should be able to address the (relatively) modest needs of
two-tier client server architectures as well as the difficult demands of fine-
grained, peer

Designing Access Layer Classes : The Process
 Mirror the Business class package
 Define relationship
 Simplify classes and relationships
 Redundant class
 Method classes
 Store attributes and methods
 Done by utilizing an OODBMS and Relational Database

 Another Approach is to let the methods be stored in a program
 Store only persistent attributes

View Layer : Designing Interface object
 Once analysis is completed, can start designing user interface for objects
and determine how these objects are to be presented.
 Goal of UI is to display and obtain needed information in an accessible,
efficient manner.
 For design to provide users information they need and clearly tell them how
to successfully complete a task
 A well Designed UI has visual appeal that motivates users to use your
application

View Layer : Designing Interface object
 How to design the view layer by mapping the UI objects to the view layer
objects
 Will look at UI design rules based on the design corollaries
 Finally, we look at the guidelines for developing a graphical user interface

User Interface Design as a creative process
 GUI uses icons to represent objects, a pointing device to select operations,
and graphic imagery to represent relationships
 Creative thinking is not confined to a particular field or a few individuals
but is possessed in varying degrees by people in many occupations.
 artist sketches, journalist promotes an idea, scientist develop a theory, the
manager implements a new strategy and programmer develops a new s/w
system or improve an existing system to create a better one.
 Creativity implies newness, but often it is concerned with the improvement
of old products as much as with the creation of a new one

User Interface Design as a creative process
 To view user interface design as a creative process, it is necessary to
understand what the creative process really involves
 The creative process is combination of the following
 A curious and imaginative mind
 A broad background and fundamentals knowledge of existing tools and
methods
 Desire to do complete and thorough job of discovering solutions once a
problem has been defined
 Being able to deal with uncertainty and ambiguity

Designing View Layer Classes
The view layer objects are responsible for two major aspects of the
applications:
 Input –responding to user interaction
 UI must be designed to translate an action by the user, such as clicking
on a button or selecting from a menu, into an appropriate response
 Response may be to open or close another interface or to send a message
down into the business layer to start some business process
 Business logic does not exist here, just the knowledge of which message
to send to which business object.

The view layer objects are responsible for two major aspects of the
applications:
 Output- displaying or printing business object
 Layer must paint the best picture possible of the business objects for the
user
 In one interface, this may mean entry fields and list boxes to display an
order and its items
 In another, it may be a graph of the total price of a customer’s orders

 The macro level UI design process
 Identify view layer objects-main objectives of the macro process is to
identify classes that interact with human actors by analyzing the use
cases developed in the analysis phase
 Each usecase involves actor and the task they want to do, these usecases
should capture a complete, unambiguous and consistent picture of the
interface requirements.
 We need to address the issue of how the interface must be implemented
 System view should be user perspective

 Micro level UI design activities:
 Designing the view layer objects by applying design axioms and
corollaries.
 Decide how to use and extend the components
 Provide most usable interface
 Prototyping the view layer interface
 After defining a design model, prepare a prototype of some of the
basic aspects of design
 Prototyping is particularly useful early in the design process

 Testing usability and user satisfaction
 Must test the application to make sure it meets the audience requirements
 To ensure user satisfaction, we must measure user satisfaction and its
usability along the way as the UI design takes form
 Usability experts believe that usability testing should be integrated into
the development process rather than performed as a post-mortem or
forensic activity.
 Refining and iterating the design

Macro-Level Process: Identifying view classes by
analyzing use cases
 The interface object manages all interactions with the actor but does not
perform any business rules or object storage operations.
 The Interface object will essentially act as a buffer between the user and the
rest of the business objects.
 Example, A business object service is one that computes employee
overtime. However, the employee's data input is an interface object.

Macro-Level Process: Identifying view classes by
analyzing use cases
 View layer macro process consist od two steps
 For every class, determine if the class interacts with a human actor
 Identify the view (interface) objects for the class.
 Zoom in by utilizing sequence or collaboration diagram
 Define the relationships among the view (interface) objects
 For the most part, interfaces objects, like access classes, interact with
business classes.

The macro-level design process

Micro-Level Process

The micro-level design process

Micro-Level Process:
 Design of view layer objects must be user driven or user centered
 A user-centered interface replicates the user’s view of doing things by
providing the outcomes users expect for any action
 example, the tool should be easy to use and natural if the purpose of the
application is to automate a paper-based procedure.
 Design your application so it allows users to apply their previous real-world
knowledge of the paper process to the application interface
 The main goal of view layer design is to address users needs

Micro-Level Process:
 The following is the process of designing view (interface) objects:
 For every interface object identified in the macro UI design process,
Apply micro-level UI design rules and corollaries to develop the UI

Micro-
Level
Process

UI Design Rule:
 Making the interface Simple (Application of Corollary 2)
 Your application's user interface should be so straightforward that users
are unaware of the components and processes that make it operate.
 Example of car engine (Complex), driver needs only a steering wheel
and the brake pedals to operate a car
 Application of Corollary 2 means, each class UI class must have a single,
clearly defined purpose
 Every additional feature potentially affects the performance, complexity,
stability, maintenance and support costs of an application.
 Harder to fix design problem after release bcz user become dependent

UI Design Rule:
 Making the Interface Transparent and Natural (Application of Corollary
4)
 Users should be able to anticipate what to do next by using their prior
experience performing things without a computer because the user
interface should be so simple and natural.
 Application of corollary 4 (strong mapping), implies that there should be
strong mapping between the users view of doing things and UI classes

UI Design Rule:
 Allowing users to be in control of the Software(Application of Corollary 1)
 Users always should feel in control of the software, rather than feeling
controlled by the software
 It has number of implications
 Operational assumption, actions are started by the user rather than the
computer or software
 Widely varying skills and preferences, must be able to customize aspects of
the interface
 Software should be as interactive and responsive as possible
 Avoid modes whenever possible, excludes general interaction or limits user
specific interactions

Purpose of a view layer Interface
 User interface can employ one or more windows
 Each window should serve a clear, specific purpose
 Forms and data entry windows
 Provide access to data that users can retrieve, display and change in the
application
 Dialog Boxes
 Display status information or ask user to supply information or make
decision before continuing task (typical feature is OK button)
 Application windows (main windows) – container of application objects or icons

Component Diagram
 Component diagram model the physical component (such as source code,
executable program, user interface) in a design
 These high-level physical component may or may not be equivalent to the
many smaller component you use in the creation of your application.
 Example, a user interface may contain many other components purchased to
put together a graphical user interface
 Another way of looking at components is the concept of packages
 A package is used to show how you can group together classes, which in
essence are smaller scale components

Component Diagram
 Package usually used to group logical components of application
 Package could be a first approximation of what eventually will turn into
physical grouping
 A component diagram is a graph of the designs components connected by
dependency relationships.
 Dependency is shown as a dashed arrow
 A component diagram in UML gives a bird’s-eye view of your software
system.
 Understanding the exact service behavior that each piece of your software
provides will make you a better developer

component diagrams Mr. N. L. Shelake Department of Information Technology
Component Diagram : -
Component diagrams are different in terms of nature and behavior.
Component diagrams are used to model the physical aspects of a
system
Physical aspects are the elements such as executables, libraries, files,
documents, etc. which reside in a node.
component diagram is to show the relationship between different
components in a system
component-based development (CBD).
component diagrams allow the planner to identify the different
components so the whole system does what it's supposed to do.

Component Diagram : -
Component diagrams may seem complex at first glance, they are
invaluable when it comes to building your system.
Component diagrams can help your team:
Imagine the system’s physical structure.
Pay attention to the system’s components and how they relate.
Emphasize the service behavior as it relates to the interface.

Component Diagram Notations:
-
A component is a logical unit block of the system, a slightly higher
abstraction than classes. It is represented as a rectangle with a smaller
rectangle in the upper right corner with tabs
A dependency is a relationship that signifies that a single or a set of
model elements requires other model elements for their specification
or implementation.
Draw dependencies among components using dashed arrows.

Artifacts are model elements that represent the physical entities in a
software system
Artifacts represent physical implementation units, such as executable
files, libraries, software components, documents, and databases.
Artifacts are commonly used in deployment diagrams, but you can also
use them in component diagrams to show the model elements, such as
components or classes, that are manifested in the artifact

-
Some real life examples of UML artifacts are:
text document
source file
script
binary executable file
archive file
database table
The UML Standard Profile defines several standard stereotypes that
apply to artifacts:
«file» A physical file in the context of the system developed.

Standard stereotypes - subclasses of «file»:
«document» A generic file that is not a «source» file or
«executable».
«source»A source file that can be compiled into an executable file.
«library» A static or dynamic library file.
«executable» A program file that can be executed on a computer
system.
«script» A script file that can be interpreted by a computer system.

Interface Notations: -
An interface (small circle or semi-circle on a stick) describes a group
of operations used (required) or created (provided) by components.
 A full circle represents an interface created or provided by the
component.
A semi-circle represents a required interface, like a person's input.

Interface Notations: -
Provided interface symbols with a complete circle at their end
represent an interface that the component
Required Interface symbols with only a half circle at their end
represent an interface that the component requires (in both cases, the
interface's name is placed near the interface symbol itself).

A component diagram for an online shopping system

Deployment Diagram: -
A deployment diagram is a UML diagram type that shows the
execution architecture of a system, including nodes such as
hardware or software execution environments, and the middleware
connecting them.
Deployment diagrams are typically used to visualize the physical
hardware and software of a system.

Deployment Diagram
 Deployment diagram show the configuration of run-time processing elements
and the software components, processes, and objects that live in them
 Software component instances represent run-time manifestations of code units
 In most cases, component diagrams are used in conjunction with deployment
diagrams to show how physical modules of code are distributed on various
hardware platforms.
 In many cases, component and deployment diagrams can be combined
 A deployment diagram is a graph of nodes connected by communication
association

Deployment Diagram
 Nodes may contain component instances, which means that the component
lives or runs at that node
 Components may contain objects, this indicates that the object is part of the
component
 Component are connected to other component by dashed-arrow dependencies.
 Each node or processing element in the system is represented by a three-
dimensional box
 Connections between the nodes (or platforms) themselves are indicated by
solid lines

Deployment Diagram Notation
 Nodes may contain component instances, which means that the component
lives or runs at that node

Steps to draw Deployment Diagram
 Identify the nodes and devices within the system
 Figure out the relationships between the nodes and devices
 Add the communication associations to the diagram
 Identify what other elements like components, active objects, Artifacts you
need to add to complete the diagram
 Add dependencies between components and objects as required

Example of Deployment Diagram

OCL3_10_05.pptx

Recommended

Recommended

More Related Content

Similar to OCL3_10_05.pptx

Similar to OCL3_10_05.pptx (20)

More from NitinShelake4

More from NitinShelake4 (9)

Recently uploaded

Recently uploaded (20)

OCL3_10_05.pptx