ObjectOriented Analysis and Design Session 1 Introduction Mira

Object-Oriented Analysis and Design Session 1: Introduction Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 1

Characterization of a Good System (1) • Useful and usable – – • Reliable – • It would be easy to add new requirements such as dealing with CDs. Affordable – • The system should mark the right ordered book for a specific student. Flexible (modifiable) and easy maintenance – • The library may be operated by less people. The students will be able to order books. The university has allocated the right budget to develop the system. Available – The system should work 7 days a week. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 2

Characterization of a Good System (2) Difficulties: • Our understanding of systems is usually partial: – It is not trivial to understand the tracking mechanism. • We tend to misinterpret casual properties as characteristic ones: – A borrower account number is not essential to the system. • We tend to solve problems locally: – Developing an additional search mechanism within the order processing. • We tend to solve whole problems. Small changes in specifications lead to reconstruction of the whole system: – The system is planned to support only books and journals. Addition of CDs implies changes to the design (and code). Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 3

The Unified Process (Booch, Jacobson, and Rumbaugh) Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 4

Unified Process (UP) • Characterization of the UP: – Incremental. – Iterative. – Use-Case Driven – Development follows stories of software usage. – Architecture-Centric – Software development is centered around system architecture (and not functionalities). Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 5

Incremental Iterative Aspects of UP • • Software is developed in distinct iterations. Each iteration extends the previous. Each iteration might involve different activities. Iterations at early stages of software development differ from iterations at later stages. • In the Library example: – First iteration might produce: • Analysis of major library concepts – Librarian, Book-Copy, Book-Loan. • Simple book borrowing functionality. – Second iteration: Complex book borrowing functionalities. – Third iteration: … Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 6

Incremental Iterative Aspects of UP Advantages: – Risks are mitigated earlier. – Change is more manageable. – There is a higher level of reuse. – The project team can learn along the way. – Managed complexity. – Early visible progress. – Early feedback. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 7

The Unified Process Official Description Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 8

Phases and Workflows in the UP • The vertical dimension (workflows) specifies the process components and artifacts. • The horizontal dimension (Phases) represents the dynamic aspect of the process and shows its lifecycle. • Workflow vs. Phase – Workflow is presented in a technical context. – Phase is presented in a business context. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 9

Modeling Languages (also called “Models”) Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 13

Modeling Objectives • • Visualize a system as it is or as we want it to be. Specify the structure or behavior of a system. Provide a template that guides system construction. Document decisions that we have made. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 14

Importance of Modeling Languages • The modeling language that expresses the problem domain influences the overall solution. • Language refinement: Every model may be expressed at different levels of precision. • A modeling language must be connected to reality. • Belief: No single modeling language is sufficient for the specification of complex systems. – A small set of nearly independent modeling languages is required Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 16

Historical View on Modeling Languages – 1960’s – Output-oriented methods – 1970’s – Process-oriented methods (Structured System Analysis and Design – SSAD): • Use DFDs – Data Flow Diagrams. – 1980’s – Data-oriented methods: • Use ERDs – Entity-Relationship Diagrams. – 1990’s – Object-oriented methods (OMT, OOD, OOSE, UP): • Standard: UML – Unified Modeling Language. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 17

Structured System Analysis and Design – Hierarchical functional system decomposition: • Decomposition by system processes. – Development methodology: Waterfall. – Visual Modeling languages: • Data Flow Diagrams (DFDs). • Entity relationship diagrams (ERDs). – When Appropriate? • Small systems. • No Domain Logic layer. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 18

Structured System Analysis and Design Example: In the Library information system: – System is broken by processes into: • Return/Loan, • Add. Resources, • report. Fines, • . . . Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 19

The Object-Oriented (OO) Approach § Structure is more stable than processes. – Preferable: Systems that are structure-oriented over systems that are solution/process-oriented. § System is decomposed by objects. § Focus is on: § Responsibilities and roles of objects. § Co-operation and collaboration between objects. – Development methodology: Iterative. – Visual languages: UML – When Appropriate? -- Rich Domain Logic layer. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 20

