1 ECGE1220 : Information de Gestion et Systèmes d’information Manuel Kolp i-campus: cours ECGE...

1

ECGE1220 : Information de Gestion et Systèmes d’information

Manuel Kolp

i-campus: cours ECGE 1220b (Manuel Kolp)

2

Systèmes d’information organisationnels

Manuel Kolp UCL-IAG-ISYS Place des Doyens, 1 1348 Louvain la Neuve [email protected] 010 47 83 95

Assistants: Youssef Achbany, Yves Wautelet, Caroline Herssens

{achbany, wautelet, herssens}@isys.ucl.ac.be

3

Part I : Informatique de Gestion

Théorie pour TPs et travail de groupe

UML RUP

31/01 10h45 – 12h45 (M. Kolp) 31/01 14h – 16h (Y. Wautelet) 02/02 10h45 – 12h30 (Y. Wautelet)

4

Part II: Systèmes d’information organisationnels Chapitre 1: Les Systèmes d’information organisationnels Chapitre 2: Evolution des rôles des SI Chapitre 3: Technologie et SI Chapitre 4: SI et Stratégie Chapitre 5: Composantes du SIO Chapitre 6: SI et Aide à la décision Chapitre 7: Gestion du Changement Chapitre 8: Projets de SI Chapitre 9: Audit de SI Chapitre 10: Sécurité des SI Chapitre 11: Contrôle interne Chapitre 12: Dimension juridique et fiscale Chapitre 13: Ethique et impact social des SI

A partir du 14/02 de 10h45 à 12h30

5

Livre obligatoire

Systèmes d'information organisationnels Pearson Education 476 pages

Auteur(s) : Pascal Vidal, Marc Augier, François Lacroux, Alain Lecoeur, Collaborateurs Ernst & Young

Date de parution : 2005

ISBN : 2-7440-7119-6

35,00 € TTC

6

Part III : TPs

A partir de la 2ème semaine

10 TPs

UML / Rational Rose E-commerce / ShopFactory ERP / SAP BD : SQL Server Application : VB .NET

Pas de programmation

7

TPs

Livre optionnel pour UML A titre d’information (pas matière du cours)

UML 2

H. Balzert

Collection Compact, 88 pages

2006, ISBN : 2-212-11753-1

Editeur : Eyrolles

+/ 12 euros

8

Part IV: Etude de cas

Groupe de 5 Basé sur matière des TPs Cas SAP IDES

uniquement « Accounting » et « Logistics » Matériel du cas (Enoncé, description, exemple de

cas 2005-2006) sur i-campus dès le 1 février

Deadline : 18 mai 2006

9

Evaluation

QCM (50%) Matière : cours théoriques, TPs, livre obligatoire (SIO) 1 pt par bonne réponse

Travail (50%)

10

Organisation du cours

Cours théorique Me 10h45 - 12h30 MONT 02 sauf 31/01/07 10h45 – 12h45

+ !! 14h – 16h Science 02 !!! TPs (salles info IAG)

A partir du 7/02 !! Me 12h45 – 14h25 !! !! Me 14h25 – 16h05 !!

11

Essentials of Visual Modeling with UML 2.0Principles of Visual Modeling

12

Objectives

Describe the importance of visual modeling and the role of Model Driven Architecture.

Define the four principles of visual modeling.

Explain what the Unified Modeling Language (UML) represents.

Define the type of process that best relates to the UML.

13

The Importance of Modeling

14

Who Should Model in Business System?

RequirementsRequirementsandand

Business Business ModelsModels

RequirementsRequirementsandand

Business Business ModelsModels

Web pagesWeb pagesWeb pagesWeb pages

Database ModelsDatabase Models

Database ModelsDatabase Models

Programming Programming LanguagesLanguages

and and ArchitecturesArchitectures

Programming Programming LanguagesLanguages

and and ArchitecturesArchitecturesSoftware

EngineerSoftwareEngineer

DatabaseDesignerDatabaseDesigner

Web ContentDeveloper

Web ContentDeveloper

BusinessAnalyst / Project

Managers

BusinessAnalyst / Project

Managers

UML/RUPUML/RUP UML/RUPUML/RUP

15

Software Project Management ProcessTime

Organization by phases helps minimize the risks of resource allocation.

16

Major Milestones: Business Decision Points

Architecture baselined

Lifecycle Architecture

Milestone

Scope and Business Case agreement

Lifecycle Objective Milestone

Product sufficiently mature for customers

Initial Operational Capability Milestone

Customer acceptanceor end of life

Product Release

InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition

time

17

Project Management Organized into Disciplines

The disciplines are:Business ModelingRequirementsAnalysis & DesignImplementationTest

Discipline: a collection of activities that are all related to a major “area of concern.”

DeploymentConfiguration &

Change ManagementProject ManagementEnvironment

18

What Is a Model?

A model is a simplification of reality.

19

Why Model?

Modeling achieves four aims: Helps you to visualize a system as you want it to be. Permits you to specify the structure or behavior of a

system. Gives you a template that guides you in constructing a

system. Documents the decisions you have made.

You build models of complex systems because you cannot comprehend such a system in its entirety.

You build models to better understand the system you are developing.

20

The Importance of Modeling

Paper Airplane Fighter Jet

Less Important More Important

21

Software Teams Often Do Not Model

Many software teams build applications approaching the problem like they were building paper airplanes Start coding from project requirements Work longer hours and create more code Lacks any planned architecture Doomed to failure

