COS 315 - PowerPoint PPT Presentation

1 / 37
About This Presentation
Title:

COS 315

Description:

Aonix Software Through Pictures. Borland Together ... The Headlines. UML is effective for modeling large, complex software systems ... – PowerPoint PPT presentation

Number of Views:40
Avg rating:3.0/5.0
Slides: 38
Provided by: gall5
Category:
Tags: cos

less

Transcript and Presenter's Notes

Title: COS 315


1
COS 315 SOFTWARE ENGINEERING 4. UML - Unified
Modeling Language An overview
2
Some Terminology Model A description or
analogy used to help visualize something that
cannot be directly observed. A model is an
abstraction describing a system or a subset of a
system Method A means or manner of procedure
especially, a regular and systematic way of
accomplishing anything. A view depicts selected
aspects of a model A notation is a set of
graphical or textual rules for representing views
3
A system is a collection of subsystems organized
to accomplish a purpose and described by a set of
models. A model is an abstraction of a system.
4
A model is built by applying well-tested
scientific principles and is expressed in a
language that encapsulates those principles. A
method is a set of steps and rules that define
how a model is derived. A methodology is an
organized collection of methods. A process is
the procedure that is followed to describe the
dimensions of software system development.
5
Examples System Aircraft Models Flight
simulator, scale model Views All blueprints,
electrical wiring, fuel system
6
Systems, Models, and Views
Flight simulator
Blueprints
Airplane
Electrical Wiring
Scale Model
7
Models, Views, and Systems as UML
8
Why model software?
  • Software is already an abstraction why model
    software?
  • Software is getting larger, not smaller
  • MS NT 5.0 40 million lines of code
  • A single programmer cannot manage this amount of
    code in its entirety (not even an AUBG COS
    major!)
  • Code is often not directly understandable by
    developers who did not participate in the
    development
  • We need simpler representations for complex
    systems
  • Modeling is a means for dealing with complexity

9
UML stands for Unified Modeling Language UML is
a graphical (visual) modeling notation for -
Specifying - Visualizing - Constructing -
Documenting the artifacts of software systems.
UML was developed by Booch, Jacobson and
Rumbaugh (the Three Amigos). They set up a
software company - Rational (since acquired by
IBM). UML unifies their separate, individual
work to create a single, unified modeling
language.
10
UML (Unified Modeling Language) A standard for
modeling object-oriented software. Resulted from
the convergence of notations from three leading
object-oriented methods OMT (James
Rumbaugh) OOSE (Ivar Jacobson) Booch (Grady
Booch) Supported by several CASE
tools Rational Rose Aonix Software Through
Pictures Borland Together ...
11
UML represents a collection of "best engineering
practices" that have proven successful in the
modelling of large and complex systems. UML
supports the creation and manipulation of models
that define the application. UML is a modeling
language, not a method (or a methodology). -
Software development methodology neutral. -
Industry standard OO modeling language (but can
also be used for non-OO systems). - Basic
premise software systems can be modeled as
collections of collaborating objects. UML also
allows the modeling of dynamic behaviour and
event handling modern software systems.
12
Object-Oriented Modeling
  • Why models?
  • To abstract reality
  • Show essential details filter out non-essential
    details
  • To help us deal with complexity
  • Deal with human limitations in understanding
    complex things
  • To allow us to focus on the big picture
  • To promote understanding of requirements, cleaner
    design, more maintainable systems
  • Why objects?
  • To more accurately reflect reality in a model
  • To reduce the semantic gap between reality and
    a model
  • To localize changes to the model
  • We can model reality as a number of interacting
    objects!

13
Object-Oriented Modeling Perspectives
  • Conceptual
  • Do not consider any aspects of implementation of
    objects
  • Focus on identifying the objects in the problem
    domain
  • Specification
  • Consider interfaces of objects (but no internal
    aspects)
  • Focus on how objects interact in the solution
    domain
  • Implementation
  • Consider all details of objects (external and
    internal)
  • Focus on how to code objects
  • Modeling proceeds from the conceptual to
    implementation
  • Same OO concepts can be used at all levels to
    build models

14
Abstraction
Mental process of selecting some object
characteristics and properties to model and
excluding others that are not relevant
  • Abstraction is always for some purpose
  • Many different abstractions of the same thing are
    possible
  • All abstractions are incomplete descriptions of
    reality
  • We do not need completeness, just modeling
    adequacy!

15
Types of Abstractions
  • Classification - group similar instances of
    objects

DBMS software
Microsoft software
IS_MEMBER_OF relationship
IS_MEMBER_OF relationship
Sybase
. . .
Access
Oracle
Word
PowerPoint
. . .
  • Pick out common properties and ignore unique
    properties

Uses IS_MEMBER_OF relationship
16
  • Aggregation - group dissimilar sets of objects

airplane
IS_PART_OF relationship
fuselage
. . .
wing
landing gear
  • Ignore differences among the parts and
    concentrateon the fact that they form the whole

Uses IS_PART_OF relationship
17
  • Generalization - group similar sets of objects

IS_A relationship
student
superclass/supertype
postgrad
. . .
secondary
undergrad
subclass/subtype
  • Note difference between classification and
    generalization
  • classification applied to individual instances
    of objects
  • generalization applied to sets of objects
    (classes)

