17. mars store aud moderne systemuviklingsmetoder kjetil ... filealistair cockburn, crystal 1997,...

Telecom and Informatics 1

17. marsStore aud

Moderne systemuviklingsmetoder

Kjetil Jørgensen-Dahl, Objectnet og

Arne-Jørgen Berre, SINTEF, UiO


Innhold

1) CV intro 5 min. (1 slide pr pers) 2) Intro 15 min (Begge) : referanseramme: Prosess og

produkt, fossefall 3) 25 min (Arne-Jørgen) - Formaliserte og modellorienterte

metoder

Pause

4) 25 min (Kjetil) - Smidige prosesser 5) 20 min - Spørsmål/debatt


Arne-Jørgen Berre Siviling. linjen for databehandling, NTNU, 1984 Dr.ing ”OO rammeverk for interoperabilitet”, NTNU, 1993

Ansatt ved SINTEF IKT, Samvirkende og tiltrodde systemer, siden 1984, Førsteamanuensis II, OMS gruppa siden 1996 Arbeid relatert til Moderne systemutviklings metoder og verktøy: Smalltalk utvikling 1984-1990: Literate Programming, Pair Programming, CRC , Testbasert Refactoring, OOAD (OORAM) 1987-1988: Xerox PARC NW, Tektronix Lab, OGC bl.a. med Kent Beck og Ward Cunningham (CRC, XP) Dr. Ing, NTNU 1993, "Object-oriented framework for systems integration and interoperability" Faget MMO/MBSU ved UiO, siden 1996 (med Tryge Reenskaug, OORAM og Alistair Cockburn, Crystal 1997, Catalysis, KoBra, UML Components, COMET for Components, Services and MDA) Bruk av SCRUM i NetAccount 2000-2001, Norge og India UML for EDOC, UML 2.0 2001-2005 SINTEF internprosjekt om Agile Modeling Methods, 2004-2005 Arbeid/Forskningsfokus 2005: MDI - Model Driven Interoperability and Extreme Modeling


Kjetil Jørgensen-Dahl

Siviling. Industriell økonomi med datateknikk, NTNU

Accenture 1998-2003, Objectnet as 2004- Kunder: Storebrand, Nordea, Finansbanken, Bladcentralen, Skattedirektoratet, SND

Invest, Vegdirektoratet, Telenor

Systemutviklingsprosjekter – fra krav t o m systemtest Roller: Utvikler, teamleder, funksjonell arkitekt, teknisk arkitekt,

systemtestleder, utvikler… Teknologiske plattformer:Diverse - de siste årene Java-basert Involvert i interne kompetansegrupper innenfor arkitektur,

datavarehus, Java, systemutviklingsprosess, m fl javaBin-styremedlem og redaksjonsmedlem java.no

Pappa til Theo og samboer med Marte!


Project ManagementProcess Configuration

RequirementsAnalysis

ArchitectureLevel

Class Level

Implementation

Test

Design

preliminaryiteration(s)

iter.#1

PhasesProcessComponents

Iterations

Elaboration Construction TransitionInception

SupportingComponents

iter.#2

iter.#n

iter.#n+1

iter.#n+2

iter.#m

iter.#m+1

Unified Process Framework

Process Workflows

Business ModelingBusiness ModelingRequirementsRequirements

Analysis Analysis DesignDesign

ImplementationImplementationTestTest

DeploymentDeployment

ManagementManagement

Conf. MngmtConf. Mngmt

EnvironmentEnvironment

Supporting Workflows

Disciplines


Systemutviklingsmetode - formål ”Veikart”

Konsept til realisert løsning

Forvaltning … og utfasing

Sikre Rett funksjonalitet Rett kvalitet

Kontroll Tid Ressurser Risiko

Formidle kunnskap Erfaring Forskning

Prosessforbedring Felles språk Repeterbarhet


Antall - og rigiditet i - retningslinjerFå/smidige

Mange/sterke

Livssyklus Konseptutvikling – Krav – Design – Utvikling – Vedlikehold