Modeling is a common thread to successful projects

22

Model Driven Architecture (MDA)

An approach to using models in software development Separate the specification of the operation of a

system from the details of the way that system uses the capabilities of its platform.

• specifying a system independently of the platform that supports it

• specifying platforms• choosing a particular platform for the system• transforming the system specification into one

for a particular platform

23

MDA Viewpoints

Computational Independent Model (CIM) Focus is on environment of the system and

requirements for the system Platform Independent Model (PIM)

Focus is on system operation, independent of platform

Platform Specific Model (PSM) Focus is on detailed usage of system on specific

platform

24

Four Principles of Modeling

The model you create influences how the problem is attacked.

Every model may be expressed at different levels of precision.

The best models are connected to reality. No single model is sufficient.

25

Design ModelProcess Model

Principle 1: The Choice of Model is Important

The models you create profoundly influence how a problem is attacked and how a solution is shaped. In software, the models you choose

greatly affect your world view. Each world view leads to a different

kind of system.

Deployment Model

26

Principle 2: Levels of Precision May Differ

Every model may be expressed at different levels of precision. The best kinds of models let you choose your

degree of detail, depending on:

• Who is viewing the model. • Why they need to view it.

View for DesignersView for Customers

27

Principle 3: The Best Models Are Connected to Reality

All models simplify reality. A good model reflects potentially fatal

characteristics.

28

Principle 4: No Single Model Is Sufficient

No single model is sufficient. Every non-trivial system is best approached through a small set of nearly independent models. Create models that can be built and studied separately,

but are still interrelated.

Process View Deployment View

Logical View

Use-Case View

Implementation View

End-userFunctionality

ProgrammersSoftware management

Performance, scalability, throughputSystem integrators System topology, delivery,

installation, communication

System engineering

Analysts/DesignersStructure

29

What Is the UML?

The UML is a language for• Visualizing• Specifying• Constructing• Documenting

the artifacts of a software- intensive system.

30

The UML Is a Language for Visualizing

Communicating conceptual models to others is prone to error unless everyone involved speaks the same language.

There are things about a software system you can’t understand unless you build models.

An explicit model facilitates communication.

31

Visual Modeling with Unified Modeling Language

Dynamic Diagrams

Static Diagrams

ActivityDiagrams

Models

SequenceDiagrams

CommunicationDiagrams

StatechartDiagrams

DeploymentDiagrams

ComponentDiagrams

ObjectDiagrams

ClassDiagrams

Use-CaseDiagrams

Allows multiple views Provides precise syntax and

semantics

32

The UML Is a Language for Specifying

The UML builds models that are precise, unambiguous, and complete.

33

The UML Is a Language for Constructing

UML models can be directly connected to a variety of programming languages. Maps to Java, C++, Visual Basic, and so on Tables in a RDBMS or persistent store in an

OODBMS Permits forward engineering Permits reverse engineering

34

ISO Norm for Business System Engineering

Actor A

Use Case 1

Use Case 2

Actor B

user : Clerk

mainWnd : MainWnd

fileMgr : FileMgr

repository : Repositorydocument : Document

gFile : GrpFile

9: sortByName ( )

L1: Doc view request ( )

2: fetchDoc( )

5: readDoc ( )

7: readFile ( )

3: create ( )

6: fillDocument ( )

4: create ( )

8: fillFile ( )

Window95

¹®¼ °ü¸®

Å¬¶óÀÌ¾ðÆ®.EXE

Windows

NT

¹®¼ °ü¸® ¿£Áø.EXE

WindowsNT

Windows95

Solaris

ÀÀ¿ë¼ ¹ö.EXE

AlphaUNIX

IBM

Mainframe

µ¥ÀÌÅ¸º£ÀÌ½º¼ ¹ö

Windows95

¹®¼ °ü¸® ¾ÖÇÃ¸´Document

FileManager

GraphicFile

File

Repository DocumentList

FileList

user

mainWnd fileMgr : FileMgr

repositorydocument : Document

gFile

1: Doc view request ( )

2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

6: fillDocument ( )

7: readFile ( )

8: fillFile ( )

9: sortByName ( )

Æ¯Á¤¹®¼ ¿¡ ́ ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äÃ»ÇÑ´Ù.

È ÀÏ°ü̧ ®ÀÚ´Â ÀÐ¾î¿Â ¹®¼ ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼

°´Ã¼¿¡ ¼³Á¤À» ¿äÃ»ÇÑ´Ù.

È ̧é °´Ã¼´Â ÀÐ¾îµéÀÎ °´Ã¼µé¿¡ ´ëÇØ ÀÌ̧ §º°·Î

Á¤·ÄÀ» ½ÃÄÑ È ̧é¿¡ º¸¿©ÁØ´Ù.

Forward and Reverse Engineering

BusinessSystem

Openning

Writing

ReadingClosing

add file [ numberOffile==MAX ] / flag OFF

add file

close file

close fileUse Case 3

Use-CaseDiagram Class Diagram

Communication Diagram

Sequence Diagram

Component Diagram

StatechartDiagram

GrpFile

read( )open( )create( )fillFile( )

rep

Repository

name : char * = 0

readDoc( )readFile( )

(from Persistence)

FileMgr

fetchDoc( )sortByName( )

DocumentList

add( )delete( )

Document

name : intdocid : intnumField : int

get( )open( )close( )read( )sortFileList( )create( )fillDocument( )

fList

1

FileList

add( )delete( )

1

File

read( )

