Software Design and Implementation. Example Architecture KIWC

Transcription

1 Software Design and Implementation Example Architecture KIWC

2 Previously on SDI What is design? What is traceability? What is architecture? Why architectures are important? Architectural styles

3 KWIC The KWIC index system accepts an ordered set of lines, each line is an ordered set of words, and each word is an ordered set of characters. Any line may be circularly shifted by repeatedly removing the first word and appending it at the end of the line. The KWIC index system outputs a listing of all circular shifts of all lines in alphabetical order.

4 KWIC: Sample input/output HOW ARCHITECTURE WINS TECHNOLOGY WARS THE ART OF SYSTEMS ARCHITECTING Input HOW ARCHITECTURE WINS TECHNOLOGY WARS ARCHITECTURE WINS TECHNOLOGY WARS HOW WINS TECHNOLOGY WARS HOW ARCHITECTURE TECHNOLOGY WARS HOW ARCHITECTURE WINS WARS HOW ARCHITECTURE WINS TECHNOLOGY THE ART OF SYSTEMS ARCHITECTING ART OF SYSTEMS ARCHITECTING THE OF SYSTEMS ARCHITECTING THE ART SYSTEMS ARCHITECTING THE ART OF ARCHITECTING THE ART OF SYSTEMS ARCHITECTING THE ART OF SYSTEMS ARCHITECTURE WINS TECHNOLOGY WARS HOW ART OF SYSTEMS ARCHITECTING THE HOW ARCHITECTURE WINS TECHNOLOGY WARS OF SYSTEMS ARCHITECTING THE ART SYSTEMS ARCHITECTING THE ART OF TECHNOLOGY WARS HOW ARCHITECTURE WINS THE ART OF SYSTEMS ARCHITECTING WARS HOW ARCHITECTURE WINS TECHNOLOGY WINS TECHNOLOGY WARS HOW ARCHITECTURE Output

5 KWIC Requirements Functional requirements Non functional requirements Modifiability changes in processing algorithm changes in data representation Extendibility Enhancement of functionality Additional functionality Performance Space Time Reusability

6 How to solve problem? (Potentially huge) design space Many solutions of the problem How to select good solution?

7 KWIC Architecture Alternative 1: Shared data solution Master control Input Circular Shift Alphabetizer Output Characters Index Alphabetized Index Input medium Output medium

8 KWIC Architecture Alternative 1 Modifiability - algorithm Line shifting As it reads line All at one time On demand (lazy) when alphabetization is needed Modifiability data Storing words and lines Compressed Uncompressed 1d/2d array, linked list Extendibility Eliminate noise words (eg. a, the, and, ) Performance Reusability

9 Architecture Alternative 1 Recap. Style: Shared Data Components: Processes & Data Connectors: Direct Data (Memory) Access, Subprogram call Constrains: Data communication between the components trough shared storage Rationale: Some intuitive appeal, as distinct computational aspect are isolated in different modules Shared data still very present. Where? OO approach getting popular

10 KWIC Architecture Alternative 2: Abstract Data Type Master control Input Output setc(i,w,j,c) getc(i,w,j) Words(i) cssetup getc(i,w,j) words(i) alph Ith(i) Lines Input medium Circular Shifter Alphabetizer Output medium

11 KWIC Architecture Alternative 2 Modifiability - algorithm Line shifting As it reads line All at one time On demand (lazy) when alphabetization is needed Modifiability data Storing words and lines Compressed Uncompressed 1d/2d array, linked list Extendibility Eliminate noise words (eg. a, the, and, ) Performance Reusability

12 Architecture Alternative 2 Recap. Style: Abstract Data Type (ADT) Components: Objects & Data Connectors: Messages Constrains: Other components can access data only by invoking interface (information hiding) Rationale: If selected, usually because of non functional requirements

13 KWIC Architecture Alternative 3: Implicit invocation Master control Input Circular Shift Alphabetizer Output Insert I-th Control I-Lines CS-Lines A-Lines I-th Input medium Output medium

14 KWIC Architecture Alternative 3 Modifiability - algorithm Line shifting As it reads line All at one time On demand (lazy) when alphabetization is needed Modifiability data Storing words and lines Compressed Uncompressed 1d/2d array, linked list Extendibility Eliminate noise words (eg. a, the, and, ) Performance Reusability

