CITM305 Notes (1) PDF

ITM305 Notes CHAPTER 1 Software Development Computer application (app) – a computer software program that executes on a computing device to carry out a specific set of functions ○ Modest scope Information System - a set of interrelated components that collects, p...

ITM305 Notes CHAPTER 1 Software Development Computer application (app) – a computer software program that executes on a computing device to carry out a specific set of functions ○ Modest scope Information System - a set of interrelated components that collects, processes, stores, and provides as output the information needed to complete business tasks, ○ Broader in scope than “app” ○ Includes database and related manual processes Systems Analysis - those activities that enable a person to understand and specify what an information system should accomplish System design - those activities that enable a person to define and describe in detail the system that solves the need 7 Steps for Software Development 1. Understand the need (business need) 2. Capture the vision 3. Define a solution 4. Communicate the vision and solution 5. Build the solution 6. Confirm that the solution meets the need 7. Launch the solution system System Development Life Cycle (SDLC)  The process consisting of all activities required to build, launch, and maintain an information system. Six core processes are: 1. Identify the problem or need and obtain approval 2. Plan and monitor the project 3. Discover and understand the details of the problem or need 4. Design the system components that solve the problem 5. Build, test, and integrate system components 6. Complete system tests and then deploy the solution Project - a planned undertaking that has a beginning and end and that produces some definite result. ○ Used to develop an information system ○ Requires knowledge of systems analysis and system design tools and techniques System development process - the actual approach used to develop a particular information system (aka methodology) ○ Unified process (UP) ○ Extreme programming (XP) ○ Scrum Most processes/methodologies now use Agile and Iterative development Iterative Development Agile development - an information system development process that emphasizes flexibility to anticipate new requirements during development ○ Fast on feet; responsive to change Iterative development - an approach to system development in which the system is “grown” piece by piece through multiple iterations. ○ Complete a small part of system (mini project), then repeat processes to refine and add more, then repeat to refine and add more, until done. Iterative and Agile Systems Development Lifecycle (SDLC) Ridgeline Mountain Outfitters (RMO) Large Retail Company ○ Outdoor and sporting clothing and accessories ○ Skiing, mountain biking, water sports ○ Hiking, camping, mountain climbing Rocky Mountain and Western States ○ Started mail order and phone order ○ Added retail stores ○ Added extensive E-business component RMO Tradeshow System Sample project for chapter Small information system (app)) Being able to larger supply chain management system Demonstrates one iteration of a small project - assumes more iterations in total project Goes through all six core processes of SDLC The plan for this chapter is to complete the iteration in six days Problem - purchasing agents attend apparel and fabric trade shows around the world to order new products from suppliers. Need - information system (app) to collect and track information about suppliers and new products while at tradeshows Tradeshow Project - is proposed ○ Supplier information subsystem ○ Product information subsystem Initial Activities: Pre-project Identify the problem and document the objective of the system (core process 1) ○ Preliminary investigation ○ System Vision Document Obtain approval to commence the project (core process 1) ○ Meet with key stakeholders, including executive management ○ Decision reached, approve plan and budget Problem Description System Capabilities Business Benefits Day 1 Activities Core Process 2: Plan the Project ○ Determine the major components (functional areas) that are needed Supplier information subsystem Product information subsystem ○ Define the iterations and assign each function to an iteration Decide to do Supplier subsystem first Plan one iteration as it is small and straightforward ○ Determine team members and responsibilities Day 2 Activities Core Process 3: Discover and Understand Details ○ Do preliminary fact-finding to understand the requirements ○ Develop a preliminary list of use cases and a use case diagram ○ Develop a preliminary list of classes and a class diagram Identify Use Cases - Both subsystems Identify Object Classes - Both subsystems Preliminary Class Diagram - Both subsystems Day 3 Activities Core Process 3: Discover and Understand Details ○ Do in-depth fact-finding to understand the requirements ○ Understand and document the detailed workflow of each use case Core Process 4: Design System Components ○ Define the use experience with screens and report sketches Supplier Information Subsystem Use cases: ○ Look up supplier ○ Enter/update supplier information ○ Lookup contact information ○ Enter/update contract information Use Case Diagram - Supplier information subsystem Draft Screen Layout - Look up supplier use case Day 4 Activities Core Process 4: Design System Components ○ Design the database (schema) ○ Design the system's high-level structure Browser, Windows, or Smart phone Architectural configuration (components) Design class diagram Subsystem architectural design Database Schema Architectural Configuration Diagram Notes on Managing the Project Lots of design diagrams shown ○ Design in a complex activity with multiple levels ○ One diagram ○ Builds  ○ on/complements another ○ Not everything is diagrammed, especially for a small project. Pick and choose Programming is also done concurrently ○ You don't design everything then code ○ You do some design, some coding, some design, some coding Day 5 Activities Core Process 4: Design System Components ○ Continue with design details ○ Proceed use case by use case Core Process 5: Build, Test, and Integrate System Components ○ Continue programming (build) ○ Build use case by use case ○ Perform unit and integration tests Day 6 Activities Core Process 6: Complete System Testing and Deploy the System ○ Perform system functional testing ○ Perform user acceptance testing ○ Possibly deploy part of the system Workflow of Testing Tasks First Iteration Recap This was a 6-day iteration of a small project ○ Most iterations are longer (2 to 4 weeks) ○ This project might be 2 iterations ○ Most projects have many more iterations End users need to be involved, particularly on days 1, 2, 3, and 6. Days 4 and 5 involved design and programming concurrently. CHAPTER 2 Ridgeline Mountain Outfitters (RMO) RMO has an elaborate set of information systems that support operations and management. Customer expectations, modern technological capabilities, and competitive pressures led RMO to believe it is time to upgrade support for sales and marketing A new Consolidated Sales and Marketing System was proposed This is a major project that grew out of the RMO strategic planning process RMO Information Systems Strategic Plan Technology Architecture - the set of computing hardware, network hardware and topology, and system software employed by the organization. Application Architecture - the information systems that support the organization (information systems, subsystems, and supporting technology) RMO Existing Application Architecture Supply Chain Management (SCM)  ○ 5 years old; Java/Oracle ○ Tradeshow system will interface with SCM Phone/Mail Order System ○ 12 years old; Visual Studia/MS SQL ○ Reached capacity; minimal integration Retail Store System ○ Older package solution; minimal integration Customer Support System (CSS) ○ Web-based system; evolved over the years, minimal integration Proposed Application Architecture: Integrate SCM and New SMS New Consolidated Sales and Marketing System (CSMS) Sales Subsystem ○ Integrates online, phone, and retail store Order Fulfillment Subsystem ○ Track shipments, rate products and services Customer Account Subsystem ○ Shopping history, linkups “mountain bucks” rewards Marketing Subsystem ○ Promotional packages, partner relationships, more complete merchandise information and reporting Systems Analysis Activities (Involve discovery and understanding) The New Consolidated Sales and Marketing System (CSMS) will require discovering and understanding extensive and complex business processes and business rules The SDLC indicates the project starts with identifying the problem, obtaining approval, and planning the project (as seen in Chapter 1) To get to the heart of systems analysis, this text skips right to analysis activities generally and specifically for the RMO CSMS project (Core Process #3) Project planning and project management are covered in detail later in the text Gather Detailed Information ○ Interviews, questionnaires, documents, observing business processes, researching vendors, comments and suggestions Define Requirements ○ Modeling functional requirements and non-functional requirements Prioritize Requirements ○ Essential, important, vs. nice to have Develop User-Interface Dialogs ○ Flow of interaction between user and system Evaluate Requirements with Users ○ User involvement, feedback, adapt to changes What Are Requirements? System Requirements = ○ Functional requirements ○ Non-functional requirements  Functional Requirements– the activities the system must perform ○ Business uses, functions the users carry out ○ Shown as use cases in Chapter 1 Non-Functional Requirements– other system characteristics ○ Constraints and performance goals FURPS+Requirements Acronym Functional requirements Usability requirements Reliability requirements Performance requirements Security requirements + even more categories… Additional Requirements Categories Design constraints – ○ Specific restrictions for hardware and software Implementation requirements ○ Specific languages, tools, protocols, etc. Interface requirements ○ Interface links to other systems Physical requirements ○ Physical facilities and equipment constraints Supportability requirements ○ Automatic updates and enhancement methods Stakeholders (Who do you involve and talk to?) Stakeholders – persons who have an interest in the successful implementation of the system  Internal Stakeholders– persons within the organization External stakeholders – persons outside the organization Operational stakeholders – persons who regularly interact with the system Executive stakeholders – persons who don’t directly interact, but use the information or have financial interest Stakeholders of a comprehensive accounting system for public company Stakeholders for RMO CSMS Project Phone/mail sales order clerks Warehouse and shipping personnel Marketing personnel who maintain online catalog information Marketing, sales, accounting, and financial managers Senior executives Customers External shippers (e.g., UPS and FedEx) RMO Internal Stakeholders Information Gathering Techniques Interviewing users and other stakeholders Distributing and collecting questionnaires Reviewing inputs, outputs, and documentation Observing and documenting business procedures Researching vendor solutions Collecting active user comments and suggestions Interviewing Users and Other Stakeholders Prepare detailed questions Meet with individuals or groups of users Obtain and discuss answers to the questions Document the answers Follow up as needed in future meetings or interviews Themes for Information Gathering Questions Preparing for the Interview Interview Session Agenda Keeping an Open Items List Distribute and Collect Questionnaires Review Inputs, Outputs, and Procedures Additional Techniques Observe and Document Business Processes  ○ Watch and learn ○ Document with Activity diagram (next section) Research Vendor Solutions ○ See what others have done for similar situations ○ White papers, vendor literature, competitors Collect Active User Comments and Suggestions ○ Feedback on models and tests ○ Users know it when they see it Models and Modeling How do we define requirements? After collecting information, create models Model– a representation of some aspect of the system being built Types of Models: ○ Textual model– something written down, described ○ Graphical models– diagram, schematic ○ Mathematical models– formulas, statistics, algorithms Unified Modeling Language (UML) ○ Standard graphical modelling symbols/terminology used for information systems Reasons for Modeling Learning from the modelling process Reducing complexity by abstraction Remembering all the details Communicating with other development team members Communicating with a variety of users and stakeholders Documenting what was done for future maintenance/enhancement Some Analysis and Design Models Documenting Workflows with Activity Diagrams Workflow– sequence of processing steps that completely handles one business transaction or customer request Activity Diagram– describes user (or system) activities, the person who does each activity, and the sequential flow of these activities ○ Useful for showing a graphical model of a workflow ○ A UML diagram Activity Diagrams Symbols Activity Diagram for RMO Order Fulfillment Activity Diagram with Concurrent Paths CHAPTER 3 User Stories A User Story is a one-sentence description of a work-related task done by a user to achieve some goal or result Acceptance Criteria identify the features that must be present at the completion of the task The template for a user story description is: ○ “As a I want to so that Sample User Story Use Cases Use case— an activity that the system performs, usually in response to a request by a user Use cases define functional requirements Analysts decompose the system into a set of use cases (functional decomposition) Two techniques for Identifying use cases ○ User goal technique ○ Event decomposition technique Name each use case using Verb-Noun User Goal Technique This technique is the most common in industry Simple and effective Identify all of the potential categories of users of the system Interview and ask them to describe the tasks the computer can help them with Probe further to refine the tasks into specific user goals, “I need to Ship items, Track a shipment, Create a return” User Goal Technique (Some RMO CSMS Users and Goals) User Goal Technique: Specific Steps 1. Identify all the potential users for the new system 2. Classify the potential users in terms of their functional role (e.g., shipping, marketing, sales) 3. Further classify potential users by organizational level (e.g., operational, management, executive) 4. For each type of user, interview them to find a list of specific goals they will have when using the new system (current goals and innovative functions to add value) 5. Create a list of preliminary use cases organized by type of user 6. Look for duplicates with similar use case names and resolve inconsistencies 7. Identify where different types of users need the same use cases 8. Review the completed list with each type of user and then with interested stakeholders Event Decomposition Technique More Comprehensive and Complete Technique ○ Identify the events that occur to which the system must respond. ○ For each event, name a use case (verb-noun) that describes what the system does when the event occurs Event– something that occurs at a specific time and place, can be described, and should be remembered by the system Events and Use Cases Types of Events External Event ○ an event that occurs outside the system, usually initiated by an external agent or actor Temporal Event ○ an event that occurs as a result of reaching a point in time State Event ○ an event that occurs when something happens inside the system that triggers some process ○ reorder point is reached for inventory item External Event Checklist External agent or actor wants something resulting in a transaction ○ Customer buys a product External agent or actor wants some information ○ Customer wants to know product details External data changed and needs to be updated ○ Customer has new address and phone Management wants some information ○ Sales manager wants update on production plans Temporal Event Checklist  Internal outputs needed at points in time ○ Management reports (summary or exception) ○ Operational reports (detailed transactions) ○ Internal statements and documents (including payroll) External outputs needed at points of time ○ Statements, status reports, bills, reminders Finding the actual event that affects the system Tracing a sequence of transactions resulting in many events Perfect Technology Assumption  Don’t worry about functions built into system because of limits in technology and people. Wait until design Event Decomposition Technique: Specific Steps 1. Consider the external events in the system environment that require a response from the system by using the checklist shown in Figure 3-3 2. For each external event, identify and name the use case that the system requires 3. Consider the temporal events that require a response from the system by using the checklist shown in Figure 3-4 4. For each temporal event, identify and name the use case that the system requires and then establish the point of time that will trigger the use case 5. Consider the state events that the system might respond to, particularly if it is a real-time system in which devices or internal state changes trigger use cases. 6. For each state event, identify and name the use case that the system requires and then define the state change. 7. When events and use cases are defined, check to see if they are required by using the perfect technology assumption. Do not include events that involve such system controls as login, logout, change password, and backup or restore the database, as these are put in later Event Decomposition Technique: Benefits Events are broader than user goal: Capture temporal and state events Help decompose at the right level of analysis: an elementary business process (EBP) EBP is a fundamental business process performed by one person, in one place, in response to a business event Uses perfect technology assumption to make sure functions that support the users work are identified and not additional functions for security and system controls Use Cases and Brief Use Case Descriptions  Brief use case description is often a one sentence description showing the main steps in a use case RMO CSMS Project Use Cases Use Case Diagrams Use case diagram— a UML model used to graphically show uses cases and their relationships to actors Recall UML is Unified Modeling Language, the standard for diagrams and terminology for developing information systems Actor is the UML name for a end user Automation boundary— the boundary between the computerized portion of the application and the users who operate the application Use Case Diagrams Symbols Use Case Diagrams— The relationship A relationship between use cases where one use case is stereotypically included within the other use case— like a called subroutine. Arrow points to subroutine Use Case Diagrams: Steps 1. Identify all the stakeholders and users who would benefit by seeing a use case diagram 2. Determine what each stakeholder or user needs to review in a use case diagram: each subsystem, for each type of user, for use cases that are of interest 3. For each potential communication need, select the use cases and actors to show and draw the use case diagram. There are many software packages that can be used to draw use case diagrams 4. Carefully name each use case diagram and then note how and when the diagram should be used to review use cases with stakeholders and users CHAPTER 4 Things in the Problem Domain Problem domain—the specific area (or domain) of the users’ business need that is within the scope of the new system. “Things” are those items users work with when accomplishing tasks that need to be remembered Examples of “Things” are products, sales, shippers, customers, invoices, payments, etc. These “Things” are modeled as domain classes or data entities In this course, we will call them domain classes. In database class you may call them data entities Things in the Problem Domain - Two Techniques for Identifying Them Brainstorming Technique  ○ Use a checklist of all of the usual types of things typically found and brainstorm to identify domain classes of each type Noun Technique ○ Identify all of the nouns that come up when the system is described and determine if each is a domain class, an attribute, or not something we need to remember Brainstorming Technique Are there any tangible things? Are there any organizational units? Sites/locations? Are there incidents or events that need to be recorded? Brainstorming Technique - Steps: 1. Identify a user and a set of use cases 2. Brainstorm with the user to identify things involved when carrying out the use case—that is, things about which information should be captured by the system. 3. Use the types of things (categories) to systematically ask questions about potential things, such as the following: Are there any tangible things you store information about? Are there any locations involved? Are there roles played by people that you need to remember? 4. Continue to work with all types of users and stakeholders to expand the brainstorming list 5. Merge the results, eliminate any duplicates, and compile an initial list The Noun Technique A technique to identify problem domain classes (things) by finding, classifying, and refining a list of nouns that come up in in discussions or documents Popular technique. Systematic.  Does end up with long lists and many nouns that are not things that need to be stored by the system Difficulty identifying synonyms and things that are really attributes Good place to start when there are no users available to help brainstorm The Noun Technique - Steps: 1. Using the use cases, actors, and other information about the system— including inputs and outputs—identify all nouns. For the RMO CSMS, the nouns might include customer, product item, sale, confirmation, transaction, shipping, bank, change request, summary report, management, transaction report, accounting, back order, back order notification, return, return confirmation... 2. Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed. For the RMO CSMS, these might include price, size, color, style, season, inventory quantity, payment method, and shipping address. 3. As this list of nouns builds, refine it. Ask these questions about each noun to help you decide whether you should include it: Is it a unique thing the system needs to know about? Is it inside the scope of the system I am working on? Does the system need to remember more than one of these items? Ask these questions to decide to exclude it: Is it really a synonym for some other thing I have identified? Is it really just an output of the system produced from other information I have identified? Is it really just an input that results in recording some other information I have identified? Ask these questions to research it: Is it likely to be a specific piece of information (attribute) about some other thing I have identified? Is it something I might need if assumptions change? 4. Create a master list of all nouns identified and then note whether each one should be included, excluded, or researched further. 5. Review the list with users, stakeholders, and team members and then define the list of things in the problem domain. Partial List of Nouns for RMO With notes on whether to include as domain class Details about Domain Classes Attribute— describes one piece of information about each instance of the class ○ Customer has first name, last name, phone number Identifier or key ○ One attribute uniquely identifies an instance of the class. Required for data entities, optional for domain classes. Customer ID identifies a customer Compound attribute ○ Two or more attributes combined into one structure to simplify the model. (E.g., address rather than including number, street, city, state, zip separately). Sometimes an identifier or key is a compound attribute. Attributes and Values Class is a type of thing. Object is a specific instance of the class. Each instance has its own values for an attribute Associations Among Things Association— a naturally occurring relationship between classes (UML term) Just to Clarify… Called association on class diagram in UML ○ Multiplicity is term for the number of associations between classes: 1 to 1 or 1 to many (synonym to cardinality) UML is the primary emphasis of this text Called relationship on ERD in database class ○ Cardinality is term for number of relationships in entity relationship diagrams: 1 to 1 or 1 to many (synonym to multiplicity) Associations and Relationships apply in two directions ○ Read them separately each way  ○ A customer places an order ○ An order is placed by a customer Minimum and Maximum Multiplicity Associations have minimum and maximum constraints ○ minimum is zero, the association is optional ○ If minimum is at least one, the association is mandator Types of Associations Binary Association ○ Associations between exactly two different classes Course Section includes Students Members join Club Unary Association (recursive) ○ Associations between two instances of the same class Person married to person Part is made using parts Ternary Association (three) N-ary Association (between n) Entity-Relationship Diagrams (ERD): ERDs have been used for many years to develop data models that are used in database development The term for “things” in ERD models is data entities ERD models are not UML models and do not use standard UML notation ERD models are not as expressive as UML models ○ They do not model generalization/specialization well  ○ They do not model whole/part well Example of ERD Notation ERD Models normally use “crows feet” notation to show cardinality ERD Cardinality Symbols Examples of crows feet notation for various cardinalities Expanded ERD with Attributes ERD with cardinalities and attributes There are several different notation methods for attributes in ERD models This notation places attributes within data entities Semantic Net A semantic net is a graphical representation of an individual data entity and its relationship with other individual entities It is often used to help understand and then develop an ERD model This example shows three classes. Quick quiz ○ What are the classes? ○ How many relationships? ○ What are min and max cardinalities? ○ What type of relationships are they? An ERD for a Bank Quick Quiz ○ What are the key fields? ○ How many accounts can a customer have? ○ How many branches can a customer be assigned to? ○ How many customers can a branch have? The Domain Model Class Diagram Class ○ A type of classification used to describe a collection of objects Domain Class ○ Classes that describe objects in the problem domain Class Diagram ○ A UML diagram that shows classes with attributes and associations (plus methods if it models software classes) Domain Model Class Diagram ○ A class diagram that only includes classes from the problem domain, not software classes so no methods UML Domain Class Notation Domain class a name and attributes (no methods) Class name is always capitalized Attribute names are not capitalized and use camelback notation (words run together and second word is capitalized) Compound class names also use camelback notation A Simple Domain Model Class Diagram Note: This diagram matches the semantic net shown previously ○ A customer places zero or more orders ○ An order is placed by exactly one customer ○ An order consists of one or more order items ○ An order item is part of exactly one order UML Notation for Multiplicity Domain Model Class Diagram Bank with many branches as show previously in ERD ○ Note notation for the key ○ Note the precise notation for the attributes (camelback) ○ Note the multiplicity notation Domain Model Class Diagram Course Enrollment at a University A Course has many CourseSections A CourseSection has many Students and a Student is registered in many CourseSections  Problem ○ How/where to capture student grades? Refined Course Enrollment Model with an Association Class CourseEnrollment Association class— an association that is treated as a class in a many to many association because it has attributes that need to be remembered (such as grade) Association Class Properties The association class is the same “thing” as the association itself The unique identifier (key) for the association class is the concatenation of the keys of the attached classes ○ In the previous example the key for CourseSection is CourseNumber+SectionNumber ○ Hence the key for CourseEnrollment is CourseNumber+SectionNumber+StudentID ○ Note: If more information is required to uniquely identify instances of the association class, then the model is incorrect, i.e., if the key cannot be formed by the concatenation of the endpoint keys, it is in error Band with members and concerts Quick Quiz ○ How many bands can a person play in? ○ For a band, how many concerts can it play in? ○ For a concert, how many bands may be playing? ○ What attributes can you use for keys? Do you ○ need to add “key” attributes? Band with Concert Booking Information Note: The association class (Booking) also provides a name and meaning for the association Given the keys you identified, what is the key for the Booking class? Does it uniquely identify instances? More Complex Issues about Classes - Generalization/Specialization Relationships Generalization/Specialization ○ A hierarchical relationship where subordinate classes are special types of the superior classes. Often called an Inheritance Hierarchy Superclass ○ the superior or more general class in a generalization/specialization hierarchy Subclass ○ the subordinate or more specialized class in a generalization/specialization hierarchy Inheritance ○ the concept that subclasses classes inherit characteristics of the more general superclass Generalization/Specialization Generalization/Specialization - Inheritance for RMO Three Types of Sales Abstract class— a class that allow subclasses to inherit characteristics but never gets instantiated. In Italics (Sale) Concrete class— a class that can have instances Inheritance – Attributes of OnlineSale are: ○ timeOnSite, chatUse, saleDateTime, priorityCode, S&H, tax, totalAmt.. Generalization/Specialization - Inheritance for the Bank with Special Types of Accounts A SavingsAccount has 4 attributes  A CheckingAccount has 5 attributes Note: the subclasses inherit the associations too More Complex Issues about Classes - Whole Part Relationships Whole-part relationship— a relationship between classes where one class is part of or a component portion of another class Aggregation— a whole part relationship where the component part exists separately and can be removed and replaced (UML diamond symbol on next slide) ○ Computer has disk storage devices (storage devices exist apart from computer) ○ Car has wheels (wheels can be removed and still be wheels) Composition— a whole part relationship where the parts cannot be removed (filled in diamond symbol) ○ OrderItem on an Order (without the Order, there are no OrderIterms) ○ Chip has circuits (without the chip, there are no circuits Whole Part Relationships Computer and its Parts Note: this is composition, with diamond symbol.  Whole part can have multiplicity symbols, too (not shown) More on UML Relationships There are actually three types of relationships in class diagrams ○ Association Relationships These are associations discussed previously, just like ER relationships Whole Part Relationships One class is a component or part of another class Generalizations/Specialization Relationships ○ Inheritance Try not to confuse relationship with association RMO CSMS Project - Domain Model Class Diagrams There are several ways to create the domain model class diagram for a project RMO CSMS has 27 domain classes overall Can create one domain model class diagram per subsystem for those working on a subsystem Can create one overall domain model class diagram to provide an overview of the whole system  Usually in early iterations, an initial draft of the domain model class diagram is completed and kept up to date. It is used to guide development. RMO CSMS Project - Sales Subsystem Domain, Model Class Diagrams RMO CSMS Project - Customer Account Subsystem, Domain Model Class Diagram RMO CSMS Project - Complete Domain Model Class Diagram RMO CSMS Project - Domain Model Class Diagrams Given the complete RMO CSMS Domain Model Class Diagram and Sales and Customer Account subsystem examples: ○ Try completing the Order Fulfilment Subsystem Domain Model Class Diagram ○ Try Completing the Marketing Subsystem Domain Model Class Diagram ○ Try Completing the Reporting Subsystem Domain Model Class Diagram Review the use cases from Chapter 3 and decide what classes and associations from the complete model are required for each subsystem ○ Classes and associations might be duplicated in more than one subsystem model Object Behavior – State Machine Diagram Each class has objects that may have status conditions or “states” Object behavior consists of the various states and the movement between these states State – a condition during an object’s life when it satisfies some criterion, performs an action, or waits for an event Transition – the movement of an object from one state to another State Machine Diagram State Machine Diagram – a diagram which shows the life of an object in states and transitions Origin state – the original state of an object before it begins a transition Destination state – the state to which an object moves after completing a transition pseudostate – the starting point in a state machine diagram. Noted by a black circle. action-expression – some activity that must be completed as part of a transition guard-condition – a true/false test to see whether a transition can fire State Machine for a Printer Syntax of transition statement ○ transition-name (parameters,...) [guard-condition] / action-expression Concurrency in a State Machine Diagram Concurrent states – when an object is in one or more states at the same time Path – a sequential set of connected states and transitions Concurrent paths – when multiple paths are being followed concurrently, i.e. when one or more states in one path are parallel to states in another path Printer with Concurrent Paths  Concurrent paths often shown by synchronization bars (same as Activity Diagram) Multiple exits from a state is an “OR” condition. Multiple exits from a synchronization bar is an “AND” condition Creating a State Machine Diagram - Steps 1. Review the class diagram and select classes that might require state machine diagrams 2. For each class, make a list of status conditions (states) you can identify 3. Begin building diagram fragments by identifying transitions that cause an object to leave the identified state 4. Sequence these states in the correct order and aggregate combinations into larger fragments 5. Review paths and look for independent, concurrent paths 6. Look for additional transitions and test both directions 7. Expand each transition with appropriate message event, guard condition, and action expression 8. Review and test the state machine diagram for the class Make sure state are really state for the object in the class Follow the life cycle of an object coming into existence and being deleted Be sure the diagram covers all exception condition Look again for concurrent paths and composite states RMO – Creating a State Machine Diagram Steps -- SaleItem 1. Choose SaleItem. It has status conditions that need to be tracked 2. List the states and exit transitions RMO – Creating a State Machine Diagram Steps -- SaleItem 3. Build fragments – see figure below 4. Sequence in correct order – see figure below 5. Look for concurrent paths – none RMO – Creating a State Machine Diagram Steps -- SaleItem 6. Add other required transitions 7. Expand with guard, action-expressions etc. 8. Review and test Below is the final State Machine Diagram RMO – Creating a State Machine Diagram Steps -- InventoryItem 1. Choose InventoryItem. It has status conditions that need to be tracked 2. List the states and exit transitions RMO – Creating a State Machine Diagram Steps -- InventoryItem 3. Build fragments – see figure below 4. Sequence in correct order – see figure below 5. Look for concurrent paths – see figure below RMO – Creating a State Machine Diagram Steps -- InventoryItem 6. Add other required transitions 7. Expand with guard, action-expressions etc. 8. Review and test Below is the final State Machine Diagram CHAPTER 10 The System Development Life Cycle (SDLC) There are two general approaches to the SDLC  Predictive Approach to the SDLC ○ Waterfall model ○ Assumes the project can be planned in advance and that the information system can be developed according to the plan ○ Requirements are well understood and/or low technical risk Adaptive Approach to the SDLC ○ Iterative model (as see in this text) ○ Assumes the project must be more flexible and adapt to changing needs as the project progresses Requirements and needs are uncertain and/or high technical risk Most projects fall on a continuum between Predictive and Adaptive Traditional Predictive SDLC Earlier approach based on engineering Typically have sequential Phases ○ Phases are related groups of development activities, such as planning, analysis, design, implementation, and deployment Waterfall model ○ SDLC that assumes phases can be completed sequentially with no overlap or iteration ○ Once one phase is completed, you fall over the waterfall to the next phase, no going back Tradition IS Development Phases Waterfall Predictive SDLC Modified Waterfall with Overlapping Phases Newer Adaptive SDLC Emerged in response to increasingly complex requirements and uncertain technological environments Always includes iterations where some of design and implementation is done from the beginning Many developers claim it is the only way to develop information systems Many IS managers are still sceptical due to apparent lack of overall plan Adaptive Approaches Incremental development  ○ Completes portions of the system in small increments and integrated as the project progresses ○ Sometimes considered “growing” a system Walking Skeleton ○ The complete system structure is built first, but with bare-bones functionality A Generic Adaptive Approach Six Core Processes go across iterations Multiple Iterations as required Methodologies, Models, Tools, and Techniques Methodologies ○ Provides guidelines for every facet of system development: What to do when, why and how ○ Specifies an SDLC with activities and tasks ○ Specifies project planning and project management models and reporting ○ Specifies analysis and design models to create ○ Specifies implementation and testing techniques ○ Specifies deployment and support techniques Other term used is System Development Process Methodologies  A Methodology includes a collection of techniques that are used to complete activities and tasks, including modeling, for every aspect of the project Methodologies, Models, Tools, and Techniques Model ○ An abstraction of an important aspect of the real world. ○ Makes it possible to understand a complex concept by focusing only on a relevant part ○ Each model shows a different aspect of the concept ○ Crucial for communicating project information In IS, some models are of system components that will be developed Other models are used to manage the development process  Tools ○ Software applications that assists developers in creating models or other components required for a project Integrated Development Environment (IDE) ○ set of tools that work together to provide a comprehensive development environment Visual Modeling Tools ○ Tools to create graphical models Some typical tools:  Technique ○ A collection of guidelines that help an analyst complete an activity or task ○ Learning techniques is the key to having expertise in a field Agile Development A guiding philosophy and set of guidelines for developing information systems in an unknown, rapidly changing environment Chaordic ○ A term for adaptive projects – chaotic yet ordered Agile Values in “Manifesto for Agile Software Development” ○ Value responding to change over following a plan ○ Value individuals and interactions over processes and tools ○ Value working software over comprehensive documentation ○ Value customer collaboration over contract negotiation Agile Modeling Principles Agile Modeling (AM) – 12 Principles ○ A philosophy – build only necessary models that are useful and at the right level of detail Agile Principles Develop software as the primary goal ○ Don’t get distracted by documentation or models Enable the next effort as your secondary goal ○ Be aware of next step versions or revisions Minimize your modeling activity ○ Only build what helps move the project forward Embrace change and change incrementally ○ Take small steps that keep you on-track and that can be reversed if necessary Model with a purpose ○ Model to understand ○ Model to communicate Build multiple models ○ Look at problems from different perspectives Build high-quality models and get feedback Focus on content rather than representation ○ Informal hand-drawn models are sometimes okay ○ Always focus on stakeholder needs Learn from each other with open communication Know your models and how to use them Adapt to specific project needs Maximize stakeholder RMI The Unified Process (UP) The UP was the early leader in adaptive approaches UP and UML (Unified Modeling Language) were developed together The Unified Process (UP) – Phases UP Phases organize iterations into four primary areas of focus during a project ○ Inception phase – getting the project started ○ Elaboration – understanding the system requirements ○ Construction – building the system ○ Transitions – preparing for and moving to deploying the new system UP SDLC divides iterations into four phases: Objectives of each phase: Unified Process – Disciplines A set of functionally related development activities ○ Each discipline are all the activities related to achieving one objective in the development project ○ Two types of disciplines Development disciplines Management – planning and control discipline Development Disciplines  ○ Business modeling ○ Requirements ○ Design ○ Implementation ○ Testing ○ Deployment Planning and Control disciplines ○ Configuration and change management ○ Project management ○ Environment Disciplines are used across all iterations Extreme Programming (XP) Takes the best practices of software development and extends them “to the extreme” ○ Focus intensely on proven industry practices  ○ Combine them in unique ways to get better results XP Core Values ○ Communication ○ Simplicity ○ Feedback ○ Courage XP Practices ○ Planning – based on user stories ○ Testing – thorough testing at every step ○ Pair Programming – watch, inspect, trade off ○ Simple Designs – Agile modeling principles ○ Refactoring – redo and cleanup as you go ○ Owning the code collectively – egoless development, anyone can review and improve code ○ Continuous integration – grow the software continuously ○ On-site customer – get sign-off as you go ○ System metaphor – what should the final system look like ○ Small releases – turn over to user frequently ○ Forty-hour work week – don’t overload the developers ○ Coding standards – follow standards for code XP Core Values and Practices XP Project Approach Three-level approach (three rings) ○ Outside ring – create user stories and define acceptance tests ○ Middle ring – conduct tests and do overall planning ○ Inside ring – iterations of coding and testing SCRUM Combination of principles of Rugby and Agile ○ Intense effort involving the entire team for a defined period of time Product backlog ○ Prioritized list of user requirements Product owner ○ The client stakeholder who controls backlog Scrum master ○ Scrum project manager Scrum Sprint  Scrum sprint ○ A time-controlled mini-project to implement part of the system Scrum Practices Scope of each sprint is frozen (but can be reduced if necessary) Time period is kept constant Daily Scrum meeting ○ What have you done since the last daily Scrum (during the last 24 hours)? ○ What will you do by the next daily Scrum? ○ What kept you or is keeping you from completing your work? CHAPTER 5 Use Case Descriptions Write a brief description as shown in Chapter 3 for most use cases.  Write a fully developed use case description for more complex use cases Typical use case description templates include: ○ Use case name ○ Scenario (if needed) ○ Triggering event ○ Brief description ○ Actors ○ Related use cases () ○ Stakeholders ○ Preconditions ○ Postconditions ○ Flow of activities ○ Exception conditions Fully Developed Use Case Description Use Case Description Details Use case name ○ Verb-noun Scenario (if needed) ○ A use case can have more than one scenario (special case or more specific path)  Triggering event ○ Based on event decomposition technique Brief description ○ Written previously when use case was identified Actors ○ One or more users from use case diagrams Related use cases ○ If one use case invokes or includes another Stakeholders ○ Anyone with an interest in the use case Preconditions ○ What must be true before the use case begins Post conditions ○ What must be true when the use case is completed ○ Use for planning test case expected results Flow of activities ○ The activities that go on between actor and the system Exception conditions ○ Where and what can go wrong Another Fully Developed Use Case Description Example UML Activity Diagram for Use Case Notes: this shows flow of activities only Activity Diagram for Ship Items Use Case Notes: ○ Synchronization bar for loop ○ Decision diamond UML Activity Diagram for Use Case Note: this shows use case with relationship System Sequence Diagram (SSD) A UML sequence diagram Special case for a sequence diagram ○ Only shows actor and one object ○ The one object represents the complete system ○ Shows input & output messaging requirements for a use case Actor, :System, object lifeline Messages System Sequence Diagram (SSD) Notation SSD Message Examples with Loop Frame Message Notation for SSD [true/false condition] return-value := message-name (parameter-list) ○ An asterisk (*) indicates repeating or looping of the message ○ Brackets [ ] indicate a true/false condition. This is a test for that message only. If it evaluates to true, the message is sent. If it evaluates to false, the message isn’t sent. ○ Message-name is the description of the requested service written as a verb-noun. ○ Parameter-list (with parentheses on initiating messages and without parentheses on return messages) shows the data that are passed with the message. ○ Return-value on the same line as the message (requires :=) is used to describe data being returned from the destination object to the source object in response to the message. SSD Message Examples Opt Frame (optional)  Alt Frame (if-else) Steps for Developing SSD 1. Identify input message See use case flow of activities or activity diagram 2. Describe the message from the external actor to the system using the message notation Name it verb-noun: what the system is asked to do Consider parameters the system will need 3. Identify any special conditions on input messages Iteration/loop frame Opt or Alt frame 4. Identify and add output return values On message itself: aValue:= getValue(valueID) As explicit return on separate dashed line SSD for Create customer account Use case SSD for Ship items Use Case Use Cases and CRUD CRUD technique – ○ Create ○ Read/Report ○ Update ○ Delete A good cross-check against the existing set of use cases. Used in database context ○ Ensure that all classes have a complete “cover” of use cases Not for primary identification of use cases Verifying use cases for Customer CRUD Analysis Steps 1. Identify all domain classes 2. For each class verify that use cases exist to Create a new instance Update existing instances Reads or reports on information in the class Deletes or archives inactive instances 3. Add new use cases as required. Identify responsible stakeholders 4. Identify which application has responsibility for each action: which to create, which to update, which to use Sample CRUD Matrix Extending and Integrating Requirements Models Use cases ○ Use case diagram Use case description Activity diagram System sequence diagram (SSD) Domain Classes ○ Domain model class diagram State machine diagram Integrating Requirements Models CHAPTER 6