read() fill the code..

Deployment Diagram

ISO/IEC 19501:2005ISO/IEC 19501:2005ISO/IEC 19501:2005ISO/IEC 19501:2005

35

History of the UML

UMLPartners’ Expertise

UML 1.0(Jan. ‘97)

UML 1.1(Sept. ‘97)

UML 1.5(March, ‘03)

UML 2.0(2004)

Other Methods

Booch ‘91 OMT - 1OOSE

Booch ’93 OMT - 2

Public FeedbackUnified Method 0.8

(OOPSLA ’95)

UML 0.9(June ‘96)

UML 0.91(Oct. ‘96)

and

36

Inputs to the UML

FusionOperation descriptions, message numbering

Before and after conditions

Meyer

HarelState charts

Wirfs-BrockResponsibilities

EmbleySingleton classes, High-level view

OdellClassificationObject lifecycles

Shlaer- Mellor

Gamma, et.alFrameworks, patterns, notes

BoochRumbaugh Jacobson

Selic, Gullekson, WardROOM (Real-Time Object-Oriented Modeling)

37

A Language Is Not Enough to Build a System

Modeling Language

Unified Process

Team- Based Development

38

What Type of Process Most Benefits the UML?

The UML is largely process independent. A process fully benefits from the UML when the process is: Use-case driven Architecture centric Iterative and incremental

39

A Use-Case Driven Process

Use cases defined for a system are the basis for the entire development process.

Benefits of use cases: Concise, simple, and understandable by a wide

range of stakeholders. Help synchronize the content of different

models.

Withdraw Money

Customer

Check Balance

40

An Architecture-Centric Process

A system’s architecture is used as a primary artifact for conceptualizing, constructing, managing, and evolving the system under development.

Benefits: Intellectual control over a project to manage its

complexity and to maintain system integrity. Effective basis for large-scale reuse. A basis for project management. Assistance in component-based development.

41

An Iterative and Incremental Process

Critical risks are resolved before making large investments.

Initial iterations enable early user feedback. Testing and integration are continuous. Objective milestones focus on the short

term. Progress is measured by assessing

implementations. Partial implementations can be deployed.

42

Iterative Development

Earliest iterations address greatest risks. Each iteration produces an executable

release, an additional increment of the system.

Each iteration includes integration and test.

T I M E

Iteration 1 Iteration 2 Iteration 3

DI

ADR

TD

IAD

R

TD

IAD

R

T

43

Review

What is a model? What are the viewpoints of MDA?

Describe each one. What are the four principles of

modeling? Describe each one. What is the UML? Describe each

of its four benefits. What process characteristics best

fit the UML? Describe each characteristic.

What is an iteration?

44

Essentials of Visual Modeling with UML 2.0Business Modeling / Requirements

45

Objectives

Describe system behavior and show how to capture it in a model.

Demonstrate how to read and interpret: A use-case diagram An activity diagram

46

What Is System Behavior?

System behavior is how a system acts and reacts. It comprises the actions and activities of a

system. System behavior is captured in use cases.

Use cases describe the interactions between the system and (parts of) its environment.

47

What Is a Use-Case Model?

A model that describes a system’s functional requirements in terms of use cases.

A model of the system’s intended functions (use cases) and its environment (actors).

View Report Card

Student

Register for Courses

Login

48

Major Concepts in Use-Case Modeling

An actor represents anything that interacts with the system.

A use case describes a sequence of events, performed by the system, that yields an observable result of value to a particular actor.

Actor

Use Case

49

What Is an Actor? Actors represent roles a user of

the system can play. They can represent a human, a

machine, or another system. They can actively interchange

information with the system. They can be a giver of

information. They can be a passive recipient

of information. Actors are not part of the

system. Actors are EXTERNAL.

Actor

50

What Is a Use Case?

Use Case

Defines a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor. A use case models a dialogue between one or

more actors and the system A use case describes the actions the system

takes to deliver something of value to the actor

51

Use Cases and Actors

A use case models a dialog between actors and the system.

A use case is initiated by an actor to invoke a certain functionality in the system.

Actor

AssociationUse Case

52

How Would You Read This Diagram?

View Report Card

Student

Register for Courses

Login

Select Courses toTeach

Submit Grades

Professor

Registrar

Billing System

Maintain ProfessorInformation

Maintain StudentInformation

Close Registration

Course Catalog

53

Documenting Use Cases

A document is created for each use case

Details the functionality the system must provide to the actor

Typical contents How the use case starts and ends Normal events Alternate events Exceptional events

54

Maintain Curriculum Flow of Events

This use case begins when the Registrar logs onto the Registration System and enters his/her password. The system verifies that the password is valid (E-1) and prompts the Registrar to select the current semester or a future semester (E-2). The Registrar enters the desired semester. The system prompts the professor to select the desired activity: ADD, DELETE, REVIEW, or QUIT.

If the activity selected is ADD, the S-1: Add a Course subflow is performed.

If the activity selected is DELETE, the S-2: Delete a Course subflow is performed.

If the activity selected is REVIEW, the S-3: Review Curriculum subflow is performed.

If the activity selected is QUIT, the use case ends. ...

55

What Is an Activity Diagram?

An activity diagram in the use-case model can be used to capture the activities and actions performed in a use case.

It is essentially a flow chart, showing flow of control from one activity or action to another.

Flow of Events

This use case starts when the Registrar requests that the system close registration.

