高等軟體設計 NCCU CS Lecture 3 Fall 2005 Sept

高等軟體設計 NCCU CS Lecture 3 Fall 2005 Sept. 27, 2005

Topics • The Big Picture: Software Development Process • Requirement Analysis and Specification • UML Overview • Class Diagrams • Sequence Diagrams

Software Process • Process is distinct from product – products are outcomes of executing a process on a project • SW Eng. focuses on process • Premise: Proper processes will help achieve project objectives of high Quality & Productivity • Software Process: A set of steps, along with ordering constraints on execution, to produce software with desired outcome • Many types of activities performed by diff people in a software project • Comprising of many component processes

Component Processes • Two major processes – Development – focuses on development and quality steps needed to engineer the software – Project management – focuses on planning and controlling the development process • Development process is the heart of software process; other processes revolve around it • These are executed by different people – developers execute development process – project manager executes the mgmt process • Other processes: – Configuration management process: manages the evolution of artifacts – Change management process: how changes are incorporated – … A process defines Who is doing What When, and How, in order to reach a certain goal.

Major Activities (Steps) in SW Development Process • Business modeling • Requirement Specification • System Analysis System Requirement Specification • System Design Requirement Analysis and Specification SRS – Architecture design (High level design) – Detailed design System Design Specification • Coding • Testing • Deployment SDS Analysis and Design

Examples of Software Development Process Iterative Requirements Analysis Design Coding Testing Requirements Analysis Design Coding Testing Time Design Coding Testing Coding Requirements Analysis Design Testing Coding Testing Scope (customer needs) Deliverables in every major steps Requirements Analysis Design Coding Testing Analysis Requirements Analysis Design Coding Testing Requirements e. Xtreme Programming (XP Requirements Analysis Design Coding Testing Waterfall

Rational Unified Process (RUP) Incremental and Iterative Workflow group activities logically In an iteration, you walk through all disciplines http: //www. upedu. org/upedu/index. asp? Tru. Y=861972421378267

Requirements: Analysis, Specification, Management

Requirement Elicitation Analyzing the problem The notion that we find out what users need by simply asking them is NOT true.

Deep Structure of Requirements WANT: local user domain knowledge NEED: global user domain knowledge Requirement Specification CAN-DO: design expert domain knowledge Not all that you hear, should be implemented; and not all that is implemented, is needed.

Stakeholder Needs (extracted from the slides of Peter Hauker, Rational)

Features of the System (extracted from the slides of Peter Hauker, Rational)

Software Requirements (extracted from the slides of Peter Hauker, Rational)

Requirements Types • Describe the functionality or services that the system is expected to provide • Address the input-output behavior of a system • Performance • Security • Reliability • UI • … • Specific Platform • Standard compliance • Legacy integration • UI • …

Requirement Specification • Definition: “Specifications represent a model of how inputs are related to system reactions and outputs” • Specification is a representation process. • Requirements are represented in a manner that ultimately leads to a smooth implementation • Specifications will increase the level of details given in the requirements • It will answer much more questions, thus furthering the analysis before solution writing • Needed for : complex, large, or critical problems.

Need for SRS • SRS establishes basis of agreement between the user and the supplier. – Users needs have to be satisfied, but user may not understand software – Developers will develop the system, but may not know about problem domain – SRS is the medium to bridge the commn. gap and specify user needs in a manner both can understand

Characteristics of a Good SRS • • Correct Complete Unambiguous Consistent Verifiable Traceable Modifiable Ranked for importance and/or stability

Requirement Specifications seldom clearly capture customer needs What user wanted How customer described it How analyst specified it How designer implemented it Don't Gather Requirements—Dig for Them

Specification Languages • Natural languages mostly used, with some structure for the document – Carry lot of noise, ambiguities, and contradictions – Hard to analyze – Example: Signs Displayed at the Foot of an Escalator in an Airport Dogs Must Be Shoes Must Be Carried Worn • Formal languages are precise and unambiguous but hard • Formal languages used for special features or in highly critical systems

Signs at the Airport – cont.

What Do Software Requirements Specify? Inputs Outputs System Environments Functions Performance Security …

Specifying the Software Requirements Needs Vision Document Features SRS Software Requirements Use-Case Model SRS Package Supplementary Specifications The Software Requirements Specification (SRS) package defines complete external behavior and characteristics of the system to be built.

What Is in an SRS Package? 1. Introduction 1. 1 Purpose 1. 2 Scope 1. 3 Definitions, Acronyms, and Abbreviations 1. 4 References 1. 5 Overview 2. Overall Description 2. 1 Use-Case Model Survey 2. 2 Assumptions and Dependencies 3. Specific Requirements 3. 1 Use Case Reports 3. 1. 1 <Use Case 1> 3. 1. 2. . . 3. 2 Supplementary Specifications 3. 2. 1 Usability Requirements 3. 2. 2 … 4. Supporting Information Appendixes Index TP 7: SRS Package Template

Use Case Approach to Modeling Functional Requirements Build a Use Case Model Use cases document the behavior of the system from the users’ point of view.

A Use-Case Model Contains Diagrams and Text The System Use Case Model Survey survey description list of all actors list of all use cases Actor 1 Use Case 1 Actor 2 Use Case 3 Actor 3 Use Case 1 Report brief description flow of events Use Case 2 Report brief description flow of events Use Case 3 Report brief description flow of events

Actors and Use Cases Actor Someone/something outside the system that interacts with the system Actor Use Case Use case What an actor wants to use the system to do

Communicates Association Actor 1 Use Case Actor 2 • A channel of communication between an actor and a use case • A line is used to represent it • An arrow indicates who initiates the communication

Use Case Diagram An Automated Teller Machine (ATM) Bank Customer Withdraw Cash Bank Consortium Transfer Funds Cashier Deposit Funds Maintain ATM Maintenance Crew

Use Case Diagrams Package Simple. Watch System Boundry Actor Read. Time Watch. User Use case Set. Time Watch. Repair. Person Change. Battery Use case diagrams represent the functionality of the system from user’s point of view

Documenting Use Cases Use case: Place Order Actors: Costumer Precondition: A valid user has logged into the system Flow of Events: 1. The use case begins when the customer selects Place Order 2. The customer enters his or her name and address 3. If the customer enters only the zip code, the system supplies the city and state 4. The customer enters product codes for products to be ordered 5. For each product code entered a) the system supplies a product description and price b) the system adds the price of the item to the total end loop 6. The customer enters credit card payment information 7. The customer selects Submit 8. The system verifies the information [Exception: Information Incorrect], saves the order as pending, and forwards payment information to the accounting system. 9. When payment is confirmed [Exception: Payment not Confirmed], the order is marked confirmed, an order ID is returned to the customer, and the use case terminates Exceptions: Payment not Confirmed: the system will prompt the customer to correct payment information or cancel. If the customer chooses to correct the information, go back to step 6 in the Basic Path. If the customer chooses to cancel, the use case terminates. Information Incorrect: If any information is incorrect, the system prompts the customer to correct it. Postcondition: If the order was not canceled, it is saved in the system and marked confirmed