Metoders omfang

ForretningsnivåKonsern (”enterprise”)

Bedrift (”business”)

Prosjekt med flere team

Prosjekt med ett team

Individ

Områder dekket Styringsprosesser

Teknisk fremgangsmåte

Risiko/muligheter

Måling

Kundeinteraksjon

Kilde: Boehm and Turner, Balancing Agilty and Discipline, 2004 (i Kjetils oversettelse)


Noen begreper

Big bang! Inkrementell Iterativ Evolusjonær

Smidig Plan-drevet

”High-Ceremony” Disiplin

Metode Prosess Teknikk

Hacking


Formaliserte og modellorienterte

> A) Formaliserte og modellorienterte: ER/DFD, OO (RUP, OORAM), Komponenter, Tjenester(SOA), MDD (COMET)

> 1980-1990:ER, DFD > 1990-2000: OO (CRC), RUP, Refactoring/Testing > 2000-2010: Komponenter, tjenester , MDD/MDA

- Extreme Modeling ?, Extreme Architecture


PhaseClass

TraditionalSA/SD/ERA

SA-based OO

ERA-based OO

Hybrid SA/ER-based OO

SA - Yordon SD - Page Jones

ERA - Chen ER-Rel.db - 3NF

OO RT SA - Wards

OOA/OOD - Coad/Yordon

OMT - Rumbaugh et. al

Fusion - HP

OOAD - Booch (93 w/C++)

HOOD - ESAOOSD - Wasserman

SD-basert OO

OO-based

RDOOD - Wirfs-Brock et. al

CRC-cards - Cunningham

OOram - Reenskaug et. al

ANALYSIS DESIGN DETAILED DESIGN

OOAD - Martin/Odell

OSDL-92 - CCITT/Bræk et. alOOSE/ObjectOry - Jacobson

Ada(C++)-based

SDL-based OO

UML (96)Booch/OMT/ObjectOry

OOAD metoder

Catalysis, Syntropy, SOMA, OBA, BHS, ...

1980

1987

1990


Historisk fokus

Kvalitet og Produktivitet

Modellering (mdlg)

Abstraksjon ogModularisering

Gjenbruk ogVedlikehold

Funksjonell mdlg ( -55 -> )Data mdlg (-60 ->)Simula 1967 + mdlg av “individer” mdlg av individers oppgave ( -70 ->)“Oppgave-behandlere”/ “saksbehandlere”

[Oppgavefokus]

SW Engineering +komplekse systemer fra velprøvete delerAbstrakte Data Typer1965-KlassifiseringFerdiglagete deler / komponenter av gitt “type”[Eksterne egenskaper]

Biblioteker ( -55 -> )Komponenter og rammeverk ( -80 -> )Patterns (-90 -> )

Vedlikehold kostbartØkende kompleksitet / størelse.

[modulbygging]“Splitt og hersk”: store, komplekse problemer deles opp i et sett av små, selvstendige og enkle problemer. (i ett eller flere trinn!)


Evolution of methodologies

UML1.0

UML1.1

UML1.2

UML1.3

UML1.4

OMT

Objectory

Booch

UML Components

Catalysis

OOram

KobrA

COMET

UML4EDOC

UML2

Pulse

UP

RUP

Notation

Process 2002

2001

1995-1999

2000


Evolution of the UML

Booch ´91

Booch ´93

Unified Method 0.8

UML 1.0

OMT - 2

OMT - 1 OOSE

UML 0.9 & 0.91

OOPSLA ´95

June ´96 & Oct ´96

Submission of UML 1.1 to OMGfor adoption, Sept ´97

Other methods

publicfeedback UML Partners’

Expertise

UML 1.1 (Sept. 1997)

Taskon,SINTEF

UML 1.4UML 2.0

(2004)


“Skandinavisk” Modellerings-perspektiv

