Transcript A Simple Software Methos + Iconics

A Simple
Software Method
Software Development Method, page 1
Software Engineering
Methods
• Most methods consist of both a modeling
language and a process (who is doing what and when).
• The modeling language, the notation, typically
include some visual language (different types of
diagrams).
• A tool to support the method is also crucial.
Software Development Method, page 2
UML Is Not a Process
A “complete” development process defines:
- Who is doing What,
- When to do it, and
- How to reach a certain goal
• The UML is intentionally process independent, and defining a
standard process was not a goal of UML. Different domain may
require different processes.
• But the UML authors promote a development process that is usecase-driven, architecture centric, iterative and incremental.
(Example of method: RUP)
Software Development Method, page 3
Software Development - Two
Processes at the Same Time
• The Management Process - schedules
work, resources and deliveries, monitor
progress.
• The Development Process - develop
software from requirements.
Software Development Method, page 4
The Development Process is Subservient
to the Management Process
• Since the management process controls project,
risk it has to be paramount.
• Some methods contains both processes, e.g.
RUP, others are mostly development processes,
like Catalysis, and others again are management
processes, e.g. Dynamic Systems Development
Method (DSDM).
Software Development Method, page 5
The waterfall model of software development
Requirements Capture
Purpose: communicate with end users and document the requirements.
“Defining the right project”.
Analysis
Purpose: understand the problem domain and the system to be implemented.
Design
Purpose: transform the products of the analysis phase into a more precise
description that can be refined into an executable program.
Implementation
Purpose: transform the products of the design phase into concepts that
can be executed on the computer (programming).
Testing and Integration
Software Development Method, page 6
Requirements Capture
• There are two types of requirements: functional
and nonfunctional.
• Functional requirements is often modeled with
use cases. A use case is a short story describing a
particular use of the system - a model of a
dialogue between an actor and the system. The
model can be visualized with a use case diagram!
• Example of a nonfunctional requirement: “the
data is stored on ASCII files”.
• Sometimes the user interface is developed or a
prototype of the system is made.
Software Development Method, page 7
Analysis
• The analysis includes object analysis and
behavior analysis.
• In object analysis all the key concepts related
to the system are documented with the help
of class diagrams.
• In behavior analysis the system is model as a
black box, only external functionality is
modeled. A operation list is produced.
Software Development Method, page 8
Design
• Design deals with objects and functions that
will be programmed.
• The classes from the analysis phase is
extended with operations. Classes necessary
for the implementation are added.
• The operations are modeled with sequence
diagrams. From the sequence diagrams we
can see the responsibility of the different
classes and how the classes interact.
Software Development Method, page 9
Static path
Requirements
use case 1
Analysis
Class Diagrams
Design
Class Diagrams
Implmentation
Declarations
class X
class X
class Y
attribut1
....
attribut1
....
attribut1
....
...
method()
class X{
....
}
.....
Test Cases
use case 1
use case 2
Operation
Lists
Methods
Sequence Diagrams
use case 2
operation 1
obj1
operation 2
Obj2
void func1()
{......}
......
met1()
....
Functional path
Software Development Method, page 10
Iterative and incremental development.
• Each cycle consist of one or more of the process components
(requirement, analysis,...), typically only a part (an increment)
of the required functionality is implemented through each
cycle.
• At each cycle the requirements are verified and
validated, this can lead to changed requirements.
• In each cycle the most risky functionality is
addressed, the cycle is aimed at eliminating the risk. In this
way serious problems is exposed at an early stage, in some
cases this can lead to termination of the project.
Requirements
Analysis
Design
First Cycle
Implementation
Testing
Requirements
....
....
Software Development Method, page 11
Types of risks
• The requirements do not specify the right system.
• The selected technology is not adequate for
solving the given types of problems.
• People with the right skills are not available to the
project.
• There are political forces that will try to stop or
delay the project.
Software Development Method, page 12
High-level view of the development
phases
• Inception - the vision of the project is specified. A go-ahead
•
•
•
•
of the project is given.
Elaboration - the project is planned. Features and
architecture is elaborated.
Construction - the system is developed through a series of
iterations.
Transition - the product is set in production. User training
is given.
In each phase the cycle of analysis, design, implementation
and testing is preformed repeatedly.
Software Development Method, page 13
The development process
At each phase several complete
cycles are possible.
In the beginning requirements
capture and analysis is focused, the
other process components are more
important later on.
R
= Requirements
A
= Analysis
D
= Design
I
= Implementation
T
= Testing
Example of development process:
R A
R A
Inception Elaboration
R A D
A D
I
Construction
D
I
T I
T
Transition
Software Development Method, page 14
The Iconix
Development
Process
Software Development Method, page 15
Use Case Driven Object Modeling with UMLtm:
A Practical Approach
by Doug Rosenberg and Kendall Scott
Software Development Method, page 16
Significant Features
• Iterative and Incremental.
• Traceability ~ you always refer back to the
requirements. (Objects are there to satisify
use cases.)
• A ”minimalist” approach - a minimal
number of steps and use of diagram types.
Software Development Method, page 17
Software Development Method, page 18
Dynamic Use Case Text
1 User..
2…
Cancel
Use Case
Model
Boundary1
Control1
obj1
Obj2
met1()
Entity1
Ok
Sequence
Diagram
GUI Prototype
Control2
Entity2
Robustness Diagram
(Class Diagram)
class A
Static
attribut1
....
class AA
class AB
attribut1
....
attribut1
....
Domain Model
Class Diagrams
Design
Class Diagrams
Software Development Method, page 19
Requirements Analysis
• Domain Modeling
– Identify your real-world domain objects and the
generalization and aggregation relationships among
those objects.
• GUI design / Prototyping
– If it’s feasible, do some rapid prototyping of the
proposed system. (Mine your legacy software). ”…the
best way to identify chunks of use cases in connection
with a prototype is to write a rough user manual, as if
the prototype were an actual fully working system.”
class A
attribut1
....
class AA
class AB
attribut1
....
attribut1
....
Cancel
Ok
• Use Case Modeling
– Identify your use cases.
– Organize the use cases into packages.
– Allocate functional requirements to the use cases and
domain objects at this stage.
Software Development Method, page 20
Analysis And Preliminary Design
• Write Use Case Text
– Write describtion of the normal flow (also called main
flow, the ”sunny day” scenario) and the alternate flows
--- 1 --- EndUser chooses Tourism/ Environment
(extensions)
• Robustness Analysis. For Each Use Case:
--- 2 --- EndUser chooses fishing
--- 3 --- ……
– Identify a first cut of objects that accomplich the
selected scenario.
– Update your domain model and your design class
diagrams with new objects and attributes as you
discover them.
class A
attribut1
....
Boundary1
class AA
class AB
attribut1
....
attribut1
....
Control1
Entity1
Control2
Entity2
Software Development Method, page 21
Design
• Interaction Modeling (Allocate behavior).
For Each Use Case:
– Identify the messages that need to be passed between objects, the objects,
and the associated methods to be involved.
Draw a sequence (or collobaration) diagram with use case text running
down the left side.
Continue to update the design class diagram with attributes and operations
as you find them.
Use Case Text
1 User..
2…
obj1
Obj2
met1()
Sequence
Diagram
Software Development Method, page 22
Dynamic
obj1
Obj2
met1()
Use Case
Model
Boundary1
Control1
Entity1
Sequence
Diagram
Control2
Entity2
Robustness Diagram
(Class Diagram)
class A
Static
attribut1
....
class AA
class AB
attribut1
....
attribut1
....
Domain Model
Class Diagrams
Design
Class Diagrams
Software Development Method, page 23
The use case model ~ heart of the
approach
• Robustness analysis
– What satisfy each use case?
– Propose a set of collaborating objects that can solve each use
case.
• Interaction modeling
– Refine the results of robustness analysis.
– Show how messages flow between the collaborating objects
that solves each use case.
The use case model is pumping through the
following modeling Software
activities.
Development Method, page 24
The Domain Modeling Is A
Conceptual Model - Perspectives
• Conceptual: The concepts of the problem domain are
addressed. The class diagrams produced under the analysis
will typically be of the conceptual type. The diagrams are
not tied to any software implementation.
• Specification: This perspective is closer to software.
Interfaces is specified, but not the implementation. It is
said that types are specified and not classes. This
perspective is typically employed under design.
• Implementation: The class diagrams produced will
reflect the classes that is to be implemented.
Software Development Method, page 25
Class
• An object has three characteristics: state, behavior
and a unique identification.
•
A class is a template for instantiation of
objects. A class diagram contains an attribute (state) and
a method (behavior) section:
Class Name
attribute: Type = initialValue
....
method(arg list): return type
....
•
The level of and the numbers of details in the class
diagram can vary, this depends on where you are in the
development process. It is for example usual to leave
the method section out under analyses.
Software Development Method, page 26
Discover Classes
• The high-level problem statement
• Lower-level requirements
• Expert knowledge of the problem space
• Use cases if already present
Software Development Method, page 27
Discover Classes
Grammatical Inspection
Noun: a word that names or
denotes something.
E.g.: Fisher doesn’t know which
river to choose….
Noun Phrases:
E.g.: Fisher selects a seasonal
fishing license…
Nouns become objects
Fisher
River
Nouns Phrases
become attributes
FishingLicense
cardType:String
Software Development Method, page 28
Operations and Associations
Grammatical Inspection
Verbs:
E.g.: He uses the localisation service
to find his object in the service.
Verbs become
operations
Locator
getObject()
Verb Phrases:
E.g.: The user can use different
devices …
Verb Phrases
become associations
EndUser
uses
Device
Software Development Method, page 29
Attributes Rather Than Objects
Possessive Phrases:
E.g.: A fishing card has a limited duration..
Possessive Phrases indicate that
nouns should be attributes rather than objects
FishingCard
duration
Software Development Method, page 30
Robustness Diagram Symbols
(Class Stereotypes)
• Control Class: Manage interactions. Its
behavioir is specific to a use case, which it
usally does not outlive.
QuizScheduler
QuizAnswer
QuizResult
• Boundary Class: Mediate between the
system and outside actors (e.g. sensor).
Often their lifeline coincide with the life
of the system.
• Entity Class: Passive objects, they do not
initiate interactions. May participate
several use cases.
Software Development Method, page 31
Robustness Diagram Rules
Allowed
Not Allowed
Software Development Method, page 32
Use Case ~ Robustness
[1] ”…you’re not finished with a use case
until the text and the robustness diagram
match.”
Software Development Method, page 33
References
•
•
•
•
•
•
•
Grady Booch, James Rumbaugh and Ivar Jacobson:
The Unified Modeling Language User Guide.
Addison-Wesley, 1999
James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy and William
Lorenzen:
Object-Oriented Modeling and Design.
Prentice Hall, 1991
Martin Fowler with Kendall Scott:
UML Distilled.
Addison-Wesley, 1997
Terry Quatrani:
Visual Modeling with Rational Rose and UML.
Addison-Wesley, 1998
Ari Jaaksi:
A Method for Your First Object-Oriented Project.
JOOP - The Journal of Object-Oriented Programming, Januar 1998
Rational software:
http://www.rational.com/uml/documentation.html
[1] Doug Rosenberg and Kendall Scott: Use Case Driven Object Modeling with UML:
A Practical Approach
Addison-Wesley
Software Development Method, page 34