• A use case describes the possible sequences of interactions among the system and one or more actors in response to some initial stimulus by one of the actors • Each way of using the system is called a use case • A use case is not a single scenario but rather a description of a set of potential scenarios

A Scenario Is a Use Case Instance Student Register for Courses Course Catalog System Scenario 1 Log on to system Approve log on Enter subject in search Get course list Display course list Select courses Confirm availability Display final schedule Scenario 2 Log on to system Approve log on Enter subject in search Invalid subject Reenter subject Get course list Display course list Select courses Confirm availability Display final schedule

Relationships between Use Cases

TRACEABILITY: the ability to find corresponding or related information in other documents or software Use Cases Desired functionality Design Model Expressed in terms of realized by Structured by Domain Model Analysis Model SRD Design Model AD, DD Tested in implemented by Implementation Model code Test Plan

Levels of Testing User needs Requirement specification Acceptance testing System testing Design Integration testing code Unit testing

Find Actors and Use Cases • • Identify actors Describe actors Identify use cases Describe use cases briefly Identify actor and use case relationships Make use case diagrams Outline use cases Use Cases have become part of the UML.

The UML is • The language of blueprints for software • A graphical language for – – visualizing specifying constructing documenting the artifacts of a software intensive system. (code & document)

Methodology • An approach to development – What to do – When to do – How to do • • Needs notation, such as UML, is notation! Example: Rational Unified Process (RUP) Methodology wars back in mid 1980 s. Notation 不能統一方法，先統一表達方式 Process Tool