A program execution is regarded as a physical model, simulating the behaviour of either a real or imaginary part of the world.A physical model consists of objects, each object is characterized by attributes and a sequence of actions. Objects organize the substance aspect of phenomena, and transformations on substance are reflected by objects executing actions.Objects may have part-objects. An attribute may be a reference to a part object or to a separate object. Some attributes represent measurable properties of the object.The state of an object at a given moment is expressed by its substance, its measurable properties and the actions going on then. The state of the model is the states of the objects in the model.

(Fra Simula)


Basis for OO Teknologi

Kvalitet og Produktivitet

Modellering Abstraksjon ogModularisering

Gjenbruk ogVedlikehold

Objekt Modell

Klassifisering/Instansiering Innkapsling Deling

Arv Polymorfisme


Objektorientert Modell

En objektorientert modell er en (simulerings) modell som består av samspillende objekter i interaksjon med hverandre.

En parallell i “virkeligheten”: en bil. Den består av et sett deler / komponenter som samvirker i et gitt mønster.( ikke alle påvirker alle andre direkte; interaksjonene/samspillet er diktert av oppgaver og hensikt)


CRC Method, class, responsibilities, and collaborators Method to learn

the most basic OO concepts plus OO “thinking” “The most effective way of teaching the idiomatic way of thinking

with objects is to immerse the learner in the "object-ness" of the material. To do this we must remove as much familiar material as possible, expecting that details such as syntax and programming environment operation will be picked up quickly enough once the fundamentals have been thoroughly understood.”

Technique also very useful during informal and creative analysis and design

Created by Kent Beck and Ward Cunningham,Textronix, 1989


The CRC-Cardan object of paper personalizing the object

Class (Name):

Responsibility: Collaborators:


UML og ( R )UP

UnifiedModelingLanguage

Process

Convergence Today Unification

leads to “standards”

Convergence in the future

Process frameworks through consensus

Two parts of a Harmonized Whole


Utvikling/Trender for Utviklingsprosesser

Source: Software Project Management, A Unified Framework, Walker Royce,Addison-Welsey, 1998

FossefallsmodellFunksjonell design-Skalerings-økonomiEgne verktøy100% skredderAd hoc prosessAlltid: over tid/kost

1960-1979

1980-1999

2000-2019?

Prosess forbedringInnkapslings-basert-Skalerings-økonomiUavhengige verktøy30% komp 70% egetGjentakbare prosessUvisst: til tid / kost

Iterativ utviklingKomponent-basertROIIntegrerte verktøy70% komp 30% egetAdmin/Målt prosess-Oftest: til tid og kost


10 viktige prinsipper for moderne systemutviklingArkitektur-orientert tilnærming Iterativ livs-syklus prosessKomponentbasert utviklingEndrings-orientert miljø “Round-trip” engineeringModell-basert notasjonObjektiv kvalitets-kontrollØkende detaljeringsgradKonfigurerbar prosess


Project ManagementProcess Configuration

RequirementsAnalysis

ArchitectureLevel

Class Level

Implementation

Test

Design

preliminaryiteration(s)

iter.#1

PhasesProcessComponents

Iterations

Elaboration Construction TransitionInception

SupportingComponents

iter.#2

iter.#n

iter.#n+1

iter.#n+2

iter.#m

iter.#m+1

Unified Process Framework

Process Workflows

Business ModelingBusiness ModelingRequirementsRequirements

Analysis Analysis DesignDesign

ImplementationImplementationTestTest

DeploymentDeployment

ManagementManagement

Conf. MngmtConf. Mngmt

EnvironmentEnvironment

Supporting Workflows

Disciplines


Faser i livssyklusen

Inception (Begynnelse/unnfangelse)Elaboration (Utdyping av planer, beskrivelse av

egenskaper og basis arkitektur)Construction (Bygging av produktet) Transition (Overgang til brukere)


Core development disciplines

Requirements

Test

Analysis

Implementation

.Design


Find actors and use cases

Prioritise use cases

Prototype user interface

Detail a use case

Evaluate test

Plan anddesign test

Structure use case model

Implementclass/ss -u.test

Implementtest

