UML LAB MANUAL
UML & Design
Patterns Lab Manual
Lab syllabus
Programs:
Take three
case studies:
Customer Support System
Point-Of-Sale Terminal
Library Management System
Week 1:
Familiarization with Rational Rose
or Umbrello
Week 2, 3
& 4:
For each case study:
a) Identify
and analyze events
b) Identify
Use cases
c) Develop
event table
d) Identify
& analyze domain classes
e)
Represent use cases and a domain class diagram using Rational Rose
f) Develop
CRUD matrix to represent relationships between use cases and problem domain
classes
Week 5
& 6:
For each case study:
a) Develop
Use case diagramsb) Develop elaborate Use case descriptions & scenarios
c) Develop
prototypes (without functionality)
d) Develop
system sequence diagrams
Week 7, 8,
9 & 10:
For each case study:
a) Develop
high-level sequence diagrams for each use case
b) Identify
MVC classes / objects for each use case
c) Develop
Detailed Sequence Diagrams / Communication diagrams for each use case showing
interactions
among all the three-layer objects
d) Develop
detailed design class model (use GRASP patterns for responsibility assignment)
e) Develop
three-layer package diagrams for each case study
Week 11
& 12:
For each case study:
a) Develop
Use case Packages
b) Develop
component diagrams
c) Identify
relationships between use cases and represent them
d) Refine
domain class model by showing all the associations among classes
Week 13
onwards:
For each case study:
a) Develop
sample diagrams for other UML diagrams - state chart diagrams, activity
diagrams
and
deployment diagrams
Week 1:
Familiarization
with Umbrello
Introduction:
Umbrello UML
Modeller is a UML diagram tool that can support you in the software development
process. Especially during the analysis and design phases of this process,
Umbrello UML Modeller will help you to get a high quality product. UML can also
be used to document your software designs to help you and your fellow
developers. Having a good model of your software is the best way to communicate
with other developers working on the project and with your customers. A good
model is extremely important for medium and big-size projects, but it is also
very useful for small ones. Even if you are working on a small one man project
you will benefit from a good model because it will give you an overview that
will help you code things right the first time.
UML is the
diagramming language used to describing such models. You can represent your
ideas in UML using different types of diagrams. Umbrello UML Modeller supports
the following types:
• Class
Diagram
• Sequence
Diagram
•
Collaboration Diagram
• Use Case
Diagram
• State
Diagram
• Activity
Diagram
• Component
Diagram
•
Deployment Diagram
• Entity
Relationship Diagram
UML Basics
About UML
This
chapter will give you a quick overview of the basics of UML. Keep in mind that
this is not a comprehensive tutorial on UML but rather a brief introduction to
UML which can be read as a UML tutorial. If you would like to learn more about
the Unified Modelling Language, or in general about software analysis and
design, refer to one of the many books available on the topic.
There are
also a lot of tutorials on the Internet which you can take as a starting point.
The Unified
Modelling Language (UML) is a diagramming language or notation to specify,
visualize and document models of Object Oriented software systems. UML is not a
development method, that means it does not tell you what to do first and what
to do next or how to design your system, but it helps you to visualize your
design and communicate with others. UML is controlled by the Object Management
Group (OMG) and is the industry standard for graphically describing software.
UML is designed for Object Oriented software design and has limited use for
other programming paradigms.
UML is
composed of many model elements that represent the different parts of a
software system. The UML elements are used to create diagrams, which represent
a certain part, or a point of view of the system. The following types of
diagrams are supported by Umbrello UML Modeller:
• Use Case
Diagrams show actors (people or other users of the system), use cases (the
scenarios when they use the system), and their relationships
• Class
Diagrams show classes and the relationships between them
• Sequence
Diagrams show objects and a sequence of method calls they make to other
objects.
•
Collaboration Diagrams show objects and their relationship, putting emphasis on
the objects that participate in the message exchange
• State
Diagrams show states, state changes and events in an object or a part of the
system
• Activity Diagrams
show activities and the changes from one activity to another with the events
occurring in some part of the system
• Component
Diagrams show the high level programming components (such as KParts or Java
Beans).
•
Deployment Diagrams show the instances of the components and their
relationships.
• Entity
Relationship Diagrams show data and the relationships and constraints between
the data.
Building
Blocks of UML :
✔
Things
✔
Relationships
✔
Diagrams.
Things in
UML :
Structural
Things
✔
Classes
✔
Interfaces
✔
Collaborations
✔
Use
Cases
✔
Active
Classes
✔
Components
✔
Nodes
Classes
Behavioral
Things
Interactions
State Machines
Grouping
Things
✔
Packages
.
Annotational
Things
✔
Notes
Relationships
in UML:
✔
Dependency
✔
Association
✔
1.
Aggregation
✔
2.
Composition
✔
Generalization
✔
Realization
Working with Umbrello UML Modeller
Umbrello UML Modeller’s user
interface and will tell you all
you need to know to start
modelling. All actions in Umbrello UML Modeller are accessible via
the menu and the toolbars, but
Umbrello UML Modeller also makes extensive use of right mouse
button context menus. You can
right mouse button click on almost any element in Umbrello
UML Modeller’s work area or tree
view to get a menu with the most useful functions that can be
applied to the particular element
you are working on. Some users find this a little confusing at
the beginning because they are
more used to working with the menu or tool bars, but once you
get used to right clicking it
will greatly speed up your work.
User
Interface
Umbrello UML Modeller’s main
window is divided in three areas that will help you keep an
overview of your entire system
and access the different diagrams quickly while working on your
model.
These areas are called:
• Tree View
• Work Area
• Documentation and Command
history Window
Tree View
The Tree View is usually located
on the top left hand side of the window and shows the all the
diagrams, classes, actors and use
cases that build up your model. The Tree View allows you to
have a quick overview of the
elements composing your model. The Tree View also gives you a
quick way to switch between the
different diagrams in your model and inserting elements from
your model into the current
diagram.
Documentation
and Command History Window
The Documentation and Command
historyWindow is the small window located on the left bottom
of Umbrello UML Modeller, and it
gives you a quick preview of the documentation for the
currently selected item and the
command history of your work session. The Documentation
Window is rather small because it
is intended to allow you just a quick pick into the element’s
documentation and the overview of
the command history while taking as little screen space as
possible. If you need to view the
documentation in more detail you can always open the item’s
properties.
Work Area
The Work Area is the main window
in Umbrello UML Modeller and is where the real action
takes place. You use theWork Area
to edit and view the diagrams in your model. TheWork Area
shows the currently active
diagram. Currently only one diagram can be shown on theWork Area
at any time.
Week-2,3 & 4:
a) Identify
and analyze events
b) Identify
Use cases .
c) Develop
Event Table
d) Identify
& analyze domain classes
e)
Represent use cases and a domain class diagram
f) Develop
CRUD matrix to represent relationship between use cases and problem domain
class.
A Event is
an occurance at specific time and space, can be described & should be
remembered by the system. Building usecase and class diagram is very important
task since it represents a transition between requirements and design phases.
-
We
can derive usecase and class diagram from an event table.
“The event
analysis technique has been preferred one of event analysis during the
requirements engineering. The results of event analysis are documented in an
event table.
An event
table can be created from the external events to support use case diagrams.
Event table
elements:
Event: An
event which causes system to do something.
Source:
Source of an event(Actors,system)
Trigger:
cause of an action.
Use case:
Activity performed by an actor using system.
Events are
classified in to three types:
-
External
events
-
Temporal
internal events
-
Conditional
internal events.
External
events: An event occurs outside of system, usually initiated by external
actor/user.
Temporal
internal events: An event that happens when system reaches a specific point in
time.
Conditional
internal events: An event occurs when something happens inside the system &
system must initiate some process to response for this event.
Event table
is a table of data that is typically written to the logfile for each scenario
& appears in analysis window. Event table contains timing information about
specific events that occur during scenario.
Ex: Event
table for “video rental Event table”
|
Event |
Trigger |
Source
actor |
Usecase |
Response |
Dest.Actor |
|
Customer
rents a video |
Customer
comes to check videos |
Customer |
Rent a
video |
Print Rental
contract |
Customer |
|
Customer
return video |
Customer
drops a video |
Customer |
Video
return |
Video is
available for rental |
Customer |
Identifying Use Cases
Before we
can produce a use case diagram we must first identify the groups of related scenarios
- the use cases. In addition we need to identify the initiators of the use
cases - the actors. Recall from the previous sections, actors reside outside of
the system and interact with it; use cases describe the functionality that
helps actors achieve their goals. There are many approaches to identifying
actors and use cases. In this section we present a method for doing this.
To identify
use cases we will take the following steps:
Step 1: Identify candidate system actors.
Step 2: Identify the goals of the actors.
Step 3: Identify the candidate use cases.
Step 4: Identify the start point for each
use case.
Step 5: Identify the end point for each
use case.
Step 6: Refine and scope units of
interaction.
Now we
discuss each of these steps in more detail.
Step 1: Identify candidate system
actors.
Read
through the requirements documentation and make a note of all the candidate
system actors. Remember an actor is not just a person but may also be an
external system such as a credit card verification service. Actors interact
with the system and reside outside of it. If you find that multiple terms have
been used to describe the same actor, group these terms together and use a
generic term. Be aware, it is crucial that you are certain that these terms are
describing the same actor.
Activity: Identify the Actors in
the Case Study
Learning Objective: This exercise will give you some
insight into the process of identifying the system actors that are responsible
for initiating uses cases.
Read
through the UWEFlix case study and identify the actors. Remember from the
previous section, actors are external to the system and not part of it. They
are not necessarily human and can be external systems such as credit card
verification services. For example, Manager could be an actor. Any others?
Step 2: Identify the goals of the
actors.
Use cases
describe the functionality required of the system in order for actors to
achieve their goals. Therefore you need to identify what the goals of your
candidate actors are. At this stage you may find that you have multiple actors
requiring the same or similar system functionality, at this stage do not worry
about this. For example, the manager needs to decide what films to shown in
which screens.
Step 3: Identify the candidate use
cases.
Now that
you have identified the candidate actors and the goals of these actors we can
identify the candidate list of use cases. Remember a use case represents a
substantial piece of system functionality, not just a single method in
software. Use cases cover a group of related scenarios, for example, a use case
called "purchase ticket" will include the scenario where payment is
unsuccessful in addition to the typical payment success scenario. Using the
actors goals try and identify the text in the requirements document that
corresponds to these goals. Choose an initial name to describe the candidate
use case and paste the textual commentary from the requirements document
underneath the use case name. At this point do not worry about common
functionality in multiple use cases.
Activity: Identify the Use Cases in
the Case Study
Learning Objective: This exercise will give you some
insight into the process of identifying the uses cases that represent the
required system functionality.
Read
through the case study and identify the use cases. Remember from the previous
section that use cases are groups of related scenarios. For example, we may
have a use case for deleting film.
Step 4: Identify the start point
for each use case.
You may
have already started to do this when producing your list of candidate use cases
but you need to identify the start point for each use case. To do this, look
for an actor and an initial event. You will find this is easier to do with some
use cases rather than others. For example, with the "DeleteFilm" use
case, the initial event may be to choose a film.
Step 5: Identify the end point for
each use case.
In a manner
similar to that of step 2, you need to identify the beneficial result of the
use case, the end point. The purpose of this step is to allow you to refine the
size of use cases, ensuring that a candidate use case is neither too small nor
too big.
Step 6: Refine and scope units of
interaction.
At this
point all of the functionality described in the requirements document needs to
be covered by at least one candidate use case. You now need to work through the
list of candidate use cases refining size and scope. Remember after completing
this step you are not after a fixed final list of actors and use cases, it is
still possible to refine this later.
Note: You will find that as you gain
more experience you will carry out steps 3-5 at the same time.
Identifying
Domain Classes
Review
From the
object-oriented perspective, the world as made of objects.
Objects can
represent material things, but they can also represent abstract things such as
events, roles, and descriptions.
If
requested by another object, an object can execute one of its
methods/functions.
Executing a
method may change the object's internal state, it may change the object's
environment, it may send requests to other objects to execute some of their
methods, and/or it may simply provide information to the original requesting
object.
Here are
some basic definitions:
Objects, Classes, and Packages
An object
model consists of one or more UML class diagrams. A class diagram is a graph:
nodes connected by arrows. The nodes represent packages, interfaces, classes,
and objects:
UML Package, Class, and Object Icons
Domains
A domain is
a package of related concepts, roles, procedures, events, and entities. (See Domain Modeling).
Examples of
domains include:
business
engineering
science
government
health care
In UML:
Examples of
sub-domains of the business might include:
sales
marketing
management
finance
In UML we
can represent this as packages connected by dependency arrows.
A
dependency arrow connecting the sales package to the business package indicates
that some of the concepts contained in business�profit, overhead, employee,
customer, etc.�are used in the sales package:
A video rental store is a sub-domain of many domains:
film
sales
In UML:
Domain Classes and Objects
Objects that represent domain entities are called entities or
domain objects. The classes they instantiate are called domain classes.
Executing a use case involves creating, destroying, querying,
and updating domain objects.
Domain Classes and Objects
Objects that represent domain entities are called entities or
domain objects. The classes they instantiate are called domain classes.
Executing a use case involves creating, destroying, querying,
and updating domain objects.
Identifying Stereotypes
Typical domain class stereotypes include:
<<thing>> = an entity that has mass and volume
<<event>> = an entity that has a start time and
duration
<<role>> = an entity that executes tasks. For
example: plumber, clerk, nurse
<<type>> = an entity that describes other
entities: film genre (Sci Fi, comedy, etc.), film rating (P, PG, etc.)
Examples of <<thing>> classes:
Person, Report,
Examples of <<role>> classes:
Customer, Doctor, Student
Examples of <<event>> classes:
Transaction,
Examples of <<type>> classes:
Genre, ProductType, Rank
Identifying Attributes
A class contains definitions of all of the attributes its
instances will contain.
An attribute has four attributes:
name
type
visibility (+ | ~ | # | -)
initial value (optional)
The type of an attribute usually is not a domain class. These
kinds of properties will be represented by associations.
Attribute types include:
primitive types: int, double, boolean
foundation classes: String, Money, Date
external/imported classes (i.e., classes from external
domains)
Example:
An employee has a name, birth date, salary, marital status,
and unique employee ID number.
We probably want to distinguish first and last name. Names
are usually strings.
We can assume the existence of a Date class for birth day.
Ideally, salary should be of type Money. If this isn't
available we can choose a type for representing decimal numbers like float (32
bit) or double (64 bit). It's probably a good idea to initialize this to zero.
Marital status can be a simple Boolean flag. We initialize it
to false.
Employee ID number should be an integer (int).
Note that we use Java primitive types. We could also use C++
types (string, bool), XSD types, or CORBA types.
By default, the visibility of all attributes should be
private. This gives the developer to make the attributes read-write or read
only. This can be done by providing getters and setters for the attributes.
Attributes usually map to fields in Java and C++:
Note that age is an example of a derived attribute. It
doesn't map to a field because it can be computed from other attributes.
Note that birthDay and id are read-only attributes.
Identifying Operations
Administrative functions: constructors, getters, setters,
destructors, printers, etc. are usually not shown in a UML diagram.
In the analysis phase we only specify operations that are
domain-specific.
An operation has four attributes:
name
return type
parameters
visibility� (+ | ~ | # | -)
Example:
A word processor document has content string and a cursor,
which marks a position in the content string.
We need to be able to insert and delete text in
a word processor at the cursor's location. We also need to be able to get a
word count and move the cursor:
Our class has two attributes: content and cursor.
The text suggests four operations. The parameters are
inferred:
Static Attributes and Operations
A static attribute or operation is an attribute or operation
belonging to a class rather than the instances of the class.
For example, a Trig utility class might contain sin and cos
methods as well as the constant PI. There is no need to create objects to
execute these methods.
Here's a Java declaration:
class TrigUtils {
�� static public double PI = 3.1416;
�� static public double sin(double x) { ... }
�� static public double cos(double x) { ... }
�� // etc.
}
Here's how this might be used:
TrigUtils.sin(TrigUtils.PI/2); // should = 1
In UML static operations and attributes are underlined:
Textual
Analysis
Example
A point-of-sale application needs to record all purchases.
Here are a few facts:
F1: Customers make purchases.
F2: Customers have names.
F3: Purchases have dates.
F4: One or more items are sold in a purchase.
F5: Items have prices and descriptions.
F6: Purchases have amounts equal to the sum of the prices of
the items sold.
F7: Customer Smith purchases copies of Ulysses and Moby Dick.
F1 and F6 are general rules about the retail sales domain,
while F7 is an assertion about a specific sale.
In this example Smith, the copy of Ulysses and the copy of
Moby Dick are objects. In fact these are things or entities, a special category
of objects that have mass and volume.
The record of the purchase is also an object. This type of
object is an event. Events don't have mass and volume. Instead they have start
times and durations.
Here's an initial analysis object model representing the
domain rules:
Assertions like F7 can be represented by objects:
CRUD Matrix:
Its a table that for every process is a system defines
interactions with main entities:
-
Create
-
Read
-
Update
-
Delete
These entities are mainly used during database design and
used for every data flow in a system.
“CRUD is used to make initial design and get software
complexity estimation.
First of all, a specification:
I
need to sell products on my website. I'd like an order is created in my ERP
system just after instant payments are finished.
Pretty short, but
let's start design!
We can see how basic
processes interacts with internal data (Product, Order, Item) and external
entities (Payment, ERP Order). Let's check first rule:
Every
process should have at least one input (R) and one output (CUD)
We can
see rule is not valid for few processes, so let's add some Entities to fulfill
this rule:
As you can see we added
actor (Customer) to be a source (trigger) for some processes.
Now we
can add estimation part. First: for every entity we can add complexity (we know
that one entities can be more complicated than another), complexity of
processes will result from used entities complexity:
Week- 5 & 6
a) Develop
Use case diagrams b) Develop elaborate Use case descriptions & scenarios
c) Develop
prototypes (without functionality)
d) Develop
system sequence diagrams
USE CASE DIAGRAM Overview: To model a system the most important aspect is to
capture the dynamic behavior. To clarify a bit in details, dynamic behavior
means the behavior of the system when it is running operating. So only static
behavior is not sufficient to model a system rather dynamic behavior is more
important than static behavior. In UML there are five diagrams available to
model dynamic nature and use case diagram is one of them. Now as we have to
discuss that the use case diagram is dynamic in nature there should be some
internal or external factors for making the interaction. These internal and
external agents are known as actors. So use case diagrams are consists of
actors, use cases and their relationships. The diagram is used to model the
system/subsystem of an application. A single use case diagram captures a
particular functionality of a system. So to model the entire system numbers of
use case diagrams are used.
Purpose:
The purpose of use case diagram is to capture the dynamic
aspect of a system. But this definition is too generic to describe the purpose.
Because other four diagrams (activity, se-quence, collaboration and State
chart) are also having the same purpose. So we will look into some specific
purpose which will distinguish it from other four diagrams. Use case diagrams
are used to gather the requirements of a system including internal and external
influences. These requirements are mostly design requirements. So when a system
is analyzed to gather its func-tionalities use cases are prepared and actors
are identified. So in brief, the purposes of use case diagrams can be as
follows:
Used to gather requirements of a
system.
Used to get an outside view of a
system.
Identify external and internal
factors influencing the system.
Show the interacting among the requirements are actors .
Sequence diagram:
It consists of set of objects
& messages so this diagram emphasizes time
ordering of messages.
It represents dynamic view of a
system
Each and every object has a life
line.
There is no sequence number and
path of msg.
It consists of focus of control.
Sequence diagram for book issue:
Objects identified :for classes:
User , library ,scanner, database
First the user gives his card
and the library class sends the card for scanning
to the scanner.
The scanner scans the card and
sends the scan code to the database and for
verification.
The book will be scanned and again validated by
the database.
Week 7, 8, 9 & 10:
a) Develop
high-level sequence diagrams for each use case
b) Identify
MVC classes / objects for each use case
c) Develop
Detailed Sequence Diagrams / Communication diagrams for each use case showing
interactions
among all the three-layer objects
d) Develop
detailed design class model (use GRASP patterns for responsibility assignment)
e) Develop
three-layer package diagrams for each case study
High level sequence diagram :
We can use high-level sequence diagrams that span several
business use cases to illustrate business processes at a coarse level.
High-level sequence diagrams give a good overview of the interactions between
customers, partners, and the business system. They serve as the basis for the
electronic data transfer between the business system and customers, business
partners, and suppliers.
Sequence Diagrams show the message exchange (i.e. method call) between
several Objects in a
specific time-delimited situation. Objects are instances of classes. Sequence
Diagrams put special
emphasis in the order and the times in which the messages to the objects
are sent.
In Sequence Diagrams objects are represented through vertical dashed
lines, with the name of
the Object on the top. The time axis is also vertical, increasing
downwards, so that messages are
sent from one Object to another
in the form of arrows with the operation and parameters name.
Messages can be either synchronous, the normal type of message call
where control is passed to
the called object until that method has finished running, or
asynchronous where control is passed
back directly to the calling object. Synchronous messages have a
vertical box on the side of the
called object to show the flow of
program control.
MVC Class diagrams :
When drawing UML
diagrams, the authors use these symbols instead of generic UML symbols -- a
practice I first learned when using Rational Rose -- and it really helps to
improve the readability and usefulness of UML diagrams.
The second
MVC diagram was the one that really turned on the light bulb for me. The
column on the left side of this MVC diagram shows the operations that are
allowed according to MVC rules, and the column on the rights shows the
"bad" behaviors -- methods of communication in your classes that
should not happen. Here's the diagram:
Model View Controller diagram rules
Personally, I just ignore the column on the
right, and focus solely on the column on the left, but initially the right
column may make the rules more clear.
The left-side column of this diagram states the
following MVC pattern rules:
1.
Users
interact with View objects.
2.
View
objects and Controller objects talk to each other.
3.
Different
Controller objects talk to each other.
4.
Controller
objects talk to Model objects.
5.
No
other forms of communication between objects are allowed.
If you understand these rules and commit them to
memory, I think you'll see that the MVC concept becomes very simple.
I've found that whenever I start to take a
shortcut, and do something like connecting to View objects together in my
programs, a little alarm starts going off in my brain, and that alarm is
directly related to this diagram and these rules.
Class Diagram
Class Diagrams show the different
classes that make up a system and how they relate to each
other. Class Diagrams are said to
be ‘static’ diagrams because they show the classes, along with
their methods and attributes as
well as the static relationships between them: which classes
‘know’ about which classes or which classes ‘are
part’ of another class, but do not show the
method calls between them.
Class
AClass defines the attributes and
the methods of a set of objects. All objects of this class (instances
of this class) share the same
behavior, and have the same set of attributes (each object has its own
set). The term ‘Type’ is
sometimes used instead of Class, but it is important to mention that these
two are not the same, and Type is
a more general term.
In UML, Classes are represented
by rectangles, with the name of the class, and can also show the
attributes and operations of the class in two
other ‘compartments’ inside the rectangle.
Attributes
In UML, Attributes are shown with
at least their name, and can also show their type, initial value
and other properties. Attributes
can also be displayed with their visibility:
• + Stands for public attributes
• # Stands for protected
attributes
• - Stands for private attributes
Operations
Operations (methods) are also
displayed with at least their name, and can also show their parameters and
return types. Operations can, just as Attributes, display their visibility:
• + Stands for public operations
• # Stands for protected
operations
• - Stands for private operations
Templates
Classes can have templates, a
value which is used for an unspecified class or type. The template
type is specified when a class is
initiated (i.e. an object is created). Templates exist in modern
C++ and will be introduced in
Java 1.5 where they will be called Generics.
Class
Associations
Classes can relate (be associated with) to each
other in different ways:
Generalization
Inheritance is one of the
fundamental concepts of Object Oriented programming, in which a class
‘gains’ all of the attributes and
operations of the class it inherits from, and can override/modify
some of them, as well as add more
attributes and operations of its own.
In UML, a Generalization
association between two classes puts them in a hierarchy representing
the concept of inheritance of a
derived class from a base class. In UML, Generalizations are
represented by a line connecting the two classes,
with an arrow on the side of the base class.
Associations
An association represents a
relationship between classes, and gives the common semantics and
structure for many types of
‘connections’ between objects.
Associations are the mechanism
that allows objects to communicate to each other. It describes the
connection between different
classes (the connection between the actual objects is called object
connection, or link. Associations
can have a role that specifies the purpose of the association and can be uni-
or bidirectional (indicates if the two objects participating in the
relationship can send messages to the other, of if only one of them knows about
the other). Each end of the association also has a multiplicity value, which
dictates how many objects on this side of the association can relate to one
object on the other side.
In UML, associations are
represented as lines connecting the classes participating in the relationship,
and can also show the role and the multiplicity of each of the participants.
Multiplicity is
displayed as a range [min..max]
of non-negative values, with a star (*) on the maximum side
representing infinite.
Three layer
package diagram
Model diagram is UML auxiliary structure diagram which
shows some abstraction or specific view of a system, to describe some
architectural, logical or behavioral aspects of the system.
The drawing below shows some major
elements of the model diagram. Layered Application is a container model which contains three
other models - Presentation
Layer, Business Layer, and Data Layer. There are dependencies defined between these
contained models.
Package
diagrams can use packages containing use cases to illustrate the functionality
of a software system. Package diagrams can use packages that represent the
different layers of a software system to illustrate the layered architecture of
a software system. The dependencies between these packages can be adorned with
labels / stereotypes to indicate the communication mechanism between the
layers.
People
find package diagrams extremely useful on larger-scale systems to get a picture
of the dependencies between major elements of a System . These diagrams correspond
well to common programming structures . Plotting diagrams of packages and
dependencies helps you keep an application's dependencies under control.
Week 11 & 12:
a) Develop
Use case Packages
b) Develop
component diagrams
c) Identify
relationships between use cases and represent them
d) Refine
domain class model by showing all the associations among classes
Use case Packages:
A model structured into
smaller units is easier to understand. It is easier to show relationships among
the model's main parts if you can express them in terms of packages. A package
is either the top-level package of the model, or stereotyped as a use-case
package. You can also let the customer decide how to structure the main
parts of the model.
·
If there are many use cases
or actors, you can use use-case packages to further structure the use-case
model. A use-case package contains a number of actors, use cases, their
relationships, and other packages; thus, you can have multiple levels of use-case
packages (packages within packages).
·
The top-level package
contains all top-level use-case packages, all top-level actors, and all
top-level use cases.
You can partition a
use-case model into use-case packages for many reasons:
·
You can use use-case
packages to reflect order, configuration, or delivery units in the finished
system.
·
Allocation of resources and
the competence of different development teams may require that the project be
divided among different groups at different sites. Some use-case packages are
suitable for a group, and some for one person, which makes packages a naturally
efficient way to proceed with development. You must be sure, however, to define
distinct responsibilities for each package so that development can be performed
in parallel.
·
You can use use-case
packages to structure the use-case model in a way that reflects the user types.
Many change requirements originate from users. Use-case packages ensure that
changes from a particular user type will affect only the parts of the system
that correspond to that user type.
·
In some applications,
certain information should be accessible to only a few people. Use-case
packages let you preserve secrecy in areas where it is needed.
Use cases are often a primary requirement
artifact in object-oriented development methodologies, this is particularly
true of instantiations of the Unified
Process, and for larger projects package diagrams are often created to organize
these usage requirements.
Component
Diagrams
Component Diagrams show the
software components (either component technologies such as
KParts, CORBA components or Java
Beans or just sections of the system which are clearly distinguishable)and the
artifacts they are made out of such as source code files, programming libraries
or relational database tables.
Components can have interfaces
(i.e. abstract classes with operations) that allow associations
between components.
Week 13 onwards:
a) Develop
sample diagrams for other UML diagrams - state chart diagrams, activity
diagrams
and
deployment diagrams
State
Diagram
State Diagrams show the different
states of an Object during its life and the stimuli that cause the
Object to change its state.
State Diagrams view Objects as
state machines or finite automates that can be in one of a set of
finite states and that can change
its state via one of a finite set of stimuli. For example an Object
of type NetServer can be in one
of following states during its life:
• Ready
• Listening
• Working
• Stopped
and the events that can cause the
Object to change states are
• Object is created
• Object receives message listen
• A Client requests a connection
over the network
• A Client terminates a request
• The request is executed and
terminated
• Object receives message stop.
State
States are the building block of
State Diagrams. A State belongs to exactly one class and represents
a summary of the values the
attributes of a class can take. A UML State describes the
internal state of an object of
one particular class
Note that not every change in one
of the attributes of an object should be represented by a State
but only those changes that can
significantly affect the workings of the object
There are two special types of
States: Start and End. They are special in that there is no event
that can cause an Object to
return to its Start state, in the same way as there is no event that can
possible take an Object out of its End state once
it has reached it.
Activity
Diagram
Activity Diagrams describe the
sequence of activities in a system with the help of Activities.
Activity Diagrams are a special form of State
Diagrams, that only (or mostly) contains Activities.
Activity Diagrams are similar to
procedural Flux Diagrams, with the difference that all Activities
are clearly attached to Objects.
Activity Diagrams are always
associated to a Class, an Operation or a Use Case.
Activity Diagrams support
sequential as well as parallel Activities. Parallel execution is represented
via Fork/Wait icons, and for the
Activities running in parallel, it is not important the order
in which they are carried out
Activity
An Activity is a single step in a
process. One Activity is one state in the system with internal
activity and, at least, one
outgoing transition. Activities can also have more than one outgoing
transition if they have different
conditions.
Activities can form hierarchies,
this means that an Activity can be composed of several ‘detail’
Activities, in which case the
incoming and outgoing transitions should match the incoming and
outgoing transitions of the detail diagram.
Deployment
Diagrams
Deployment diagrams show the
runtime component instances and their associations. They include
Nodes which are physical
resources, typically a single computer. They also show interfaces
and objects (class instances).
Entity
Relationship Diagrams
Entity Relationship Diagrams (ER
Diagrams) show the conceptual design of database applications.
They depict the various entities
(concepts) in the information system and the existing relationships
and constraints between them. An
extension of Entity Relationship Diagrams named
’Extended Entity Relationship
Diagrams’ or ’Enhanced Entity Relationship Diagrams’ (EER), are
used to incorporate Object Oriented design
techniques in ER Diagrams.
Comments
Post a Comment