The Object-Oriented (OO) Approach Example: In the Library information system: – System is broken by the object model into: • Classes: Book, Copy, Library. Manager, . . . • Association: borrow/return, . . . • Processes: Return/Loan, Add. Resources, report. Fines, … – by assigning responsibilities to objects. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 21

Encapsulation and Abstraction Encapsulation: When a client is not able to know more than is in the Interface. Abstraction: When a client does not need to know more than is in the interface – declared services For example: Core Module – List and its Client – Queue Abstraction/encapsulation are essential for modularity Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 22

A measure for abstraction: Cohesion is the amount of coherency of a module – a module needs a main theme: Theme 1 - Borrowing Theme 2 - Searching High cohesion is a major pattern (advice) in assigning responsibilities to modules Good abstraction implies reuse Pluggable components. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 23

What is Dependency? Module A depends on module B if changes to module B can imply changes to module A: A is a client of B – A use services of B; B acts as a server to A Ordering depends on Searching • Important information for a module: – Which modules are its clients? – What assumptions clients make about it? – Which modules are its servers? Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 24

A measure for dependency: Coupling is the amount of dependency among modules. A system with many dependencies has high coupling. Good systems have low coupling. Low coupling is a major pattern (advice) in assigning responsibilities to modules. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 25

Achieving Modularity • Interface is the means for achieving modularity: – Interfaces encapsulated modules • Interface of a module: – Encapsulates knowledge about a module. – Defines features on which clients can rely. • Contract of a module – Declares the responsibilities of a module (interface, services, constraints). – States the context dependencies of a module -the services it requires in order to work. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 26

Layering • A common technique for breaking apart complex software systems. – Machine architectures: Programming languages + Operating systems. Device drivers + CPU instructions. Logic gates inside chips. – Networking: FTP TCP IP Ethernet. • Principles: – Higher layers use services of lower layers. – Lower layers are unaware of their higher layers. – Each layer hides its lower layers from its super layers. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 27

Pros. and Cons. of Layering • Pros. – Understand one layer independently of other layers: • Abstraction – Replace layers with alternative implementations. – Minimize dependencies between layers. – A layer can be used for multiple purposes in higher layers • Information systems • Cons. – Reduce efficiency: Translation takes time. – Changes in a higher layer propagate downwards. • Addition of a field in a user interface propagates down to the database layer – instead of a direct database schema revision. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 28

The Three Principal Layers Presentation Responsibilities Display information –windows, HTML. Handle user/communication requests – mouse, keyboard, command line. Domain Logic Application core (business logic) Data source Mira Balaban and Arnon Sturm Persistent data storage (Data base, files) Object-Oriented Analysis and Design 29

Splitting Information among Layers (1) Example: “Find the award winning staff member – serves maximal number of book loans”. Bad splitting: (no splitting) 1. The UI layer access the database for all staff members and the number of book loans they each handled. 2. It then finds the maximal number of book loans. 3. Finally, it finds the corresponding staff member and singles it with a red color. Drawbacks: – Change in the awarding policy implies changes in the UI layer. – If the awarding policy is duplicated (e. g. , for communication with the Human Resource department) than policy change implies multiple revisions (consistency problems). – Change in the singling-out technique implies system changes. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 30

Splitting Information among Layers (2) • Good splitting: – UI Layer asks Domain Layer for the winning staff member. – Domain Layer asks Data Layer for all staff members and the number of book loans they handled. – Domain Layer determines the award winning staff member according to the awarding policy. – Domain Layer asks the UI Layer to single out the award winning staff member. – UI Layer singles out the award winning staff member with a red color. • Advantages: – Changing the awarding policy affects only the domain layer in a single point (3). – Change in the singling-out technique (5) does not affect the rest of the system. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 31

Component-based software engineering • Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. • Process stages: – – Component analysis. Requirements modification. System design with reuse. Development and integration. • Becomes popular as component standards are emerging. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 32

The Unified Modeling Language (UML) started at 1995 Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 33

