System Analysis and Design

Transcription

1 System Analysis and Design Svatopluk Štolfa Department of Computer Science VŠB-TU Ostrava 2007 Course Objectives After completing this course you will be able to: Perform all roles in the system development process. Apply presented techniques to create necessary models. Understand to the needs of iterative development of the system models and system itself. 1

2 Prerequisites Students should have an understanding of: Basics of software engineering Course - Introduction to the Software Engineering Overview of the software process Course - Software Process Introduction Requirements gathering Roles and responsibilities Requirements model Analysis Analysis model Design Design model Design patterns Implementation Implementation model Course Outline 2

3 PART I INTRODUCTION Iterative Software development 3

4 Core Engineering Workflows Business modeling describes the structure and dynamics of the organization Requirement describe the use case-based method for eliciting requirements Analysis and design describe the multiple architectural views Implementation takes into account sw development, unit test, and integration Test describes test cases and procedures Deployment covers the deliverable system configuration Disciplines Produce and Share Models Business Modeling Requirements Analysis & Design Implementation Test Use-Case Model Design Model Implementation Model Test Suite Use-Case Model Design Model Implementation Model Design Model 4

5 Unified Modeling Language 1/3 Diagram Description Learning Priority Activity Diagram Class Diagram Communication Diagram Component Diagram Composite Structure Diagram Depicts high-level business processes, including data flow, or to model the logic of complex logic within a system. Shows a collection of static model elements such as classes and types, their contents, and their relationships. Shows instances of classes, their interrelationships, and the message flow between them. Depicts the components that compose an application, system, or enterprise. Depicts the internal structure of a classifier (such as a class, component, or use case), including the interaction points of the classifier to other parts of the system. High High Low Medium Low Unified Modeling Language 2/3 Diagram Description Learning Priority Deployment Diagram Interaction Overview Diagram Object Diagram Package Diagram State machine Diagram Shows the execution architecture of systems. A variant of an activity diagram which overviews the control flow within a system or business process. Depicts objects and their relationships at a point in time, typically a special case of either a class diagram or a communication diagram. Shows how model elements are organized into packages as well as the dependencies between packages. Describes the states an object or interaction may be in, as well as the transitions between states. Medium Low Medium Low Medium 5

6 Unified Modeling Language 3/3 Diagram Description Learning Priority Sequence Diagram Timing Diagram Use Case Diagram Models the sequential logic, in effect the time ordering of messages between classifiers. Depicts the change in state or condition of a classifier instance or role over time. Shows use cases, actors, and their interrelationships. High Low High Software Lifecycle and UML Diagrams Activity diagrams Class diagrams Use Case diagrams Sequence diagrams Class diagams Sequence diagrams Collaboration diagrams Statechart diagrams Deployment diagrams Component diagrams Deployment diagrams 6

7 PART II REQUIREMENTS References Aybuke Aurum, Claes Wohlin (Eds.): Engineering and Managing Software Requirements, Springer-Verlag, 2005 IBM Corporation, Rational University: REQ480: Mastering Requirements Management with Use Cases, USA 2003 UML Superstructure, v. 2.1, Charles S. Wasson: System Analysis, Design and Development Concepts, Principles, and Practices, John Wiley & Sons, Inc. 7

8 What is a Requirement? IEEE standard: 1. A condition or capability needed by a user to solve a problem or achieve an objective 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents A document representation of condition or capability as is in 1. or 2. Requirements Classification 1/2 Functional requirements what system will do Non-functional requirements constraints on the types of solutions e.g. accuracy, performance, security, modifiability Goal level requirements related to the business goals Domain level requirements related to problem area Product level requirements related to the product Design level requirements what to build 8

9 Requirements Classification 2/2 Primary requirements elicited from stakeholders Derived requirements derived from primary requirements Other classifications Business requirements vs. technical requirements Product requirements vs. process requirements i.e. business needs versus how people will interact with the system Role based requirements e.g. customer requirements, user requirements, system requirements FURPS+ Model The acronym FURPS to describe the major categories of requirements with subcategories as shown below: Functionality Usability Reliability Performance Supportability The "+" in FURPS+ reminds you to include such requirements as: design constraints implementation requirements interface requirements physical requirements. 9

10 Functionality, Usability Functionality Functional requirements may include: feature sets capabilities security Usability Usability requirements may include such subcategories as: human factors aesthetics consistency in the user interface online and context-sensitive help wizards and agents user documentation training materials Reliability, Performance Reliability Reliability requirements to be considered are: frequency and severity of failure recoverability predictability accuracy mean time between failure (MTBF) Performance A performance requirement imposes conditions on functional requirements. For example, for a given action, it may specify performance parameters for: speed efficiency availability accuracy throughput response time recovery time resource usage 10

11 Supportability Supportability requirements may include: testability extensibility adaptability maintainability compatibility configurability serviceability installability localizability (internationalization) Design Requirement, Implementation Requirement Design Requirement A design requirement, often called a design constraint, specifies or constrains the design of a system. Implementation Requirement An implementation requirement specifies or constrains the coding or construction of a system. Examples are: required standards implementation languages policies for database integrity resource limits operation environments 11

