INF 111 / CSE 121: Software Tools and Methods Software Tools and - PDF document

INF 111 / CSE 121: Software Tools and Methods Software Tools and Methods Lecture Notes for Summer Quarter 2008 Michele Rousseau Lecture Notes 7 - UML Announcements � Quiz #3- Thursday – What will it cover? ● All readings assigned since the last quiz ● Plus the readings not covered on the last quiz: ● Through slide 54 in today’s lecture ◘ Configuration Management ◘ Only through the first break! � Readings on UML ● Another book on UML: ◘ McLaughlin, Pollice & West (2006). Head First Object-Oriented Analysis & Design. O’Reilly, 2006. � Assignments ● #1 has been graded ● Assignment #3 will be posted later this week Lecture Notes 7 - UML 2 1

Last Lecture � Quiz #2 � Configuration Management Lecture Notes 7 - UML 3 Today’s Lecture � Finish up ● Configuration Management ◘ Version Control ◘ Version Control � Modeling ● OOAD ◘ UML • Class Diagrams • Class Diagrams • Use Case Diagrams • Sequence Diagrams Lecture Notes 7 - UML 4 2

CASE tools for configuration management � CM processes are often standardised ● procedures are pre-defined � Lots of Docs and Data to be managed � Lots of Docs and Data to be managed � Tools make it possible � Can be… ● Individual tools ● Workbenches ● Environments Lecture Notes 7 - UML 5 CM workbenches � Open workbenches ● Tools for each stage in the CM process are integrated integrated ◘ Includes organizational procedures � Integrated workbenches ● Provide whole-process, integrated support ◘ More tightly integrated tools � easier to use. ◘ Less flexible in the tools used • Have to use tools built in Lecture Notes 7 - UML 6 3

Change management tools � Change management is a procedural process ● it can be modelled & integrated with a version management system. management system. � Change management tools ● Form editor ◘ supports processing the CRFs ● Workflow system ◘ define who does what ◘ automates information transfer; ◘ automates information transfer; ● Change database ◘ manages change proposals ◘ linked to a VM system ● Change reporting system ◘ generates management reports (CR status) Lecture Notes 7 - UML 7 Version management tools � Version and release identification ● assigns identifiers automatically for each new version � Storage management. ● Stores the differences between versions (the delta) ● Stores the differences between versions (the delta) ◘ rather than all the version code. � Change history recording ● Record reasons for version creation. � Independent development ● Only one version at a time may be checked out for change. ● Parallel working on different versions. � Project support ● Manages groups of files associated with a project ◘ rather than just single files. Lecture Notes 7 - UML 8 4

Delta-based versioning Lecture Notes 7 - UML 9 Moving on to OOAD � Object Oriented Analysis & Design (OOAD) using… (OOAD) using… ● UML – Part ◘ Overview ◘ More details in discussion Lecture Notes 7 - UML 10 5

Brooks on Invisibility of Software “Software is invisible and unvisualizable . Geometric abstractions are powerful tools.” “As soon as we attempt to diagram software structure, we find it to constitute one, but several general directed graphs, superimposed tit t b t l l di t d h i d on upon another. The several graphs may represent the flow of control, the flow of data, patterns of dependency, time sequence, name-space relationships. These are usually not even planar, much less hierarchical. Indeed , one of the ways of establishing conceptual control over such structure is to enforce link cutting until one or more of the graphs becomes hierarchical .” Lecture Notes 7 - UML 11 What is UML? Unified Modeling Language (UML) Let’s break it down: Unified Unified � In 1994, ● Two important methodologists Rumbaugh and Booch decided to unify their approaches in 1994 � In 1995, another methodologist, Jacobson, joined the team ● His work focused on use cases ● His work focused on use cases � In 1997, ● the Object Management Group (OMG) started to standardize UML Lecture Notes 7 - UML 12 6