UML Models • • Business Use Case diagrams Activity diagrams Sequence/collaboration diagrams Object/Class diagrams State diagrams Component diagrams Deployment diagrams 捕捉需求；表達設計

Visual Modeling Using UML Diagrams Use-case diagram Class diagram Statechart diagram Document. List Use Case 1 File. Mgr Actor A Actor B Document add( ) delete( ) fetch. Doc( ) sort. By. Name( ) name : int docid : int num. Field : int get( ) open( ) close( ) read( ) sort. File. List( ) create( ) fill. Document( ) Use Case 2 File. List f. List add( ) delete( ) read() fill the code. . 1 Use Case 3 rep Repository (from Persistence) File read( ) Grp. File name : char * = 0 read. Doc( ) read. File( ) Collaboration diagram 9: sort. By. Name ( ) Repository main. Wnd : Main. Wnd 1: Doc view request ( ) read( ) open( ) create( ) fill. File ( ) Document. List Deployment diagram Windows 95 Window 95 File. Manager Windows 95 L 2: fetch. Doc( ) Document g. File : Grp. File 4: create ( ) ¹®¼ °ü¸® Å¬¶óÀÌ¾ðÆ®. EXE ¹®¼ °ü¸® ¾ÖÇÃ¸´ 8: fill. File ( ) Windows NT user : Clerk Solaris file. Mgr : File. Mgr ¹®¼ °ü¸® ¿£ Áø. EXE Graphic. File 3: create ( ) Alpha UNIX ÀÀ¿ë¼ ¹ö. EXE 6: fill. Document ( ) File. List Windows NT IBM Mainframe 7: read. File ( ) 5: read. Doc ( ) document : Document repository : Repository µ¥ÀÌÅ¸º£ÀÌ½º¼ ¹ö main. Wnd user Æ¯Á¤¹®¼ ¿¡ ´ ÇÑ º¸±â¸¦ ë » ç¿ëÀÚ°¡ ¿äÃ» ÇÑ´Ù. file. Mgr : File. Mgr document : Document 1: Doc view request ( ) 2: fetch. Doc( ) g. File repository Component diagram 3: create ( ) 4: create ( ) 5: read. Doc ( ) È ÀÏ°ü¸®ÀÚ´ ÀÐ¾î¿ ¹®¼ ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼ °´Ã¼¿¡ ¼³Á¤À» ¿äÃ» ÇÑ´Ù. 6: fill. Document ( ) 7: read. File ( ) 8: fill. File ( ) È ¸é °´Ã¼´ ÀÐ¾îµéÀÎ °´Ã¼µé¿¡ ´ëÇØ ÀÌ¸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È ¸é¿¡ º¸¿©ÁØ´Ù. 9: sort. By. Name ( ) Sequence diagram Forward and Reverse Engineering Target System

Modeling: From Requirements To Solution • Modeling a system involves: – identifying the things that are important to your particular view – Their structures and properties – consider how specific instances of these things must fit together (interaction). • Modeling a system is affected by how you expect to use the system

A Simple Example: Dice Game • Requirements is the Starting Point (WHAT, i. e. , problem oriented) Dice Game: • A player rolls two dice. § If the total is seven, the player wins; otherwise he loses.

SE: Dice Game • Solution Dice Game: • Roll two dice. CONGRATULATIONS! You won the game.

SE: Dice Game • Modeling Features: Dice Game: • A player rolls two dice. § If the total is seven, the player wins; otherwise he loses. Play with one user and two dice

SE: Dice Game Modeling Structure Rolls 1 Player 2 name Die Face. Value 2 1 Plays 1 Dice. Game total 1 Includes

SE: Dice Game Modeling Behavior : Dice. Game Die 1: Die 2: Die Play() roll() Get. Face. Value() Result() Total()

UML Diagrams Static Dynamic Class Use Case Object Sequence Component Collaboration Deployment Statechart Structural Activity Behavioral

OOA Using UML: Overview • Requirements elicitation – Use case diagrams • Requirements analysis – – Class diagrams Sequence diagrams State diagrams Activity diagrams • Requirements verification and validation – We will discuss it later

