GETI 2101 : Information Systems

Transcription

1 GETI 2101 : Information Systems IBM Essentials of Visual Modeling with UML 2.0 Principles of Visual Modeling IBM

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 The Importance of Modeling IBM

3 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 Software Project Management Process Time Organization by phases helps minimize the risks of resource allocation. IBM

4 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 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

5 What Is a Model? A model is a simplification of reality. IBM 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

6 The Importance of Modeling Less Important More Important Paper Airplane Fighter Jet IBM 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

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

8 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 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

9 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 Principle 3: The Best Models Are Connected to Reality All models simplify reality. A good model reflects potentially fatal characteristics. IBM

10 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 What Is the UML? The UML is a language for Visualizing Specifying Constructing Documenting the artifacts of a softwareintensive system. IBM

11 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 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

12 The UML Is a Language for Specifying The UML builds models that are precise, unambiguous, and complete. IBM 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

13 Æ Á ¹ ¼- ëçñ º ±â»ç ëàú äã»çñ Ù. È-ÀÏ ü ÀÚ Â Àоî  ¹ ¼-ÀÇ Á º ÇØ ç ¹ ¼- ü ¼³Á À» äã»çñ Ù. È- é ü  ÀоîµéÀΠüµé ëçø ÀÌ º Î Á ÄÀ» ½ÃÄÑ È- é º ÁØ Ù. 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 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

14 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 A Language Is Not Enough to Build a System Team- Based Development Modeling Language Unified Process IBM

15 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 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

16 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 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

17 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 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

18 Essentials of Visual Modeling with UML 2.0 Business Modeling / Requirements IBM 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

19 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 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

20 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 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

21 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 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

22 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 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

23 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

24 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 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

25 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 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

26 Essentials of Visual Modeling with UML 2.0 Analysis and Design (Class Diagrams) IBM 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

27 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 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

28 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 Operations The behavior of a class is represented by its operations RegistrationManager addcourse(student,course) IBM

29 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 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

30 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 Example: Registration Package Registration CloseRegistrationForm CloseRegistrationController RegisterForCoursesForm RegistrationController IBM

31 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 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 * CourseOffering IBM

32 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 , 4..6 IBM Example: Multiplicity RegisterForCoursesForm 1 1 RegistrationController Student 1 0..* Schedule 0..* 0..4 CourseOffering IBM

33 Where Are We? Class diagrams Class relationships Association Aggregation Generalization IBM 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

34 Example: Aggregation RegisterForCoursesForm 1 1 RegistrationController Student 1 0..* Schedule 0..* 0..4 CourseOffering IBM 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

35 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 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

36 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 Essentials of Visual Modeling with UML 2.0 Analysis and Design (Interaction Diagrams) IBM

37 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 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

38 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 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

39 Interaction Diagrams Sequence Diagram Time oriented view of object interaction Sequence Diagrams Communication Diagram Structural view of messaging objects Communication Diagrams IBM 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

40 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 Sequence Diagram Contents: Objects :RegisterForCoursesForm :RegistrationController SWTSU Catalog : CourseCatalogSystem Anonymous Objects Named Object Lifelines IBM

41 Sequence Diagram Contents: Actor :RegisterForCoursesForm :RegistrationController SWTSU Catalog : CourseCatalogSystem : Student : Course Catalog Actor instances IBM 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

42 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 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

43 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 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

44 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 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

45 Communication Diagrams Contents: Objects : RegisterForCoursesForm Objects : RegistrationController SWTSU Catalog : CourseCatalogSystem IBM Communication Diagram Contents: Actors : RegisterForCoursesForm : Student : Course Catalog Actors : RegistrationController SWTSU Catalog : CourseCatalogSystem IBM

46 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 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

47 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 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

48 Essentials of Visual Modeling with UML 2.0 Analysis and Design (State Machine Diagrams) IBM Objectives Demonstrate how to read and interpret a: State machine diagram IBM

49 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 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

50 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 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

51 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 Example: State Machine Hired Applied accepted H Assistant Professor maxpapers rejected Tenured seniority retired Professor H takesabbatical return Hiatus IBM

52 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 Essentials of Visual Modeling with UML 2.0 Implementation (Component Diagrams) IBM

53 What Is a Component Diagram? A diagram that shows the organizations and dependencies among components <<component>> ComponentA <<component>> ComponentB <<component>> ComponentC <<component>> ComponentD IBM 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

54 The Physical World Component diagrams illustrate the organizations and dependencies among software components Billing.exe Register.exe People.dll Course.dll IBM Essentials of Visual Modeling with UML 2.0 Implementation (Deployment Diagrams) IBM

55 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 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

56 Example: Deployment Diagram <<client workstation>> PC <<Campus LAN>> <<Campus LAN>> 1 1 <<application server>> Registration Server 1 <<Campus LAN>> 1 <<legacy RDBMS>> Course Catalog <<legacy>> Billing System IBM 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

57 Essentials of Software Project Mangement Rational Unified Process IBM Objectives Understand Business software project looking at: Symptoms and root causes Iterative Develpment An introduction to Rational Unified Process IBM

58 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 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

59 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 Iterative Development Produces Executables Requirements Planning Management Environment Analysis & Design Implementation Test Evaluation Each iteration results in an executable release. Deployment IBM

60 Risk Profiles Waterfall Risk Risk Risk Reduction Iterative Risk Time IBM 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

61 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 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 Rational Unified Process Rational Objectory Process 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 Rational Approach Objectory Process 3.8 IBM OMT Booch UML 1.0

62 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 RUP Organization RUP is organized: By time Phases and iterations By content Disciplines IBM

63 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 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

64 Bringing It All Together: The Iterative Approach time content In an iteration, you walk through all disciplines. Disciplines group related activities. IBM 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

65 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 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

66 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 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

67 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 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

68 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 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

69 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 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

70 Changing Focus of Iterations Over Time Iteration 1 Iteration 2 Iteration 3 Req Design Impl Test Deploy Time IBM 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

71 Number of Iterations Rule of thumb: Use 6 ± 3 iterations Phase Low Medium High Inception Elaboration Construction Transition Total IBM 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

72 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 RUP Disciplines RUP has disciplines. Artifacts from each discipline evolve over the iterative process. IBM

73 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 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

74 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 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

75 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 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

76 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 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

77 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 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

78 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 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

79 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 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

80 Configuration & Change Management Discipline Purpose: controls change to, and maintains the integrity of, a project s artifacts. IBM 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