CS 426 Senior Projects in Computer Science

crookpatedspongyΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 4 χρόνια και 1 μήνα)

95 εμφανίσεις

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]