Sequence Diagrams Objects Interaction diagrams • A sequence diagram shows a particular sequence of messages exchanged between a number of objects • Sequence diagrams also show behavior by showing the ordering of message exchange • A sequence diagram shows one particular communication sequence in one run of the system – it is not characterizing all possible runs

Ordered messages

Components of Sequence Diagrams • Object (an instance of a class) – shown as a box at the top of a vertical dashed line – instance syntax instance. Name: Class. Name : Order. Entry. Window Object • Lifeline – dashed line, represents time flow Lifeline instance name can be omitted (means anonymous instance)

Components of Sequence Diagrams • Messages – communication between objects – method calls at the implementation level : Product. Order : Stock. Item Message check() needs. To. Reorder() • Special message types – self delegation – return • show returns only if it adds to clarity – <<create>> – <<destroy>> Self-delegation Return

Components of Sequence Diagrams • Two kinds of control information: : Order : Product. Order *prepare() – message conditions • message is sent only if the condition is true – iteration marker: * • message sent to multiple receiver objects : Stock. Item check() Iteration message condition [check=“true”] remove()

Example Sequence Diagram : Order. Entry. Window : Order : Product. Order : Stock. Item prepare() *prepare() check() [check=“true”] remove() needs. To. Reorder() [needs. To. Reorder=“true”] <<create>> : Reorder. Item [check=“true”] <<create>> : Delivery. Item

Sequence diagrams and use cases Finding the objects System Object Border One Two Three Four use case scenario written down here Time

Building a Sequence Diagram 1 1. Identify the use case whose sequence diagram you will build (if applicable). 2. Identify which entity initiates the use case – the user, or – an object of a class • name the object 3. Draw a rectangle to represent this object at left top – use UML object: Class notation 4. Draw an elongated rectangle beneath this to represent the execution of an operation 5. Draw an arrow pointing right from its top my. Object : My. Class Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Building a Sequence Diagram 2 6. Identify which entity handles the operation initiated my. Object 1 : My. Class 1 – an object of a class • name the object 7. Label the arrow with the name of the operation 8. Show a process beginning, using an elongated rectangle 9…… Continue with each new statement of the use case. operation() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Sequence diagram shapes Fork - centralised Stair - decentralised • operations can change order • Operations have strong connections • new operations may be added • performed in same order • behaviour is encapsulated

Activity Diagrams • Activity diagrams show the flow among activities associated with a given object using: – – – activity and action states transitions branches merges forks joins guard expressions Authorize Payment branch [succeeded] [failed] Dispatch Order Cancel Order

Activity Diagram Do Something More [condition true] else Fork and Join Do A Task Do Another Task } In parallel Do Even More Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Stock Manager Order Processing Finance Receive. Supply Receive Order *for each order item Authorize Payment Choose Outstanding Order Items Check Order Item * for each chosen order item [in stock] [failed] Assign to Order [succeeded] Assign to Order vertical lines are used to separate “swimlanes” to show which activities are handled by which part of the system Cancel Order [need to reorder] Reorder item [stock assigned to all order items and payment authorized] Dispatch Order [all outstanding order items filled] Add Remainder to Stock

Class Diagrams Structures and Relationships

UML Class Diagrams • Class diagrams can be used at different stages of development – For requirements specification, for design specification, and for implementation • In requirements specification class diagrams can be used to model real world objects or concepts • In design specification it can be used to specify interfaces and classes that will be implemented in an object oriented program • In implementation they can be used to show the architecture of the software by showing the relationships among different classes

Object Oriented Class Analysis Object/concept representations • Domain concept • Visualization of concept Book title • Programming language representation public class book { private String title; public Chapter get. Chapter(); }

UML Classes • A class is represented as a three-part box • Class Name • Attributes – At conceptual level it is a piece of information associated with the class that can be accessed and possibly modified – Corresponds to a field at the implementation level – Difference from association: navigability is from class to attribute (not both ways as in association) • Operations – The processes the class can carry out (methods at implementation level) – Basic operations (such as get. Value) on attributes can be omitted (they can be inferred)

Class Diagrams wafer Canister + num. Canisters: int num. Wafers: int size: float +: Visible from without + display() get. Num. Open. Slots() + set. Status() canister Responsibilities: describes each canister undergoing fabrication Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. Class name Attribute: type Operations Place for comments