Design ause case

Architecturalanalysis

Design aclass/package

Analyse aclass/package

Analyse ause case

Perform integration tes

Integratesystem

SA

UCS

A

UCE

CE

UID

TE

SI

IT

STArch.Design

Arch.Impl

Perf.sys.test

Telecom and Informatics

The Waves of Client/Server Technology

Base Source: Client/Server Survival Guide, 1994, 1996 Robert Orfali, Dan Harkey OS/2 Edition, VNR Computer library + AJB update 2004

1982 1986 1990 1994 1998 1999 2000 2001 2002 2004

FileServers

Database Servers

Groupware

TP Monitors

DistributedObjects

FirstWave

SecondWave

ThirdWave

OMG CORBACOM/OLEWeb/InternettJava

J2EE/EJBCOM+Corba Comp

Server-sidecomponentsc

MDA, WebServices, .NetService-orientedArchitecture SOAP, XMLWSDL/WSFL

FourthWave

FifthWave

P2PGridAgents,

FIPA SOA


DeferredSynch request

Naming service

Persistence service

ServerComponents

Message

Transaction service

Concurrencyservice

XML

Synchron.request

Event - publish & subscribe

Data services &Legacy systems

Shared BusinessServices

User services(application/process)

Interaction/Presservices

Trading serviceSecurity service

Workflowservice

Streaming

Integration service

User InterfaceDocument modelWeb interaction

System/Use Mngt

MultiMedia,QoS

Discovery


BusinessmodelScoping statements

Platform specificmodel

UMT Config model

Component implementationmodel

Bus

ines

s D

omai

nSy

stem

Dom

ain

Model world Real world

Concepts& Artifacts

Processes

Actors

Goal Model

Architecturemodel

Visionfor change

Context statement

Risk analysis

Business Process & RoleModel -> WARM

Business Resource Model

PIM Data Types

Context Businessmodel Goal Model

Visionfor change

Context statement

Risk analysis

Business Process & RoleModel


0,1

0,1

Deployment

User ServiceTierUser ResourceService Tier LS

Legacy

BusinessServiceTier

ResourceServiceTier

Presentation Tier

User Dialog Tier Com

ponent Infrastructure &W

orkflow Engine (M

icroworkflow)

User ServiceD

omain

Business Service

Dom

ainUserInterfaceTier

RARA

LA

Workflow Service Domain

Component structureand internal design

Interface and interaction specification

Busines domain to system domainmapping

•Work element analysis•Use case refinement and RA analysis

Work Element Analysis Model

Use case model

Requirementsmodel

Use case Scenario Model

PrototypeSystem Boundary

*RA Analysis

COMET


OMG Model-Driven Architecture (MDA)

www.omg.org/mda


MDA From 30.000 Feet

Use of platform independent models (PIM) as specification Transformation into platform specific models (PSM) using tools


BusinessmodelScoping statements

Platform specificmodel

UMT Config model

Component implementationmodel

Bus

ines

s D

omai

nSy

stem

Dom

ain

Model world Real world

Concepts& Artifacts

Processes

Actors

Goal Model

Architecturemodel

Visionfor change

Context statement

Risk analysis

Business Process & RoleModel -> WARM


PIM Data Types

Context Businessmodel Goal Model

Visionfor change

Context statement

Risk analysis

Business Process & RoleModel


0,1

0,1

Deployment

User ServiceTierUser ResourceService Tier LS

Legacy

BusinessServiceTier

ResourceServiceTier

Presentation Tier

User Dialog Tier Com

ponent Infrastructure &W

orkflow Engine (M

icroworkflow)

User ServiceD

omain

Business Service

Dom

ainUserInterfaceTier

RARA

LA

Workflow Service Domain

Component structureand internal design

Interface and interaction specification

Busines domain to system domainmapping

•Work element analysis•Use case refinement and RA analysis

Work Element Analysis Model

Use case model

Requirementsmodel

Use case Scenario Model

PrototypeSystem Boundary

*RA Analysis

