What is UML?
What is UP?
[
Arlow
and
N
eustadt
, 2005]
January 24, 2013
CS
426 Senior Projects in
Computer Science
University of Nevada, Reno
Department of Computer Science & Engineering
2
/32
What is UML?
UML history
MDA
–
the future of UML
Why
“
unified
”
?
Objects and UML
UML structure
UML building blocks
UML common mechanisms
Architecture
3
/32
What is UP?
UP History
UP Axioms
UP Core Workflows
UP Structure
Details on UP Phases
4/32
The UML (
Unified Modeling Language
) is a general
purpose visual modeling language for systems
Usually associated with OO software systems, but with wider
application than that
Incorporates modern best practices in modeling techniques and
software engineering
Designed to be supported by CASE tools
It is
not
a methodology, but a notation that can be used in various
software development methodologies
Not tied to any methodology or specific
lifecycle; however the
preferred method
for using UML is the UP (
Unified Process
)
5
/32
Stages of UML evolution, Fig. 1.2 [Arlow & Neustadt, 2005]
6/32
Model driven architecture (MDA) is based on the idea that
models can drive the production of executable software
environments
7
/32
UML unification encompasses the following:
Development lifecycle
:
UML can be used from requirements
engineering to implementation
Application domains
:
UML has been used in a profusion of
applications, of various types
Implementation languages and platforms
:
UML is language and
platform independent
Development processes
:
UP is only one of the processes
supported by UML
Its own internal concepts
:
UML is based on a set of concepts that
have been applied consistently throughout the notation’s
development
8
/32
The main premise for using UML is that software
systems can be modeled as
collections of
interacting objects
There are two major, complementary parts in a
UML model:
Static structure
= constituent objects + their
relationships
Dynamic behaviour
= functionality provided by the
collaborating objects
9
/32
There are three main parts in UML structure, as indicated
b
elow, Fig. 1.4 [
Arlow
&
Neustadt
2005]
10
/32
UML is composed of three building blocks [Fig. 1.5,
Arlow
2005]:
Things, or modeling elements (modeling constructs)
Relationships, that specify how things relate semantically
Diagrams, that provide views into UML models and show
collections of interrelated things
11
/32
UML
things
, or
modeling elements
, can be
classified as:
Structural things
, e.g., class, interface, use case, component,
node (the “nouns” of a UML model)
Behavioural things
, such as interactions and state machines (the
“verbs” of a UML model)
Grouping things
, e.g. package, which gathers related modeling
elements
Annotational
things
, e.g., the “sticky note” that can be
appended to any modeling construct
12
/32
UML
relationships
indicate how two or more things are
interconnected. Relationships apply to structural and grouping
things and are as follows [Table 1.1,
Arlow
&
Neustadt
2005]:
13
/32
A
UML model
is a repository of all
things
and
relationships
created
to describe the structure and behavior of the system under
development
Diagrams
provide views (or windows) into this model
Diagrams also provide mechanisms for entering information into
the model
There are 13 types of UML diagram, 6 of them describing the
static structure of the system (
the static model
), and 7 the
dynamic aspects of the system (
the dynamic model
)
[see next slide]
14/32
Types of UML diagrams [Fig. 1.6,
Arlow
&
Neustadt
, 2005]
15
/32
UML syntax for diagram [Fig. 1.7,
Arlow
&
Neustadt
, 2005] &
diagram with implied frame [Fig. 1.8,
Arlow
&
Neustadt
, 2005]
16
/32
UML has four common mechanisms that are applied consistently,
in different contexts, throughout UML [Fig. 1.9,
Arlow
2005]
17
/32
Specifications
are textual descriptions of the semantics of UML
elements. Example, Fig. 1.10 [
Arlow
&
Neustadt
, 2005]
18
/32
Adornments
allow showing more information on UML elements.
Example, Fig. 1.11 [
Arlow
&
Neustadt
, 2005]
19
/32
Common divisions
are ways of thinking about the world
(for modeling purposes)
Common divisions in UML are of two types:
Classifiers and instances [see Table 1.2 in the book]
Interface and implementation
20
/32
There are three types of mechanisms that provide
support
for UML
extensibility
, Table 1.3 [
Arlow
&
Neustadt
, 2005]
21
/32
The system architecture is
“
the organizational structure of the system,
including its decomposition into parts, their connectivity, interaction,
mechanisms and the guiding principles that inform the design of a system.
”
[
Rumbaugh
1998]
There is a typical
“
4+1 views
”
architecture of a system defined by UML:
Logical view
, captures the vocabulary of the problem domain using classes and
objects
Process view
, depicts the threads and processes of the system as active classes
Implementation view
,
shows the physical code base of the system in terms of
components
Deployment view
, models the physical deployment of components onto
computational nodes
Use case view
, captures the requirements of the system using a set of use cases. This
is the view
“
+1
”
to which all other views connect.
22
/32
The
“
4 +1 views
”
architecture, Fig. 1.13 [
Arlow
&
Neustadt
2005]
23
/32
A
software development
process
(SDP) or
software
engineering process
(SEP)
defines the
who
,
what
,
when
,
and
how
of developing
software
The
Unified Software
Development Process
(USDP)
or, in short, the
Unified Process
(UP) is an industry standard
process created by the authors
of UML
Fig 2.2 [Arlow & Neustadt 2005]
24
/32
UP evolution, Fig. 2.3 [
Arlow
&
Neustadt
, 2005]
25
/32
Grady Booch
Video: why engineering?
Video: the promise, the limits, the beauty of software
Video: smarter products for a smarter planet
Ivar Jacobson
Jim Rumbaugh
26
/32
Requirements and
risk driven
Architecture centric
Iterative and incremental
Each iteration contains all the elements of a regular software
development project: planning, analysis, design, construction,
integration, testing, internal or external release
27
/32
Requirements
:
Determining what the system should do
Analysis
:
Refining and structuring the requirements
Design
:
Defining system architecture to satisfy requirements
Implementation
:
Building the software
Testing
:
Verifying that the implementation is correct
A
baseline
is the result of an iteration, a partially
complete
version
of
the
final system. An
iteration
is the
difference
between two consecutive baselines
.
28
/32
Fig.2.5 [
Arlow
&
Neustadt
, 2005]
29
/32
Fig.2.6 [
Arlow
&
Neustadt
, 2005]
30
/32
Fig.2.7 [
Arlow
&
Neustadt
, 2005]
31
/32
Each of the four phases of UP (inception, elaboration,
construction, transition) has:
A goal
A focus of activity
One or more core workflows
A milestone, with a number of conditions of satisfaction
Details of the above for Inception are given next. The
remaining three phases are described in Subsection
2.9 of the textbook
32
/32
Inception
Goal: Get the project off the ground
Tasks:
▪
Assess feasibility
▪
Create a strong business case
▪
Capture essential requirements
▪
Identify critical tasks
Focus: Requirements specification and analysis
Milestone: Life
-
cycle objectives [see conditions of
satisfaction in Table 2.1 of the book]
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Σχόλια 0
Συνδεθείτε για να κοινοποιήσετε σχόλιο