CS 325: Software Engineering
January 19, 2016
System Engineering
•
•
•
•
•
Stepwise Refinement
Traceability
UML Introduction
Use Case Diagrams
Configuration Management
Stepwise Refinement
Traditionally, a top-down approach is
used to design software
• Start with the initial problem
statement
• Break it into a few general steps
• Take each "step", and break it
further into more detailed steps
• Keep repeating the process on
each "step", until you get a
breakdown that is pretty specific,
and can be written more or less
in pseudocode
• Translate the pseudocode into
real code
CS 325
January 19, 2016
System Engineering
Page 20
Traceability
One common document used to
track system requirements is a
traceability matrix, which may be
used to determine the correlation
between system requirements and
user requirements, or between test
cases and system requirements.
The former case can assist in
identifying user requirements that
the system does not meet or system
requirements that are not deemed
necessary by users.
The latter case can ensure that
all system requirements will be
adequately tested.
CS 325
January 19, 2016
System Engineering
Page 21
UML Introduction
The Unified Modeling Language (UML)
is a graphical modeling language for
sketching classes and procedures prior
to coding.
Diagram
Structure
Diagram
Class
Diagram
Composite
Structure
Diagram
Component
Diagram
Deployment
Diagram
Behavior
Diagram
Object
Diagram
Package
Diagram
Activity
Diagram
Communication
Diagram
Interaction
Diagram
Interaction
Overview
Diagram
State
Machine
Diagram
Sequence
Diagram
Use Case
Diagram
Timing
Diagram
UML Version 2.0 defines thirteen diagram types.
CS 325
January 19, 2016
System Engineering
Page 22
UML Introduction
Use Case
• Models interactions between the software system and the “outside world”
Activity
• Models sequential and parallel activities taking place within the software system
Class
• Models the software systems classes as well as their relationships with each other
Object
Sequence
Communication
Timing
• Models instances of classes, usually as a means of clarifying the class itself
• Models the sequence of interactions between system objects when the order is important
• Models the means by which objects within the software system interact
• Models the change in state of system objects over time, usually in response to external events
Interaction Overview
• Models “big picture” system interactions by tying together Sequence, Communication, Timing Diagrams
Composite Structure
• Models how objects work together inside a class to help achieve system goals
Component
Package
State Machine
Deployment
CS 325
January 19, 2016
System Engineering
Page 23
• Models the reusable, replaceable classes and subsystems within the software system
• Models logically related groups of classes into organized structures
• Models the state of system objects and the transitions that may cause the state to change
• Models physical configuration of software and hardware that will comprise system’s implementation
UML Introduction
In iterative software development processes (e.g., spiral),
UML diagrams are often used as a blueprint for the
software system, providing detailed specifications to
which the developers adhere.
Agile software development, on the other hand, tends to
use UML diagrams as a sketch for the software system,
providing rough guidelines for the developers to follow.
The Rational Unified Process was
specifically developed to take
advantage of UML’s features, with Use
Case Diagrams playing a central role in
the Requirements discipline and the
other UML diagrams prominent in the
Analysis & Design discipline.
CS 325
January 19, 2016
System Engineering
Use Case Diagrams
UML Use Case Diagrams assist developers in
understanding customer and user software needs.
The simple Use
Case Diagram at
right illustrates the
interaction
between various
stick figure actors
and several ovalshaped use cases
in a restaurant
system.
CS 325
January 19, 2016
System Engineering
Page 25
Use Case Diagrams
Use Case Diagrams describe what a system does
from the point of view of an external observer.
Use Case Diagrams are helpful in
three ways:
• New use cases generate new
requirements as the system is
analyzed.
• Their notational simplicity
provides a good way to
communicate with clients.
• Collecting scenarios for a use
case may suggest corresponding
ideas for test cases.
CS 325
January 19, 2016
System Engineering
Page 26
Use Case Diagrams
Arrowed associations indicate
that the actor is invoking the use
case, while non-arrowed
associations merely signify that
the actor is associated in some
way with the use case.
The <<extends>> relationship
indicates that one use case
might reuse the behavior of
another use case, depending on
how the system is implemented.
CS 325
January 19, 2016
System Engineering
Page 27
Use Case Diagrams
The <<inherits>>
stereotype is used to
indicate that the actor
(or use case) is a more
specialized version of
the associated actor
(or use case).
This is called the
generalization
relationship.
The <<includes>> relationship indicates
that one use case definitely reuses all
of the behavior of another use case.
CS 325
January 19, 2016
System Engineering
Page 28
Use Case Diagrams
System boundary
boxes can be drawn
around use cases to
indicate the scope of
the system, e.g., to
identify which use
cases will be
delivered in each
major release of the
software system.
CS 325
January 19, 2016
System Engineering
Page 29
Configuration Management
When multiple developers are working on the
same software, there is a danger that one
developer might overwrite the changes made
by another developer.
Version control systems like Subversion are
designed to eliminate such dangers from
collaborative efforts.
CS 325
January 19, 2016
System Engineering
Page 30
Configuration Management
One means of protecting everyone’s changes
is to only permit one developer to have write
access to any file at a time.
This approach is hard to administer, compels unnecessary
serialization (i.e., what if Harry and Sally are working on
independent parts of the same file?), and might ignore
needed serialization (what if Harry and Sally are working on
separate, but dependent files?).
CS 325
January 19, 2016
System Engineering
Page 31
Configuration Management
Subversion emphasizes an alternative approach,
allowing developers to edit whatever files they want
and then merge their respective versions.
When the versions are merged, a determination is
made about whether they potentially conflict with
each other, in which case the developers must
manually resolve the conflicts themselves.
CS 325
January 19, 2016
System Engineering
Page 32