15 Architecture Alternative 3 Recap. Style: Implicit invocation Components: Processes & Data Connectors: Implicit invocation Constrains: Computations are invoked implicitly as data is modified, based on active data model Rationale: If selected, usually because of non functional requirements Can be difficult to control the order of processing

16 KWIC Architecture Alternative 4: Pipes and Filters Input Circular Shift Alphabetizer Output Input medium Output medium

17 KWIC Architecture Alternative 4 Modifiability - algorithm Line shifting As it reads line All at one time On demand (lazy) when alphabetization is needed Modifiability data Storing words and lines Compressed Uncompressed 1d/2d array, linked list Extendibility Eliminate noise words (eg. a, the, and, ) Performance Reusability

18 Architecture Alternative 4 Recap. Style: Pipes and Filters Components: Filters Connectors: Pipes Constrains: Data can be shared only trough pipes, no direct access Rationale: If selected, because of component reusability Possible performance lost

19 KWIC Architecture: Summary Shared Data ADT Implicit Invocation Pipes and Filters Modifiability Algorithm Data repr Extendibility Performance Space Time Reusability

20 Administration: Dates of examinations Possible dates 19 th January: Normal Examination 27 th January: Repetitive Examination

21 Software Design and Implementation (R)UP

22 Imagine the world Where there are no directions for making software Where most projects fail Where each project and every company has its own notation Where customer cannot read plans Where developers cannot read specifications Where software is not developed iteratively

23 What is process? A process defines Who is doing What, When and How to reach a certain Goal. In software engineering the goal is to build a software product or to enhance an existing one New or changed requirements Software Engineering Process New or changed system

24 Waterfall Development Requirements Analysis Design Code & Unit Testing Subsystem Testing System Testing T I M E

25 Waterfall Development: Risk vs. Time R I S K Requirements Analysis Design Code & Unit Testing Subsystem Testing System Testing T I M E

26 (Rational) Unified Process ((R)UP) Three in one Software development approach Well-defined and well-structured software engineering process Process product provided with customizable process framework

27 Rational Unified Process (RUP) Unifies best practices from many disciplines into a consistent full lifecycle process Premier process for the UML, developed by the company that brought you the UML Applicable to a wide variety of applications and industries Decreases Time To Market Increases Predictability

28 Rational Unified Process: Geneology Requisite Requirements Mgmt Objectory Use Cases OO Analysis Rational Abstraction Encapsulation Iterative Devel OO Architecture Visual Modeling UML RUP Verdix Cross-development Pure-Atria SQA Automated Testing Automated Branch/Merge Dynamic Views Replication Runtime Error Detection

29 RUP Increase of team productivity All team members share 1 knowledge base 1 process 1 view how to develop process 1 modeling language

30 UML Definition OMG-endorsed standard (Object Management Group) UML Semantics Document inside-view specifies semantics of constructs UML Notation Guide outside-view specifies notation for expressing constructs Object Constraint Language specification document definition of a (textual) language for expressing logical constraints

31 O Que é a UML? Unified Modeling Language é a linguagem para: Especificar Visualizar Construir Documentar os artefatos de software de um sistema

32 UML is For For Problems Specifying Visualizing Promoting Understanding Documenting For Problem Solving Capturing Attempts Communicating Attempts Leveraging Knowledge For Solutions Specifying Visualizing Evaluating Constructing Documenting

33 Some Parts of UML Class Diagrams models Object Diagrams example models Use Case Diagrams document who can do what in a system Sequence Diagrams shows interactions between objects used to implement a use case Collaboration Diagrams same as above, different style Statechart Diagrams possible states and responses of a class and what transitions them Activity Diagrams describe the behaviour of a class in response to internal processing Component Diagrams Organization of and dependencies amongst software implementation components Deployment Diagrams Describe the mapping of software implementation components onto processing nodes

34 This Course and UML You will use UML for the project UML Has its warts Good enough when augmented by written explanation Cover only the most useful subset of UML Mainly class/object/use case/sequence charts. UML is still evolving (still upcoming 2.0, some proposals for 3.0) -

35 RUP Overview Unified Process is component based system is built using software components interconnected using well defined interfaces Unified Process uses Unified Modeling Language (UML) Unified Process is distinguished by being use-case driven architecture-centric iterative and incremental Based around the 4Ps - People, Project, Product, Process

