Software analysis and design tools T120B029 2004 pavasario sem. Instructor: Eduardas Bareiša, Associate Professor Department of Software Engineering Studentų 50-406 Office Hours: Monday 8:00 - 10:00, Friday 8:00 - 10:00 Lectures Hours: Tuesday 12:30 - 14:00; Labs Hours: Monday 08:00 - 09:45; 10:00 - 11:45; Tuesday 10:00 - 11:45; Thursday 17:45 - 19:15; Friday 08:00 - 09:45; phone: +370 37 300361 email: edas@soften.ktu.lt www. soften.ktu.lt/~edas/t120b029 2 T120B029 Textbooks • Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process ,2/e (ISBN: 0130925691) • Ian Sommerville, Software Engineering 6th Edition 3 T120B029 LINKS • http://www.smartdraw.com/resources/cen ters/software/omt.htm • http://www.smartdraw.com/resources/cen ters/software/oose.htm • http://www.smartdraw.com/resources/cen ters/software/booch.htm • http://www.smartdraw.com/resources/cen ters/uml/uml.htm 4 T120B029 Software Lifecycle Activities Requirements Elicitation Requirements Analysis Expressed in Terms Of System Design Structured By Object Design Implementation Implemented By Realized By Verified By class... class... class... Use Case Model Testing Application Implementat SubSystems Domain ion Domain Objects Objects Source Code ? class.... ? Test Cases 5 T120B029 Products of Requirements Process Requirements Elicitation system specification :Model Analysis analysis model :Model 6 T120B029 Modeling with UML T120B029 Why model software? Software is already an abstraction: why model software? Software is getting larger, not smaller – NT 5.0 ~ 40 million lines of code – A single programmer cannot manage this amount of code in its entirety. • Code is often not directly understandable by developers who did not participate in the development • We need simpler representations for complex systems – Modeling is a mean for dealing with complexity 8 T120B029 Application and Solution Domain • Application Domain (Requirements Analysis): – The environment in which the system is operating • Solution Domain (System Design, Object Design): – The available technologies to build the system 9 T120B029 What is UML? • UML (Unified Modeling Language) – An emerging standard for modeling object-oriented software. – Resulted from the convergence of notations from three leading object-oriented methods: • OMT (James Rumbaugh) • OOSE (Ivar Jacobson) • Booch (Grady Booch) • Supported by several CASE tools – Rational ROSE – Microsoft Visio – ... 10 T120B029 UML and This Course • You can model 80% of most problems by using about 20% UML • In this course, we teach you those 20% 11 T120B029 UML First Pass • Use case diagrams – Describe the functional behavior of the system as seen by the user. • Class diagrams – Describe the static structure of the system: Objects, Attributes, and Associations. • Sequence diagrams – Describe the dynamic behavior between actors and the system and between objects of the system. • Statechart diagrams – Describe the dynamic behavior of an individual object as a finite state machine. • Activity diagrams – Model the dynamic behavior of a system, in particular the workflow, i.e. a flowchart. 12 T120B029 UML First Pass: Class Diagrams Class Multiplicity 1 2 PushButton state push() release() Association SimpleWatch 1 LCDDisplay blinkIdx blinkSeconds() blinkMinutes() blinkHours() stopBlinking() referesh() 1 1 1 2 1 Battery load() Time now() Attributes Operations Class diagrams represent the structure of the system 13 T120B029 Concepts In Software: Type and Instance • Type: – An abstraction in the context of programming languages – Name: int, Purpose: integral number, Members: 0, -1, 1, 2, -2, . . . • Instance: – Member of a specific type • The type of a variable represents all possible instances the variable can take. • Abstract data type: – Special type whose implementation is hidden from the rest of the system. 14 T120B029 Classes Name TariffSchedule zone2price getZones() getPrice() Attributes Operations • • • • • TariffSchedule Table zone2price Enumeration getZones() Price getPrice(Zone) Signature TariffSchedule A class represent a concept. A class encapsulates state (attributes) and behavior (operations). Each attribute has a type. Each operation has a signature. The class name is the only mandatory information. 15 T120B029 Instances tariff_1974:TarifSchedule zone2price = { {‘1’, .20}, {‘2’, .40}, {‘3’, .60}} • An instance represents a phenomenon. • The name of an instance is underlined and can contain the class of the instance. • The attributes are represented with their values. 16 T120B029 Associations TarifSchedule Enumeration getZones() Price getPrice(Zone) TripLeg * * price zone • Associations denote relationships between classes. • The multiplicity of an association end denotes how many objects the source object can legitimately reference. • Associations should be named (added by Hartrum) 17 T120B029 1-to-1 and 1-to-Many Associations Country name:String Has-capital 1 1 City name:String 1-to-1 association Polygon 1 * Point x:Integer y:Integer draw() 1-to-many association 18 T120B029 Qualification • The qualifier improves the information about the multiplicity of the association between the classes. • It is used for reducing 1-to-many multiplicity to 1-1 multiplicity Without qualification: A directory has many files. A file belongs only to one directory. Directory Directory 1 * File filename filename 1 0..1 File With qualification: A directory has many files, each with a unique name 19 T120B029 Aggregation • An aggregation is a special case of association denoting a “consists of” hierarchy. • The aggregate is the parent class, the components are the children class. Exhaust System 1 Muffler 0..2 Tailpipe 20 T120B029 Composition • A solid diamond denote composition, a strong form of aggregation where components cannot exist without the aggregate. TicketMachine 3 ZoneButton 21 T120B029 Generalization • Generalization relationships denote inheritance between classes. • The children classes inherit the attributes and operations of the parent class. • Generalization simplifies the model by eliminating redundancy. Button CancelButton ZoneButton 22 T120B029 Object Types • Entity Objects – Represent the persistent information tracked by the system (Application domain objects, “Business objects”) • Boundary Objects – Represent the interaction between the user and the system • Control Objects: – Represent the control tasks performed by the system • Having three types of objects leads to models that are more resilient to change. – The boundary of a system changes more likely than the control – The control of the system change more likely than the application domain • Object types originated in Smalltalk: – Model, View, Controller (MV) 23 T120B029 Example: 2BWatch Objects • UML provides several mechanisms to extend the language • UML provides the stereotype mechanism to present new modeling elements <<entity>> Year <<entity>> Month <<control>> ChangeDateControl <<boundary>> ButtonBoundary <<boundary>> LCDDisplayBoundary <<entity>> Day 24 T120B029 Finding Participating Objects in Use Cases • For any use case do the following – Find terms that developers or users need to clarify in order to understand the flow of events • Always start with the user’s terms, then negotiate: – – – FieldOfficerStationBoundary or FieldOfficerStation? IncidentBoundary or IncidentForm? EOPControl or EOP? – Identify real world entities that the system needs to keep track of. Examples: FieldOfficer, Dispatcher, Resource – Identify real world procedures that the system needs to keep track of. Example: EmergencyOperationsPlan – Identify data sources or sinks. Example: Printer – Identify interface artifacts. Example: PoliceStation – Do textual analysis to find additional objects (Use Abott’s technique) – Model the flow of events with a sequence diagram 25 T120B029 UML First Pass: Sequence Diagram Object :WatchUser :SimpleWatch :LCDDisplay pressButton1() blinkHours() pressButton1() blinkMinutes() pressButton2() :Time incrementMinutes() refresh() pressButtons1And2() commitNewTime() stopBlinking() Activation Message Sequence diagrams represent the behavior as interactions 26 T120B029 Sequence Diagram Observations • UML sequence diagrams represent behavior in terms of interactions. • Complement the class diagrams which represent structure. • Useful to find participating objects. • Time consuming to build but worth the investment. 27 T120B029 UML First Pass: Statechart Diagrams Initial state Event button1&2Pressed Blink Hours Transition button2Pressed State Increment Hours button1Pressed button1&2Pressed Blink Minutes button2Pressed Increment Minutes button1Pressed Stop Blinking Blink Seconds button2Pressed Increment Seconds button1&2Pressed Final state T120B029 28 Activity Diagrams • An activity diagram shows flow control within a system Handle Incident Document Incident Archive Incident • An activity diagram is a special case of a state chart diagram in which states are activities (“functions”) • Two types of states: – Action state: • Cannot be decomposed any further • Happens “instantaneously” with respect to the level of abstraction used in the model – Activity state: • Can be decomposed further • The activity is modeled by another activity diagram 29 T120B029 Activity Diagram: Modeling Decisions Open Incident [lowPriority] Allocate Resources [fire & highPriority] [not fire & highPriority] Notify Fire Chief Notify Police Chief 30 T120B029 Activity Diagrams: Modeling Concurrency • Synchronization of multiple activities • Splitting the flow of control into multiple threads Splitting Synchronization Allocate Resources Open Incident Coordinate Resources Archive Incident Document Incident 31 T120B029 Activity Diagrams: Swimlanes • Actions may be grouped into swimlanes to denote the object or subsystem that implements the actions. Allocate Resources Open Incident Coordinate Resources Document Incident Dispatcher Archive Incident FieldOfficer 32 T120B029 Other UML Notations UML provide other notations that we will be introduced in subsequent lectures, as needed. • Implementation diagrams – Component diagrams – Deployment diagrams – Introduced in lecture on System Design • Object Constraint Language (OCL) – Introduced in lecture on Object Design 33 T120B029 Summary • UML provides a wide variety of notations for representing many aspects of software development – Powerful, but complex language – Can be misused to generate unreadable models – Can be misunderstood when using too many exotic features • We concentrate only on a few notations: – Functional model: use case diagram – Object model: class diagram – Dynamic model: sequence diagrams, statechart and activity diagrams 34 T120B029 Analysis: UML Activity Diagram Define use cases Define participating objects Define entity objects Define boundary objects Define control objects Define interactions Define efine Define n o n t r i v i a la D associations behavior ttributes Consolidate model Review model T120B029 35 Requirements Analysis Document Template 1. Introduction 2. Current system 3. Proposed system 3.1 Overview 3.2 Functional requirements 3.3 Nonfunctional requirements 3.4 Constraints (“Pseudo requirements”) 3.5 System models 3.5.1 Scenarios 3.5.2 Use case model 3.5.3 Object model 3.5.3.1 Data dictionary 3.5.3.2 Class diagrams 3.5.4 Dynamic models 3.5.5 User interface 4. Glossary 36 T120B029