Week 5 Notes - Software Architecture and Design
Week 5 Notes - Software Architecture and Design ITIS 3310
Popular in Software Arch and Design
verified elite notetaker
Popular in ComputerScienence
verified elite notetaker
This 18 page Class Notes was uploaded by Jakeya Flood on Thursday September 24, 2015. The Class Notes belongs to ITIS 3310 at University of North Carolina - Charlotte taught by Lance Peterman in Summer 2015. Since its upload, it has received 39 views. For similar materials see Software Arch and Design in ComputerScienence at University of North Carolina - Charlotte.
Reviews for Week 5 Notes - Software Architecture and Design
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 09/24/15
Chapter 7 Principles 0 Principles that Guide Process 0 Principle 1 Be agile Whether the process model you choose is prescriptive or agile the basic tenets of agile development should govern your approach Principle 2 Focus on quality at every step The exit condition for every process activity action and task should focus on the quality of the work product that has been produced Principle 3 Be ready to adapt Process is not a religious experience and dogma has no place in it When necessary adapt your approach to constraints imposed by the problem the people and the project itself Principle 4 Build an effective team Software engineering process and practice are important but the bottom line is people Build a self organizing team that has mutual trust and respect Principle 5 Establish mechanisms for communication and coordination Projects fail because important information falls into the cracks andor stakeholders fail to coordinate their efforts to create a successful end product Principle 6 Manage change The approach may be either formal or informal but mechanisms must be established to manage the way changes are requested assessed approved and implemented Principle 7 Assess risk Lots of things can go wrong as software is being developed It s essential that you establish contingency plans Principle 8 Create work products that provide value for others Create only those work products that provide value for other process activities actions or tasks 0 Principles that Guide Practice 0 Principle 1 Divide and conquer Stated in a more technical manner analysis and design should always emphasize separation of concerns SOC Principle 2 Understand the use of abstraction At its core an abstraction is a simplification of some complex element of a system used to communication meaning in a single phrase Principle 3 Strive for consistency A familiar context makes software easier to use Principle 4 Focus on the transfer of information Pay special attention to the analysis design construction and testing of interfaces Principle 5 Build software that exhibits effective modularity Separation of concerns Principle 1 establishes a philosophy for software Modularity provides a mechanism for realizing the philosophy Principle 6 Look for patterns Brad suggests The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered throughout all of software development O O Principle 7 When possible represent the problem and its solution from a number of different perspectives Principle 8 Remember that someone will maintain the software 0 Communication Principles 0 O O Principle 1 Listen Try to focus on the speaker s words rather than formulating your response to those words Principle 2 Prepare before you communicate Spend the time to understand the problem before you meet with others Principle 3 Someone should facilitate the activity Every communication meeting should have a leader a facilitator To keep the conversation moving in a productive direction To mediate any con ict that does occur To ensure than other principles are followed 0 O Principle 4 F acetoface communication is best But it usually works better when some other representation of the relevant information is present Principle 5 Take notes and document decisions Someone participating in the communication should serve as a recorder and write down all important points and decisions Principle 6 Strive for collaboration Collaboration and consensus occur when the collective knowledge of members of the team is combined Principle 7 Stay focused modularize your discussion The more people involved in any communication the more likely that discussion will bounce from one topic to the next Principle 8 If something is unclear draw a picture Principle 9 a Once you agree to something move on b If you can t agree to something move on c If a feature or function is unclear and cannot be clarified at the moment move on Principle 10 Negotiation is not a contest or a game It works best when both parties win 0 Planning Principles 0 Principle 1 Understand the scope of the project It s impossible to use a roadmap if you don t know where you re going Scope provides the software team with a destination Principle 2 Involve the customer in the planning activity The customer defines priorities and establishes project constraints Principle 3 Recognize that planning is iterative A project plan is never engraved in stone As work begins it very likely that things will change Principle 4 Estimate based on what you know The intent of estimation is to provide an indication of effort cost and task duration based on the team s current understanding of the work to be done Principle 5 Consider risk as you define the plan If you have identified risks that have high impact and high probability contingency planning is necessary O O Principle 6 Be realistic People don t work 100 percent of every day Principle 7 Adjust granularity as you define the plan Granularity refers to the level of detail that is introduced as a project plan is developed Principle 8 Define how you intend to ensure quality The plan should identify how the software team intends to ensure quality Principle 9 Describe how you intend to accommodate change Even the best planning can be obviated by uncontrolled change Principle 10 Track the plan frequently and make adjustments as required Software projects fall behind schedule one day at a time 0 Modeling Principles 0 In software engineering work two classes of models can be created Requirements models also called analysis models represent the customer requirements by depicting the software in three different domains the information domain the functional domain and the behavioral domain Design models represent characteristics of the software that help practitioners to construct it effectively the architecture the user interface and component level detail 0 Agile Modeling Principles 0 O 0 00000 O Principle 1 The primary goal of the software team is to build software not create models Principle 2 Travel light don t create more models than you need Principle 3 Strive to produce the simplest model that will describe the problem or the software Principle 4 Build models in a way that makes them amenable to change Principle 5 Be able to state an explicit purpose for each model that is created Principle 6 Adapt the models you create to the system at hand Principle 7 Try to build useful models forget about building perfect models Principle 8 Don t become dogmatic about model syntaX Successful communication is key Principle 9 If your instincts tell you a paper model isn t right you may have a reason to be concerned Principle 10 Get feedback as soon as you can 0 Requirements Modeling Principles 0 O O Principle 1 The information domain of a problem must be represented and understood Principle 2 The functions that the software performs must be defined Principle 3 The behavior of the software as a consequence of external events must be represented Principle 4 The models that depict information function and behavior must be partitioned in a manner that uncovers detail in a layered or hierarchical fashion Principle 5 The analysis task should move from essential information toward implementation detail Design Modeling Principles 0 00000 O O Principle 1 Design should be traceable to the requirements model Principle 2 Always consider the architecture of the system to be built Principle 3 Design of data is as important as design of processing functions Principle 4 Interfaces both internal and external must be designed with care Principle 6 Component level design should be functionally independent Principle 7 Components should be loosely coupled to each other than the environment Principle 8 Design representations models should be easily understandable Principle 9 The design should be developed iteratively Living Modeling Principles 0 O O O O O O Principle 1 Stakeholder centric models should target specific stakeholders and their tasks Principle 2 Models and code should be closely coupled Principle 3 Bidirectional information ow should be established between models and code Principle 4 A common system view should be created Principle 5 Model information should be persistent to allow tracking system changes Principle 6 Information consistency across all model levels must be verified Principle 7 Each model element has assigned stakeholder rights and responsibilities Principle 8 The states of various model elements should be represented Construction Principles 0 O The construction activity encompasses a set of coding and testing tasks that lead to operational software that is ready for delivery to the customer or end user Coding principles and concepts are closely aligned programming style programming languages and programming methods Testing principles and concepts lead to the design of tests that systematically uncover different classes of errors and to do so with a minimum amount of time and effort Preparation Principles 0 Before you write one line of code make sure you I Understand of the problem you re trying to solve I Understand basic design principles and concepts I Pick a programming language that meets the needs of the software to be built and the environment in which it will operate I Select a programming environment that provides tools that will make your work easier I Create a set of unit tests that will be applied once the component you code is completed Coding Principles 0 Once you start writing code make sure to Constrain your algorithms by following structured programming practice Consider the use of pair programming Select data structures that will meet the needs of the design Understand the software architecture and create interfaces that are consistent with it Keep conditional logic as simple as possible Create nested loops in a way that makes them easily testable Select meaningful variable names and follow other local coding standards Write code that is self documenting Create a visual layout e g indentation and blank lines that aids understanding 0 Validation Principles 0 After you ve completed your first coding pass be sure you Conduct a code walkthrough when appropriate Perform unit tests and correct errors you ve uncovered Refactor the code 0 Testing Principles 0 Al Davis suggests the following Principle 1 All tests should be traceable to customer requirements Principle 2 Tests should be planned long before testing begins Principle 3 The Pareto principle applies to software testing Principle 4 Testing should begin in the small and progress toward testing in the large Principle 5 Exhaustive testing is not possible Principle 6 Testing effort for each system module commensurate to eXpected fault density Principle 7 Static testing can yield high results Principle 8 Track defects and look for patterns in defects uncovered by testing Principle 9 Include test cases that demonstrate software is behaving correctly 0 Deployment Principles Principle 1 Customer expectations for the software must be managed Principle 2 A complete delivery package should be assembled and tested 0 O O O O Principle 3 A support regime must be established before the software is delivered Principle 4 Appropriate instructional materials must be provided to endusers Principle 5 Buggy software should be xed rst delivered later Chapter 8 Requirements 0 Engineering Requirements 0 Inception Ask a set of questions that establish Basic understanding of the problem O I The people who want a solution I The nature of the solution that is desired and I The effectiveness of preliminary communication and collaboration between the customer and the developer Elicitation Elicit requirements from all stakeholders Elaboration Create an analysis model that identifies data function and behavioral requirements Negotiation Agree on a deliverable system that is realistic for developers and customers Specification Can include one or more of the following I A written document I A set of models I A formal mathematical I A collection of user scenarios use cases I A prototype Validation A review mechanism that looks for Errors in content or interpretation Areas where clari cation may be required Missing information Inconsistencies a major problem when large products or systems are engineered Con icting or unrealistic unachievable requirements Requirements management 0 Inception O O 0 Identify stakeholders I who else do you think I should talk to Recognize multiple points of view Work toward collaboration The first questions are in this stage some of them are I Who is behind the request for this work I Who will use the solution I What will be the economic benefit of a successful solution I Is there another source for the solution that you need 0 Eliciting Requirements 0 O O 0 Meetings are conducted and attended by both software engineers and customers Rules for preparation and participation are established An agenda is suggested A quotfacilitatorquot can be a customer a developer or an outsider controls the meeting A quotdefinition mechanismquot can be work sheets ip charts or wall stickers or an electronic bulletin board chat room or virtual forum is used The goal is I To identify the problem I Propose elements of the solution I Negotiate different approaches and I Specify a preliminary set of solution requirements Elicitation Work Products 0 O O O O O a statement of need and feasibility a bounded statement of scope for the system or product a list of customers users and other stakeholders who participated in requirements elicitation a description of the system s technical environment a list of requirements preferably organized by function and the domain constraints that apply to each a set of usage scenarios that provide insight into the use of the system or product under different operating conditions any prototypes developed to better define requirements Quality Function Deployment O O O 0 Function deployment determines the value as perceived by the customer of each function required of the system Information deployment identifies data objects and events Task deployment examines the behavior of the system Value analysis determines the relative priority of requirements NonFunctional Requirements 0 NonFunctional Requirement NFR quality attribute performance attribute security attribute or general system constraint A two phase process is used to determine which NFR s are compatible I The first phase is to create a matrix using each NFR as a column heading and the system SE guidelines a row labels I The second phase is for the team to prioritize each NFR using a set of decision rules to decide which to implement by classifying each NPR and guideline pair as complementary overlapping con icting or independent UseCases O A collection broad example of user broad example scenarios that describe the thread of usage of a system I Think about in a global perspective Each scenario is described from the point of view of an actor a person or device that interacts with the software in some way Each scenario answers the following questions I Who is the primary actor the secondary actor s I What are the actor s goals I What preconditions should exist before the story begins I What main tasks or functions are performed by the actor I What extensions might be considered as the story is described I What variations in the actor s interaction are possible I What system information will the actor acquire produce or change I Will the actor have to inform the system about changes in the external environment I What information does the actor desire from the system I Does the actor wish to be informed about unexpected O UseCase Diagram Arms disarms system lo Multiple use simian l cases within the diagram Responds to alarm event Encounters an error condition Reconfigures sensors and related system features system administrator 0 Building the Analysis Model 0 Elements of the analysis model Scenariobased elements 0 Functional processing narratives for software functions I Use case descriptions of the interaction between an actor and the system 39I Classbased elements 0 Implied by scenarios Behavioral elements 0 State diagram Floworiented elements I Data ow diagram Eliciting Requirements Conduct FAST meetings Make lists of functions classes Make lists of constraints etc Use QFDto informally define actors prioritize prioritize requirements requirements I I draw usecase write scenarIo dIagram x Create Usecases complete template N N N N Class Diagram 0 Basis of all Object Oriented Programs Sensor nameid type locann area characteristics identify enabe disabe recon gure State Diagram 0 O f Eyetern status may aplay me I quotenter rim 11 Esaulay attue steely ti Strata 39arrialtIIea Heatlirr Eumman s a State name lErrtryFauhrayatEma may ct pull warrant panel la red userquot rnlutl a interpret uaer in put What is the importance of this diagram I Transactions might go through a level of states State activitiea Analysis Patterns Good way of understanding business language to discuss with stakeholder 0 Pattern name A descriptor that captures the essence of the pattern 0 Intent Describes What the pattern accomplishes or represents 0 Motivation A scenario that illustrates how the pattern can be used to address the problem 0 Forces and context A description of external issues forces that can affect how the pattern is used and also the external issues that will be resolved when the pattern is applied 0 Solution A description of how the pattern is applied to solve the problem with an emphasis on structural and behavioral issues 0 Consequences Addresses What happens when the pattern is applied and What trade offs exist during its application Design Discusses how the analysis pattern can be achieved through the use of known design patterns Known uses Examples of uses within actual systems Related patterns One or more analysis patterns that are related to the named pattern because 0 It is commonly used with the named pattern 0 It is structurally similar to the named pattern 0 It is a variation of the named pattern 0 Negotiating Requirements 0 O 0 Identify the key stakeholders 0 These are the people who will be involved in the negotiation Determine each of the stakeholders win conditions 0 Win conditions are not always obvious 0 WinX Negotiate 0 Work toward a set of requirements that lead to win win 0 Requirements Monitoring 0 Especially needs in incremental development 0 Distributed debugging uncovers errors and determines their cause 0 Runtime verification determines whether software matches its specification 0 Runtime validation assesses whether evolving software meets user goals 0 Business activity monitoring evaluates whether a system satisfies business goals 0 Evolution and codesign Provides information to stakeholders as the system evolves 0 Validating Requirements 0 0 Is each requirement consistent with the overall objective for the systemproduct Have all requirements been specified at the proper level of abstraction That is do some requirements provide a level of technical detail that is inappropriate at this stage Is the requirement really necessary or does it represent an add on feature that may not be essential to the objective of the system Is each requirement bounded and unambiguous Does each requirement have attribution That is is a source generally a specific individual noted for each requirement Do any requirements con ict with other requirements Is each requirement achievable in the technical environment that will house the system or product Is each requirement testable once implemented 0 Does the requirements model properly re ect the information function and behavior of the system to be built 0 Has the requirements model been partitioned in a way that eXposes progressively more detailed information about the system 0 Have requirements patterns been used to simplify the requirements model Have all patterns been properly validated Are all patterns consistent with customer requirements Chapter 9 Requirements Modeling ScenarioBased Methods 0 Requirements Analysis 0 Requirements analysis 0 Specifies software s operational characteristics 0 Indicates software39s interface with other system elements 0 Establishes constraints that software must meet 0 Requirements analysis allows the software engineer called an analyst or modeler in this role to o Elaborate on basic requirements established during earlier requirement engineering tasks 0 Build models that depict user scenarios functional activities problem classes and their relationships system and class behavior and the flow of data as it is transformed 0 Elements of Requirements Analysis Scenarm aw a 39 mall s MWE i r ELIE I i erg ag2 dlagra lmg use 1533 Emllahuratmn user marge magrams Ee aw39m af Haw madeifs Eng Ew state diagrams FDE EequenEE data models diagrams 34 wa e requiremen IE Requirements Modeling 0 O O Scenario based System from the user s point of View Data Shows how data are transformed inside the system Class oriented Defines objects attributes and relationships Flow oriented Shows how data are transformed inside the system Behavioral Show the impact of events on the system states A Bridge 0 system description analysis model 0 Rules of Thumb O O O The model should focus on requirements that are visible within the problem or business domain The level of abstraction should be relatively high Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain function and behavior of the system Delay consideration of infrastructure and other non functional models until design Minimize coupling throughout the system 2 Major Characteristics gt kMid term I A model all stakeholders understand I Might have to make multiple models 0 Domain Analysis 0 0 Define the domain to be investigated Collect a representative sample of applications in the domain 0 Analyze each application in the sample 0 Develop an analysis model for the objects 0 ScenarioBased Modeling 0 What to write about 0 Inception and elicitation Provide you with the information you ll need to begin writing use cases 0 Requirements gathering meetings QFD and other requirements engineering mechanisms are used to 0 Identify stakeholders 0 Define the scope of the problem 0 Specify overall operational goals 0 Establish priorities 0 Outline all known functional requirements and O O O 0 Describe the things objects that will be manipulated by the system 0 To begin developing a set of use cases list the functions or activities performed by a specific actor How much to write about 0 As further conversations with the stakeholders progress the requirements gathering team develops use cases for each of the functions noted 0 In general use cases are written first in an informal narrative fashion 0 If more formality is required the same use case is rewritten using a structured format similar to the one proposed 0 Enough detail to be understoodlt How detailed should we make our description How should we organize the description 0 UseCases O A scenario that describes a thread of usage for a system 0 Actors represent roles people or devices play as the system functions 0 Users can play a number of different roles for a given scenario 0 Developing a UseCase O O O O 0 What are the main tasks or functions that are performed by the actor What system information will the actor acquire produce or change Will the actor have to inform the system about changes in the external environmentgt lt What information does the actor desire from the system Does the actor wish to be informed about uneXpected changesquotlt 0 Reviewing a UseCase O O Use cases are written first in narrative form and mapped to a template if formality is needed Each primary scenario should be reviewed and refined to see if alternative interactions are possible I Can the actor take some other action at this point I Is it possible that the actor will encounter an error condition at some point If so what I Is it possible that the actor will encounter some other behavior at some point If so what UseCase Diagram SafeHome Access camera surveillance via the cameras Internet Configure SafeHome system parameters homeowner Exceptions 0 Describe situations failures or user choices that cause the system to exhibit unusual behavior I Identify in a use case where failures might take place Brainstorming should be used to derive a reasonably complete set of exceptions for each use case Are there cases where a validation function occurs for the use case I Are there cases where a supporting function actor fails to respond appropriately Can poor system performance result in unexpected or improper use actions 0 Activity Diagram 0 Supplements the use case by providing a graphical representation of the ow of interaction within a specific scenario enter password and user ID valid passwords ID invalid passwords ID select major functio ot her functions m ay also be selected input tries remain select surveillance nomput tries remain thumbnail VielNS select a specific camera select specific I t camera thunbnail seec camera Icon view camera outpu in labelled window pronpt for another view eat this funct Ion see amt her camera 0 Swimlane Diagrams O Allows the modeler to represent the ow of activities described by the use case and at the same time indicate which actor if there are multiple actors involved in a specific use case or analysis class has responsibility for the action described by an activity rectangle homeowner camera enter password and user ID interface valid passwordsID in asswo rd 5 ID select major function other function mayalso be selected select surveillance prompt for reentry in p ut tries remain tria remain t h u mb n ail vieWS select a specific cam era A A select Spec39f39c select camera icon camera thumbnails generate video output view camera output prompt for in labelled window another view exitthis f nction see an oth er camera