36 RUP Overview II Provides disciplined approach to assigning tasks and responsibilities Guide for how to use Unified Modeling Language (UML) effectively Activities create and maintain (UML) models Is a configurable process

37 Iterative and Incremental

38 Iterative Development Initial Planning Planning Requirements Management Environment Analysis & Design Implementation Deployment Evaluation Each iteration results in an executable release Test

39 Risk Profile of an Iterative Development Transition Transition Risk Risk Inception Inception Elaboration Elaboration Construction Construction Preliminary Preliminary Iteration Iteration Architect. Architect. Iteration Iteration Architect. Architect. Iteration Iteration Devel. Devel. Iteration Iteration Devel. Devel. Iteration Iteration Devel. Devel. Iteration Iteration Transition Transition Iteration Iteration Transition Transition Iteration Iteration Post- Postdeployment deployment Waterfall Waterfall Time Time Staffing Risk Risk

40 Iterative Development Characteristics Critical risks are resolved before making large investments Initial iterations enable early user feedback Testing and integration are continuous Objective milestones provide short-term focus Progress is measured by assessing implementations Partial implementations can be deployed

41 Iterative and Incremental Controlled iterative development is superior to the traditional waterfall approach for many reasons: Handle changing requirements Continuous integration Risk mitigation Allows for tactical changes Facilitates reuse Results in a more robust architecture Learning Process refinement

42 Iterative and Incremental Divides all work into smaller iterations Early iterations are prototypes They serve as trail blazers for both projects planning and technologies Early architectural prototypes define the core architecture The time-sequential order of iterations is critical and based on use case prioritizations and risks Results in incremental releases of the system Develop the software iteratively One or more iterations leads to a new increment of the system Iterations may be concurrent

43 Iterative Development Process Components Requirements Analysis Design Architecture Level Class Level Inception Phases Elaboration Construction Transition One iteration Implementation Test Supporting Components Project Management Process Configuration preliminary iteration(s) iter. #1 iter. #2 iter. #n iter. #n+1 iter. #n+2 iter. #m iter. #m+1 Iterations

44 Use Case Driven

45 Use Case Driven All process components, from requirements capture to test, are driven by use cases Analyze Capture, Clarify and Validate the Use Cases Design and Implementation Realize the Use Cases Test Verify that the Use Cases are fulfilled Use cases bind these work steps together

46 Use-Case-Driven Development The use cases defined for a system are the basis for the entire development process. The use cases drive the development: In requirements analysis the use cases are used to capture the requirements In design you identify classes from the usecases In implementation you implement the use cases In test you verify the use cases during test The use cases constitute test cases

47 Process Components and Models Requirements Analysis realized by Each process component is associated with a particular model. Design Implementation Use-Case Model Design Model implemented by verified by Test Implementation Model Test Model

48 Use-Case-Driven Development Use cases play several roles during the software-engineering process. They are used as a basis for iterative development They form a foundation for what is described in user manuals They may be used as ordering units For example, a customer can get a system configured with a particular mix of use cases

49 Organizing Work Assignments are on a per use case basis Analysis Design and Implementation Testing Domain Experts System Architects Senior Designers Programmers Senior System Integrators and Testers

50 Architecture-Centric

51 Architecture-Centric Focuses on finding the the architecture baseline up-front A systematic approach to defining a good architecture Derived from top rank use cases Balanced with component legacies: platform technology, frameworks, patterns, and Balanced with performance, trade-offs,... Designed to make the system more resilient to future changes Designed for and with substantial reuse Intuitively understandable

52 Architecture is Multi-Dimensional Logical View Component View Use Cases Collaboration View Deployment View

53 Architecture - How and When Process Components Requirements Analysis Design Architecture Level Class Level Inception Phases Elaboration Construction Transition Architecture iteration Implementation Test Supporting Components Project Management Process Configuration preliminary iteration(s) iter. #1 iter. #2 iter. #n iter. #n+1 iter. #n+2 iter. #m iter. #m+1 Iterations

54 Summing Up

55 Putting It All Together Process Components Requirements Analysis Design Architecture Level Class Level Inception Phases Elaboration Construction Transition Implementation Test Supporting Components Project Management Process Configuration preliminary iteration(s) iter. #1 iter. #2 iter. #n iter. #n+1 iter. #n+2 iter. #m iter. #m+1 Iterations

