software development method, page 1 a simple software method

Software Development Method, page 1

A SimpleSoftware Method


Software Engineering Software Engineering MethodsMethods

• Most methods consist of both a modeling modeling language and a processlanguage and a process (who is doing what and when).

• The modeling language, the notation, typically include some visual languagevisual language (different types of diagrams).

• A tooltool to support the method is also crucial.


UML Is Not a ProcessUML 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 independentThe 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 use-case-driven, architecture centric, iterative and incremental. (Example of method: RUP)


• The Management ProcessThe Management Process - schedules work, resources and deliveries, monitor progress.

• The Development ProcessThe Development Process - develop software from requirements.

Software Development - Two Software Development - Two ProcessProcesseses at the Same Time at the Same Time


• Since the management process controls project, risk it has to be paramount.

• Some methods contains both processes, e.g. Some methods contains both processes, e.g. RUPRUP, others are mostly development processes, like Catalysis, and others again are management processes, e.g. Dynamic Systems Development Method (DSDM).

The The Development Development Process is Subservient Process is Subservient to the Management to the Management ProcessProcess


The waterfall model of software developmentThe waterfall model of software developmentRequirements Capture

Purpose: communicate with end users and document the requirements. “Defining the right project”.

Requirements CapturePurpose: communicate with end users and document the requirements.

“Defining the right project”.

AnalysisPurpose: understand the problem domain and the system to be implemented.

AnalysisPurpose: understand the problem domain and the system to be implemented.

DesignPurpose: transform the products of the analysis phase into a more precise

description that can be refined into an executable program.

DesignPurpose: transform the products of the analysis phase into a more precise

description that can be refined into an executable program.

ImplementationPurpose: transform the products of the design phase into concepts that

can be executed on the computer (programming).

ImplementationPurpose: transform the products of the design phase into concepts that

can be executed on the computer (programming).

Testing and IntegrationTesting and Integration


Requirements CaptureRequirements Capture• There are two types of requirements: functional and functional and

nonfunctionalnonfunctional.• Functional requirements is often modeled with use Functional requirements is often modeled with use

casescases. 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: a nonfunctional requirement: “the data “the data is stored on ASCII files”is stored on ASCII files”.

• Sometimes the user interfaceuser interface is developed or a prototype of the system is made.


AnalysisAnalysis• The analysis includes object analysis and object analysis and

behavior analysisbehavior analysis.

• In object analysisobject analysis all the key concepts related to the system are documented with the help of class diagramsclass diagrams.

• In behavior analysisbehavior analysis the system is model as a black box, only external functionality is external functionality is

modeledmodeled. A operation list is produced.


• Design deals with objects and functions that Design deals with objects and functions that will be programmedwill be programmed.

• The classesclasses from the analysis phase is extended with operationsextended with operations. Classes necessary for the implementation are added.

• The operations are modeled with sequence operations are modeled with sequence diagramsdiagrams. From the sequence diagrams we can see the responsibility of the different classes and how the classes interact.

DesignDesign


Static pathStatic path

use case 1

use case 2

Requirements

class X

attribut1....

...

operation 1

operation 2

....

operation 1

operation 2

....

AnalysisClass Diagrams

OperationLists

Test Cases

use case 1

use case 2

void func1(){......}......

void func1(){......}......

Methods

class X{....}

.....

class X{....}

.....

ImplmentationDeclarations

class X

attribut1....

method()

DesignClass Diagrams

class Y

attribut1....

Sequence Diagrams

obj1

met1()

Obj2

Functional pathFunctional path


Iterative and incremental development.Iterative and incremental development.• Each cycle consist of one or more of the process components

(requirement, analysis,...), typically only a partonly a part (an increment) of the required functionality is implemented through each cycleis implemented through each cycle.

• At each cycle the requirements are verified and validatedrequirements are verified and validated, this can lead to changed requirements.

• In each cycle the most risky functionality is addressedIn 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 Implementation Testing Requirements ....

First Cycle ....


Types of risksTypes of risks

• The requirements do not specify the right systemthe right system.

• The selected technologytechnology is not adequatenot adequate for solving the given types of problems.

• People with the right skillsright skills are not available to the project.

• There are political forcespolitical forces that will try to stop or delay the project.


High-level view of the development High-level view of the development phasesphases

• InceptionInception - the vision of the project is specified. A go-ahead of the project is given.