1. The system checks to see if registration is in progress. If it is, then a message is displayed to the Registrar and the use case terminates. The Close Registration processing cannot be performed if registration is in progress.

2. For each course offering, the system checks if a professor has signed up to teach the course offering and at least three students have registered. If so, the system commits the course offering for each schedule that contains it.

Activity 1 Activity 3

Activity 2

56

What Is an Activity?

A specification of behavior expressed as a flow of execution via sequencing of subordinate units. Subordinate units include nested activities and

ultimately individual actions. May contain boolean expression constraints

when the activity is invoked or exited

<<Precondition>>Boolean constraint

Activity 5<<Postcondition>>Boolean constraint

Activity 4

Activity 2

57

Example: Activity Diagram

SynchronizationBar (Fork)

GuardCondition

SynchronizationBar (Join)

Decision

Concurrent Threads

Transition

Select Course

[ add course ]

Check Schedule

Check Pre-requisites

Assign to Course

Resolve Conflicts

Update Schedule

Delete Course

[ checks completed ] [ checks failed ]

[ delete course ]

Activity/Action

58

Swimlanes: Responsabilities from Actors

Registrar Professor

Select courses to teach

Create curriculum

Create catalog

Place catalog in bookstore

Open registration

Close registration

[ Registration time period expired ]

Mail catalog to students

59

Review

What is system behavior? What is a use-case model? What

are its benefits? What is an actor? A use case? What is an activity diagram?

60

Essentials of Visual Modeling with UML 2.0 Analysis and Design (Class Diagrams)

61

Objectives

Describe the static view of the system and show how to capture it in a model.

Demonstrate how to read and interpret a class diagram.

Model an association and aggregation and show how to model it in a class diagram.

Model generalization on a class diagram.

62

What Is a Class Diagram?

Static view of a system

CloseRegistrationForm

+ open()+ close registration()

Student

+ get tuition()+ add schedule()+ get schedule()+ delete schedule()+ has pre-requisites()

Schedule- semester

+ commit()+ select alternate()+ remove offering()+ level()+ cancel()+ get cost()+ delete()+ submit()+ save()+ any conflicts?()+ create with offerings()+ update with new selections()

Professor- name- employeeID : UniqueId- hireDate- status- discipline- maxLoad

+ submitFinalGrade()+ acceptCourseOffering()+ setMaxLoad()+ takeSabbatical()+ teachClass()

CloseRegistrationController

+ is registration open?()+ close registration()

63

Class Diagrams

A class diagram shows the existence of classes and their relationships in the logical view of a system

A class is a collection of objects with common structure, common behavior, common relationships and common semantics

A class is drawn as a rectangle with three compartments

Classes should be named using the vocabulary of the domain

64

Attributes

The structure of a class is represented by its attributes

Attributes may be found by examining class definitions, the problem requirements, and by applying domain knowledge

Each course offeringhas a number, location and time

CourseOffering

numberlocationtime

65

Operations

The behavior of a class is represented by its operations

RegistrationManager

addCourse(Student,Course)

66

Class Diagram Usage

When modeling the static view of a system, class diagrams are typically used in one of three ways, to model: The vocabulary of a system Collaborations A logical database schema

67

Example: Class Diagram

Is there a better way to organize class diagrams?

CloseRegistrationForm

LoginForm

Professor

BillingSystem

CloseRegistrationController

RegisterForCoursesForm

Course

CourseCatalogSystem

Student

RegistrationController

CourseOffering

Schedule

68

A general purpose mechanism for organizing elements into groups.

A model element that can contain other model elements.

A package can be used: To organize the model under development As a unit of configuration management

Review: What Is a Package?

University

Artifacts

69

Example: Registration Package

Registration

CloseRegistrationForm CloseRegistrationController

RegisterForCoursesForm RegistrationController

70

What Is an Association?

The semantic relationship between two or more classifiers that specifies connections among their instances.

A structural relationship specifying that objects of one thing are connected to objects of another thing.

CourseStudent Schedule

71

What Is Multiplicity?

Multiplicity is the number of instances one class relates to ONE instance of another class.

For each association, there are two multiplicity decisions to make, one for each end of the association. For each instance of Professor, many Course Offerings

may be taught. For each instance of Course Offering, there may be

either one or zero Professor as the instructor.

Professor CourseOffering

0..1 0..*0..1 0..*

instructor

72

Multiplicity Indicators

2..4

0..1

1..*

0..*

1

*

2, 4..6

Unspecified

Exactly One

Zero or More

Zero or More

Zero or One (optional value)

One or More

Specified Range

Multiple, Disjoint Ranges

73

Example: Multiplicity


CourseOfferingSchedule0..4

0..*Student

0..*

1

RegistrationController1

1

1

1

0..1

0..1

0..1

74

Class diagrams Class relationships

Association Aggregation Generalization

Where Are We?

75

What Is an Aggregation?

A special form of association that models a whole-part relationship between the aggregate (the whole) and its parts. An aggregation is an “is a part-of” relationship.

Multiplicity is represented like other associations.

PartWhole

0..1

1

76

Example: Aggregation


CourseOfferingSchedule0..4

0..*Student

0..*

1

RegistrationController1

1

1

1

0..1

0..1

0..1

77

What Is Generalization?

A relationship among classes where one class shares the structure and/or behavior of one or more classes.

Defines a hierarchy of abstractions where a subclass inherits from one or more superclasses. Single inheritance Multiple inheritance

Is an “is a kind of” relationship.

78

Example: Single Inheritance

One class inherits from another.

