Advanced

Programming
COSC 2020
Unit 2: Software Development Tools

• Software development methods

– Waterfall method
– Agile method
• UML Diagrams
– We’ll use these in a lecture or two
SOFTWARE ENGINEERING
How do you know that your code works?

• What does “works” even mean?

– Runs without crashing?
– Seems to work properly when you play around with it?
– Meets specification?
• How do you prove this
– To yourself?
– To your team?
– To your (paying) client?
Software Engineering
“The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of
engineering to software.”

- IEEE Standard 610-1990

“Engineering is the systematic application of scientific knowledge in creating and

building cost-effective solutions to practical problems and service of mankind.
Software engineering is that form of engineering that achieves the principles of
computer science and mathematics to achieving cost-effective solutions to
software problems.”

- CMU/SEI-90-TR-003
Waterfall software development

• Linear and sequential Conceptualize

– Progress flows downward Analyze

• Requires completely
finishing each step before System Design

moving on Object Design

• Good for projects with

Implementation

– Fixed scope and target Integration and

Testing

– Known (or knowable)

requirements Deployment

– Known technology
V software development

• A “modified waterfall”
– Bent to show high/low level
thinking

• Highlights the level of

abstraction
– Begin/end with high-level
ideas
– Implementation (middle) is
the most concrete and
specific
Iterative software development

• A series of “mini
waterfalls”
– Divide the project into
smaller tasks or objectives

• Allows step-by-step
construction
– Build a basic functionality
first
– Add more functions later
Criticisms of waterfall (and its relatives)

• Progress is slow-moving
– No moving forward until the current step is completely
done
– Useable and testable code occurs late in the process
• Not flexible or iterative
– No going backwards once the specification is set
– Feedback arrives late (or not at all)
• No way to discover requirements as you develop
– Doesn’t handle unknown requirements very well
Agile software development

• A set of informal principles developed in the 1990s

– “Manifesto for Agile Software Development” (2010)

• Focus is on tighter coupling between client and

developer
– More frequent communication and feedback
– Flexibility for evolving or changing specifications
– Faster turnaround to something working/demonstrable
Extreme programming

• Good programming
practices
– … taken to 10 (or 11)

• Features include
– Partner coding
– Continuous integration
– Frequent client interaction
Test-driven development

• “Tests are the specification”

– Convert specification into unit test code first
• Iterate on specified behavior to the level of testable detail
– Run tests early and often on code
• Most/all tests will fail early on because you’re not done yet!
– Measure success by testing
• Work is complete exactly when all tests are passing
– “A bug isn’t an error in logic; it’s a test that was not
written.”
Test-driven development steps

1. Write a test
– Describe the expected or correct behavior for a feature
– Convert a bug report into a test that reproduces the
failure
2. Run all tests (and the new test will fail)
– This validates that the test you wrote does indeed work
properly
3. Write the simplest solution that passes your test
4. Run all tests again (to confirm your first solution
works)
UML DIAGRAMS
What is UML

• A standardized visual language

– Describes software design and development (and some
related aspects)

• An evolving standard
– Developed at Rational Software (1994-96): UML 0.x
– Object Management Group standard (1997-2005): UML 1.x
– ISO standard (2005 – present): UML 2.x
A UML diagram of UML diagrams
Sequence diagrams
Sequence diagrams

• Used to model interactions and messages

– Lifelines for interaction participants
• Indications of creation and destruction
– Messages between participants
• Start and end of behaviors
• Messages and replies
Lifelines

• One lifeline per participant

– Begins at “head”
• Identifies participant (and
maybe type)
– Vertical line (dashed or solid)

• One line per object

– Occasionally, the object is a
collection
Executions – doing stuff

• Indicate work by
participant
– A rectangle over the lifeline
• Typically message-driven
– Started by receiving a
message
– Can involve sending
messages too
• Can overlap
– Call method on self
– Call method on other object
that calls back
Sending a message

• Interaction between participants

– Directed edge from one lifeline to another
– Leaves from an execution
• Asking a question/behavior during your work
• Usually annotated
– Describe the action qualitatively
– (later) a method name/signature (esp. in OOP design)
Wait or continue?

