1 ecge1220 : information de gestion et systèmes d’information manuel kolp i-campus: cours ecge...
Post on 11-Jan-2016
216 Views
Preview:
TRANSCRIPT
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 kolp@isys.ucl.ac.be 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
RegisterForCoursesForm
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
RegisterForCoursesForm
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
:RegisterForCoursesForm :RegistrationController SWTSU Catalog : CourseCatalogSystem
: 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)
4: get course offerings( )
:RegisterForCoursesForm :RegistrationController SWTSU Catalog : CourseCatalogSystem
: Student : Course Catalog
6: display blank schedule( )
5: display course offerings( )
Message
92
1: create schedule( )
2: get course offerings( )
3: get course offerings(for Semester)
4: get course offerings( )
6: display blank schedule( )
:RegisterForCoursesForm :RegistrationController SWTSU Catalog : CourseCatalogSystem
: Student : Course Catalog
Sequence Diagram Contents: Execution Occurrence
Execution Occurrence
5: display course offerings( )
93
1: create schedule( )
2: get course offerings( )
3: get course offerings(for Semester)
4: get course offerings( )
6: display blank schedule( )
:RegisterForCoursesForm :RegistrationController SWTSU Catalog : CourseCatalogSystem
: Student : Course Catalog
Sequence Diagram Contents: Event Occurrence
Event Occurrence
5: display course offerings( )
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( )
2: get course offerings( )
3: get course offerings(forSemester)
4: get course offerings( )
98
Communication Diagrams Contents: Objects
Objects
: RegisterForCoursesForm
: RegistrationController SWTSU Catalog : CourseCatalogSystem
99
Communication Diagram Contents: Actors
: Student : Course Catalog
: RegisterForCoursesForm
: RegistrationController SWTSU Catalog : CourseCatalogSystem
Actors
100
Communication Diagram Contents: Links and Messages
: Student
: RegisterForCoursesForm
: RegistrationController : CourseCatalogSystem
5: display course offerings( )
6: display blank schedule( )
: Course Catalog1: create schedule( )
2: get course offerings( )
3: get course offerings(forSemester)
4: get course offerings( )
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
Ambiguous communications
Undetected inconsistencies
Ambiguous communications
Undetected inconsistencies
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Model Visually (UML)
Continuously Verify Quality
Model Visually (UML)
Continuously Verify Quality
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
Iteration 2Iteration 2
Test Suite 2Test Suite 2
Iteration 4Iteration 4
Test Suite 4Test Suite 4
Iteration 3Iteration 3
Test Suite 3Test Suite 3
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 2001
Rational Unified Process 5.5 1999
Rational Unified Process 2002
Rational Unified Process 2003
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
InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition
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
InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition
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
Development 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
top related