• ElaborationElaboration - the project is planned. Features and architecture is elaborated.

• ConstructionConstruction - the system is developed through a series of iterations.

• TransitionTransition - the product is set in production. User training is given.• In each phase the cycle of analysis, design, implementation and In each phase the cycle of analysis, design, implementation and

testing is preformed repeatedly.testing is preformed repeatedly.


The development processThe 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.

Inception

R = Requirements

A = Analysis

D = Design

I = Implementation

T = Testing

R A R A R A D A D I D I T I T

Elaboration Construction Transition

Example of development process:


The Iconix Development

Process


Use Case Driven Object Modeling with UMLtm:A Practical Approach

by Doug Rosenberg and Kendall Scott


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.


Use CaseModel Boundary1 Entity1Control1

Control2 Entity2

Robustness Diagram(Class Diagram)

DesignClass DiagramsDomain Model

Class Diagrams

SequenceDiagram

obj1

met1()

Obj2

1 User..2 …

Use Case Text

Ok

Cancel

GUI Prototype

class AB

attribut1....

class A

attribut1....

class AA

attribut1....

Dynamic

Static


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.”

• 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.

class AB

attribut1....

class A

attribut1....

class AA

attribut1....

Ok

Cancel


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 (extensions)

• Robustness Analysis. For Each Use Case:– 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.

--- 1 --- EndUser chooses Tourism/ Environment--- 2 --- EndUser chooses fishing--- 3 --- ……

Boundary1 Entity1Control1

Control2 Entity2class AB

attribut1....

class A

attribut1....

class AA

attribut1....


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.

SequenceDiagram

obj1

met1()

Obj2

1 User..2 …

Use Case Text


Use CaseModel Boundary1 Entity1Control1

Control2 Entity2

Robustness Diagram(Class Diagram)

DesignClass Diagrams

Domain ModelClass Diagrams

SequenceDiagram

obj1

met1()

Obj2

class AB

attribut1....

class A

attribut1....

class AA

attribut1....

Dynamic

Static


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 activities.


The Domain Modeling Is A Conceptual Model - Perspectives

• ConceptualConceptual: 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.

• SpecificationSpecification: 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.

• ImplementationImplementation: The class diagrams produced will reflect the classes that is to be implemented.


Class• An objectobject has three characteristics: statestate, behaviorbehavior and a a

unique identificationunique identification.

• A class is a template for instantiation of objectsA class is a template for instantiation of objects. A class diagram contains an attribute (state) and a method (behavior) section:

Class Nameattribute: 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 It is for example usual to leave usual to leave the method section out under analysesthe method section out under analyses.


Discover Classes• The high-level problem statement

• Lower-level requirements

• Expert knowledge of the problem space

• Use cases if already present


Discover Classes Grammatical Inspection

NounNoun: a word that names or denotes something.E.g.: Fisher doesn’t know which river to choose…. Fisher River

Noun PhrasesNoun Phrases:E.g.: Fisher selects a seasonal fishing license…

FishingLicense

cardType:String

Nouns become objects

Nouns Phrasesbecome attributes


Operations and Associations Grammatical Inspection

VerbsVerbs: E.g.: He uses the localisation service to find his object in the service. Locator

getObject()

VerbVerb Phrases Phrases:E.g.: The user can use different devices …

EndUser

Verbs becomeoperations

Verb Phrasesbecome associations

Deviceuses


Attributes Rather Than Objects

PossessivePossessive Phrases Phrases:E.g.: A fishing card has a limited duration..

FishingCard

Possessive Phrases indicate that

nouns should be attributes rather than objects

duration


QuizAnswer

Robustness Diagram Symbols(Class Stereotypes)

QuizResult

QuizScheduler

• Control Class:Control Class: Manage interactions. Its behavioir is specific to a use case, which it usally does not outlive.

• Boundary Class:Boundary Class: Mediate between the system and outside actors (e.g. sensor). Often their lifeline coincide with the life of the system.

• Entity Class:Entity Class: Passive objects, they do not initiate interactions. May participate several use cases.


Robustness Diagram Rules

Allowed

Not Allowed


[1] ”…you’re not finished with a use case until the text and the robustness diagram match.”

Use Case ~ Robustness


ReferencesReferences• 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

http://www.rational.com/uml/documentation.html

software development method, page 1 a simple software method

Documents

software development

development processes

complete development

simple software method

management process slide

standard process

example of method

analysis purpose