GETI 2101 : Information Systems IBM 2005 1 Essentials of Visual Modeling with UML 2.0 Principles of Visual Modeling IBM 2005 2
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. IBM 2005 3 The Importance of Modeling IBM 2005 4
Who Should Model in Business System? Business Analyst / Project Managers Requirements and Business Models UML/RUP Web pages Web Content Developer Software Engineer Programming Languages and Architectures Database Models Database Designer IBM 2005 5 Software Project Management Process Time Organization by phases helps minimize the risks of resource allocation. IBM 2005 6
Major Milestones: Business Decision Points Scope and Business Case agreement Architecture baselined Product sufficiently mature for customers Customer acceptance or end of life time Inception Elaboration Construction Transition Lifecycle Objective Milestone Lifecycle Architecture Milestone Initial Operational Capability Milestone Product Release IBM 2005 7 Project Management Organized into Disciplines Discipline: a collection of activities that are all related to a major area of concern. The disciplines are: Business Modeling Requirements Analysis & Design Implementation Test Deployment Configuration & Change Management Project Management Environment IBM 2005 8
What Is a Model? A model is a simplification of reality. IBM 2005 9 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. IBM 2005 10
The Importance of Modeling Less Important More Important Paper Airplane Fighter Jet IBM 2005 11 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 IBM 2005 12
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 IBM 2005 13 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 IBM 2005 14
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. IBM 2005 15 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. Process Model Deployment Model Design Model IBM 2005 16
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 Customers View for Designers IBM 2005 17 Principle 3: The Best Models Are Connected to Reality All models simplify reality. A good model reflects potentially fatal characteristics. IBM 2005 18
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. Logical View Implementation View Analysts/Designers Structure Use-Case View End-user Functionality Programmers Software management Process View System integrators Performance, scalability, throughput Deployment View System engineering System topology, delivery, installation, communication IBM 2005 19 What Is the UML? The UML is a language for Visualizing Specifying Constructing Documenting the artifacts of a softwareintensive system. IBM 2005 20
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. IBM 2005 21 Visual Modeling with Unified Modeling Language Allows multiple views Provides precise syntax and semantics Sequence Diagrams Use-Case Diagrams Class Diagrams Static Diagrams Object Diagrams Communication Diagrams Models Component Diagrams Dynamic Diagrams Statechart Diagrams Activity Diagrams Deployment Diagrams IBM 2005 22
The UML Is a Language for Specifying The UML builds models that are precise, unambiguous, and complete. IBM 2005 23 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 IBM 2005 24
Æ Á ¹ ¼- ëçñ º ±â»ç ëàú äã»çñ Ù. È-ÀÏ ü ÀÚ Â Àоî  ¹ ¼-ÀÇ Á º ÇØ ç ¹ ¼- ü ¼³Á À» äã»çñ Ù. È- é ü  ÀоîµéÀΠüµé ëçø ÀÌ º Î Á ÄÀ» ½ÃÄÑ È- é º ÁØ Ù. 1: Doc view request ( ) 1: Doc view request ( ) 9: sortbyname ( ) L 2: fetchdoc( ) 9: sortbyname ( ) 2: fetchdoc( ) 7: readfile ( ) 5: readdoc ( ) 3: create ( ) 6: filldocument ( ) 4: create ( ) 8: fillfile ( ) 4: create ( ) 8: fillfile ( ) 3: create ( ) 6: filldocument ( ) 5: readdoc ( ) 7: readfile ( ) FileMgr fetchdoc( ) sortbyname( ) rep Repository (from Persistence) name : char * = 0 readdoc( ) readfile( ) FileList add( ) delete( ) read( ) File DocumentList add( ) delete( ) flist 1 GrpFile read( ) open( ) create( ) fillfile( ) Document name : int docid : int numfield : int get( ) open( ) close( ) read( ) sortfilelist( ) create( ) filldocument( ) read() fill the code.. Openning Reading add file [ numberoffile==max ] / flag OFF close file Closing close file add file Writing Window95 ¹ ¼- ü Å óàì¾ðæ.exe Windows NT Windows NT ¹ ¼- ü Áø.EXE Windows95 IBM Mainframe µ ÀÌÅ º À̽º¼-¹ö Solaris ÀÀ ë¼-¹ö.exe Windows95 ¹ ¼- ü ¾ÖÇà Alpha UNIX ISO Norm for Business System Engineering Use-Case Diagram Class Diagram Statechart Diagram ISO/IEC 19501:2005 Use Case 1 Actor A Use Case 2 Actor B Use Case 3 Communication mainwnd : MainWnd Diagram FileManager Repository DocumentList Deployment Diagram gfile : GrpFile Document user : Clerk filemgr : FileMgr GraphicFile File FileList repository : Repository document : Document user mainwnd filemgr : FileMgr document : Document Sequence Diagram gfile repository Component Diagram Forward and Reverse Engineering Business System IBM 2005 25 History of the UML UML 2.0 (2004) UML 1.5 (March, 03) UML Partners Expertise UML 1.1 (Sept. 97) UML 1.0 (Jan. 97) UML 0.9 (June 96) and UML 0.91 (Oct. 96) Unified Method 0.8 (OOPSLA 95) Public Feedback Booch 93 OMT - 2 OOSE Other Methods Booch 91 OMT - 1 IBM 2005 26
Inputs to the UML Rumbaugh Booch Jacobson Meyer Before and after conditions Harel State charts Fusion Operation descriptions, message numbering Embley Singleton classes, High-level view Gamma, et.al Frameworks, patterns, notes Wirfs-Brock Responsibilities Shlaer- Mellor Object lifecycles Selic, Gullekson, Ward ROOM (Real-Time Object-Oriented Modeling) Odell Classification IBM 2005 27 A Language Is Not Enough to Build a System Team- Based Development Modeling Language Unified Process IBM 2005 28
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 IBM 2005 29 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. Check Balance Customer Withdraw Money IBM 2005 30
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. IBM 2005 31 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. IBM 2005 32
Iterative Development Iteration 1 Iteration 2 Iteration 3 R AD I D T R AD I D R T AD I D T T I M E Earliest iterations address greatest risks. Each iteration produces an executable release, an additional increment of the system. Each iteration includes integration and test. IBM 2005 33 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? IBM 2005 34
Essentials of Visual Modeling with UML 2.0 Business Modeling / Requirements IBM 2005 35 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 IBM 2005 36
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. IBM 2005 37 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 Register for Courses Student Login IBM 2005 38
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 IBM 2005 39 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 IBM 2005 40
What Is a 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 Use Case IBM 2005 41 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. Association Use Case Actor IBM 2005 42
How Would You Read This Diagram? View Report Card Register for Courses Course Catalog Maintain Professor Information Student Login Maintain Student Information Registrar Select Courses to Teach Close Registration Professor Submit Grades Billing System IBM 2005 43 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 IBM 2005 44
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 IBM 2005 QUIT, 45 the use case ends. 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 2 Activity 1 Activity 3 IBM 2005 46
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 Activity 2 <<Precondition>> Boolean constraint Activity 4 Activity 5 <<Postcondition>> Boolean constraint IBM 2005 47 Example: Activity Diagram Concurrent Threads Guard Condition Check Schedule Select Course [ add course ] [ delete course ] Check Pre-requisites [ checks completed ] [ checks failed ] Decision Delete Course Activity/Action Synchronization Bar (Fork) Synchronization Bar (Join) Assign to Course Resolve Conflicts Transition Update Schedule IBM 2005 48
Swimlanes: Responsabilities from Actors Registrar Create curriculum Professor Create catalog Select courses to teach Place catalog in bookstore Mail catalog to students Open registration [ Registration time period expired ] Close registration IBM 2005 49 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? IBM 2005 50
Essentials of Visual Modeling with UML 2.0 Analysis and Design (Class Diagrams) IBM 2005 51 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. IBM 2005 52
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() - semester Schedule + commit() + select alternate() + remove offering() + level() + cancel() + get cost() + delete() + submit() + save() + any conflicts?() + create with offerings() + update with new selections() CloseRegistrationController + is registration open?() + close registration() Professor -name - employeeid : UniqueId - hiredate -status - discipline - maxload + submitfinalgrade() + acceptcourseoffering() + setmaxload() + takesabbatical() + teachclass() IBM 2005 53 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 IBM 2005 54
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 offering has a number, location and time CourseOffering number location time IBM 2005 55 Operations The behavior of a class is represented by its operations RegistrationManager addcourse(student,course) IBM 2005 56
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 IBM 2005 57 Example: Class Diagram Is there a better way to organize class diagrams? RegisterForCoursesForm LoginForm RegistrationController CloseRegistrationForm Schedule CloseRegistrationController Student Professor Course CourseOffering CourseCatalogSystem BillingSystem IBM 2005 58
Review: What Is a Package? 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 University Artifacts IBM 2005 59 Example: Registration Package Registration CloseRegistrationForm CloseRegistrationController RegisterForCoursesForm RegistrationController IBM 2005 60
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. Student Schedule Course IBM 2005 61 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 instructor 0..1 0..* CourseOffering IBM 2005 62
Multiplicity Indicators Unspecified Exactly One Zero or More Zero or More One or More 1 0..* * 1..* Zero or One (optional value) Specified Range Multiple, Disjoint Ranges 0..1 2..4 2, 4..6 IBM 2005 63 Example: Multiplicity RegisterForCoursesForm 1 1 RegistrationController 0..1 0..1 Student 1 0..* Schedule 0..* 0..4 CourseOffering IBM 2005 64
Where Are We? Class diagrams Class relationships Association Aggregation Generalization IBM 2005 65 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. Whole 1 Part 0..1 IBM 2005 66
Example: Aggregation RegisterForCoursesForm 1 1 RegistrationController 0..1 0..1 Student 1 0..* Schedule 0..* 0..4 CourseOffering IBM 2005 67 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. IBM 2005 68
Example: Single Inheritance One class inherits from another. Superclass (parent) - balance -name -number Ancestor Account + withdraw() + createstatement() Generalization Relationship Subclasses (children) Savings Checking Descendents IBM 2005 69 Example: Multiple Inheritance A class can inherit from several other classes. FlyingThing Animal Multiple Inheritance Airplane Helicopter Bird Wolf Horse Use multiple inheritance only when needed and always with caution! IBM 2005 70
Review 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? IBM 2005 71 Essentials of Visual Modeling with UML 2.0 Analysis and Design (Interaction Diagrams) IBM 2005 72
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. IBM 2005 73 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. IBM 2005 74
Objects Interact with Messages A message shows how one object asks another object to perform some activity. Message getcourseofferings(forsemester) : Car buyer :RegistrationController :CourseCatalogSystem IBM 2005 75 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 IBM 2005 76
Interaction Diagrams Sequence Diagram Time oriented view of object interaction Sequence Diagrams Communication Diagram Structural view of messaging objects Communication Diagrams IBM 2005 77 Interaction Diagrams Timing Diagram Time constraint view of messages involved in an interaction Timing Diagrams Interaction Overview Diagram High level view of interaction sets combined into logic sequence Interaction Overview Diagrams IBM 2005 78
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 IBM 2005 79 Sequence Diagram Contents: Objects :RegisterForCoursesForm :RegistrationController SWTSU Catalog : CourseCatalogSystem Anonymous Objects Named Object Lifelines IBM 2005 80
Sequence Diagram Contents: Actor :RegisterForCoursesForm :RegistrationController SWTSU Catalog : CourseCatalogSystem : Student : Course Catalog Actor instances IBM 2005 81 Sequence Diagram Contents: Messages :RegisterForCoursesForm :RegistrationController SWTSU Catalog : CourseCatalogSystem : Student : Course Catalog 1: create schedule( ) 2: get course offerings( ) 3: get course offerings(for Semester) 4: get course offerings( ) 5: display course offerings( ) Reflexive Messages 6: display blank schedule( ) Message IBM 2005 82
Sequence Diagram Contents: Execution Occurrence :RegisterForCoursesForm :RegistrationController SWTSU Catalog : CourseCatalogSystem : Student : Course Catalog 1: create schedule( ) 2: get course offerings( ) 3: get course offerings(for Semester) 5: display course offerings( ) 4: get course offerings( ) 6: display blank schedule( ) Execution Occurrence IBM 2005 83 Sequence Diagram Contents: Event Occurrence :RegisterForCoursesForm :RegistrationController SWTSU Catalog : CourseCatalogSystem : Student : Course Catalog 1: create schedule( ) 2: get course offerings( ) 3: get course offerings(for Semester) 5: display course offerings( ) 4: get course offerings( ) 6: display blank schedule( ) Event Occurrence IBM 2005 84
Messages The behavior of a class is represented by its operations Interaction may be found by examining operations in class diagrams registration form registration manager RegistrationManager 3: Add student to Math 101 addcourse(student,course) IBM 2005 85 Interaction and Relationships Interaction must correspond to relationships If two objects must talk there must be a pathway for communication RegistrationManager Registration Manager Math 101: Course 3: add student to Math 101 Course IBM 2005 86
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 IBM 2005 87 Example: Communication Diagram 5: display course offerings( ) 6: display blank schedule( ) 1: create schedule( ) : RegisterForCoursesForm : Course Catalog : Student 2: get course offerings( ) 4: get course offerings( ) 3: get course offerings(forsemester) : RegistrationController : CourseCatalogSystem IBM 2005 88
Communication Diagrams Contents: Objects : RegisterForCoursesForm Objects : RegistrationController SWTSU Catalog : CourseCatalogSystem IBM 2005 89 Communication Diagram Contents: Actors : RegisterForCoursesForm : Student : Course Catalog Actors : RegistrationController SWTSU Catalog : CourseCatalogSystem IBM 2005 90
Communication Diagram Contents: Links and Messages Messages 5: display course offerings( ) 6: display blank schedule( ) 1: create schedule( ) : RegisterForCoursesForm Links : Course Catalog : Student 2: get course offerings( ) 4: get course offerings( ) 3: get course offerings(forsemester) : RegistrationController : CourseCatalogSystem IBM 2005 91 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 IBM 2005 92
Sequence and Communication Diagram Differences Sequence diagrams Show the explicit sequence of messages Show execution occurrence Better for visualizing overall flow Better for real-time specifications and for complex scenarios Communication diagrams 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 IBM 2005 93 Review 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? IBM 2005 94
Essentials of Visual Modeling with UML 2.0 Analysis and Design (State Machine Diagrams) IBM 2005 95 Objectives Demonstrate how to read and interpret a: State machine diagram IBM 2005 96
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) IBM 2005 97 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 IBM 2005 98
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 IBM 2005 99 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 Assistant Professor Event Tenured IBM 2005 100
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. Assistant Professor maxpapers Tenured Transition Event Name IBM 2005 101 Example: State Machine Hired Applied accepted H Assistant Professor maxpapers rejected Tenured seniority retired Professor H takesabbatical return Hiatus IBM 2005 102
State Transition Diagram Add student[ count < 10 ] Initialization do: Initialize course Add Student / Set count = 0 Open entry: Register student exit: Increment count Cancel Cancel [ count = 10 ] Canceled do: Notify registered students Cancel Closed do: Finalize course IBM 2005 103 Essentials of Visual Modeling with UML 2.0 Implementation (Component Diagrams) IBM 2005 104
What Is a Component Diagram? A diagram that shows the organizations and dependencies among components <<component>> ComponentA <<component>> ComponentB <<component>> ComponentC <<component>> ComponentD IBM 2005 105 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>> ComponentName Component Name IBM 2005 106
The Physical World Component diagrams illustrate the organizations and dependencies among software components Billing.exe Register.exe People.dll Course.dll IBM 2005 107 Essentials of Visual Modeling with UML 2.0 Implementation (Deployment Diagrams) IBM 2005 108
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 IBM 2005 109 What Is a Connector? A connector represents a: Communication mechanism Physical medium Software protocol <<100-T Ethernet>> <<client workstation>> Kiosk <<application server>> Server Connector <<RS-232>> <<client workstation>> Console IBM 2005 110
Example: Deployment Diagram <<client workstation>> PC <<Campus LAN>> 1 0..2000 <<Campus LAN>> 1 1 <<application server>> Registration Server 1 <<Campus LAN>> 1 <<legacy RDBMS>> Course Catalog <<legacy>> Billing System IBM 2005 111 Review 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? IBM 2005 112
Essentials of Software Project Mangement Rational Unified Process IBM 2005 113 Objectives Understand Business software project looking at: Symptoms and root causes Iterative Develpment An introduction to Rational Unified Process IBM 2005 114
Symptoms of Software Development Problems User or business needs not met Requirements churn Modules don t integrate Hard to maintain Late discovery of flaws Poor quality or end-user experience Poor performance under load No coordinated team effort Build-and-release issues IBM 2005 115 Trace Symptoms to Root Causes Symptoms Root Causes Best Practices 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 Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change IBM 2005 116
Waterfall Development Characteristics Waterfall Process Requirements Analysis Design Code and Unit Test Subsystem Integration System Test 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 IBM 2005 117 Iterative Development Produces Executables Requirements Planning Management Environment Analysis & Design Implementation Test Evaluation Each iteration results in an executable release. Deployment IBM 2005 118
Risk Profiles Waterfall Risk Risk Risk Reduction Iterative Risk Time IBM 2005 119 Test Each Iteration Iteration 1 Iteration 2 Iteration 3 Iteration 4 UML Model and Implementation Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4 Tests IBM 2005 120
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 IBM 2005 121 History of RUP Tree browser upgraded for enhanced capabilities of creating customized My RUP tree Improved Process for independent testing Rational Process Workbench Major addition of content Performance Testing Business Modeling Configuration & Change Mgt Rational Unified Process 2003 Rational Unified Process 2002 Rational Unified Process 2001 Rational Unified Process 2000 Rational Unified Process 5.5 1999 Rational Unified Process 5.0 1998 Rational Objectory Process 4.1 1997 Introduction of RUP Platform providing a configurable process framework Major addition of tool mentors Project Management UML 1.3 RealTime Objectory UI Design Data Engineering UML 1.1 Requirements Test Process Rational Objectory Process 4.0 1996 Rational Approach Objectory Process 3.8 IBM 2005 122 OMT Booch UML 1.0
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. IBM 2005 123 RUP Organization RUP is organized: By time Phases and iterations By content Disciplines IBM 2005 124
RUP Organization By Time Inception Elaboration Construction Transition time Rational Unified Process has four phases: Inception: Define the scope of project Elaboration: Plan project, specify features, baseline architecture Construction: Build the product Transition: Transition the product into end-user community IBM 2005 125 RUP Organization By Content RUP content is organized into disciplines. A discipline is a collection of activities that are all related to a major area of concern. The disciplines are: Business Modeling Requirements Analysis & Design Implementation Test Deployment Configuration & Change Management Project Management Environment IBM 2005 126
Bringing It All Together: The Iterative Approach time content In an iteration, you walk through all disciplines. Disciplines group related activities. IBM 2005 127 Major Milestones: Business Decision Points Scope and Business Case agreement Architecture baselined Product sufficiently mature for customers Customer acceptance or end of life Inception Elaboration Construction Transition time Lifecycle Objective Milestone Lifecycle Architecture Milestone Initial Operational Capability Milestone Product Release IBM 2005 128
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 IBM 2005 129 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) IBM 2005 130
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 IBM 2005 131 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) IBM 2005 132
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 IBM 2005 133 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) IBM 2005 134
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 IBM 2005 135 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 ) IBM 2005 136
What Is an Iteration? In an iteration, you walk through all disciplines. Iteration: A distinct sequence of activities with a baselined plan and evaluation criteria resulting in a release (internal or external). IBM 2005 137 Changing Focus of Phases Over Time Planned (Business) Decision Points Scope and Business Case agreement (Understand the problem) Architecture baselined (Understand the solution) Product sufficiently mature for customers to use (Have a solution) Acceptance or end of life Inception Elaboration Construction Transition Preliminary Iteration Architecture Iteration Architecture Iteration Development Iteration Development Iteration Development Iteration Transition Iteration Transition Iteration Planned (Technical) Visibility Points IBM 2005 138
Changing Focus of Iterations Over Time Iteration 1 Iteration 2 Iteration 3 Req Design Impl Test Deploy Time IBM 2005 139 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 IBM 2005 140
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 IBM 2005 141 Conditions that Increase the Number of Iterations Inception Working with new functionality Unknown business environment Highly volatile scope Make-buy decisions Construction Lots of code to write and verify New technology or development tools Elaboration Working with new system environment (new architectural features) Untested architectural elements Need for system prototypes Transition Need for alphas and betas Conversions of customer base Incremental delivery to customers IBM 2005 142
One Iteration Complete Planned Iteration Work Assess Iteration Start Iteration Using Iteration Plan Consider risks Add Change Control Boardapproved changes Artifact: Iteration Assessment Adjust Objectives Continue Adjust Remaining Plan Stop Adjust Target Product Project Stopped Reduce risk Accept change Steer project Plan Next Iteration Start Next Iteration Artifact: Iteration Plan IBM 2005 143 RUP Disciplines RUP has disciplines. Artifacts from each discipline evolve over the iterative process. IBM 2005 144
Core RUP Elements: Roles, Activities, Artifacts Project Manager Identify and Assess Risks Vision Risk List Roles perform activities which have input and output artifacts. 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. IBM 2005 145 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 IBM 2005 146
Roles Are Used for Resource Planning Resource Role Activities Paul Mary Joe Sylvia Stefan Designer Requirements Specifier System Analyst Implementer Architect Define Operations Detail a Use Case Find Actors and Use Cases Perform Unit Tests Identify Design Mechanisms Each individual in the project is assigned to one or several roles. IBM 2005 147 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 IBM 2005 148
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 IBM 2005 149 Artifact 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 Iteration Plan Storyboard Use Case Model Project Measurements Developer Test Business Goal Test Environment Configuration Iteration Assessment Analysis Model Architectural Proof-of-Concept Workspace Tools User-Interface Prototype Business Use Case Model IBM 2005 150
Disciplines Produce and Share Models Various disciplines produce Models Business Modeling Analysis & Design Requirements Implementation Input To Realized By Business Use- Case Model B B B B Business Object Model Use-Case Model Automated By Realized By Design Model Implemented By Implementation Model Deployment each of those models is Assessed Verified By Test Validated By IBM 2005 151 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 IBM 2005 152
Requirements Discipline Purpose 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 IBM 2005 153 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. IBM 2005 154
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. IBM 2005 155 Test Discipline Purpose: 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 IBM 2005 156
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 shrinkwrapped package, download site, etc.) IBM 2005 157 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 IBM 2005 158
Configuration & Change Management Discipline Purpose: controls change to, and maintains the integrity of, a project s artifacts. IBM 2005 159 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 IBM 2005 160