12 Interface Requirement, Physical Requirement Interface Requirement An interface requirement specifies: an external item with which a system must interact constraints on formats, timings, or other factors used by such an interaction Physical Requirement A physical requirement specifies a physical characteristic that a system must possess; for example, material shape size weight This type of requirement can be used to represent hardware requirements, such as the physical network configurations required. Requirements Management A systematic approach to: Eliciting, organizing, and documenting requirements. Establishing and maintaining agreement between customer/user and the project team on the changing requirements. Requirement management requires strategy. Requirement management plan: Types of requirements to collect and where you will collect them. Types of attributes to track. Types of requirements to trace. Types of documents to produce. Management guidelines. The GOAL is to deliver quality products on time and on budget that meet the customer s real needs. 12

13 Requirements Management Essential Practices Requirement Elicitation, Specification, and modeling Understanding the needs of stakeholder, eliciting requirements, modeling and collecting them in the repository Prioritization Decide which requirements are important to customers Requirement Dependencies and Impact Analysis Requirements change => impact to the project, record decisions, Requirement Negotiation Conflict negotiation,... Quality Assurance Requirements Elicitation is concerned with learning and understanding the needs of users and project sponsors with the ultimate aim of communicating these needs to the system developers The requirements elicitation process involves a set of activities that must allow for communication, prioritization, negotiation, and collaboration with all the relevant stakeholders 13

14 The Requirements Elicitation Process Understanding the application domain Existing work processes, related problems, political, organizational, and social aspects related to the system Identifying the sources of requirements Existing documentation, business processes, Analyzing the stakeholders Customer, project sponsor, users, partners, customers Identification of key users and product champion Selecting the techniques, approaches, and tools to use Depends on the specific context of the project Eliciting the requirements from stakeholders and other sources Techniques and Approaches for RE Interviews Questionnaires Task analysis Domain analysis Introspection Repertory grids Card sorting Laddering Group work Brainstorming Joint application development Requirements workshops Ethnography Observation Protocol analysis Apprenticing Prototyping Goal based approaches Scenarios Viewpoints 14

15 Techniques and Approaches Detail 1 Interviews Interview is a essentially human based social activity Unstructured - is best applied for exploration of unknown domain Structured usage of a predefined sets of questions, gather a specific information Questionnaires Questions must be focused to avoid gathering large amounts of redundant and irrelevant information Efficient way to collect information quickly, limited in the depth of knowledge they are able to elicit More useful as informal checklist to ensure fundamental elements are addressed early on Techniques and Approaches Detail 2 Task Analysis Top-down approach, high level tasks are decomposed into subtasks Primary objective is to construct hierarchy of the tasks performed by the users and the system Domain analysis Examining of the existing and related documentation and applications Introspection Requires the analyst to develop requirements based on what stakeholders and users want and need from the system Useful when analyst is familiar with the domain and business processes performed by the user or analyst is forced to use this technique when users have no experience with software system in their work environment 15

16 Techniques and Approaches Detail 3 Repertory Grids Involve asking stakeholder to develop attributes and assign values to a set of domain entities. The aim is to identify and represent the similarities an differences between the different domain entities Card Sorting Requires the stakeholder to sort series of cards containing the names of domain entities into groups and explain the rationale for the way in which the cards are sorted All entities should be involved, problem domain must be sufficiently understood Laddering Stakeholders are asked a series of short prompting questions and required to arrange the answers into an organized structure Mainly used as a way to clarify requirements and categorize domain entities Techniques and Approaches Detail 4 Group work Collaborative meeting, involves a number of different stakeholders Stakeholder must feel comfortable and confident in speaking openly and honestly => less effective in highly political situations Brainstorming Generating as many ideas as possible Often used to develop the preliminary mission statement Joint Application Development General discussion about the problems to be solved and the available solutions to those problems JAD sessions are typically well structured with defined steps, the main goals of the system have already been established before 16

17 Techniques and Approaches Detail 5 Requirements workshops Number of different types of group meetings, emphasis is on developing and discovering requirements for a software system Ethnography Study of people in their natural setting, involves the analyst actively or passively participating Effective when the need for a new system is result of existing problems with processes and procedures Observation One of the most widely used ethnographic techniques Analyst observes the actual execution of existing processes Techniques and Approaches Detail 6 Protocol Analysis Participants perform an activity whilst talking it through aloud, describing the actions being conducted and the thought process behind them Apprenticing Involves analyst actually learning and performing the task under the instruction of an experienced user Efficient when the users have difficulty in explaining their actions Prototyping Providing stakeholders with prototypes of the system to support the investigation of possible solutions Helpful when developing new systems for entirely new applications 17