Class Relationships: 3 Kinds Window Event open() close() dependency generalization Console. Window Dialog. Box Control association

Dependency • • A change in one thing may affect another. “Uses” relationship. May have a name, but not common. Use Dependency to show one thing uses another. Audio. Clip name record(m: Microphone) start() stop() Microphone dependency When • Operations of the client class create objects of the supplier class • Operations of the client class have signatures whose return class or arguments or local vars are instances of (or references to) the supplier class

Dependence : UML Notation … and …Typical My. Dependent. Class att: int my. Function() Implementation My. Referenced. Class dependence (reference to a class) class My. Dependent. Class {. . . void my. Function 1( My. Referenced. Class r ) {. . . } My. Referenced. Class my. Function 2( … ) {. . . } } void my. Function 3( … ) { My. Referenced. Class m … } parameter or return type or local variable type Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Generalization • Relationship between general thing (parent) and more specific thing (child) • Child “is a kind of” parent. • Child inherits attributes and operations of parent. • Use when you want to show parent child relationship generalization Shape Rectangle Circle Square base class Polygon leaf class

Associations • Relations between classes • Roles 1 left. Role – analogous to names of instance variables • Navigation – bidirectional: each class references the other – unidirectional: A knows B, but B doesn’t know A – no arrow heads: means either “bidirectional” or “not specified” • Multiplicities – 0, 1, *, 0. . 1, 1. . *, 5. . 6, and so on – says how many objects each object knows – would be realized through arrays, sets, lists, and so on * right. Role

Associations: Conceptually • Responsibility – – – A A knows B A talks to B A is responsible for updating B A can get data from B A is owner of B A can do things with B • A link between objects of the two classes B

Associations (UML) • Represent conceptual relationships between classes (structural) direction indicator: relationship name Professor * teaches teacher how to read relation name 1. . * Course class role names Multiplicity defines the number of objects associated with an instance of the association. Default of 1; Zero or more (*); n. . m; range from n to m inclusive

Association : UML Notation and Typical Implementation Employer 反應在 Attribute上 1. . 3 employs is employed by 1. . n Employee class Employer { Employee[ ] employees; . . . } class Employee { Employer[ ] employers; . . . } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Multiplicity –the number of instances of one class that may be related to an instance of another –constrains the number of links between objects 1 1. . * Class exactly one 0. . * Class mandatory (one or more) Class many (zero or more) 0. . 1 Class optional (zero or one) 2. . 4, 6. . 8 Class numerically specified

An Example of Association Modeling from HL 7 Version 3 Tutorial Reference Information Model By George W. Beeler, Jr. , Ph. D

Unified Modeling Language “Association role name” • Class defines things • Objects are instances • Associations relate things – describe the way things relate to other things Patient name DOB address : PN : TS : AD 0. . * provides care for seeks care at Doctor name : PN 1. . * specialty : CD phone : TEL cardinality or “multiplicity” • specifies how many such object instances each association instance can/must have

Unified Modeling Language • Class defines things • Objects are instances • Associations relate things – describe the way things relate to other things “Reading” associations in plain English: Patient name DOB address : PN : TS : AD 0. . * seeks care at provides care for Doctor name : PN 1. . * specialty : CD phone : TEL “Every Patient … seeks care at … 1 to many … Doctors” “Every Doctor … provides care for. . . zero to many … Patients”

Unified Modeling Language The most compelling reason for having links and attributes is for many-to-many relationships • • Class defines things Objects are instances Associations relate things Associative classes add properties to relationships – attributes about association Patient name DOB address : PN : TS : AD 0. . * provides care for Doctor name : PN 1. . * specialty : CD phone : TEL seeks care at Encounter type time reason : CV : IVL TS : CD

Unified Modeling Language • • Class defines things Objects are instances Associations relate things Associative classes add properties to relationships – attributes about association Patient name DOB address : PN : TS : AD 0. . * 1 Encounter type time reason : CV : IVL TS : CD 1 1. . * Doctor name : PN specialty : CD phone : TEL