COMET


SOA

Services Messages Dynamic discovery Web services


IIS, ASP+ XML/HTML

Web Transactions?

BTS

IntegrationServer, CICS ,..

XML/XSLT

WSDL

Data services &Legacy systems

Shared BusinessServices

User services(application/process)

Interaction/PresservicesSOAP

WS SecuritySAML

UDDI-white

- yellow- green pages

WebServices

HTTP

BPEL4WS


Automation in Software DevelopmentRequirements Requirements Requirements

Implementation

Source in ageneral-purposelanguage, e.g.,

Java or C++

Implementation

(may generatecode in

Java or C++)

Source indomain-specificlanguage (DSL)

Implementation

(may generatecode in

Java or C++)

Source indomain-specificlanguage (DSL)

High-level spec(functional andnonfunctional)

Manuallyimplement

Manuallyimplement

Manuallyimplement

Compile Compile Compile

Compile Compile

Implement withInteractive,automatedsupport


MDA and Agile Development

MDA is appropriate for agile development Models are not just additional documentation artifacts, but

they are the actual source Instant feedback through simulation / rapid code

generation Model-based testing Domain-specific modeling languages may simplify

communication with your customer


Service Oriented Architecture (SOA) definition

A set of components which can be invoked, and whose interface descriptions can be published and discovered (W3C).

The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface. (CBDI) (www.cbdiforum.com)


Agile Methods – Smidige metoder

The Agile Manifesto


Extreme Programming – XP (p. 114)

Kent Beck, Ward Cunningham – Chrysler 1996


XP - 4 basic principles and practices

4 basic principles: Feedback Communication Simplicity Courage

4 main practices: Continuous Planning Continuous Design Continuous Coding Continuous Testing

Customers Developers Coaches/Managers


Agile Architecture

Agility in a nutshell


Agile Software Development Alliance

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

http://www.agilealliance.org/home


The Agile Alliance

Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas


Potential problems with traditional approaches to Enterprise Architecture There is not an architecture effort Skewed focus Developers do not know that the architecture exists Developers do not follow the architecture Developers do not work with the architects Outdated architecture Narrowly focused architecture methods


An Agile approach to Architecture

Focus on people, not technology or techniques Keep it simple Work iteratively and incrementally Roll up your sleeves Build it before you talk about it Look at the whole picture Make your architecture attractive to customers


What should Architecture efforts produce?

Support for the customers of the architecture A vision and plan to achieve that vision A collection of models and documentation describing the

architecture


Potential problems with an Agile approach

It does not include an explicit way to ensure compliancy It depends on people being responsible It requires you to actively strive to keep things simple It requires you to accept an agile approach to modeling

and documentation

It’s all about people …


Agile Modeling – Extreme Modeling

Traditionally - either - insist on sophisticated models before coding - or – think that modeling is paper-intensive, overly

bureaucratic, and waste of time

Architect – pro-modeling Programmer – anti-modeling


Refactoring - Improving the design of existing code

1. Refactoring - a first example 2. Principles in refactoring 3. Bad Smells in Code 4. Building Tests 5. Toward a catolog of refactorings 6. Composing Methods 7. Moving Features between objects 8. Organizing data 9. Simplifying Conditional Expressions 10. Making Method calls simpler 11. Dealing with Generalization 12. Big Refactorings 13. Refactoring, Reuse and Reality 14. Refactoring tools

M. Fowler, with K. Beck, J. Brant, W. Opdyke, D. Roberts, Addison-Wesley, August 1999

Refactoring: Improving the design of existing code


Refactoring - What and Why ?

Refactoring is the process of changing a software system in such a way that it does not alter the external behaviour of the code yet improves its internal structure.

Improving to make it easier to understand and cheaper to modify


When should you refactor

The rule of three - Three strikes and you refactor Refactor when you add function Refactor when you need to fix a bug Refactor as you do a code review

17. mars store aud moderne systemuviklingsmetoder kjetil ... filealistair cockburn, crystal 1997,...

Documents