Synchronous call Asynchronous call

• Sender waits for a response • Sender does not wait for a
– Typical method call behavior response
• Solid arrowhead – Does other work until response
arrives
• Open arrowhead
What’s the answer?

• A reply to an earlier
message
– Not triggering a new
execution
– Often the end of a recipient
execution

• Dashed line, open arrow

– Allows sync. caller to resume
The beginning and the end

Create message Delete message

• Sender is creating receiver • Sender is destroying receiver
• Dashed line, open arrow • Solid line, solid arrow
– Big ‘X’ to end lifeline
You have to choose

• Alternatives
– Conditional message
• Only one or the other
– Reflects an if/else style
execution

• Option
– Conditional message
– Reflects an if (without else)
Play it again

• Looping behavior
– Send the same message
again
– Often recipient is a
collection
• Loop is a for-each loop
• Can be annotated
– Min/max iterations
– Condition to continue
Class diagrams

• Frequently used in OOP software design

– Show classes involved in software
• Attributes, behaviors, access rules
– Show relationships between classes
• Interactions, ownership, derivation, dependency

• UML is language-independent
– These are OOP ideas without syntax
Class blocks

• Core elements of class

diagrams
– Represent one class in a
software project
• Not one instance, but whole
class

• Describe the class

– Type
– Attributes
– Operations
Member properties

• Member visibility can be marked

– + public
– # protected
– ~ package
– - private
• Classifier members (static) are underlined
• Abstract members are italicized
Relationships

• Relationships are marked with “edges” between class

diagrams

• The type of relationship is specified by

– Line style
– Arrowhead style
– Annotations (“adorned”)
Association

• Generic interactions
– Typically static relationships
– Often ornamented to explain
• Direction can be specified
– Uni- or bi-directional

• Can incorporate 2+
entities
Aggregation and composition

• HAS A relationships
– Always binary
– Arrowhead points to the
container

• Aggregation (open
arrowhead)
– Non-exclusive, non-
destructive

• Composition (filled
arrowhead)
Generalization

• IS A relationship
– Typically inheritance or
implementation
– Arrowhead points to more
general type

• Can be styled as
– Separate target
– Shared target
Activity Diagrams
Activity diagrams

• Used to model stepwise actions or activity

– Describes a behavior
– Highlights sequential activities
• Relative order
• Decision-making and branching
• Concurrency

• Appears as a “flowchart”
What’s in an activity?

• Activity nodes
– Represent an action taken
• Variable initialization or assignment; arithmetic; function call
– May be layered
• A “high level” activity diagram might describe an action in a
single node
• A subsequent diagram might expand that node to a full diagram
of its own
Organizing your activities

• “Swim lane” notation

– Separates actions by their
actor/agent
– Clarifies workflow
• Who does what
• Who prompts whom
• What order do things happen in
We’re gonna need a bigger diagram

• Connectors
– Purely for spatial
organization
• A “portal” to another place or
page
– Useful for
• Avoiding a long arrow edge
• Avoiding edge crossings
• Moving between pages
Controlling activity flow
Starting and stopping

• Initial node • Final node

– Starting point for activity – Ending point for activity
– Usually appears once – Appears 1+ times
• Concurrent flows might have • First one reached during
multiple, but it’s not as execution ends that execution
common – “Circled circle”
– Solid black circle • A “bullseye” or target
• Maybe annotated to explain
inputs
Decisions, decisions…

• Decision nodes
– “Decision diamond”
– Branching execution
• One way in, many ways out
• Flow follows exactly one
branch
– Branches have guards
• Conditions to choose (poss.
“else”)
– Decisions can be annotated
too
Merging paths

• Merge nodes
– Bring flows back together
• Usually after decisions
– Merge alternatives
• At most one input branch will
be taken
• NOT for concurrent execution
Doing two things at once

• Fork node
– “Branching bar”
– Concurrent execution
• All output branches occur at
the same time
– Branches represent
simultaneous activities
Putting it back together

• Join node
– Brings concurrent flows back
together
– A synchronization point
• All flows must reach the black
bar
• THEN flow continues out the
single exit