What Is the UML? • The Unified Modeling Language (UML) is a family of independent languages for • • Specifying Visualizing Constructing Documenting different aspects of a software-intensive system. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 34

UML Goals • Define an easy-to-learn but semantically rich visual modeling language. • Unify existing Object-Oriented modeling languages: – Booch, OMT, and OOSE modeling languages. • Incorporate industry best practices. Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 35

The SSAD Visual Languages Use Case Diagrams DFDs Use Case Diagrams Transaction Diagrams DFDs Model State Diagrams Menu Diagrams Hierarchies Scenario Diagrams ERD Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 36

The UML Visual Languages Use Case Diagrams Activity Diagrams Scenario Diagrams Sequence Diagrams Scenario Diagrams Collaboration Diagrams Mira Balaban and Arnon Sturm Use Case Diagrams State Diagrams Class Diagrams State Diagrams Model Deployment Diagram State Diagrams Object Diagrams Component Diagrams Object-Oriented Analysis and Design Diagrams 37

The UML Modeling Languages • Requirements engineering languages: – Use-cases and use-case diagrams. – Activity diagrams. • Structure (static) modeling languages: – Class diagrams. – Object diagrams. • Behavioral (dynamic) modeling languages: – Sequence diagrams; collaboration diagrams. – Statecharts. • Implementation level languages: – Deployment diagrams. – Component diagrams. • Object Constraints Language (OCL). Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 38

The UML Modeling Languages • In this course we teach software modeling in various stages of software analysis and design. • We use the following UML languages: – – – Use-cases and use-case diagrams. Activity diagrams (very shortly). Class diagrams and object diagrams: In much detail. Sequence diagrams, collaboration diagrams; Statecharts. Object Constraints Language (mainly the static aspects). Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 39

Requirements Use Case Model And Contracts Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design 40

Goal This session introduces the object-oriented software development process. (Larman: Applying UML and Patterns). Mira Balaban & Arnon Sturm 41

Stages in a development cycle: I. III. IV. V. Understanding requirements – use cases. Static modeling – Conceptual class diagram. Identify operations and create their contracts. Assign responsibilities and design interaction diagrams. Design level class diagrams, implementation and testing. The stages are not performed in sequence. Mira Balaban & Arnon Sturm 42

I. Understanding requirements – Use Cases • • • A use case is a narrative document – a story -that describes the sequence of events of an actor using a system to complete a process. A use case describes a typical interaction between an external entity (the actor – person, system, organization) to the system. A use case describes multiple scenarios. A scenario is a single path through the use case. A use case depends on partial understanding of the requirements. Use cases can be found by looking for their initiator actors. Mira Balaban & Arnon Sturm 43

CASE STUDY: Point-of-Sale • • • A Point Of Sale (POS) is a computerized application used (in part) to record sales and handle payments. Typically used in a retail store. Includes hardware and software. Interfaces to service applications, e. g. , tax calculator and inventory control. Fault tolerant, e. g. , remote services failure. Support varied client-side terminals and interfaces. Provide flexibility and customization -- different business rule processing, e. g. , when a new sale is initiated. Mira Balaban & Arnon Sturm 44

I. Understanding requirements – Use Cases Example: Use case Process Sale, in a brief format. A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a receipt from the system and then leaves with the items. Mira Balaban & Arnon Sturm 45

I. Understanding requirements – DFD E 1. Client Pa ym en ti Running total and current list of items 1. Record Item barcodes D 1| inventory list nf o 2. Receive payment info of i te ms Payment info 3. Record purchase Pa ym en Mira Balaban and Arnon Sturm Approval 3. Print receipt Pa ym ti E 3. Credit company E 2. Cashier nf o 3. Validate payment en t in fo Payment info Object-Oriented Analysis and Design E 1. Client E 3. Credit company 46

I. Understanding requirements – Use Cases Example: Use case Handle Returns, in a casual format. Mira Balaban & Arnon Sturm 47

