UNIT 5 Object Oriented Analysis and Design with
UNIT 5 Object Oriented Analysis and Design with UML 1
Summary Unit 4. . . Patterns for Object Orientation 4 Based on Patterns from Christopher Alexander Ä Patterns for buildings 4 Smart, generic, well-proven, simple, reusable Solutions 4 Pattern Elements Ä Pattern name Ä Problem description Ä Solution description Ä Consequences, collaborations 2
Summary Unit 4. . . 4 Types of Patterns Ä Analysis Patterns Ä Design Patterns Ä Creational patterns Ä Structural patterns Ä Behavioural patterns Ä Antipatterns Ä Development antipatterns Ä Architectural antipatterns Ä Managerial antipatterns 3
Summary Unit 4. . . 4 Abstract Factory 4
Summary Unit 4. . . 4 Composite Pattern 5
Summary Unit 4. . . 4 Proxy Pattern 6
Summary Unit 4. . . 4 Observer Pattern 7
Summary Unit 4. . . 4 Root Causes – Sloth, Haste The Blob 4 General Form – Designs where one class monopolizes the processing, and other classes primarily encapsulate data – Key problem is : majority of responsibilities are allocated to a single class – In general it is a procedural design • conflicts with OO paradigm 8
Summary Unit 4. . . 4 Root Causes Vendor Lock-in – Sloth, Apathy, Pride/Ignorance 4 General Form – Commercial product upgrades drive the application software maintenance cycle – Promised product features are delayed or never delivered – The product varies significantly from the advertised open systems standard – Repurchase is needed when upgrade is missed 9
Physical Architecture 10
Physical Architecture… 4 Until now : Logical Architecture – What functionality does the system deliver – Which classes exist, and how are those classes related to each other – How do the classes and their objects collaborate to deliver the functionality – What are the timing constraints on functions in the system – What would be a suitable plan for a number of developers to follow to develop this architecture 11
Physical Architecture… 4 Physical Architecture : – Goal : Provide a blue print of all the parts that together define the system • Their structure, interfaces, and the mechanisms they use to communicate • where are specific concepts, functions located 12
Physical Architecture. 4 Answers questions like : – In which programs or processes are classes and objects physically located? – On which computers do the programs and processes execute? – Which computers and other hardware devices are in the system, and how are they connected to each other? – What are the dependencies between different code files? If a specific file is changed, which other files have to be recompiled? 13
Physical Architecture Views… 4 Two views for physical Architecture – Component View – Deployment View 4 Both views describe the decomposition of the software and hardware – A mapping to components, processes, and computers 14
Physical Architecture Views… 4 Component View – Shows the organization of the code components and their dependencies – Described by component diagrams – Used by developers 15
Physical Architecture Views. 4 Deployment View – Shows the deployment of the system into the physical architecture with computers and devices – Represented by the deployment diagram – Used by developers, testers, and integrators 16
Hardware Concepts 4 Processors – The computers that execute the programs in the system – Microprocessors, embedded systems, . . . 4 Devices – Support devices connected to a processor – Printers, routers, card readers, . . . 4 Connections – Communication mechanism between nodes 17
Software Concepts 4 Components – The physical implementation of logical model elements (e. g. classes) 4 Processes and threads – A process is a heavyweight flow of control, a thread represents a lightweight flow of control 4 Objects – Passive objects vs active objects 18
Component Symbols 19
Component Diagram… 4 Describes SW components and their dependencies to each other, representing the structure of the code 4 The components are typically implementation files 20
Component Diagram… 4 Kinds of SW Components : – Source component Compile Time • source code files implementing one or more classes – Binary component Link Time • object code that is the result of compiling a source code file (library file, object file, …) – Executable component Processor • executable program file that is the result of linking all the binary components. 21
Component Diagram… Dependency Component Located on Nodes 22
Component Diagram… 4 Stereotypes for Compile time components – <<file>> • a file containing source code – <<page>> • a web page – <<document>> • a documentation file 23
Component Diagram. 4 Stereotypes for Link time components – <<library>> • a dynamic link library (linked at run time) • a static library (linked at link time) 4 Stereotypes for Run time components – <<application>> • an executable program – <<table>> • a database table 24
Deployment Diagram… 4 Describes the run time architecture of processors, devices, and software components that execute in this architecture 4 Physical description of the system topology 25
Deployment Diagram Symbols 26
Deployment Diagram… 4 Elements of deployment diagrams : – Nodes – Connections – Components 27
Deployment Diagram… 4 Nodes – physical objects with computational resource – e. g. computers with processors, printer devices, card readers, … – Consider issues like capability and localization • primary memory, computation power, secondary storage, geographic distribution, … – Possible stereotypes : • <<Printer>>, <<Router>>, <<Controller>>, . . . 28
Deployment Diagram… 29
Deployment Diagram… 4 Connections – Connect nodes by communication associations – Normal associations (straight lines) – Stereotypes on the associations indicate the kind of communication protocol • e. g. <<TCP/IP>>, <<APPLETALK>>, . . . 30
Deployment Diagram… 31
Deployment Diagram… 4 Components – Inside a node : • indicates that they execute on this node instance – With a dependency to a node : • indicates that this node type supports this component type – Remember : • only run time components are shown 32
Deployment Diagram… 33
Deployment Diagram… 4 Aspects to consider when allocating components to nodes : – Resource usage • use the HW resources in an efficient manner – Geographical location • where is the functionality required, and what functionality must be available locally (performance) – Access to devices • every client a dedicated device, or a shared device 34
Deployment Diagram. . – Security • handling of access rights, protection of information, . . . – Performance • e. g. usage of proxies – Extensibility and portability • operating systems, machine architecture, . . . 35
A Process for using UML 36
Book The Unified Software Development Process Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley © 1999, ISBN 0201571692 37
UML… 4 The UML provides users with : – An expressive modelling language • For the specification, construction, visualization and documentation of the artefacts of a software system • For the construction of different kinds of models • For the exchange of models – Ready to use core concepts • However, extensibility and specialization mechanisms are available 38
UML… – A formal basis for understanding the modelling language • Metamodel in terms of a UML class diagram • “Semantics” is part of the official UML documentation – Support for higher level development concepts • Such as collaborations, patterns and components 39
UML. 4 It does not prescribe how the work should be done – A certain process is needed – A certain modelling tool is needed – Modelling guidelines are needed – A certain programming language is needed Ø Mainly results in Openness of the UML ! A process should make these needs concrete ! 40
A Process… 4 A process describes : – What to do – How to do it – When to do it – Why it should be done 4 A process results in : – A documentation about the system to be built – A product that solves the initial problems 41
A Process. 4 A process should focus on the following aspects : – Process context – Process user – Process steps – Process evaluation 42
Process Context… 4 Efficiency of IS is measured by the contribution of it to the business 4 Developers must interact with people from the business 4 To solve a problem, the problem solver must understand how the business works 4 Interpersonal relationships are formed between the people in the business and the problem solvers 43
A Process. 4 A process should focus on the following aspects : – Process context – Process user – Process steps – Process evaluation 44
Process User 4 How should a developer use and adopt the process: – guidelines 4 Guided by : – Perceptual process – Values and ethics – Motives and prejudices – Reasoning ability – Experiences, skills – Roles, . . . 45
A Process. 4 A process should focus on the following aspects : – Process context – Process user – Process steps – Process evaluation 46
Process Steps. 4 Problem formulation – Understanding the domain of concern – Completing the diagnosis (specification) – Defining the prognosis outline – Defining the problems 4 Solution design – Complete a conceptual or logical design – Draw a physical design 4 Implementation design 47
A Process. 4 A process should focus on the following aspects : – Process context – Process user – Process steps – Process evaluation 48
Process Evaluation 4 Describes how to evaluate the results 4 To check whether the real problems have been captured, and to identify new problems during the work 49
History of the Unified Process Rational Unified Process 5. 0 1998 Rational Objectory Process 4. 1 1996 -1997 Objectory Process 1. 0 -3. 8 1987 -1995 Ericsson Approach 50
Basic Properties of the Unified Process 4 Basic properties of the Unified Process : – Use case driven – architecture centric – iterative – incremental 51
Use Case Driven Systems 4 Use cases describe the systems functionality – Therefore they affect all phases and views Requirements ANALYSIS Use Cases DESIGN IMPLEMENTATION TEST 52
Architecture Centric 4 Consider a well defined basic system architecture 4 This architecture is reflected by the different views Logical View Component View Use Case View Deployment View Concurrency View 53
Iterative 4 Instead of trying to define all the details of a model at once, develop as a sequence of steps 4 Each iteration adds new information or detail 4 Each iteration product is evaluated before it is used as input for the next iteration – Results in continuous feedback 54
Incremental 4 Iterations can be seen as an increment of the system (kind of prototyping) 4 Each delivered increment is tested and evaluated : – Does the system provides the required functionality for this step? – Does the system satisfy non-functional requirements for this step? – Are we still on schedule, or on budget? – Where there new problems encountered? 55
Iterative and Incremental System Functionality No Waterfall ! Increment 3 Increment 2 Increment 1 ANALYSI DESIGN IMPLEME TEST S NT Time 56
Rational Unified Process 4 Basic ideas : – Based on models of systems to be built (views) – Process oriented (well defined reusable activities) – Iterative and Incremental – Risk driven (high risk in early phase) – Cyclical (each cycle results in a generation of the system) 57
Unified Process Life Cycle t o Pr c du n tio a er n Ge Product Life Cycle First Generation le c y P n io t a r Ite y Ac it tiv Third Generation Fourth Generation … Cycle C se a h Second Generation Inception Elaboration Construction Transition Iteration Iteration 7 6 5 4 3 2 1 Requireme Analysis Design nts Implementati on Testing 58 (Verification/validat ion)
Unified Process Phases Inception Elaboration Construction Transition time Define the scope and goal of the project Plan the project, specify features and baseline the architecture Iterative product development Delivery of the product to the end users 59
Inception phase 4 Requires a lot of work in the first cycle 4 Establishes all basic ideas about the product – functional and non functional properties 4 Results in a plan : – What to build – Whether it can be built – How it should be built 4 Decision whether or not to go ahead with the project 60
Elaboration Phase 4 A more detailed analysis of the system or generation to be built 4 Detailed specification of functionalities by different diagrams 4 Tool testing 4 Project planning : – – Schedules Resource allocation Estimates. . . 61
Construction Phase 4 Main activity is programming 4 Testing of the specifications 4 Documenting the system 62
Transition Phase 4 Deliver the product to the end users 4 Includes general issues like : – Marketing – Packaging – Installation – Configuration – Training – Support – Maintenance 63
Phases, Iterations, Activities se a h P n io t ra Ite y t it vi Ac Inception Elaboration Construction Transition Iteration Iteration 7 6 5 4 3 2 1 Requireme Analysis Design nts Implementati on Testing (Verification/validat ion) 4 Each activity results in artefacts – Implementation and Testing rely upon the documentation artefacts created during Requirements Specification, Analysis and Design 64
Phases, Iterations, Activities Inception Elaboration Construction Transition Requirements An iteration in the elaboration phase Analysis Design Implementation Test P re lim ina ry Ite ra tion (s) ite r. #1 ite r. #2 ite r. #n ite r. # n+ 1 ite r. # n+2 ite r. #m +1 65
Results of the Requirements Specification Phase… 4 Goal is the description of the required system functionality from the user’s point of view – Description of use cases – Conceptual model of the Universe of Discourse to which the application belongs – Defines how the system should communicate with its environment, represented by actors 4 Communication medium between users and developers 66
Results of the Requirements Specification Phase. * 1 Requirements Model Use Case Model 1 Problem Domain * 1 Description of Use Cases * <<UML>> Class Diagram * UI Specification Model Interface Model <<UML>> Use Case Diagram * Specification of System Interfaces 67
Results of the Analysis Phase… 4 Goal is a detailed analysis of the problem domain and use cases – Complementation of the model by means of additional objects – Definition/refinement of the object’s structure – Definition of the object’s behavior – Definition of the interaction between the objects 68
Results of the Analysis Phase… 4 Preservation of a certain level of abstraction enhances the potential reusability 4 Categorization of objects increases locality of changes and therefore leads to a more stable system architecture – Model classes – View classes – Control classes 69
Results of the Analysis Phase. 1 Structure Model * <<UML>> Class Diagram * <<UML>> Sequence Diagram * <<UML>> Collaboration Diagram Analysis Model 1 Behaviour Model * <<UML>> Statechart Diagram 70
Results of the Design Phase… 4 Previous focus : – WHAT is required from the system 4 New focus : – HOW should the system fulfil these requirements • Implementation dependent decisions are made, constituting the basis for refining the analysis model 71
Results of the Design Phase… 4 System design – Decomposition of the system into parts and distribution thereof • Concurrency and real-time aspects • Persistency mechanisms • … 4 Detailed design – Completing the class diagram by means of implementation dependent concerns • Completing the class properties (private, protected, public) • Decomposing structures which cannot be implemented as such • … 72
Results of the Design Phase. 1 1 Design Model Structure Model Behaviour Model * <<UML>> Component Diagram * <<UML>> Deployment Diagram * Architectural Description 73
Management Artefacts… 4 Not the product 4 Used to: – Drive/monitor the project’s progress – Estimate the risks – Adjust the resources – Give visibility to the customer or the investors. 74
Management Artefacts… 4 Organizational Policy document – A codification of the organization's process 4 Vision document – Describes the system level requirements, qualities, and priorities. 4 Business Case document – Describes the financial context, contract, projected return on investment, etc. 4 Development Plan document – Contains the iteration plan 75
Management Artefacts. 4 Evaluation Criteria document – Contains the requirements, acceptance criteria, and other specific technical objectives, – Contains the iteration goals and acceptance levels. 4 Release Description documents for each release. 4 Deployment document – Additional information useful for transition, training, installation, sales, manufacturing. 4 Status Assessment documents – Periodic snapshots of project status • metrics of progress, staffing, expenditure, results, critical risks, 76 actions items, post-mortem.
Technical Artefacts… 4 Either the delivered goods – Executable software and manuals 4 Or the blueprints used to manufacture – the delivered goods, software models, source code, and other engineering information useful to understand evolve the product. 77
Technical Artefacts. 4 User's Manual – developed early in the lifecycle. 4 Software documentation – Preferably self-documenting source code, supported by appropriate tools to maintain it and models 4 Software Architecture document – Describes the overall structure of the software, its decomposition in major elements: class categories, classes, processes, subsystems, the definition of critical interfaces, and rationale for the key design decisions. 78
What Next ? 79
Take a look at. . . 4 Books – UML distilled (Martin Fowler) 4 Teach yourself an OO language 4 Surf the Internet – The Rational website (http: //www. rational. com) • UML ‘inventors’ work there • Evolution of the Unified Process • All kinds of UML resources 80
Interesting Links… 4 UML Related – – – http: //www. sdmagazine. com/uml/home. shtml http: //www-4. ibm. com/software/ad/standards/ocl. html http: //www. objektteknik. se/umllinks. htm http: //www. uml-zone. com/ http: //www. essaim. univ-mulhouse. fr/ uml/outillage. html 81
Interesting Links. 4 OO Related – http: //www. omg. org/ – http: //www. Jcampus. org/ – http: //www. developer. com/ – http: //www. objectnews. com/ – http: //www. javasoft. com/ – http: //www. visualworks. com/ – http: //www. cincom. com – http: //www. squeak. org/ – http: //www. esug. org/ e b c. a. ub t t h p / / p: . v g ro 82
Questions ? ? 83
- Slides: 83