CheckingSavings

Superclass (parent)

Subclasses(children)

Generalization Relationship

Descendents

Ancestor

Account

- balance- name- number

+ withdraw()+ createStatement()

79

Example: Multiple Inheritance

A class can inherit from several other classes.

Use multiple inheritance only when needed and always with caution!

FlyingThing Animal

HorseWolfBirdHelicopterAirplane

Multiple Inheritance

80

What does a class diagram represent?

What benefits do packages provide to the model?

Define association, aggregation, and generalization.

How do you find associations? What is multiplicity? What

information does multiplicity provide the modeler?

Review

81

Essentials of Visual Modeling with UML 2.0 Analysis and Design (Interaction Diagrams)

82

Objectives

Describe dynamic behavior and show how to capture it in a model.

Demonstrate how to read and interpret: A sequence diagram A communication diagram

Explain the similarities and differences between communication and sequence diagrams.

83

Objects Need to Collaborate

Objects are useless unless they can collaborate to solve a problem. Each object is responsible for its own behavior

and status. No one object can carry out every responsibility

on its own. How do objects interact with each other?

They interact through messages.

84

Objects Interact with Messages

A message shows how one object asks another object to perform some activity.

: Car buyer:RegistrationController :CourseCatalogSystem

getCourseOfferings(forSemester)

Message

85

What is an Interaction Diagram?

Generic term that applies to several diagrams that emphasize object interactions Sequence Diagram Communication Diagram

Specialized Variants Timing Diagram Interaction Overview Diagram

86

Interaction Diagrams

Sequence Diagram Time oriented view of object

interaction

Communication Diagram Structural view of messaging

objectsCommunication

Diagrams

Sequence Diagrams

87

Interaction Diagrams

Timing Diagram Time constraint view of

messages involved in an interaction

Interaction Overview Diagram High level view of interaction

sets combined into logic sequence

Timing Diagrams

Interaction Overview Diagrams

88

What Is a Sequence Diagram?

A sequence diagram is an interaction diagram that emphasizes the time ordering of messages.

The diagram shows: The objects participating in the interaction. The sequence of messages exchanged.

Sequence Diagram

89

Sequence Diagram Contents: Objects

:RegisterForCoursesForm :RegistrationController SWTSU Catalog : CourseCatalogSystem

Anonymous Objects

Lifelines

Named Object

90


: Student : Course Catalog

Sequence Diagram Contents: Actor

Actor instances

91

Sequence Diagram Contents: Messages

ReflexiveMessages

1: create schedule( )

2: get course offerings( )

3: get course offerings(for Semester)




6: display blank schedule( )

5: display course offerings( )

Message

92








Sequence Diagram Contents: Execution Occurrence

Execution Occurrence


93








Sequence Diagram Contents: Event Occurrence

Event Occurrence


94

Messages

The behavior of a class is represented by its operations

Interaction may be found by examining operations in class diagrams registration

formregistration

manager

3: Add student to Math 101RegistrationManager

addCourse(Student,Course)

95

Registration

Manager

Math 101:

Course

3: add student to Math 101

RegistrationManager

Course

Interaction and Relationships

Interaction must correspond to relationships If two objects must “talk” there must be a

pathway for communication

96

What Is a Communication Diagram?

A communication diagram emphasizes the organization of the objects that participate in an interaction.

The communication diagram shows: The objects participating in the interaction. Links between the objects. Messages passed between the objects.

Communication Diagrams

97

Example: Communication Diagram

: Student

: RegisterForCoursesForm

: RegistrationController : CourseCatalogSystem

5: display course offerings( )6: display blank schedule( )

: Course Catalog1: create schedule( )


3: get course offerings(forSemester)


98

Communication Diagrams Contents: Objects

Objects


: RegistrationController SWTSU Catalog : CourseCatalogSystem

99

Communication Diagram Contents: Actors



: RegistrationController SWTSU Catalog : CourseCatalogSystem

Actors

100

Communication Diagram Contents: Links and Messages

: Student


: RegistrationController : CourseCatalogSystem



: Course Catalog1: create schedule( )


3: get course offerings(forSemester)


Links

Messages

101

Sequence and Communication Diagram Similarities

Semantically equivalent Can convert one diagram to the other without

losing any information Model the dynamic aspects of a system Model a use-case scenario

102

Sequence and Communication Diagram Differences

Sequence diagrams

Communication diagrams

Show the explicit sequence of messages

Show execution occurrence

Better for visualizing overall flow

Better for real-time specifications and for complex scenarios

Show relationships in addition to interactions

Better for visualizing patterns of communication

Better for visualizing all of the effects on a given object

Easier to use for brainstorming sessions

103

What is the purpose of an interaction diagram?

What is a sequence diagram? A communication diagram?

What is a timing diagram? An interaction overview diagram?

What are the similarities between sequence and communication diagrams?

What are the differences between sequence and communication diagrams?

Review

104

Essentials of Visual Modeling with UML 2.0 Analysis and Design (State Machine Diagrams)

105

Objectives

Demonstrate how to read and interpret a: State machine diagram

106

Example: Professor

There are a sequence of events before an instructor becomes a University professor. Assistant professor (achieves tenure by

producing a number of quality publications) Tenure/Associate professor Professor (based on seniority)

107

What Are State Machine Diagrams?

A state machine diagram models dynamic behavior.

It specifies the sequence of states in which an object can exist: The events and conditions that cause the object

to reach those states The actions that take place when those states