I. Understanding requirements – Use Cases The detailed format for use cases includes the main story of the described process, the alternatives, and characterize the general Situation. The usecases. org format (www. usecases. org) includes: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Name. Primary actor. Stakeholders and interests. Preconditions. Post conditions. Main success scenario. Alternative flows. Special requirements. Technology variations. Frequency of occurrence. Open issues. Mira Balaban & Arnon Sturm 48

I. Understanding requirements – Use Cases Example: Use case Process Sale, in a detailed format. Mira Balaban & Arnon Sturm 49

I. Understanding requirements – Use Cases Mira Balaban & Arnon Sturm 50

I. Understanding requirements – Use Cases Mira Balaban & Arnon Sturm 51

I. Understanding requirements – Use Cases 4 a . Mira Balaban & Arnon Sturm 52

I. Understanding requirements – Use Cases Mira Balaban & Arnon Sturm 53

I. Understanding requirements – Use Cases Mira Balaban & Arnon Sturm 54

I. Understanding requirements – Use Cases Mira Balaban & Arnon Sturm 55

I. Understanding requirements – Use Cases Mira Balaban & Arnon Sturm 56

I. Understanding requirements – Use Cases M i r a B a l a b a n & A r n o n S t u r m A two-column conversation format between an actor and the system: 57

I. Understanding requirements – Use Cases What use cases are not ? A common mistake about use cases: A use case is a relatively large, end-to-end process description, that typically includes many steps or transactions; it is not normally an individual step or activity. For example: “print the receipt” is a step, system function, not a use case. Mira Balaban & Arnon Sturm 58

I. Understanding requirements – Use Cases Finding use cases: • Choose system boundary: Decide what is outside the system. For POS – cashier, payment authorization, inventory control, … • Identify primary actors. • Identify actor goals. • Define use cases that satisfy actor goals. Mira Balaban & Arnon Sturm 59

I. Understanding requirements – Use Cases Essential versus real use cases: • Essential – conceptual specification of expanded use cases. The customer identifies himself/herself. • Real – Concrete specification of the process. The customer inserts his/her credit card and types the code. Only in design level. Mira Balaban & Arnon Sturm 60

I. Understanding requirements – Use Cases Visualization of use cases – use case diagrams: A use case diagram illustrates: • A set of use cases for a system. • Their actors. • Relationships between actors and use cases. • Inter-relationships between use cases. Mira Balaban & Arnon Sturm 61

I. Understanding requirements – Use Cases A use case visualization in UML – an icon: Process Sale An actor visualization: Mira Balaban & Arnon Sturm 62

I. Understanding requirements – Use Cases A partial use case diagram for the POS application: Mira Balaban & Arnon Sturm 63

I. Understanding requirements – Use Cases Relating Multiple Use Cases – The embedded alternatives can be singled out as independent use cases. Mira Balaban & Arnon Sturm 64

I. Understanding requirements – Use Cases Relating Multiple Use Cases: Alternatives are turned into full use cases. The Buy Items use case “uses” the new use cases: • Pay by Cash. • Pay by Credit. • Pay by Check. In the use case document: 1. Insert an explicit reference in the alternatives section. 2. Add a section: Related Use Cases. Mira Balaban & Arnon Sturm 65

I. Understanding requirements – Use Cases Relationships between use cases: • • <<uses>> (also called <<includes>>) is a relationship that denotes references between use cases. <<extends>> is a relationship that denotes a “special case”: Pay by Check “extends” Limits Exceeded <<extends>> is used to emphasize similarity and diversion: • • Capture the normal use case. Describe variations. Mira Balaban & Arnon Sturm 66

I. Understanding requirements – Use Cases Use Case Modeling Tips • Make sure that each use case describes a significant chunk of system usage that is understandable by domain experts, customers, and programmers • When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams • Factor out common usages that are required by multiple use cases – If the usage is required use <<include>> – If the base use case is complete and the usage may be optional, consider use <<extend>> • A use case diagram should – contain only use cases at the same level of abstraction – include only actors who are required • Complexity management Mira Balaban & Arnon Sturm 67