Models Models are abstract representations � Contain essential characteristics and omit non-essential details non essential details � Models can be representations of the world ● Domain models ● Requirements � Models can be representations of software � Models can be representations of software ● Specifications ● Design ● Systems Lecture Notes 7 - UML 13 Why make models? � Systems are complex and hard to understand ● The world, organizations, relationships, software � Models can make certain aspects more clearly visible than in the real system � What can you do with models? ● Express your ideas and communicate with other engineers ● Reason about the system ◘ detect errors ◘ detect errors ◘ predict qualities ● Generate parts of the real system ◘ Code ◘ Schemas Can reverse engineer a system to make a model Lecture Notes 7 - UML 14 7

What constitutes a good model? � A model should… ● Provide abstraction ● Render the problem in a format amenable to p reasoning ● use a standard notation ● be understandable by clients and users ● lead software engineers to have insights about the system ● make the problem solvable computationally k th bl l bl t ti ll ◘ Be good enough ● Be a tool for communication Lecture Notes 7 - UML 15 Architecture not usually a good example… … BUT Imagine the building the Biltmore g g � 175,000 Sq. Ft. (that’s 4 acres) � 250 rooms � 35 bd/43 ba. � 65 fireplaces � 125,000 acre lot (that’s 195 sq mi) Lecture Notes 7 - UML 16 8

Where would you begin? � A model helps reduce complexity l it ● Eliminates details that are not necessary at the time ● Allows you to divide an conquer large tasks Lecture Notes 7 - UML 17 What constitutes a good model? A model should… � Abstract away unnecessary details � Provide a means to reason about the system � Use a standard notation � Be understandable by clients and users � Lead software engineers to have insights about the system � Be a tool for communication Lecture Notes 7 - UML 18 9

Remember: It’s only a model There will always be: � Phenomena in the application domain that are not in the model (abstraction) t i th d l ( b t ti ) � Details in the application that are not in the model (abstraction) ● Just what you need � A model is never perfect � A model is never perfect ● “If the map and the terrain disagree, believe the terrain” Lecture Notes 7 - UML 19 Modeling Languages � Natural language ● Extremely expressive and flexible ● Very poor at capturing the semantics of the model model ● Better used for elicitation, and to annotate models for communication � Semi-formal notation ● Captures structure and some semantics ● Can perform (some) automated reasoning, Can perform (some) automated reasoning, consistency checking, animation, etc. ● Mostly visual - for rapid communication with a variety of stakeholders Examples : diagrams, tables, structured English, etc. Lecture Notes 7 - UML 20 10

Modeling Languages (2) � Formal notation ● very precise semantics, extensive reasoning possible ● Can automate reasoning consistency checking ● Can automate reasoning, consistency checking, completeness checking, simulation, etc.. ● Every detailed models ) Lecture Notes 7 - UML 21 Unified Modeling Language (UML) UML is a … ● semi-formal graphical (visual) modeling language ● Object Modeling Language (OMD) j g g g ( ) ● A way to communicate details… ◘ Code ◘ Architecture � Uml is descriptive � tries not to be prescriptive prescriptive … essentially it is a set of diagrams used to model the system Lecture Notes 7 - UML 22 11

3 Common Way to Use UML � Sketch - Quick Communication Q Abstraction � Blueprint – Complete Specification � Programming Language � Programming Language Lecture Notes 7 - UML 23 UML as a Sketch � Helps communicate some aspect of the system ● Forward & reverse engineering � “Rough out” issues in the code � Not all of the code – just parts that you are working on immediately ● Selective communication � NOT complete specification � Short discussion with a team � Short discussion with a team ● (10 min – 1 day) � Quick and Collaborative � Informal Lecture Notes 7 - UML 24 12

UML as a Blueprint � Complete specification ● Forward & reverse engineering � Detailed design ● All design decisions laid out All d i d i i l id t ● Simplifies programming � Usually done by senior developer � More formally documented � CASE tools ● Forward Engineering ◘ Support diagramming ◘ Repository to store information ● Reverse Engineering ◘ Read source code � Generate Diagrams Lecture Notes 7 - UML 25 UML as a Programming Language � UML Diagrams compiled into exe code ● Automatic code generation ● Sophisticated tool support Sophisticated tool support Lecture Notes 7 - UML 26 13