Uses IS_A relationship
18
Note We can combine different types of
abstraction when modeling
student
generalization
undergrad
classification
Ivan
. . .
Georgi
Elena
aggregation
. . .
name
student id
Notice the different diagrammatic forms for
generalization, classification and aggregation.
19
UML A collection of diagrams for system
visualization of - Software structure -
Behavior - Physical organization The good
news! - You can model most problems by using
only a small amount of UML - In this course, we
look at this small amount
20
Unified Modeling Language, currently in
specification version 1.4 (version 2.0 due for
release) Combination of earlier methods -
Booch, OMT(Rumbaugh), OOSE (Jacobson) Version
1.0 in early 1997
21
History of UML
22
The Headlines UML is effective for modeling
large, complex software systems It is simple to
learn for most developers, but provides advanced
features for expert analysts, designers and
architects It can specify systems in an
implementation-independent manner You can model
80 of most problems by using about 20 UML.
Structural modeling specifies a skeleton that can
be refined and extended with additional structure
and behavior Use case modeling specifies the
functional requirements of system in an
object-oriented manner
23
UML
  • The basic building blocks of UML are
  • model elements (classes, objects, components,
    use cases, etc.)
  • relationships (associations, generalization,
    dependencies, etc.)
  • Depicted via diagrams
  • class, object diagrams
  • use case diagrams
  • sequence (event) diagrams
  • activity diagrams
  • collaboration diagrams
  • package diagrams
  • deployment diagrams

24
UML Diagrams
  • Two types of diagrams
  • Structural diagrams
  • Behavioural diagrams

25
UML First Pass Use case diagrams - Describe the
functional behavior of the system as seen by the
user. Class diagrams - Describe the static
structure of the system Objects, Attributes,
and Associations. Sequence diagrams - Describe
the dynamic behavior between actors and the
system and between objects of the
system. Statechart diagrams - Describe the
dynamic behavior of an individual object as a
finite state machine. Activity diagrams - Model
the dynamic behavior of a system, in particular
the workflows, i.e. it is essentially a flowchart.
26
UML First Pass - Use Case Diagram Example
Actor
Association
ReadTime
SetTime
WatchUser
WatchRepairPerson
Use case
ChangeBattery
Use case diagrams represent the functionality of
the system from the users point of view
27
UML First Pass - Class Diagram Example
Class
Association
Multiplicity
SimpleWatch
1
1
1
1
1
1
2
2
Battery load()
Time now()
PushButton state push()release()
LCDDisplay
blinkIdx blinkSeconds() blinkMinutes() blinkHours(
) stopBlinking() referesh()
Operations
Attributes
Class diagrams represent the structure of the
system
28
UML First Pass - Sequence Diagram Example
Actor
Object
Message
Activation
Sequence diagrams represent the behaviour as
interactions
29
UML First Pass - Statechart Diagram Example
State
Event
Initial state
Transition
Final state
button12Pressed
Statechart diagrams for objects with interesting
dynamic behaviour - represent behaviour as states
and transitions
30
Packages Models can quickly become complex as
they are refined. This complexity can be dealt
with by grouping related elements into
packages. A package is a grouping of model
elements such as use cases, classes,
etc. Packages are displayed as a rectangle with
a tab attached to their upper-left
corner. Packages allow clients and developers to
organize diagrams into related groups and focus
only on a limited set of diagrams at a time.
31
Package
SimpleWatch
Actor
ReadTime
SetTime
WatchUser
WatchRepairPerson
Use case
ChangeBattery
In this example, use cases dealing with simple
watch operations are grouped together in the
SimpleWatch package. A complex system can be
decomposed into subsystems, where each subsystem
is modeled as a package
32
Other UML Notations
  • UML provides other notations as well.
  • Implementation diagrams
  • Component diagrams
  • Deployment diagrams
  • Object Constraint Language (OCL)

33
UML Core Conventions
  • Rectangles are classes or instances
  • Ovals are functions or use cases
  • Instances are denoted with an underlined names
  • myWatchSimpleWatch
  • IvanFirefighter
  • Types are denoted with nonunderlined names
  • SimpleWatch
  • Firefighter
  • Diagrams are graphs
  • Nodes are entities
  • Arcs are relationships between entities

34
Summary
  • UML provides a wide variety of notations for
    representing many aspects of software development
  • Powerful, but complex language
  • Can be misused to generate unreadable models
  • Can be misunderstood when using too many exotic
    features
  • We concentrate only on a few notations
  • E.g.
  • Functional model use case diagram
  • Object model class diagram
  • Dynamic model sequence diagrams, statecharts and
    activity diagrams

35
Questions?
36
References http//www.sdmagazine.com/documents/s
815/sdm0003z/0003z1.htm http//www.togethersoft.c
om/services/practical_guides/ umlonlinecourse/ind
ex.html http//www.cetus-links.org/oo_uml.htmloo
_uml_tutorials http//www.embarcadero.com/support
/uml_central.asp http//www.csci.csusb.edu/dick/s
amples/uml.html http//www.michael-thomas.com/uml
/ http//www.quicks.demon.co.uk/uml.htm http//p
ipin.tmd.ns.ac.yu/uml/sparx-tut/UML_Tutorial.htm
http//www.omg.org/uml/ http//www.rational.com/u
ml/index.jsp?SMSESSIONNO
37
Reading Bruegge and Dutoit Chapter 2
Modeling with UML
Write a Comment
User Comments (0)
About PowerShow.com