are reached

Assistant Professor

Tenured

108

Special States

The initial state is the state entered when an object is created. An initial state is mandatory. Only one initial state is permitted. The initial state is represented as a solid circle.

A final state indicates the end of life for an object. A final state is optional. A final state is indicated by a bull’s eye. More than one final state may exist.

Applied

109

What Are Events?

An event is the specification of a significant occurrence that has a location in time and space. An event is an occurrence of a stimulus that can

trigger a state transition. Example:

• Successful publication of numerous papers

TenuredAssistantProfessor

Event

110

What Are Transitions?

A transition is a change from an originating state to a successor state as a result of some stimulus. The successor state could possibly be the originating

state. A transition may take place in response to an

event. Transitions can be labeled with event names.

Transition Event Name

TenuredAssistantProfessor maxPapers

111

Example: State Machine

Hired

AssistantProfessor

Tenured

Professor

Applied

rejected

accepted

Hiatus

H

H

takeSabbatical

retired

maxPapers

seniority

return

112

State Transition Diagram

InitializationOpen

Closed

Canceled

entry: Register studentexit: Increment count

do: Initialize course

do: Finalize course

do: Notify registered students

[ count = 10 ]

Add Student / Set count = 0

Add student[ count < 10 ]

Cancel

Cancel

Cancel

113

Essentials of Visual Modeling with UML 2.0 Implementation (Component Diagrams)

114

What Is a Component Diagram?

A diagram that shows the organizations and dependencies among components

ComponentA

<<component>>

ComponentC

<<component>>

ComponentB

<<component>>

ComponentD

<<component>>

115

What Is a Component?

A modular part of a system that hides its implementation behind a set of external interfaces. Part of a logical or physical system

<<component>>Component NameComponentName

<<component>>

116

The Physical World

Component diagrams illustrate the organizations and dependencies among software components

Course.dll

People.dll

Register.exeBilling.exe

117

Essentials of Visual Modeling with UML 2.0 Implementation (Deployment Diagrams)

118

What Is a Deployment Diagram?

The deployment diagram shows: Configuration of processing nodes at run-time Communication links between these nodes Deployed artifacts that reside on them

119

What Is a Connector?

A connector represents a: Communication mechanism

• Physical medium• Software protocol

<<application server>>Server

<<RS-232>>

<<100-T Ethernet>>

Connector

<<client workstation>>Console

<<client workstation>>Kiosk

120

Example: Deployment Diagram

<<legacy RDBMS>>Course Catalog

<<Campus LAN>>

<<Campus LAN>><<Campus LAN>>

<<application server>>Registration Server

<<client workstation>>PC

Billing System

<<legacy>>

0..2000

1

1

1

11

121

Define state. How do you determine the classes with significant state?

What is a state machine diagram? Describe the different parts of the diagram.

What is a component diagram? What is the purpose of a

deployment diagram?

Review

122

Essentials of Software Project MangementRational Unified Process

123

Objectives

Understand Business software project looking at:

Symptoms and root causes Iterative DevelpmentAn introduction to Rational Unified Process

124

Symptoms of Software Development Problems

User or business needs not metRequirements churnModules don’t integrateHard to maintainLate discovery of flawsPoor quality or end-user experiencePoor performance under loadNo coordinated team effortBuild-and-release issues

125

Trace Symptoms to Root Causes

Needs not met

Requirements churn

Modules don’t fit

Hard to maintain

Late discovery

Poor quality

Poor performance

Colliding developers

Build-and-release

Insufficient requirements

Ambiguous communications

Brittle architectures

Overwhelming complexity

Undetected inconsistencies

Poor testing

Subjective assessment

Waterfall development

Uncontrolled change

Insufficient automation

Symptoms Root Causes Best Practices





Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually (UML)

Continuously Verify Quality

Manage Change





Modules don’t fit

Modules don’t fit

126

Waterfall Development Characteristics

Delays confirmation of critical risk resolution Measures progress by assessing work-products that

are poor predictors of time-to-completion Delays and aggregates integration and testing Precludes early deployment Frequently results in major unplanned iterations

Waterfall Process

Requirements Analysis

DesignCode and Unit Test

Subsystem Integration

System Test

127

Iterative Development Produces Executables

Planning

Requirements

Analysis & Design

Implementation

Deployment

Test

Evaluation

ManagementEnvironment

Each iteration results in an executable release.

128

Risk ReductionRisk ReductionRisk ReductionRisk Reduction

TimeTime

Ris

kR

isk

Waterfall Risk

Iterative Risk

Risk Profiles

129

UML Model and

Implementation

Tests

Iteration 1Iteration 1

Test Suite 1Test Suite 1







Test Each Iteration

130

Achieving Best Practices Through a Process

Iterative approach Guidance for

activities and artifacts

Process focus on architecture

Use cases which drive design and implementation

Models which abstract the system

131

History of RUP

•Rational Process Workbench•Major addition of content

•Major addition of tool mentors

Improved Process for independent testing

Rational Objectory Process 4.1 1997

Rational Objectory Process 4.0 1996

Rational Unified Process 5.0 1998

Rational Unified Process 2000


Rational Unified Process 5.5 1999



Rational Approach

•Project Management•UML 1.3•RealTime

•Performance Testing•Business Modeling•Configuration & Change Mgt

•Objectory UI Design•Data Engineering•UML 1.1

•OMT•Booch•UML 1.0

•Requirements •Test Process

•Tree browser upgraded for enhanced capabilities of creating customized My RUP tree