18 Interviews Domain Group work Ethnography Prototyping Goals Scenarios Viewpoints Techniques and Approaches Detail 7 Goal based approaches High level goals are decomposed and elaborated into sub goals and then further refined in such way that individual requirements are elicited Scenarios Descriptions of current and future processes including actions and interactions between the users and the system Viewpoints Viewpoint approaches aim to model domain from different perspectives Techniques and Approaches for Elicitation Activities Understanding the domain Identifying sources of requirements Analyzing the stakeholders Selecting techniques and approaches Eliciting the requirements X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X 18

19 Interviews Domain Group work Ethnography Prototyping Goals Scenarios Viewpoints Complementary and Alternative Techniques and Approaches Interviews C A A A C C C Domain C C A A A A A Group work A C A C C C C Ethnography A A A C C A A Prototyping A A C C C C C Goals C A C C C C C Scenarios C A C A C C A Viewpoints C A C A C C A Requirements Specification and Modeling Specification Language Complexity Appropriate level of abstraction must be used Hierarchy grouping system parts together, Orthogonality independent behaviors Representation scheme graphical or textual representation Model Continuity Non-Functional Requirements User Requirements Modeling System Requirement Modeling 19

20 Requirement Prioritization Most software projects have more candidate requirements than can be realized within the time and cost constraints Prioritization helps to identify the most valuable requirements from the set of requirements by distinguishing the critical few from the trivial many Prioritization Provides Support for: For stakeholders to decide on the core requirements for the system To plan optimal set of requirements for the successive releases To trade off desired project scope against sometimes conflicting constraints (time, budget, To balance the business benefit of each requirement against its cost To balance implications of requirements on the software architecture To select only a subset of the requirements and still produce a system that will satisfy the customers To estimate expected customer satisfaction To get a technical advantage and optimize market opportunity To minimize rework and schedule slippage (plan stability) To handle contradictory requirements, focus the negotiation process, and resolve disagreements between stakeholders To establish relative importance of each requirement to provide the greatest value at the lowest cost 20

21 Aspects of Prioritization Importance Prioritization of the most important requirements from several reasons like business importance, urgency of implementation, Penalty Penalty when the requirement is not fulfilled Cost Complexity, ability to reuse code, Time Risk Development risks, performance risks, Volatility Market change, business requirement change, legislative change, Requirement Interdependencies - Traceability Problem Problem Space Needs Features Solution Space Software Requirements The Product To Be Built Test Procedures Design User Docs 21

22 Requirements Traceability RT is achieved through associating related information objects such as: Requirements and related system components satisfying those requirements System objectives and requirements derived from those requirements Change proposals and requirements which they intend to ensure Test cases and the requirements which fulfillment they intend to ensure System components and the resources needed to implement those requirements Interdependency Types 1/2 Structural Interdependencies Refined to higher-level requirement is refined by a number of more specific requirements Changes to one requirement changes to another requirement if a new version of that requirement is developed Similar to one stated requirement is similar to or overlapping with one or more other requirement 22

23 Interdependency Types 2/2 Constraining Interdependencies Requires the fulfillment of one requirement depends on the fulfillment of another requirement Conflicts with a requirement is in conflict with another requirement if they cannot exist at the same time Cost/Value Interdependencies Increases/Decreases cost of if one requirement is chosen for implementation, then the cost of implementing another requirement increases or decreases Increases/Decreases value of if one requirement is chosen for implementation, then the value to the customer of another requirement increases or decreases How Requirements Interdependencies Facilitate Requirements Management Knowledge about decomposition Change Management and Impact Analysis How requirement has changed over time, influence, Release Planning Selection of requirements on the basis of dependency Reuse of Components Traceability Reuse of Requirements Dependency Design and Implementation Conflicting or inconsistent requirements Testing Order of functionality tests 23

24 Impact Analysis Impact analysis is the activity of identifying what needs to be modified in order to make a change, or determine the consequences on the system if the change is implemented. Software life-cycle objects (SLO) requirement, architectural component, class, Change management process Uncontrolled change vs. Top-down change (from requirements) Quality Quality: Old Concepts Satisfies requirements documents. Passed system test. Development adhered to process. Activity-based Quality: Modern Concept Understand all stakeholder needs. Continually assess all artifacts to see if needs are met. Results-based 24

25 Market-Driven vs. Bespoke Development Bespoke Development Market-driven Development Mani stakeholder Customer organization Developing organization Users Known or identifiable Unknown, may not exist Distance to users Usually small Usually large Requirements conception Lifecycle Specific RE issues Elicited, analyzed, validated One release, then maintenance Elicitation, modeling, validation, conflict resolution Invented (by market pull or technology push) Several releases as long as there is a market demand Steady stream of requirements, prioritization cost estimation, release planning Primary goal Compliance to specification Time-to-market Measure of success Satisfaction, acceptance Sales, market share RUP: Disciplines Workflows Business Modeling Workflow Requirements Workflow 25

26 Requirements Workflow Roles and Artifacts 26

27 Artifacts Description 1/3 Artifact Use-Case Model (Actor,Use Case,Use-Case Package Storyboard Glossary Purpose Use cases are used to define functional requirements. Projects with behavioral requirements that are not really understood should consider Storyboarding as a means to elicit requirements. Ensures that everyone on the project is using a common vocabulary. Tailoring (Optional, Recommended) Recommended for most projects. Use cases are the recommended method for capturing functional requirements. Optional Other requirements elicitation techniques may be used. Recommended for most projects. Artifacts Description 2/3 Artifact Requirements Attributes Requirements Management Plan Software Requirements Specification Purpose A database of requirements attributes helps ensure that requirements are properly prioritized, tracked, and traced. Describes the information to be collected and control mechanisms to be used for measuring, reporting, and controlling changes to the product requirements. Used to collect the set of all requirements in a formal document provided to the customer. Tailoring (Optional, Recommended) Optional - However, on projects with relatively few requirements, a database of requirements attributes may not be strictly necessary. Optional - Projects with relatively few requirements may take a lightweight approach to requirements management which can be documented directly in the Software Development Plan. Optional - On less formal projects, a formal document may not be required. 27

28 Artifacts Description 3/3 Artifact Stakeholder Requests Supplementary Specifications Vision Purpose Captures all requests made on the project, as well as how these requests have been addressed. Used to capture non-functional requirements. Captures very high-level requirements and design constraints, to give the reader an understanding of the system to be developed. Tailoring (Optional, Recommended) Recommended for most projects. In order to build a system that meets the needs of the stakeholders, it is important to solicit and review their requests. Recommended for most projects. Recommended for most projects. Requirements Workflow 28

29 Analyze a Problem Identify stakeholders Describe stakeholders in vision document Understand the problem domain What is the problem behind problem? Business models Identify problem Describe problem in vision document Identify the constraints and business solution Define terms Glossary document Workflow Detail The purpose of this workflow detail is to gain agreement on the problem being solved. Analysis of the problem involves identify the stakeholders, define the boundary of, and identify the constraints imposed on the system. 29

30 Analyze a Problem - Summary Summary Capture a common vocabulary Develop vision Find actors and use cases Develop requirements management plan Key Resulting Artifacts Glossary Vision Use case model Requirements management plan Requirements atributes Vision Document 1. Introduction 2. Positioning 3. Stakeholder and User Descriptions 4. Product Overview 5. Product Features 6. Constraints 7. Quality Ranges 8. Precedence and Priority 9. Other Product Requirements 10. Documentation Requirements 11. Appendix 1 - Feature Attributes 30

31 Requirements Workflow Understand Stakeholder Stakeholder request artifact Consist of many materials Customer requirement specification, s, notes, Identify requirements Recognize and label: Application behaviors Behavioral attributes Issues and assumptions Assure that stakeholder and analyst share the same vision of problem and solution 31

32 Workflow Detail The purpose of this workflow detail is to understand the needs of the primary project stakeholders by gathering information about the desired or envisaged product. Understand Stakeholder - Summary Summary Capture a common vocabulary Define vision Elicit stakeholder requests Find actors and use cases Manage dependencies Review change request Key resulting artifacts Glossary Vision Stakeholder requests Use case model Supplementary specifications Requirements attributes 32

33 Requirements Workflow Define System Capture the software requirements Input vision, stakeholder requirements, business model Output use case model, supplementary specification Identify actors and use cases. Brief Description. Outline each use case. Basic Flow of Events. Alternative Flows of Events. Detail each use case. Detail the flows of events. Structure each use case flow of events. Add detail. Pre- and post-conditions, special requirements, relationships, use-case diagrams, and so on. 33

34 Workflow Detail The purpose of this workflow detail is to begin converging on the scope of the high-level requirements by outlining the breadth of the detailed requirements for the system. Define System - Summary Summary Develop vision Capture a common vocabulary Find actors and use cases Manage dependencies Key Resulting Artifacts Glossary Use case model Supplementary specification Requirements attributes Detailed use cases 34

35 Requirements Workflow Manage Scope What can be delivered in a fixed timeframe Budged, resources, time Prioritize requirements Establish requirements baseline The set of features that can only be changed through a formal procedure. Under-promise and over-deliver Not too much you want to maintain credibility Manage expectations 35

36 Workflow Detail The purpose of this workflow detail is to make the scope of the system being developed as explicit as possible, and focus on a manageable body of requirements work for the iteration. Manage Scope - Summary Summary Develop vision Manage dependencies Prioritize use cases Key Resulting Artifacts Vision Requirements attributes 36

37 Requirements Workflow Refine the System Definition Detail each use case Create a specification that can be implemented Clarify important details in flow events Describe additional information Preconditions and postconditions Use case diagrams Relationships, extensions, Non-functional requirements Usability training, online help, GUI, Reliability availability, accuracy, Performance speed and efficiency Supportability ability to be easily modified 37

38 Workflow Detail The purpose of this workflow detail is to further refine the requirements in order to capture the consensus understanding of the system definition. Refine the System Definition - Summary Summary Detail a use case Detail the software requirements Model the user interface Prototype the user interface Key Resulting Attributes Supplementary specification Use case Software requirements specification Use case storyboard Requirements attributes 38

39 Requirements Workflow Traceability Manage Change Trace requirements from the top to the bottom of your model/document hierarchy. Impact analysis Metrics How many use cases do we have? What critical features haven t been approved? What is the estimated cost of the proposed changes? How many changes since the last review? 39

40 Workflow Detail The purpose of this workflow detail is to further refine the requirements in order to capture the consensus understanding of the system definition. Manage Change - Summary Summary Manage dependencies Review change request Review requirements Structure the use case model Review record Key Resulting Artifacts Use case model Requirements attributes 40

41 Use Case Modeling Actor e-shop Order Processing Customer Salesman Product delivery System Border Use Case Dispatch worker Use Case Model Use case model is mostly text Each use case symbol in the diagram is described by the use case specification Use case lifecycle Discovery Brief description Outline Full description 41

42 Creating a Use Case Model Find actors and use cases Identify and briefly describe actors Who is interacting with the system? Identify and briefly describe use cases What is a goal of each actor? Write Use Cases Use cases are NOT pure functional decompositions Use cases describe goals complete uses of the system Structure Use Case Model Extend is a relationship from an extension use case to a base use case, specifying how the behavior defined for the extension use case extends the behavior defined for the base use case. The base use case does not depend on performing the behavior of the extension use case. Include is a relationship from a base use case to an inclusion use case, specifying how the behavior for the base use case contains the behavior of the inclusion use case. The base use case depends on performing the behavior of the inclusion use case. Generalization is a relationship between a more general use case and its more specific version Actor generalization is a relationship between a general actor that represents the common characteristics and more specific actors 42

43 Use Case Relationship Example Customer data entry «include» Payment checking «include» Include relationship Salesman Generalization Order processing «extends» Catalog offering Extend relationship Express order processing Relationship between Actors Login into system Employee Generalization Customer data entry Salesman 43

44 Textual Representation of Use Case Use Case Element Use Case Number Application Use Case Name Use Case Description Primary Actor Precondition Trigger Basic Flow Alternate Flows Description ID to represent your use case What system or application does this pertain to The name of your use case, keep it short and sweet Elaborate more on the name, in paragraph form. Who is the main actor that this use case represents What preconditions must be met before this use case can start What event triggers this use case The basic flow should be the events of the use case when everything is perfect; there are no errors, no exceptions. This is the "happy day scenario". The exceptions will be handled in the "Alternate Flows" section. The most significant alternatives and exceptions PART II ANALYSIS & DESIGN 44

45 References - upravit Aybuke Aurum, Claes Wohlin (Eds.): Engineering and Managing Software Requirements, Springer-Verlag, 2005 IBM Corporation, Rational University: REQ480: Mastering Requirements Management with Use Cases, USA 2003 UML Superstructure, v. 2.1, Charles S. Wasson: System Analysis, Design and Development Concepts, Principles, and Practices, John Wiley & Sons, Inc. Purpose The purposes of Analysis & Design are: To transform the requirements into a design of the system-to-be. To evolve a robust architecture for the system. To adapt the design to match the implementation environment, designing it for performance. 45

46 Relation to Other Disciplines The Analysis & Design discipline is related to other disciplines, as follows: The Business Modeling discipline provides a organizational context for the system. The Requirements discipline provides the primary input for Analysis and Design. The Implementation discipline implements the design. The Test discipline tests system designed during Analysis and Design. The Environment discipline develops and maintains the supporting artifacts that are used during Analysis and Design. The Project Management discipline plans the project, and each iteration (described in an Iteration Plan). Analysis and Design Overview Analysis and Design 46

47 Analysis Versus Design Analysis Focus on understanding the problem Idealized design Behavior System structure Functional requirements A small model Design Focus on understanding the solution Operations and attributes Performance Close to real code Object lifecycles Nonfunctional requirements A large model Analysis and Design Are Not Top-Down or Bottom-Up 47

48 Software Architecture Software architecture encompasses a set of significant decisions about the organization of a software system. Selection of the structural elements and their interfaces by which a system is composed Behavior as specified in collaborations among those elements Composition of these structural and behavioral elements into larger subsystems Architectural style that guides this organization Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational (derived from Mary Shaw) IEEE Architectural Description Mission fulfills 1..* Enviroment inhibits influences System has an Architecture is important to 1..* is addressed to 1..* has 1..* Stakeholder identifies 1..* described by 1 participates in Architecture Description provides Rationale has 1..* Concern identifies 1..* used to cover 1..* has a source 0..1 Viewpoint Library Viewpoint selects 1..* conforms to View organized by 1..* participates in 1..* establish methods for 1..* Model aggregates 1..* 48

49 Definitions of Key Terms Term Architectural Description View Viewpoint Concerns Description A collection of products to document an architecture. An AD selects one or more viewpoints for use. The selection of viewpoints typically will be based on consideration of the stakeholders to whom the AD is addressed and their concerns. A representation of a whole system from the perspective of a related set of concerns. A view may consist of one or more architectural models. Each such architectural model is developed using the methods established by its associated architectural viewpoint. An architectural model may participate in more than one view. A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis. Those interests which pertain to the system s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, security, distribution, and evolvability. Architecture Constrains Design and Implementation Architecture involves a set of strategic design decisions, rules or patterns that constrain design and construction. Architecture decisions are the most fundamental decisions, and changing them will have significant effects. Code Implementation Design Architecture 49

50 Fault Tolerant Architecture System architecture must be ROBUST to tolerate and cope with various types of internal and external vulnerabilities When confronted with these conditions, the processing must be able to continue without significant performance degradation or catastrophic failure. Depending on system design objectives, there are numerous ways of developing fault-tolerant architectures. FMEA/FMECA (failure modes and effect analysis / failure modes effects, and criticality analysis) the purpose is to understand HOW system and its components might fail because of misapplication, misuse, or abuse by users, poor design, or a single point of failure. Architecture Representation The representation of architecture should allow various stakeholders to communicate and discuss the architecture. The various stakeholders have different concerns and are interested in different aspects of architecture. Architectural view simplified description (an abstraction) of a system from particular perspectives (e.g.): Logical organization of the system Functionality of the system Concurrency aspects Physical distribution of the software on the underlying platform 4+1 view 50

51 4+1 View Model of Architecture Logical View View design classes and their organization Analysts/Designers into packages and subsystems, and the organization of these Structure packages and subsystems into Use-Case View layers. It contains also some use case realizations. It is a subset of the design model. Process View contains the description of the tasks (process and threads) involved, Performance their interactions and configurations, and the allocation of design objects Scalability and classes to tasks. This view need Throughput only be used if the system has System a significant integrators degree of concurrency. It is a subset of the design model. contains use cases and scenarios Use-Case that encompasses View architecturally significant behavior, classes, -or End technical user risks. functionality Security It is a View subset of the use-case model. Data View Implementation View contains an overview of the Programmers implementation model and its Software organization in management terms of modules into packages and layers. The allocation of packages and classes (from the Logical View) to the packages and modules of the Implementation View is also described. It is a subset of the implementation model. Deployment View contains the description of the various physical nodes for the most typical platform configurations, and the System engineering System topology Delivery, installation distributed. It is a subset of the communication User Interface allocation View of tasks (from the Process View) to the physical nodes. This view need only be used if the system is deployment model. Architectural Focus 1/2 Although the views above could represent the whole design of a system, the architecture concerns itself only with some specific aspects: The structure of the model - the organizational patterns, for example, layering. The essential elements - critical use cases, main classes, common mechanisms, and so on, as opposed to all the elements present in the model. A few key scenarios showing the main control flows throughout the system. The services, to capture modularity, optional features, product-line aspects. 51

52 Architectural Focus 2/2 Architectural views are abstractions of the entire design, in which important characteristics are made more visible by leaving details aside. These characteristics are important when reasoning about: System evolution-going to the next development cycle. Reuse of the architecture, or parts of it, in the context of a product line. Assessment of supplementary qualities, such as performance, availability, portability, and safety. Assignment of development work to teams or subcontractors. Decisions about including off-the-shelf components. Insertion in a wider system. Faults or Malfunctions can Cause System Failures Inadequate system architecture selection Lack of system stability during various operating environment conditions Internal component failures due to operating environment conditions Latent defects due to improper or inadequate testing Faulty control logic Unknown modes and states Preoccupation with trivial, molecular level computation processing Poor work practices Improper operation results from abuse, misuse, or misapplication of the system Physical breaks in resource or data communication interfaces or supplies Lack of preventive and corrective maintenance Physical intrusion such as hacking, spamming, malicious mischief, and sabotage by unauthorized users and threats 52

53 Architectural Blueprints The graphical depiction of an architectural view is called an architectural blueprint. For the various views described above, the blueprints are composed of the following diagrams from the Unified Modeling Language. Logical view. Class diagrams, state machines, and object diagrams Process view. Class diagrams and object diagrams (encompassing task-processes and threads) Implementation view. Component diagrams Deployment view. Deployment diagrams Use-case view. Use-case diagrams depicting use cases, actors, and ordinary design classes; sequence diagrams depicting design objects and their collaboration Analysis and Design Workflow Analysis Design 53

54 Roles and Artifacts Important Decisions Decide How to Perform the Workflow Decide How to Use Artifacts Decide Which Reports to Use Decide How to Review Decide Whether to Generate Code 54

55 Decide How to Perform the Workflow Decide which workflow details to perform and in which order. Decide what parts of the Analysis & Design workflow details to perform. User interface design, database design Decide when, during the project lifecycle, to introduce each part of the workflow. Document the decisions in the Development Case, under the headings Disciplines, Analysis & Design, Workflow. Decide How to Use Artifacts 1/2 Make a decision about what artifacts to use and how to use each of them. For each artifact, decide how the artifact should be used: Classification Must have Should have Could have Won't have Explanation You must use this artifact. It is a key artifact and may cause problems later in development if it's not produced. You should have this artifact, if at all possible, but it is negotiable. If you do not produce this artifact, you should be able to justify why not. Could have means that this artifact doesn't have to be produced. It's only produced if it adds value and if there's enough time. This means you won't use this artifact. This may occur where a Rational Unified Process artifact is replaced by a local artifact. 55

56 Decide How to Use Artifacts 2/2 Artifact Analysis Model Analysis Model Analysis Model Analysis Model Analysis Model How to use Incep Elab Const Trans Comment Won't Won't Won't Won't No Analysis Model is developed Could Could Could Could Normal Could Should Won't Won't Must Won't Won't Won't Should Must Must Must An evolutionary approach where the Analysis Model is replaced by the Design Model An evolutionary approach where the Analysis Model is mandatory during the Inception phase to help scope the project but is replaced by the Design Model during Elaboration A formal process where the Analysis Model is a mandatory, preserved artifact that is optional in the inception phase Artifacts 1/6 Artifact Analysis model (Analysis class) Navigation Map, User-Interface Prototype Purpose An analysis model is useful to better understand the requirements before making design decisions. On complex systems it may be maintained to provide a conceptual overview of the system. Projects with a large and complex user-interface should consider user-interface design. Tailoring (Optional, Recommended) Optional On many projects, an initial Design Model is used in place of the Analysis Model. On projects which do create an Analysis Model, it is typically a temporary artifact which evolves into a design model. Optional More informal user-interface design may be sufficient on smaller development efforts. 56

57 Artifacts 2/6 Artifact Purpose Tailoring Design model Design class; Design package Most systems, even smaller systems, should be designed before being implemented in order to avoid costly rework due to design errors. Visual models allow the design to be easily communicated. Tools for forward engineering and reverse engineering can ensure consistency with the implementation model and save effort. Classes and packages are a basic part of any object-oriented design. Object-oriented design is the standard design approach used on most projects. Recommended for most projects. On smaller projects, the use of automated tools is not critical, but may have long term productivity benefits. Recommended for most projects. The main tailoring issues are deciding which stereotypes to use (this may be captured in the Design Guidelines). Artifacts 3/6 Artifact Purpose Tailoring Use-case realization Interface Design subsystem Event Provide the bridge from use cases to design. Interfaces are typically used to define behavior independently from large-grained components that realize the behavior. Design Subsystems are used to encapsulate behavior inside a component that provides interfaces. It is used to encapsulate the interactions of classes and/or other subsystems. May be useful for systems that respond to many external events. Recommended for most projects. Recommended for most projects. Component-based design is becoming a standard design approach. Recommended for most projects. Subsystems are often useful to raise the level of design abstraction. They make systems easier to be understood. Recommended for real-time systems. 57

58 Artifacts 4/6 Artifact Purpose Tailoring Protocol Signal Capsule Data model Required for real-time systems. May be useful for systems that require concurrency and are event-driven. Required for realtime systems. For real-time systems, but can be useful in modeling and designing any system that has a high degree of concurrency. Used to describe the logical and possibly physical structure of the persistent information. Recommended for real-time systems. Recommended for real-time systems.. May be useful for systems that require concurrency and are event-driven. Recommended for real-time systems. Recommended for projects that use a database. Artifacts 5/6 Artifact Purpose Tailoring Deployment Model Architectural Proofof-Concept Shows the configuration of processing nodes at run-time, the communication links between them, and the component instances and objects that reside on them. Used to determine whether there exists a solution that satisfies the architecturallysignificant requirements. Optional. Many systems have multiple processing nodes and therefore need to address the Deployment Model. Recommended for most projects. Many projects will use an Architectural Proof-of-Concept to determine the feasibility of requirements. It may take many forms, for example: a list of known technologies which seem appropriate to the solution a sketch of a conceptual model of a solution a simulation of a solution an executable prototype. 58

59 Artifacts 6/6 Artifact Purpose Tailoring Reference Architecture Software Architecture Document (SAD) User-Interface Prototype Reference Architectures speed up development and reduce risks by re-using proven solutions. The Software Architecture Document is used to provide a comprehensive architectural overview of the system. This overview is helpful to understand the system, and to capture key architectural decisions. Used to expose and test functionality and usability before the real development starts. It is an effective means of validating the design before too much time is wasted. Recommended for most projects. If suitable Reference Architecture material exists, it can dramatically speed up development and reduce risk. Recommended for most projects. A high level overview of the software architecture is useful on all but the smallest systems. Complex systems typically require a greater level of detail and more views than smaller projects. Recommended for most projects. Decide How to Review Decide on the review level for each artifact The advantages of a design review are: It detects problems that are impossible, or very difficult, to detect in testing. For example, issues of style, and layout. It is a way to enforce a common modeling style and an opportunity for individuals to learn from each other. It detects those defects that wouldn't otherwise get detected until later in the project during tests. 59

60 Other Decisions Decide Which Reports to Use The decision of which reports to use will depend on the reporting tools available to the project. Decide Whether to Generate Code The way you do design differs depending on whether you generate code from the design model or not. If you generate code, the design needs to be very detailed. Analysis & Design ANALYSIS 60

61 Analysis and Design Workflow Perform Architectural Synthesis This workflow detail is about showing that there exists, or is likely to exist, a solution which will satisfy the architecturally significant requirements, thus showing that the system, as envisioned, is feasible. 61

62 Workflow Detail The purpose of this workflow detail is to construct and assess an Architectural Proof-of- Concept to demonstrate that the system, as envisioned, is feasible. Perform Architectural Synthesis - Summary Summary Perform architectural analysis Construct architectural proof of concept Asses viability of architectural proof of concept Key Resulting Artifacts Architectural design overview Design model overview Software architecture document updated Deployment model overview Architectural proof of concept Review record 62

63 Analysis and Design Workflow Define a Candidate Architecture Purpose: To define a candidate architecture for the system based on experience gained from similar systems or in similar problem domains. To define the architectural patterns, key mechanisms, and modeling conventions for the system. To define the reuse strategy. To provide input to the planning process. 63

64 Patterns and Mechanisms An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them Buschman et al, Pattern- Oriented Software Architecture A System of Patterns Layers Model-view-controller (MVC) An architectural mechanism is a strategic decision regarding common standards An architectural mechanism represents a common solution to a frequently encountered problem. It may be patterns of structure, patterns of behavior, or both. Architectural Mechanism Categories Analysis mechanisms capture the key aspects of a solution in a way that is implementation-independent. Design mechanisms are more concrete. They assume some details of the implementation environment, but are not tied to a specific implementation Implementation mechanisms specify the exact implementation of the mechanism. Implementation mechanisms are bound to a certain technology, implementation language, vendor, or other factor. Sample Analysis Mechanisms Persistency Communication (IPC and RPC) Transaction management Information exchange, format conversion Security Error detection / handling / reporting 64

65 Workflow Detail The purpose of this workflow detail is to create an initial sketch of the software architecture. Define a Candidate Architecture - Summary Summary Key Concepts Define the High-Level Organization of Subsystems Identify Analysis mechanisms Identify Key Abstractions Create Use-Case Realizations Checkpoints Key Resulting Artifacts Software Architecture Document Design Model Deployment Model 65

66 Analysis and Design Workflow Analyze Behavior identifying analysis classes that satisfy the required behavior determining how these analysis classes fit into the logical architecture (the major subsystems and classes) of the system. The analysis classes may be determined to belong to existing subsystems, require the creation of new subsystems, or cause existing subsystems and their interfaces to be redefined. 66

67 Workflow Detail The purpose of this Workflow Detail is to transform the behavioral descriptions provided by the requirements into a set of elements upon which the design can be based. Perform Architectural Synthesis - Summary Summary Use case analysis Identify design elements Review the design Design the user interface Prototype the user intteface Key Resulting Artifacts Analysis model Analysis classes Use case realizations Design model Interface Review record User-interface prototype 67

68 Analysis & Design GOOD PRACTICES - ANALYSIS Conceptual Modeling Models are not right or wrong; they are more or less useful. The choice of model affects the flexibility and reusability of the resulting system. Don't add flexibility you are unlikely to use, but think about future possibilities The simplest model is not necessarily the first one you think of. Conceptual models are linked to interfaces (types) not implementations(classes). 68

69 Analysis Patterns A pattern is an idea that has been useful in one practical context and will probably be useful in others. Martin Fowler Patterns are those things that developers think may be useful in other contexts Patterns are a starting point, not a destination. Patterns and Frameworks What is the principal benefit of object technology? reuse?, Reuse means assembling system from tried and tested components. There are no common components in many domain areas. To accomplish this, common framework must be established A software framework is a reusable design for software system An effective framework must not be too complex or too bulky Pattern is a named nugget of instructive information that captures the essential structure and insight of a successful family of proven solutions to a recurring problem that arises within a certain context and system of forces 69

70 Class Model Notation 1/2 Class Model Notation 2/2 70

71 Party Example: A telephone utility s customers may be individuals or businesses. Many aspects of dealing with customers are the same, in which case they are treated as parties. Where they differ they are treated through their subtype. Organization Hierarchy Represents the hierarchy of organizational units within a business You don t need to limit yourself to a single hierarchic association. 71

72 Accountability Represents a complex graph of relationships between parties Each instance of accountability represents a link between two parties, the accountability type indicates the nature of the link. Knowledge Level A group of objects that describe how another group of objects should behave (also known as a meta level) 72

73 Object Graph A group of objects connected together in a graph structure. Object graphs are a common way of representing situations where many objects of the same fundamental type can be connected in a recursive structure. You see them in organizational structures, work breakdown structures, product structures... Object Graph - Variation A group of objects connected together in a graph structure. 73

74 Accountability and Knowledge Level Combination Quantity Represent dimensioned values with both their amount and their unit The basic idea of Quantity is a class that combines the amount with the unit. Arithmetic and comparison operations 74