Unified Modeling Language • • • Person name DOB address : PN : TS : AD Patient gender donor V. I. P. : CD : BL 0. . * 1 Class defines things Objects are instances Associations relate things Associative classes Generalization classes Encounter type time reason : CV : IVL TS : CD 1 1. . * Doctor specialty : CD phone : TEL privileges : CV • Generalization classes can simplify the model – through reuse of common concepts – express logical truths of the application domain – work the other way as “specialization classes”

Unified Modeling Language • • • Person name DOB address : PN : Date : AD Patient gender donor V. I. P. : CD : BL 0. . * 1 0. . 1 Class defines things Objects are instances Associations relate things Associative classes Generalization classes Reflexive associations Encounter type time reason follow-up : CV : IVL TS : CD 1 1. . * Doctor specialty : CD phone : TEL privileges : CV 0. . 1 • Reflexive associations structure instances of one class – chain (predecessor successor, ) hierarchy (parent child, ) or network

Associations – UML Links – Link is a semantic connection among objects. – A link is an instance of an association. class Worker association name 1. . * works for employee +set. Salary( s : Salary) +set. Dept( d : Dept) w : Worker Named object assign(development) link * employer class Company : Company Anonymous object

Associations – Link Attributes • Link Attributes The most compelling reason for having links and attributes is for many to many relationships File User access permission link attribute • UML Association Class File * 1. . * User class Access. Right access permission association class

Use an Association Class When: • An attribute is related to an association • Instances of the association class must have a life-time dependency on the association • There is a many-to-many association between two concepts and information associated with the association itself

N ary Association • An n-ary association is an association among three or more classes – N equals to the number of classes in the association • Each instance of the association is an n-tuple of values from the respective classes • A binary association (seen in the previous lectures) is a special case of the n-ary association – the multiplicities of n ary association are less obvious than multiplicities of binary associations • • It is usually best to use binary associations to keep a model clearer

Example Indicates n-ary association Association class

Aggregation and Composition • Aggregation is a part of relationship • Composition is also a part of relationship, but part and whole live and die together Order shows aggregation 1 1 Shipping Information 1 Billing Information 1. . * Book shows composition

Refinement of Aggregations – An aggregation relationship means that the source object must contain semantic knowledge of the target object – The relationships may be of two kinds: • By reference • By value (Composition) C++ style design consideration, not good for other languages

By Reference/By Value Relationships – By reference relationships denote independent lifetimes • Shown as an unfilled diamond By value relationship indicate dependent lifetimes Create the object then create the related object Delete the object then delete the related object In Java, only by-reference aggregation

Recursive Aggregation – aggregation can be FIXED - VARIABLE - RECURSIVE - the number and type of the parts is fixed the number of parts may vary, but the number of levels is fixed the number of levels, and hence parts, is unlimited * Compound statement Block * Program Simple statement

Modeling Structural Relationships Considering a bunch of classes and their association relationships p School 1 has 1. . * Department 0. . 1 1. . * 5 assigned to 5 member * 1. . * attends 4 Student * * 1. . * 3 teaches 1. . * Course * 1 chairperson Instructor

Parameterized Classes (Template) • Class List represents a collection of objects of a class • That class becomes a parameter to the parameterized class - e. g. list of accounts Parameterized class List Insert(T) Remove(T) TT Account. List <<bind>> T to Account

UML State Diagrams • nodes represent states: rounded rectangles with state name – initial state represented as solid circle – final state represented as bull’s eye • edges represent transitions between states and are labeled with an event name (the trigger) STATE-1 Event-c Event-b STATE-2 Event-a Event-e STATE-3 Event-d result

How do they all fit together? • Functionality – use case diagrams • Decomposition – class diagrams (class structure) – package diagrams, deployment diagrams (architecture) • Behavior – state diagrams, activity diagrams • Communication – sequence diagrams, collaboration diagrams

Analysis vs. Design

Analysis and Design

OOA and OOD • OO techniques can be used in analysis (req) as well as design • The methods and notations are similar • In OOA we model the problem, while in OOD we model the solution • Often OOA structures are subsumed in the solution domain structures • The line between OOA and OOD is not fixed

Summary • Software Development Process • Requirement Analysis and Specification – Use Case Modeling • The Unified Modeling Language – Class diagrams • Association, Dependency, Inheritance, Aggregation – Sequence diagrams – Activity diagrams – State diagrams • From OOA to OOD