•Introduction of RUP Platform providing a configurable process framework

Objectory Process 3.8

132

Role of UML in RUP

Rational Unified Process was developed hand-in-hand with the UML.

Many artifacts in Rational Unified Process have a UML representation.

Rational Unified Process also includes guidelines for UML concepts.

133

RUP Organization

RUP is organized:

By time Phases and iterations

By content Disciplines

134

RUP Organization By Time

Rational Unified Process has four phases: Inception: Define the scope of projectElaboration: Plan project, specify

features, baseline architecture Construction: Build the productTransition: Transition the product into

end-user community


time

135

RUP Organization By Content

The disciplines are:Business ModelingRequirementsAnalysis & DesignImplementationTest

RUP content is organized into disciplines.

A discipline is a collection of activities that are all related to a major ‘area of concern’.

DeploymentConfiguration & Change ManagementProject ManagementEnvironment

136

Bringing It All Together: The Iterative Approachtime

content

Disciplines group related activities.

In an iteration, you walk through all disciplines.

137

Major Milestones: Business Decision Points

Architecture baselined

Lifecycle Architecture

Milestone

Scope and Business Case agreement

Lifecycle Objective Milestone

Product sufficiently mature for customers

Initial Operational Capability Milestone

Customer acceptanceor end of life

Product Release


time

138

Inception Phase: Objectives

Establish project scope and boundary conditions Determine the use cases and primary scenarios

that will drive the major design trade-offs Demonstrate a candidate architecture against

some of the primary scenarios Estimate the overall cost and schedule Identify potential risks (the sources of

unpredictability) Prepare the supporting environment for the project

139

Inception Phase: Evaluation Criteria

Stakeholder concurrence on scope definition and cost/schedule estimates

Agreement that the right set of requirements has been captured and that there is a shared understanding of these requirements

Agreement that the cost/schedule estimates, priorities, risks, and development process are appropriate

All risks have been identified and a mitigation strategy exists for each

Milestone: Lifecycle Objectives (LCO)

140

Elaboration Phase: Objectives

Define, validate and baseline the architecture as rapidly as is practical

Baseline the vision Refine support environment Baseline a detailed plan for the

Construction phase Demonstrate that the baseline architecture

will support the vision at a reasonable cost in a reasonable period of time

141

Elaboration Phase: Evaluation Criteria

Product Vision and requirements are stable. Architecture is stable. Key test and evaluation approaches are proven; major

risk elements have been addressed and resolved. Iteration plans for Construction phase are of sufficient

detail and fidelity to allow work to proceed, and are supported by credible estimates.

All stakeholders agree that current vision can be met if the current plan is executed to develop the complete system, in the context of the current architecture.

Actual resource expenditures versus planned expenditures are acceptable.

Milestone: Lifecycle Architecture (LCA)

142

Construction Phase: Objectives

Complete the software product for transition to production

Minimize development costs by optimizing resources and avoiding unnecessary scrap and rework

Achieve adequate quality as rapidly as is practical

Achieve useful versions (alpha, beta, and other test releases) as rapidly as possible

143

Construction Phase: Evaluation Criteria

The evaluation criteria for the Construction phase involve the answers to these questions:

Is this product release stable and mature enough to be deployed in the user community?

Are all the stakeholders ready for the product’s transition into the user community?

Are actual resource expenditures versus planned still acceptable?

Milestone: Initial Operational Capability (IOC)

144

Transition Phase: Objectives

Achieve user self-supportability Achieve stakeholder concurrence that

deployment baselines are complete and consistent with the evaluation criteria of the vision

Achieve final product baseline in a rapid and cost-effective manner

145

Transition Phase: Evaluation Criteria

The primary evaluation criteria for the Transition phase involve the answers to these questions:

Is the user satisfied? Are actual resources expenditures versus

planned expenditures acceptable?

Milestone: Product release (“GA”)

146

What Is an Iteration?

Iteration: A distinct sequence of activities with a baselined plan and evaluation criteria resulting in a release (internal or external).

In an iteration, you walk through all disciplines.

147

Changing Focus of Phases Over Time

Planned (Technical) Visibility Points

Inception Elaboration Construction Transition

PreliminaryIteration

ArchitectureIteration

Architecture Iteration

Development Iteration



TransitionIteration

TransitionIteration

Acceptanceor end of life

Product sufficiently mature for customers to use (Have a solution)

Architecture baselined(Understand the solution)

Scope and Business

Case agreement(Understand the problem)

Planned (Business) Decision Points

148

Changing Focus of Iterations Over Time

TimeTime

ReqReq

DesignDesign

ImplImpl

TestTest

DeployDeploy

Iteration 1Iteration 1 Iteration 2Iteration 2 Iteration 3Iteration 3

149

Duration of an Iteration An iteration begins with planning and

requirements and ends with an internal or external release.

Ideally an iteration should run from two to six weeks, depending on your project size and complexity.

Factors that affect duration of an iteration: Size, stability and maturity of organization Familiarity with the iterative process Size of project Technical simplicity of project Level of automation used to manage code, distribute

information, perform testing

150

Number of Iterations Rule of thumb: Use 6 ± 3 iterations

Phase Low Medium High

Inception 0 1 1

Elaboration 1 2 3

Construction 1 2 3

Transition 1 1 2

Total 3 6 9

151

Conditions that Increase the Number of Iterations

Inception Working with new

functionality Unknown business

environment Highly volatile scope Make-buy decisions