56 There is NO Universal (OO) Process! organization products people skills configurable process tools configurable and open application domain An Integrated set of Tools to Support Process & People

57 RUP Is a Process Framework A set of pluggable components

58 Two parts of a Harmonized Whole Unified Modeling Language Process Convergence Today Unification leads to standards Convergence in the future Process frameworks through consensus

59 Software Design and Implementation OOA

60 Evolution of Object-Oriented Development Methods Mid to late 1980s Object-Oriented Languages (esp. C++) were very much in vogue However, there was little guidance on how to divide a problem into OO classes. 1990: Object Modeling All at around the same time, many were borrowing an argument from structured design: The best organization for a software systems is one that is cohesive in the problem domain, not in the solution space Tends to isolate changes Tends to make the program easier to understand Developed methods for applying this concept to OO design. Rumbaugh, Coad, Wirfs-Brock, Booch, Jacobson

61 Object Modeling Method Step 1: OOA Analyze the problem domain Identify problem domain classes and relationships between classes Identify attributes and methods Identify states and transitions Sample object structures and interactions Not programming! Abstracting the real-world. Step 2: OOD Use the OOA as the core of a solution to: User interface design Database design OO program design

62 Uses for UML OOA A visual language for, in the problem domain, capturing knowledge about a subject expressing knowledge for the purposes of communication OOD A visual language for, in the solution space, capturing design ideas communicating design ideas Related, but distinct usages Must supplement both with written explanations

63 The World Out There The real world is impenetrably complex e.g., a complete model of you would include DNA, behavior specifications, total history, parents history, influences, for a particular problem, abstracting you as last name first name student ID course final grade may be enough. The Object-Oriented paradigm is one method for simplifying the world.

64 Objects [Rumbaugh] An object is A concept, abstraction, or thing with crisp boundaries and meaning for the problem at hand Objects promote understanding of the real world provide a practical basis for computer implementation Decomposition of a problem into objects depends on Judgment The nature of the problem being solved Not only the domain: two analyses of the same domain will turn out differently depending upon the kind of programs we wish to produce.

65 Classes A class describes a group of objects with similar properties. Class: Instructor Object: Mitja Lenič Object: Jorgel Cardoso Class: Department Object: Department of Computer Science Object: Departamento de Matemática e Engenharias Instructor Department

66 Attributes Data values held by the objects of a class Instructor -name :string -age :int -weight :int

67 Operations A function or a transformation that may be applied to or by objects in a class. Not often used (not often terribly useful) in an OOA Instructor -name :string -age :int -weight :int +teach ():void +grade ():void +listen_to_complaints ():void

68 Links and Associations The means for establishing relationships among objects and classes. link: a connection between two object instances association: a collection of links with common structure and semantics. Instructor Department

69 Object Diagrams Models instances of things contained in class diagrams. Shows a set of objects and their links at a point in time Useful preparatory to deciding on class structures. Useful in order to better explain more complex class diagrams by giving instance examples. DME : Department Mitja :Instructor Jorge :Instructor DCS :Department

70 Multiplicity Used to indicate the number of potential instances involved in the association when the other associated classes are fixed. Instructor * + has Department + teaches for * A given instructor can teach for potentially many departments (or none) A given department employs zero or more instructors

71 Multiplicities Carry Important Messages Used to indicate the number of potential instances involved in the association when the other associated class is fixed. Instructor 1..* + has Department + teaches for 0..2 A given instructor can teach for at most one department at a time, or may not be currently teaching for any department All departments have at least one instructor, but probably more

72 Attributes on Associations pay Instructor teaches for Department

73 Aggregation Indicators (Part-Of) Department Window Implied multiplicity of 1 Student Frame Glass Aggregation (no associated semantics) Composition (strong ownership, coincident lifetime)

74 Generalization (a.k.a. Inheritance, is-a) Shape Rectangle Circle Triangle Square

75 Avoiding Morphing Classes Analysis shown below may not be a good choice, as objects of class SDIInstructor may teach other things and different things next term. Avoid situations where objects will need to morph classes Instructor SDIInstructor

76 Next time on SDI OOA Example OOD