Elaboration Working with new system

environment (new architectural features)

Untested architectural elements

Need for system prototypes

Construction Lots of code to write and

verify New technology or

development tools

Transition Need for alphas and betas Conversions of customer

base Incremental delivery to

customers

152

One IterationArtifact: Iteration Assessment

Artifact: Iteration Plan

Reduce risk

Accept change

Steer project

Start Iteration Using Iteration Plan

Start Next Iteration

Complete Planned Iteration Work

Adjust Objectives

Adjust Target Product

Adjust Remaining Plan

Plan Next Iteration

Project StoppedStop

Assess Iteration

Continue

•Consider risks

•Add Change Control Board- approved changes

153

RUP Disciplines

RUP has disciplines.RUP has disciplines.

Artifacts from each discipline evolve over the iterative process.

Artifacts from each discipline evolve over the iterative process.

154

Core RUP Elements: Roles, Activities, Artifacts

Roles perform activities which have input and output artifacts.

Risk List

Project Manager

Identify and Assess Risks

Vision

Example: The Project Manager role performs the Identify and Assess Risks activity, which uses the Vision artifact as input and produces the Risk List artifact as output.

155

Core RUP Element: Role

A role defines the behavior and responsibilities of an individual, or a set of individuals working together as a team.

Team members can “wear different hats”: each member can play more than one role one role can be played by more than one

member

156

Roles Are Used for Resource Planning

Each individual in the project is assigned to one or several roles.

Resource

Paul

Mary

Joe

Sylvia

Stefan

Role

Designer

Requirements Specifier

System Analyst

Implementer

Architect

Activities

Define Operations

Detail a Use Case

Find Actors and Use Cases

Perform Unit Tests

Identify Design Mechanisms

157

Some RUP Roles

Project Manager Business Analyst System Analyst Business Process Analyst System Architect Database Designer System Designer Network Architect Software Engineer Web Engineer Technical Writer

158

Core RUP Element: Activity

A piece of work a role performs Granularity of a few hours to a few days Repeated as necessary in each iteration

159

A document, model, or model element produced, modified, or used by a process

The responsibility of roles

Likely to be subject to configuration control

May contain other artifacts

Artifact

Iteration Plan

Developer Test

Tools

Storyboard

Project Measurements

Workspace

Business Use Case Model

Business Goal

Iteration Assessment

Analysis Model

Architectural Proof-of-ConceptUse Case Model

Test Environment Configuration

User-Interface Prototype

160

Disciplines Produce and Share Models

Various disciplines produce Models …

Analysis &Design

Require-ments

Business Modeling

Implement-ation

ImplementedBy

ImplementationModel

Design Model

Use-Case Model

Business Use-Case Model

Business Object Model

Realized By

AutomatedBy

Realized By

Test

Verified By Validated By

BBB

B

… each of those models is Assessed

Deploym

ent

Input To

161

Business Modeling Discipline

Purpose Understand problems in target organization and

identify potential improvements Ensure customer and end user have common

understanding of target organization Derive system requirements to support target

organization Understand structure and dynamics of

organization in which system is to be deployed This discipline uses an approach very

similar to that of system development

162

Requirements DisciplinePurpose Establish and maintain agreement with the

customers and other stakeholders on what the system should do

Provide system developers with a better understanding of the system requirements

Define the boundaries of (delimit) the system Provide a basis for planning the technical

contents of iterations Provide a basis for estimating cost and time to

develop the system Define a user-interface for the system, focusing

on the needs and goals of the users

163

Analysis & Design Discipline

Purpose: Transform the requirements into a design

of the system-to-be Evolve a robust architecture for the

system Adapt the design to match the

implementation environment

Primary artifact is the Design Model.

164

Implementation Discipline

Purpose: Implement classes and objects in terms of

components and source code Define the organization of the components

in terms of implementation subsystems Test the developed components as units Create an executable system

Primary artifact is Implementation Model.

165

Test DisciplinePurpose:

Finding and documenting defects in software quality Generally advising about perceived software quality Proving the validity of the assumptions made in design

and requirement specifications through concrete demonstration

Validating the software product functions as designed Validating that the requirements have been implemented

appropriately

The Test discipline: Focuses primarily on the evaluation or assessment of

quality realized through a number of core practices Acts in many respects as a service provider to the other

disciplines

166

Deployment Discipline

Purpose: Manage the activities associated with ensuring that the software product is available for its end users, such as: Product deployment Testing at the installation and target sites Beta testing Creating end-user support material Creating user training material Releasing to customer (in the form of shrink-

wrapped package, download site, etc.)

167

Project Management Discipline

Purpose: Provide a framework for managing

software-intensive projects. Provide practical guidelines for planning,

staffing, executing, and monitoring projects. Provide a framework for managing risk. Main artifacts are: Project Plan Risk Management Plan Business Case Iteration Plans

168

Configuration & Change Management Discipline

Purpose: controls change to, and maintains the integrity of, a project’s artifacts.

169

Environment Discipline

Purpose: Focuses on the activities necessary to configure the process for a project. Defines what improvements are realistic under the project’s circumstances:

• Current process• Current tools• Current staff skills and capabilities for change• Current problems and possible improvement

objectives

1 ECGE1220 : Information de Gestion et Systèmes d’information Manuel Kolp i-campus: cours ECGE...

Documents

Transcript of 1 ECGE1220 : Information de Gestion et Systèmes d’information Manuel Kolp i-campus: cours ECGE...