ACS-2913 Final Study PDF

ACS-2913 Midterm Study 1 -- Introduction Slides *[Software Development, Systems Analysis Design]* **Computer Application (app)** - A computer software program that executes on a computing device to carry out a specific set of functions - Modest scope - By definition, an application s...

ACS-2913 Midterm Study 1 -- Introduction Slides *[Software Development, Systems Analysis Design]* **Computer Application (app)** - A computer software program that executes on a computing device to carry out a specific set of functions - Modest scope - By definition, an application supports a specific task **Information System** - A set of interrelated components that collects, processes, stores, and provides as output the information needed to complete the business tasks - Broder in scope than app - Includes database and related manual processes *[Systems Analysis and Design]* Analysis and design are important parts of what is known as the "**Systems Development Lifecycle"** **Systems Analysis** - Describing the problem from the user's perspective **Systems Design** - Describing the solution that solves the problem from the user's perspective A diagram of a system Description automatically generated *[System Development Lifecycle]* - Understand the "business need" - Capture the vision - Define a solution - Communicate the vision and the solution - Build the solution (or direct others to build it) - Launch the information system *[Systems Development Projects]* **Project** -- a planned undertaking that has a beginning and end and that produces some definite result **SDLC** -- the entire process consisting of all activities required to build, launch, and maintain an information system **6 main activities** for SDLC: 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 or satisfy the need 5. Build, test, and integrate system components 6. Complete system tests and deploy the solution *[Information Systems Development Process/Methodology]* [ ] Set of comprehensive guidelines for carrying out the activities of the SDLC ***Waterfall model** --* is a breakdown of project activities into linear *sequential* phases, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks ***Spiral model*** -- combines the idea of iterative development with systematic, controlled aspects of the waterfall model. This spiral model is a combination of iterative development process model and sequential linear development model i.e. the waterfall model with a very high emphasis on risk analysis. It allows incremental releases of the product or incremental refinement through each iteration around the spiral ***Software model*** -- refers to building software application prototypes which displays the functionality of the product under development, but may not actually hold the exact logic of the original software Most processes/methodologies now use **Agile** and Iterative development ***Agile development*** - emphasizes flexibility to anticipate new requirements during development - Fast on feet; responsive to change ***Iterative development*** - System is "grown" piece by piece through multiple iterations - Complete small part of system (mini project), then repeat processes to refine and add more, until done *[Agile-Iterative Development]* An iterative system **development process** that develops the system in ***"sprint" increment***s lasting from two weeks to two months - Concentrates on ***maximizing the team's ability to deliver quickly*** and ***respond to*** ***emerging requirements*** ***Scrum***: a method to keep the agile system development effort focused and moving quickly - The scrum master coordinates all activities - *Scrum is a **framework** that helps teams work together* ***Extreme programming (XP)*** promotes incremental development of a system using short development cycles to: - Improve productivity - Accommodate new customer requirements ***Feature-Driven Development (FDD)*** - A framework in the Agile methodology - Focuses on developing software w/ features that satisfy client needs - Aims to ensure regular and on-time delivery to customers, in line with the values and principles of the Agile Manifesto - ***Key difference b/w FDD and Scrum***: FDD has a *more structured approach to planning and managing the development process,* while Scrum *is more flexible and adaptable* - Development team is organized into small, cross-functional feature teams, each of which is responsible for delivering a specific set of features ***Kanban*** - An agile management method built on a philosophy of continuous improvement, where work items are "pulled" from a product backlog into a steady flow of work - Framework is applied using **Kanban boards** -- a form of visual project management - In a Kanban, tasks -- represented as cards -- move through stages of work -- represented as columns - That way, team can see where work is in real-time *[Benefits of Iterative Development]* - Core functions can be deployed in early iterations - Newer technologies can be explored early on to avoid re-architecting system *[Iterative and Agile SDLC]* Summary of Lecture - This course is about developing information systems that solve an organization need - System development involves 6 core processes, known as the SDLC - Important terminology: - Computer application - Information system - Project - System analysis - System design - System development lifecycle (SDLC) - Information system development process (methodology) - Agile development - Iterative development 2 -- Project Example *[System Vision Document]* - Problem description - System capabilities - Business benefits  *[Day 1 Activities]* ***Core Process 2: Plan the Project*** - Determine the major components (functional pieces) that are needed - Supplier information subsystem - Product information system - Define the iterations and assign each function to an iteration - Decide to do supplier subsystem first - Plan one iteration as it is small and straight forward - Determine team members and responsibilities *[Work Breakdown Structure]* I. **Discover and understand the details of all aspects of the problem \~ system analysis** 1. Meet with the purchasing department manager \~ 3hrs 2. Meet with several purchasing agents \~ 4hrs 3. Identify and define use cases \~ 3hrs 4. Identify and define info requirements \~ 2hrs 5. Develop workflows and descriptions for the use case \~ 6hrs II. **Design the components of the solution to the problem \~ system design** 1. Design the input screens, output screens, and reports \~ 6hrs 2. Design and build database \~ 4hrs 3. Design overall architecture \~ 4hrs 4. Design program details \~ 6hrs III. **Build the components and integrate everything into the solution** 1. Code and unit test GUI layer \~ 14hrs 2. Code and unit test Logic layer programs \~ 8hrs 3. Perform all system-level test \~ 5hrs 4. Perform User acceptance test \~ 8hrs *[Day 2 Activities]* ***Core Process 3: Discover and Understand Details*** - Do preliminary fact-finding to understand requirements - Develop a preliminary list of ***use cases*** and a ***use case diagram*** - Develop a preliminary list of ***classes*** and ***class diagram*** *[Identify Use Cases Both Subsystems]* *[Identify Object Classes ]* A screenshot of a phone Description automatically generated *[Preliminary Class Diagram]* *[Day 3 Activities]* ***Core Process 3: Discover and Understand Details*** - Do in-depth fact-finding to understand requirements - Understand and document the detailed workflow of each use case ***Core Process 4: Design System Components*** - Define the user experience with screens and report sketches *[Use Case Diagram \~ Supplier IS]* *[Activity Diagram (Workflow)]* *[Draft Screen Layout]*  *[Preliminary Design Class Diagram]* Includes view layer classes and domain layer classes *[Subsystem Architectural Design Diagram]* *[Day 4 Activities]* ***Core Process 4: Design System Components*** - Design the database (schema) - Table design - Key and index identification - Attribute types - Referential integrity - Design the system's high-level structure - Browser, window, or smart phone - Architectural configuration (components) - Design class diagram - Subsystem architectural design *[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 system Summary of Lecture - System vision document (SVD) - Work breakdown structure (WBS) - Work sequence draft - Use cases - Use case diagram - Object classes (domain classes) - Class diagram - High level structural design (architectural design) - Database schema - Screen layout 3 -- Requirements *[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 Systems 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 supports 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 Studio/MS SQL - Reached capacity; minimal integration Retail Store System - Older packages solution; minimal integration Customer Support System (CSS) - Web based system: evolved over the years, minimal integration *[New Consolidated Sales and Marketing System (CSMS)]* Sales Subsystem - Integrates online, phone, and retail stores 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 *[System Analysis Activities]* The New Consolidated Sales and Marketing Systems (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, - Planning the project To get to the heart of systems analysis details of project planning activities are omitted A close-up of a diagram Description automatically generated **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, importance, vs. nice to have **Develop User-Interface Dialogs** - Flow of interaction between user and system **Evaluate Requirements with Users -- Requirements Baseline** - User involvement, feedback, adapt to changes *[What are Requirements]* - A statement provided by a stakeholder about what they believe they need in order to solve a particular business problem or respond to a specific business need ***System Requirements*** = - Functional requirements - Non-functional requirements ***Functional Requirements*** -- the activities the system must perform - Business uses, functions the users carry out ***Non-Functional Requirements*** -- other system characteristics - Constraints and performance goals *[FURPS+ Requirement Acronym]* **F**unctional requirements **U**sability requirements **R**eliability requirements **P**erformance requirements **S**ecurity 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]* ***Stakeholders*** -- persons who have an interest in 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 Summary Systems analysis involves defining system requirements -- functional and non-functional Analysis activities include - Gather detailed info - Define reqs. - Prioritize reqs. - Develop user-interface dialogs - Evaluate reqs. with users FURPS+ is the acronym for functional, usability, reliability, performance, and security reqs. Stakeholders are the people who have interest in the success of the project. There are internal vs. external stakeholders and operational vs. executive stakeholders **Scope creep (i.e., user requests for additional features and functions). Scope creep happens because users sometimes have many unsolved problems, and the system investigation may be the first time anybody has listened to their needs. How do you keep the system from growing and including new functions that should not be part of the system?** *[The Role of the Systems Analyst]* *Analyst's Approach to Problem Solving* *[Knowledge and Skills: Required of a System Analyst]* Summary - A system's analyst is someone who solves business problems by using information systems technology - Problem solving means looking into the problem in great detail, understanding everything about the problem, generating several alternatives for solving the problem, and then picking the best solution - Information systems are usually part of the solution, and information systems development is much more than writing programs - A system is a collection of interrelated components that function together to achieve some outcome - Information systems components can be thought of as a subsystem that interact or as hardware, software, inputs, outputs, data, people, and procedures - Many different types of systems solve organizational problems, including customer relationship management systems, supply chain management systems, human resource management systems, manufacturing managements systems, accounting and financial management systems - A system analyst needs broad knowledge and a variety of skills, including technical, business, and people knowledge and skills 4 -- Requirements II *[How to Identify Requirements]* - We call it "information gathering" - Important to be as **specific** and **clear** as possible as the entire system will be based on the information that is gathered at this stage - In order to gather "good" information about the system, there are specific methods (techniques) that can be followed - A good **Business Analyst** is one who can **gather specific, detailed, relevant** requirements about a systems, and is able to **document** those properly for Systems Designers/Developers *[Information Gathering/Requirements Elicitation Techniques]* 1. **Interviewing** users and other stakeholders 2. Distributing and collecting **questionnaires** 3. **Reviewing** inputs, outputs, and documentation/document analysis 4. **Observing** and **documenting** business procedures 5. **Researching** vendor solutions 6. **Collecting** active user **comments** and suggestions *[1. 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 Note: Can use JAD (Joint Application Development) session (When number of stakeholders are significantly large) *[Joint Application Development (JAD) Session/Workshop]* - Very common technique in business analysis world - It brings system developers and users together in a productive and creative environment through a structured approach that involves discussion groups with the goal to obtain requirements and specifications - **Ultimate purpose of JAD** is to **include the client** in the development process and **develop a more satisfactory end-product** that will meet the client's needs more efficiently - JAD allows clients to have **full autonomy** in project development and allows them to **participate** in their application's development through a series of workshops - JAD is a special type of a group meeting in which all (most) users meet with an analyst at the same time - Users jointly define and agree upon system requirements or design dramatically reducing the design time *[Advantages of JAD]* - JAD allows you to resolve difficulties more simply and produce better, error-free software - The joint collaboration between the company and the clients lowers all risks - JAD reduces costs and time needed for project development - Well-defined requirements improve system quality - Due to the close communication, progress is faster - JAD encourages the team to push each other to work faster and deliver on time *[Themes for Information Gathering Questions]* Theme: What is the information that you would like to get? For each theme, identify questions that will get you the information you need A table with text on it Description automatically generated *[Preparing for the Interview]*  *[Interview Session Agenda]* A screenshot of a discussion Description automatically generated *[Distribute and Collect Questionnaires]*  *[Review Inputs, Outputs, and Procedures]* A close-up of a form Description automatically generated *[Additional Techniques]* ***Observe and Document Business Procedures*** - Watch and learn - Document with **activity diagram** ***Research Vendor Solutions*** - See what others have done in 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  *[Defining. Requirements]* - Once information is gathered, requirements should be defined in order to properly document what the system should accomplish - To define requirements, there are several different ways to document them - The **most common way to define requirements** is through the **creation of models** *[Models and Modeling]* **Model** -- a representation of some aspect of the system being build **Types of Models** - Textual model -- something written down, described - Graphical models -- diagram, schematic - Mathematical models -- formulas, statistics, algorithms **Unified Modeling Language (UML)** - Standard graphical modeling symbols/terminology used for information systems *[Reasons for Modeling]* - Learning from the modeling 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]* A diagram of a car Description automatically generated *[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]* A diagram of a warehouse Description automatically generated *[Activity Diagram with Concurrent Paths]*  Summary of Lecture - Information gathering techniques are used to collect information about the project - Interviews, questionnaires, reviewing documents, observing business processes, researching vendors, comments and suggestions - UML Activity Diagram is used to document (model) workflows after collecting information - Models and modeling are used to explore and document requirements - Unified Modeling Language (UML) is the standard set of notations and terminology for information systems models 5 -- Use Cases Slides *[User Stories]* - Describes the **type of user, what they want,** and **why** - Template for user story description is: **As a \ I want to \ so that \** Q: What are the 3 elements of a user story? *role, goal, benefit, who, what, why* - Sentence for [acceptance criteria] is: **\\\** *[Use Cases]* - Use cases define **functional requirements** which are essentially the business rules/logic - **Two techniques for identifying use cases:** *user goal technique, event decomposition technique* *User Goal Technique* - Most common technique - **Identify** all the potential categories of **users** of the system - Interview/ask to describe **tasks the computer can help them with** Specific Steps: 1. **Identify** all **potential users** 2. **Classify** potential users in terms of their **functional role** (e.g. shipping, marketing, sales..) 3. **Classify** potential users by **organizational level** (e.g. operational, management, executive) 4. Interview to find a list of **specific goals** 5. **Create a list** of preliminary use cases organized by type of user 6. **Look for duplicates** w/ similar use cases \~ eliminate redundancy) 7. Identify where different types of users need same use cases 8. Review completed list *Event Decomposition Technique* - More **comprehensive** & complete technique \~ **identify** the **events** that occur to which the **system must respond** **Event:** occurs at a **specific time** and **place,** can be **described**, and should be **remembered** by system *[Types of Events]* **External Event \~ outside system** e.g. customer buys a product, customer wants to know product details, customer has new address and phone, sales manager wants update on product plans **Temporal Event \~** occurs as a result of reaching a **point in time** e.g. management reports (summary/exception), operational reports (detailed transactions), internal statements and docs (including payroll), statements, status reports, bills, reminders **State Event** \~ occurs when something happens inside system; triggers some process *Benefits:* - Events are broader than user goal: capture temporal and state events - Help decompose at right level of analysis (EBP \~ elementary business process; performed by one person, one place, in response to a business event) *[Perfect Technology Assumption]* Q: What is the perfect technology assumption? Assumption that a system runs under perfect operating and technological conditions; by doing this they avoid tasks regarding system failure, which they will add controls later in design process. Q: What are three examples of events that involve system controls that should not be included initially because of the perfect technology assumption? a. Backing up a database b. User logging into the system c. Restoring the database this one Summary of Lecture: - Use cases are functional requirements the system must carry out in response to use request - 2 techniques for identifying use cases: *user goal technique & event decomposition technique* - User goal technique \~ asking users what goals they have when interacting with system - Event decomposition technique \~ identify events that occur that system must respond to - 3 types of events: external, temporal, and state events 6 -- Use Cases II Slides *[Use Cases & Brief Use Case Descriptions]* - **One sentence description** showing the **main steps** in a use case - Typically, should include **what action** the user is intending to perform, and **how data is affected internally** in the system *[Use Case Diagrams]* - **UML (unified modelling language**) model used to illustrate use cases and their relationships to actors - **Actor** \~ UML name for **end user** - **Automation boundary** -- boundary b/w computerized portion of application and users who operate it *Use Case Diagram Symbols* A diagram of a person with text Description automatically generated  *Use Case Diagrams -- The \ relationship* - Relationship b/w use cases where **one use case** is stereotypically **included within the other use case** -- like a **subroutine** A diagram of a sales system Description automatically generated - Show by a **dashed arrow w/ and open arrowhead** from the including (**base**) use case to the **included** (common part) use case \~ **labeled** w/ **\** - Used to simplify large use cases - Used to extract common parts of the behaviours of two or more use cases *[Use Case Diagram Steps]* 1. **Identify** all the **stakeholders** and **users** who benefit from seeing use case diagram 2. Determine **what each stakeholder or user needs** to review in use case diagram: 3. Select the **use cases** and **actors** to show and draw the use case diagram 4. Name each use case diagram and note when and how the diagram should be used to review use cases w/ stakeholders and users Summary of Lecture: - Brief use case description is written for use cases - Use case diagram is the UML diagram used to show use cases and actors - Use case diagram shows actors, automation boundary, use cases that involve each actor, and the \ relationship - A variety of use case diagrams are drawn depending on the presentation needs of the analysis 7 -- Domain Class Slides *[Things in the Problem Domain]* - **Problem domain** \~ specific area of the users' business need that is **within the scope** of the new system -- e.g. inventory - "**Things"** -- items users work with when accomplishing tasks that need to be remembered -- e.g. products, sales, shippers, customers, invoices, payments, etc. - These "things" are modeled as **domain classes** or **data entities \~** call them domain classes in this course ***Two Techniques for Identifying Them*** *Brainstorming Technique* - Use a **checklist** of all usual types of things typically found and **brainstorm** to **identify domain classes** of each type  Steps: 1. Identify a **user** and a set of **use cases** 2. **Brainstorm w/ the user** to identify things involved when carrying out the use case -- things about which information should be captured by system 3. Ask questions: 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 user and stakeholders to expand brainstorming list 5. Merge results, eliminate duplicates, & compile an initial list *Noun Technique* - Identify all **nouns** that come up when the system is described & **determine** if each is a **domain class,** an **attribute,** or not something we need to remember - A technique to identify problem domain classes (things) by **finding, classifying,** and **refining a list of nouns** that come up in discussions or documents - **Popular** technique, **systematic** - Difficult identifying **synonyms** that are really attributes - Good place to start **when there are no users available** to help brainstorm Steps: 1. Using the use cases, actors, and other info. about systems -- including inputs/outputs -- identify all nouns. 2. Using other info. from existing systems, current procedures, and current reports or forms, add items or categories of information needed 3. As this list of nouns builds, refine it. Ask these questions: Decide to include \~ 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? Decide to exclude \~ 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? Research it \~ is it likely to be a specific piece of info (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 A list of information on a computer Description automatically generated *[Details about Domain Classes]* **Attribute** -- describes one piece of info about each instance of the class -- e.g. Customer has a 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 -- e.g. Customer ID identifies a customer **Compound attribute** -- 2 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.  *[Association Among Things]* - A naturally occurring relationship b/w classes (UML term) *["Association" vs "Relationship"]* - Called **association** on class diagram in UML \~ **multiplicity** is a term for the \# of associations b/w classes: 1 to 1 or 1 to many (synonym to cardinality) - Called **relationship** on ERD database class \~ **cardinality** is a term for \# 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 e.g. a customer places an order; an order is placed by a customer *[Minimum and Maximum Multiplicity]* Associations have minimum and maximum constraints - If minimum is [zero], association is **optional** - If minimum is [at least one], association is **mandatory** A list of items on a yellow background Description automatically generated *[Object Associations]* An association is a **"using"** relationship b/w 2 or more objects in which objects have their own lifetime and there is no owner. e.g. Imagine the relationship b/w a doctor and a patient. A **doctor** can be associated with *multiple* **patients** and at the same time, one patient can visit *multiple* doctors for treatment and/or consultation. Each of these objects have their own life cycle and there is no owner. *[Types of Associations]* **Binary Association** \~ associations b/w exactly two different classes -- Course Section includes Students, Members join Club **Unary Association (recursive)** \~ associations b/w two instances of the same class -- Person married to person, Part is made using parts **Ternary Association (three)** \~ n-ary association (between n) Summary of Lecture: - Focuses on modelling functional requirements as a part of system analysis - "Things" in the problem domain are identified and modelled, called domain classes or data entities - Two techniques for identifying domain classes/data entities are the brainstorming technique and the noun technique - Domain classes have attributes and associations - Associations are naturally occurring relationships among classes, and associations have minimum and maximum multiplicity 8 -- Domain Modeling Slides *[The Domain Model Class Diagram]* **Class** \~ a type of classification is 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 w/ **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** \~ several ways to create the domain model class diagram \~ 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 *[UML Domain Class Notation]* - Domain class has a **name** and **attributes** (no methods) - Class name is always **capitalized** - Attribute names are **not capitalized** and use **camelback notation** - **Compound class** names also use camelback notation *[A Simple Domain Model Class Diagram]* - A customer places zero or more orders - An order is placed exactly by one customer - An order consists of one or more order items - And order item is a part of exactly one order *[UML Notation for Multiplicity]* *[Domain Model Class Diagram Example]*  Bank w/ many branches - Note notation for the key - Note the precises notation for the attributes (camelback) - Note the multiplicity notation *[EX. Course Enrollment Model w/ an Association Class]* **Association class** -- an association that is treated as a class in a **many to many** associations b/c it has attributes that need to be remembered (such as grades) *[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 key of the attached class - In the previous example of 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 an error *[EX. Hospital Registration System]* Where is the patient's medical history remembered in this model? - Each ward has many medical histories, and each medical history is associated with a patient - Each patient has many visits, and each visit is association with a ward *[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 generalization/specialization hierarchy **Inheritance** \~ the concept that subclasses classes inherit characteristics of the more general superclass A diagram of a vehicle Description automatically generated **Abstract class** \~ a class that allow subclasses to inherit characteristics but never gets instantiated. In Italics *(Sale)* **Concrete class** \~ a class that can be instantiated **Inheritance** \~ attributes of OnlineSale are: timeOnSite, chatUse, saleDateTime, priorityCode, S&H, tax, totalAmt...  *[Generalization/Specialization:] Inheritance for the Bank w/ Special Types of Accounts* A SavingsAccount has 4 attributes A CheckingAccount has 5 attributes Note: the subclasses inherit the associations too A diagram of a bank account Description automatically generated *[More Complex Issues about Classes: Whole Part Relationships]* **Whole-part relationship \~** a relationship b/w 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 (empty diamond symbol) \~ 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 diamond symbol) \~ on an Order (w/o the Order, there are no OrderItems) \~ chip has circuits (w/o the chip, there are no circuits)  Note: this aggregation, with diamond symbol Whole part can have multiplicity symbols, too *[More on UML Relationships]* 3 types of **relationships** in class diagrams **Associate Relationships** \~ associations discussed previously, just like ERD relationships **Whole Part Relationships** \~ one class is a component or part of another class **Generalization/Specialization Relationships** \~ inheritance \*\*try not to confuse relationship w/ association Summary of Lecture: - UML class diagram notation is used to create a domain model class diagram for a system. The domain model classes do not have methods b/c they are not yet software classes - 3 UML class diagram relationships: association relationships, generalization/specialization (inheritance) relationships, whole-part relationships - Other class diagram concepts are abstract vs concrete classes, compound attributes, composition and aggregation, association classes, super classes and subclasses *[Deliverables for Sprint Review]* 1. **Project Goals, Scope, and Plan (e.g. WBS)** 2. **Initial Product Backlog:** \~ a comprehensive list of features and functionalities required for the project \~ prioritized backlog items based on initial business value and dependencies \~ documentation of backlog items accessible to the development team 3. **Project Team Setup and Roles Assignment** **\~** documentation of the assembled cross-functional team **\~** clear definition and assignment of roles and responsibilities for team members 4. A demo of your prototype (**MVP**), (if available) 9 -- State Machine Slides *[Object Behaviour -- State Machine Diagram]* **Object behaviour** consists of the various **states** and the **movement** b/w these states **State** -- a condition during an object's life when **it satisfies some criteria, performs an action,** or **waits** for an event **Transition** -- the movement of an object from one state to another A **"State machine"** is an abstract concept (a model) to identify objects behaving like a "Machine" that can be in one of many finite states https://upload.wikimedia.org/wikipedia/commons/thumb/9/9e/Turnstile\_state\_machine\_colored.svg/330px-Turnstile\_state\_machine\_colored.svg.png *[State Machine Diagram]* A **state machine** is anything that can have different states - we will refer to different states of an **object** - the **states are the different combinations of information that an object can hold** and ***not how they behave*** **Applications of a State machine Diagram** - depicting event-driven object in a reactive system - illustrating use cases scenarios in a business context - describing how an object moves through various states w/in its lifetime - showing the overall behaviour of a state machine or the behaviour of a related set of state machines **State Machine Diagram** -- diagram that shows life of an object in states and transitions **Origin state** -- off state **Designation state** -- on state **Pseudostate** -- nothing is really happening at this state, starting point **Action-expression** -- some activity that must be completed as a part of a transition ex. Laptop off, press on, not automatically available for use so it performs bootstrapping first, completing transition from off to on **Guard-condition** -- a true/false test to see whether transition can fire \~ safety measure  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 *[Composite States]* **State containing other states and transitions** Printer can be On and either Idle or Working *[Concurrent Paths]* Multiple paths in composite state - printer On paths are independent A diagram of a software development process Description automatically generated - concurrent paths often shown by **synchronization bars** (same as activity diagram) *[Create a State Machine Diagram] -- Steps* 1. review class diagram & select classes that might require state machine diagrams 2. for each class, make a list of status conditions (states) 3. begin building diagram fragments by identifying transitions the 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. 8 review & test the state machine diagram for the class *[EX Bank Account]* An account begins by being active, once in the active state, the account can remain active, become overdrawn, or be closed. 10 -- Use Case Descriptions Slide *[Use Case Descriptions]* Write a *brief description* as shown  *[Brief Use Case Descriptions]* - A brief description can be used for very simple use cases - Systems to be developed is a small, well-understood application - A simple use case would normally have a single scenario and very few -- if any -- exception conditions - A brief description does not document the internal processing since for simple use cases there are few steps *[Use Case Descriptions]* - Write a *fully developed* *use case description* for more complex use cases - Typically 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 (i.e. error condition) *[Fully Developed Use Case Description]* - Use case: create a customer account *[Fully Developed Use Case Description Create customer account (part 1)]* A screenshot of a computer screen Description automatically generated *[Fully Developed Use Case Description Create customer account (part 2)]*  *[Use Case Description Details]* **Use case name** - Verb-noun **Scenario** - 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 case begins **Postconditions** - 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 - Usually, the flow of activities is the most difficult part to develop, but also assists the analyst and use to understand the requirements more deeply - Exception conditions -- where and what can go wrong *[Another Fully Developed Use Case Description]* Use case -- Ship items *[Fully Developed Use Case Description -- Ship items (part 1)]* A list of items on a white background Description automatically generated *[Fully Developed Use Case Description -- Ship items (part 2)]*  *[Activity Diagrams for Use Cases]* - Activity diagrams were introduced earlier as a technique for documenting user workflows - They are easily understood diagram to document the workflows of the business processes - Here we will use them to model processing as well - Activity diagrams are also an effective technique to document the flow of activities within a use case - They are helpful when the flow of activities for use case is complex *[UML Activity Diagram for Use Case]* Create Customer Account Note: this shows flow of activities only A diagram of a credit card Description automatically generated *[UML Activity Diagram for Use Case]* Fill shopping cart Note: this shows use case with \ relationship  Summary of Lecture - Focuses on models to provide details of use cases - Fully *developed use case descriptions* provide information about each use case, including actors, stakeholders, preconditions, postconditions, the flow of activities and exceptions conditions - Activity diagrams (first shown in Chapter 2) can also be used to show the flow of activities for a use case Lecture 11 \~ Extended Requirements Modeling *[Overview]* - ***System sequence diagrams*** (SSDs) show the **inputs** and **outputs** for each **use case** as messages - ***CRUD analysis***, which correlates (i.e. *shows the connection between)* **problem domain classes** and **use cases**, is an effective technique to ***double check that all required use cases*** have been identified - Not all use cases are modelled at this level of detail - Only model when there is **complexity** and **a need to communicate details** *[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 We revisit the Use Cases - The Domain Model did not model how Use Cases interact with the system - **System Sequence Diagrams (SSD)** model how interactions (incidents, events) unfold - Domain Model used simplified Class Diagram - SSDs use simplified Sequence Diagrams *[System Sequence Diagram (SSD) Notation]* A diagram of a system Description automatically generated *[SSD Message Examples w/ Loop Frame]*  *[Message Notation for SSD]* *\[true/false condition\] return-value := message-name (parameter-list)* - **An asterisk (\*)** indicates repeating or looping of the message - **Bracket \[\]** indicate a true/false condition. This is a test for that message only. If it evaluates 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 A close-up of a computer screen Description automatically generated *[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]* *[SSD]* SSDs are part of the Use Case analysis - Draw an SSD for a main success scenario of each use case, and frequent or **complex** alternative scenarios - SSDs allow for **black box** description of the behaviour of the system - SSDs can also be used to **illustrate collaborations between systems** (or part of the systems) *[Use Case Analysis -- CRUD Technique]* - 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]* A table with text on it Description automatically generated *[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 *[Requirements Models]* A diagram of different colors Description automatically generated *[Integrating Requirements Models]*  ***[Quick Quiz]*** Q: what are the two types of interaction diagrams? A: Sequence diagrams and communication diagrams Q: What is the difference between SSD and sequence diagram? Q: How can return values be shown for messages? A: Two ways. Either as a return value on the message, or as a return dashed line Q: What are the parts of a message syntax and what do they mean? - A: \* means repeated message, \[true/false condition\] indicates if message can "fire" or not, return-value is the data returned from the message, := equals, message-name is a descriptor of the service requested by the message, (parameter-list) is the input data sent to the destination object. Q: What does the activation life line mean? - A: It is the duration that the object is alive and processing a given received message. *[Summary]* *System sequence diagrams (SSDs)* show the inputs and outputs for each use case as messages *CRUD analysis* serves to verify that all domain classes are fully supported by the new system, i.e. have use cases to fully process all required actions Not all use cases and domain classes are modelled at a detailed level. Only model when there is complexity and a need to communicate details All of the models must be consistent and intergrate together to provide a complete picture of the requirements and specification ***Running Cases: Sandia Medical Devices*** Figure 5-22 shows a set of use cases for the patient and physician actors. A diagram of a diagram Description automatically generated - Develop an SSD for the ***View history*** use case. - Assume that the system will automatically display the most recent glucose level, which is updated at five-minute intervals by default. - Assume further that the user can ask the system to view glucose levels during a user-specified time period and that the levels can be displayed in tabular form or as a graph. ***Solution***  Lecture 12 \~ Intro to Design *[Overview]* This chapter introduces system design, and the design activities involved in systems development **Design bridges gap between requirements to actual implementation** **Objective of design is to define, organize, and structure the components of the final solution to serve as a blueprint for construction** In this chapter, an emphasis is placed on application design using OO (object-oriented) principles *[What is Systems Design?]* - **Analysis** provides the **starting point** for **design** - **Design** provides the **starting point** for **implementation** - Analysis and design results are documeneted to coordinate the work - Objective: to define, organize and structure the components of the final solution to serve as a **blueprint to construction** - How many components of design are there to build a commercial aircraft? *[Analysis to Design to Implementation]* A diagram of a design process Description automatically generated *[Two Levels of Design]* **Architectural Design** - Broad design of the overall system infrastructure - Also called ***General Design*** and ***Conceptual Design*** **Detailed Design** - Low level design that includes the design of the specific program details - Design of each use case - Design of the database - Design of user and system interfaces - Design of controls and security *[Inputs for Systems Design]* The input to design activities consists of documents and models build during earlier activities On iterative projects analysis and design activities are often done concurrently. However, the **first focus of an iteration should always be identifying and specifying requirements (i.e. analysis) and then determining solutions (i.e. design)** *[Outputs for Systems Design]* - **Design is also a model-building activity** - Design is much more oriented toward technical issues and there requires **less user involvement** and more involvement by other systems professionals - Design involves describing, organizing, and structuring the system solution - The **output is set of diagrams and documents that records various aspects of the solution system** *[Analysis Objectives vs Design Objectives]* *[Analysis Models to Design Models]*  *[Design Activities]* A diagram of software Description automatically generated *[Design Activities and Key Questions]*  *[Describe the Environment]* Two key elements in the environment **Communications with External Systems** - Message formats - Web and networks - Communication protocols - Security methods - Error detection and recovery **Conforming to an existing Technology Architecture** - Discover and describe existing architecture - Chapter 7 provides more details *[Design the Application Components]* Application component is a well-defined unit of software that performs some functions(s) Issues involve how to package components including - Scope and size -- what are the functions, boundaries, interfaces? - Programming language -- what are the accepted languages? - Build or buy -- is an acceptable version available to purchase? *[Design Activities: Design the application architecture and software]* Partition system into subsystems Define software architecture - Three layer or model-view-controller Detailed design of each use case - Design class diagrams - Sequence diagrams - State machine diagrams *[Typical Models for Defining Application Components]* Diagram of a diagram of a component Description automatically generated *[Design Class Diagram]* Detail design for two use cases: *Process New Sale* *Make payment*  *[Design Activities: Design the User Interfaces]* Dialog design begins with requirements - Use case flow of activities - System sequenced diagram Design adds in screen layout, look and feel, navigation, user experience Now we require interface design for many different environment and devices - Smartphone - Notebooks, tablets, iPads *[Design Activities: Design the System Interfaces]* Information system interacts with many other systems, internal and external - Much more integration now System interfaces connect with other systems in many different ways - Save data another system uses - Read data another system saved - Real time request for information - Software services *[Design Activities: Design the Database]* Starting with the domain model class diagram (or ERD) Choose database structure - Usually relational database - Could be ODBMS framework Design architecture (distributes, etc.) Design database schema - Tables and columns in relational Design referential integrity constraints - Foreign key references *[Design Software Classes and Methods]* AKA Detailed Design A model building activity - Design Class Diagram - Sequence Diagrams - State-Machine Diagrams *[Typical Design Class Diagram with Attributes and Methods]* A diagram of a sales flow Description automatically generated with medium confidence *[Design Activities: Design the Security and System Controls]* Protect the organization's assets Becomes crucial in internet and wireless User interface controls Application controls Database controls Network controls *[Integrity and Security Controls]*  *[Summary]* This chapter introduces the concept of Systems Design - Analysis is fact finding and modeling - Design is modeling to specify how system will be implemented - Design is bridge between analysis and implementation Activities of Systems Design - Describe the environment - Design the application components - Design the User Interface - Design the database - Design the software classes and methods *[Review Questions]* - **1. What is System Design? What is the primary objective of systems design?** - **2. What is the difference between systems analysis and systems design?** - **3. List the major elements that must be designed for a new software application.** - **What are the key questions? 13** - **What are the Inputs and outputs of Systems design? 8 - 9** - **4. List the models that are used for systems analysis. 11** - **5. List the models that are used for systems design. 11** - **6. What is the difference between user-interface design and system-interface design?** - **7. On a project that uses iterations to develop the system, in which iteration does systems design begin? Explain why.** - **8. What is the difference between architectural design and detail design? 7** - **9. Designing the security and controls impacts the design of which other elements? 24** - **10. Describe what is required for database design. 21** - **What are the** Two key elements in the environment that need to be described in System Design? 14 *[Solutions to Review Questions]* **What is the primary objective of systems design?** The objective of systems design is to define, organize, and structure the components of the final solution system that will serve as the blueprint for construction. **2. What is the difference between systems analysis and systems design?** The objective of systems analysis is to understand the needs and requirements, while the objective of design is to figure out the solution to those needs and requirements. Analysis is to understand the problem, design is to solve the problem. (and implementation is to build the solution.) **3. List the major elements that must be designed for a new software application.** From figure 6-1 the elements that must be designed include: --- The application software --- The database --- The user interface --- The network and environment --- The security and controls --- The system interface List the models that are used for systems analysis. Analysis models include - Class diagrams - Use case diagrams - System sequence diagrams - Use case descriptions - Activity diagrams - State machine diagrams 5\. List the models that are used for systems design. Design models include - Package diagrams --- Database schema - Nodes and locations diagrams --- User-interface layouts - Design class diagrams --- Security and controls documents - Sequence diagrams --- Communication diagrams What is the difference between user-interface design and system-interface design? - **User-interface design has to do with designing the screens (and reports) that the users see and interact with. Those require substantial user input and consideration for ease of use. System-interface design has to do with those automated interfaces with other systems and tends to consist of technical specifications.** 7\. On a project that uses iterations to develop the system, in which iteration does systems design begin? Explain why. - **Adaptive projects that use iteration include analysis, design, and implementation in every iteration. So, design will begin within the first iteration. Depending on the desire result of the first iteration, the design activities may be primarily high-level structural design but may also include low-level detailed program design.** 8\. What is the difference between architectural design and detail design? - **Architectural design is sometimes called high-level design. It has to do with the overall structure and configuration of the solution system, including network, applications, databases, and how they all work together. Detailed design focuses on the internal methods and logic of the classes or modules.** **9. Designing the security and controls impacts the design of which other elements?** - Security and controls affect all other elements of the design and of the system. For example, security is required for the network. Security and controls are required to protect the database. Security and controls are required for the application software to protect from attacks as well as normal input errors. **10. Describe what is required for database design.** - The database consists of identifying those classes that are persistent (must exist between executions). It also includes defining attributes (fields), keys, indexes, and relationships between those classes. Finally, storage and throughput requirements also impact the design. Lecture 13 \~ OODesign *[Overview]* This chapter and the next focus on designing software for the new system, at both the architectural and detailed level design Design models are based on the requirements models learned in Chapters 3, 4, and 5 The steps of object-oriented design are explained The main model discussed is the design class diagram In this chapter, the CRC Cards technique is used to design the OO software The chapter finishes with fundamental principles of good OO design *[OO Design: Bridging from Analysis to Implementation]* - **OO Design**: Process by which a set of detailed OO design models are built to be used for coding - **Strength** of OO is **requirements models** from Chapters 3, 4, and 5 are extended to design models. **No reinventing the wheel** - ***Design models are created in parallel to actual coding/implementation with iteratives SDLC*** - **Agile approach says create models only if they are necessary**. Simple detailed aspects don't need a design model before coding *[Object-Oriented Program Flow]* -  A person standing next to a diagram Description automatically generated **Instantiation** - Creation of an object in memory based on the template provided by the class **Method** - The function executed within an object when invoked by a message request (method call) *[Sample Java with Methods]*  *[Sample VB.net with Methods]* A screenshot of a computer program Description automatically generated *[Analysis to Design to Implementation: Model Flow]*  *[Introduction to Design Models: Class Diagram]* A screenshot of a student\'s program Description automatically generated *[Introduction to Design Models: Sequence Diagram]*  *[Introduction to Design Models: Communication Diagram]* A diagram of a student upd controller Description automatically generated *[Introduction to Design Models: Class-Responsibility-Collaboration (CRC)]*  *[Steps of Object-Oriented Design]* **Object-oriented design** - The process to **identify** the **classes**, their **methods** and the **messages** required to **execute** a **use case** **Use case driven** - Design is carried use case by use case **Use Case Realization** - Represents **how a use case will be implemented in terms of collaborating objects** - The realizations reside within the design. By walking through a design exercise of showing how the design elements will perform the use case, the team gets confirmation that the design is robust enough to perform the required behaviour **Three paths** - **Simple** use case: use **CRC Cards** - **Medium** use case: use **Communication** Diagram - **Complex** use case: use **Sequence** Diagram A diagram of a diagram Description automatically generated *[Design Class Diagrams -- Types]* **Stereotype** a way of **categorizing** a model element by its characteristics, indicated by guillemots (\\>) - **Persistent class** a class whose objects exist after a system is shut down (data remembered) - **Entity class** a design identifier for a problem domain class (usually persistent) - **Boundary class or view class** a class that exists on a system's automation boundary, such as input window form or web page - **Controller class** a class that mediates between boundary classes and entity classes, acting as a switchboard between the **view layer** and **domain layer** - **Data access class** a class that is used to retrieve data from and send data to a database *[Design Class Stereotypes]*  *[Notation for a Design Class]* Syntax for Name, Attributes, and Methods A close-up of a list of text Description automatically generated *[Notation for Design Classes]* **Attributes** - Visibility -- indicates (+ or -) whether an attribute can be accessed ***directly*** by another object. Usually ***private (-)*** not public (+) - Attribute name -- lower case camelback notation - Type expression -- class, string, integer, double, date - Initial value -- if applicable the default value - Property -- if applicable, such as {key} - Examples: - accountNo: String{key} - startingJobCode: integer = 01 **Method Signature** - the notation for a method, contains the information needed to invoke a method **Methods** - visibility -- indicates (+ or --) whenever a method can be invoked by another object. Usually ***public (+)***, can be private if invoked within class like a subroutine - Method name -- lower case camelback, verb-noun - Parameters -- variables passed to a method - Return type -the type of the data returned - Examples: +getName(): string (what is returned is a string) -checkValidity(date): int (assuming int is a returned code) **Class level method** -- applies to class rather than objects of class (aka static method). Underline it - [+findStudentAboveHours(hours): Array] - [+getNumberOfCustomers(): Integer] **Class level attribute** -- applies to the class rather than an object (aka static attribute). Underline it. - [noOfPhoneSales: int] **Abstract class** -- class that can't be instantiated - only for inheritance. Name in ***Italics*** **Concrete class** -- class that can be instantiated  *[First-Cut Design Class Diagram]* - Proceed use case by use case, adding to the diagram - Pick the domain classes that are involved in the use case (see preconditions and post conditions for ideas) - Add a controller class to be in charge of the use case - Determine the initial navigation visibility requirements using the guidelines and add to diagram - Elaborate the attributes of each class with visibility and type - Note that often the associations and multiplicity are removed from the design class diagram as in text to emphasize navigation, but they are often left on *[Start with Domain Class Diagram RMO Sales Subsystem]* A diagram of a sales flow Description automatically generated with medium confidence *[Developing Design Classes]* **Navigation Visibility** - The ability of one object to view and interact with another object - Accomplished by adding an object reference variable to a class - Shown as an arrowhead on the association line -- customer can find and interact with sale b/c it has mySale reference variable *[Navigation Visibility Guidelines]* - **One-to-many associations** that indicate a **superior/subordinate** relationship are usually **navigated from the superior to the subordinate** - **Mandatory associations**, in which objects in one class can't exist w/o objects of another class, are usually **navigated from the more independent class to the dependent** - When an object needs information from another object, a navigation arrow might be required - **Navigations arrows may be bidirectional** *[Create First Cut Design Class Diagram]* Use Case with controller added*Create telephone sale*  *[Summary]* Designing software solves business problems by bridging the gap b/w analysis and implementation. Design of software proceeds use case by use case, sometimes called "use case driven" and the design of each use case is called use case realization. The process of design proceeds along three paths depending on the complexity of the user case. Simple use cases use CRC cards, medium complexity uses communication diagrams, complex use cases proceed with sequence diagrams. Design class diagrams include additional notation because design classes are now software classes, not just work concepts. Key issues are attribute elaboration and adding methods. Method signatures include visibility, method name, arguments, and return types. Other key terms are abstract vs. concrete classes, navigation visibility, and class level attributes and methods. Lecture 14 \~ OODesign 2 *[Quick Quiz about Design Class Modeling]* 1. What is the difference between a domain class diagram and a design class diagram? A: The domain class diagram defines the problem domain classes. It is a tool of analysis. The design class diagram defines design classes. It includes domain classes and other design classes. The detail information within the classes is also elaborated with attribute details and method names 2. what is a controller class? A: it is a class that serves as the interface between the view layer and the logic layer. 3. What are the elements of a method signature? A: method visibility, method name, method parameter list, and return type 4. What is a class level method? A: A method that works on the class level and not just an object. It often references all of the objects in a class. 5. What is navigation visibility used for? A: It identifies which classes can access the methods (API) of which other classes. If another class is 'visible' then its methods can be accessed. 6. Which way does visibility usually go in a one-to-many relationship? A: Usually from the one class to many. Often there is a superior (the one class) and a subordinate (the many class), where the superior has access to the subordinate. *[Designing with CRC Cards]* CRC Cards -- Classes, Responsibilities, Collaboration Cards OO design is about assigning Responsibilities to Classes for how they Collaborate to accomplish a use case Usually, a manual process done in a brainstorming session - 3 X 5 note cards - One card per class - Front has responsibilities and collaborations - Back has attributes needed *[CRC Cards]* A brainstorming technique for designing interactions in use cases by assigning responsibilities and collaborations for classes A **CRC card** is a card layout for a single class and identifies the class and its attributes, its responsibilities, and its collaborations, i.e. the methods in its API. *[Example of CRC Card]* A diagram of a customer Description automatically generated *[CRC Cards Procedure]* 1. Because the process is to design, or realize, a single use case, start with a set of unused CRC cards. Add a controller class (Controller design pattern). 2. Identify a problem domain class that has primary responsibility for this use case that will receive the first message from the use case controller. For example, a Customer object for new sale - Using the domain model that was developed during analysis, select one class to take responsibility. Focus only on the problem domain classes. On the left side of the card, write the object's responsibility 3. Use the first cut design class diagram to identify other classes that must collaborate with the primary object class to complete the use case. Flesh out the cards. - Other classes will have required information. List these classes on the primary problem domain card. As you identify the other classes, write their responsibilities on their cards 4. Add user-interface classes to identify inputs and outputs 5. Add any other required utility classes *[CRC Cards Suggestions]* Start with the class that gets the first message from the controller. Name the responsibility and write it on card. Now ask what this first class needs to carry out the responsibility. Assign other classes responsibilities to satisfy each need. Write responsibilities on those cards. Sometimes different designers play the role of each class, acting out the use case by verbally sending messages to each other demonstrating responsibilities on those cards. Add collaborators to card showing which collaborate with which. Add attributes to back when data is used Eventually, user interface classes or even data access classes can be added *[Example: Create customer Account]*  Controller and primary domain classes A close-up of a customer Description automatically generated Problem domain classes and user interface classes  **Adding data access classes** A screenshot of a computer Description automatically generated **Final DCD with method signatures**  *[Example: Create telephone sale]* A screenshot of a computer screen Description automatically generated *[Example: DCD for Create telephone sale]*  *[Fundamental Design Principles]* 1. **Responsibility** - A design principle that states ***that objects are responsible for carrying out system processing*** - A fundamental assumption of OO design and programming - Responsibilities include **"knowing"** and **"doing"** - Objects know about other objects (association) and they know about their attribute values - Objects know how to carry out methods, do what they are asked to do - If deciding between two alternative designs, choose the one where objects are assigned responsibilities to collaborate so as to complete tasks (don't think procedurally) 2. **Separation of Responsibilities** - AKA Separation of Concerns - Applied to a group of classes - ***"Segregate classes into packages or groups based on primary focus of the classes"*** - **Basis for multi-layer design --** - View, domain, data - **Facilitates multi-tier computer configuration** 3. **Protection from Variations** - A design principle that states that: ***parts of a system unlikely to change are separated (protected) from those that will surely change*** - Separate user interface forms and pages that are likely to change from application logic - Put database connection and SQL logic that is likely to change in separate classes from application logic - Use adaptor classes that are likely to change when interfacing with other systems - If deciding between two alternative designs, choose the one where there is protection from variations 4. **Indirection** - A design principle that states that: ***an intermediate class is placed between two classes to decouple them but still link them*** - A controller class between the UI classes and problem domain classes is an example ***see slide 9 from previous PPT*** - Support **low coupling** - Indirection is used to **support security** by directing messages to an intermediate class as in a firewall - If deciding between two alternative designs, choose the one where indirection reduces coupling or provides greater security 5. **Coupling** - *A quantitative measure of how closely related classes are linked (tightly or loosely coupled)* - Two classes are tightly coupled if there are lots of associations with another class - Two classes are tightly coupled if there are lots of messages to another class - It is best to have classes that are **loosely coupled** - If deciding between two alternative designs, choose the one where overall coupling is less 6. **Cohesion** - *A quantitative measure of the focus or **unity of purpose** within a single class (high or low cohesiveness)* - One class has low cohesiveness if all of its responsibilities are consistent and make sense for purpose of the class (a customer carries out responsibilities that naturally apply to customers) - One class has low cohesiveness if its responsibilities are broad or makeshift - It is best to have classes that are **highly cohesive** - If deciding between two alternative designs, choose the one where overall cohesiveness is high *[Summary]* CRC Cards technique can be used to design how the classes collaborate to complete each use case. CRC stands for Classes, Responsibilities, and Collaborations. Once responsibilities are assigned to classes, the design class diagram is updated by adding methods to classes and updating navigation visibility. Decisions about design options are guided by some fundamental design principles. Some of these are coupling, cohesion, protection from variations, indirection, and object responsibility. Lecture 15 \~ Interaction Diagrams *[OOD with Interaction Diagrams]* CRC Cards focuses on the business logic, also known as problem domain layer of class Three layers include - View layer, - Business logic/problem domain layer, and - Data access layer Questions that come up include - How do objects get created in memory? - How does the user interface interact with other objects? - How are objects handled by the database? - Will other objects be necessary? - What is the lifespan of each object? **Use Case Realization** - The process of elaborating the detailed design for a particular use case using interaction diagrams **Communication Diagram** - A type of interaction diagram which **emphasizes the set of objects** involved in a use case **Sequence Diagram** - A type of interaction diagram which **emphasizes the sequence of messages** involved in a use case *[Use Case Controller]* - **Switchboard** between user-interface classes and domain layer classes - **Reduces coupling** between view and domain layer - a controller can be created for each use case, however, several controllers can be combined together for a group of related use cases - it is a completely **artificial class** -- an artifact - use-case controllers **provide a uniform way of coordinating actor events, user interfaces and system services** *[Interaction Diagrams]* Interaction diagrams are used to illustrate **how objects interact via messages** They are used for **dynamic object modeling** There are two common types: - **sequence** and - **communication** interaction diagrams *[Communication Diagrams]* - communication diagrams show the message flow between objects in an OO application and also imply the basic associations (relationships) between classes A diagram of a message Description automatically generated *[Understanding Communication Diagrams]* **Actor** -- the external role of the person or thing that initiates the use case **Object** -- the instantiated class objects that perform the actions (methods) to execute the use case. They receive messages and process messages **Link** -- simply connectors between objects to carry the messages **Messages** -- the requests for service with an originating actor or object and a destination object, which performs the requested service *[Message Syntax]* ***\[true/false condition\] sequence-number:*** ***Return-value: = message-name (parameter-list)*** - **true/false condition** -- determines if message is sent - **sequence number** -- notes the order of the messages - **return-value** -- value coming back to origin object from the destination object - **message-name** -- camelCase name identifier. Reflects the requested service - **parameter-list** -- the arguments being passed to the destination object Every element of a message is optional *[Example Communication Diagram:]* ***Create customer account use case***  *[OOD with Communication Diagrams]* First-cut DCD for *Create customer account* use case A diagram of a server Description automatically generated *[OOD for Create Customer Account]* Input model -- SSD  *[OOD Steps for Creating Communication Diagrams]* Extend input messages 1. From the DCD put objects on communication diagram 2. For each message, find primary object, ensure visibility, elaborate use case with all messages between objects 3. Name each message and add all required message elements *[OOD with Communication Diagrams]* *createNewCustomer* message extended to all objectsA computer screen shot of a computer Description automatically generated *enterAddress* message extended to all objects  *enterAccount* message extended to all objects A diagram of a computer Description automatically generated ***Final communication diagram with all messages***  *[OOD with Communication Diagrams]* Updated DCD A diagram of a customer account Description automatically generated Lecture 16 \~ Detailed OO Design *[Sequence Diagrams]* UML sequence diagrams that model the flow of logic within a system in a visual manner Sequence diagrams illustrate interactions in a kind of fence format, in which each new object is added to the right  *[Understanding Sequence Diagrams]* **Lifeline** - The dashed line under the object serves as an origin point and a destination point for messages **Activation Lifeline** - The vertical box on a lifeline which indicates the *time period* when the object is *executing based on the message* **Messages have origins and destinations** - May be on lifeline or on object box - Return values may be dashed message arrow, or on same message *[OOD with Sequence Diagrams]* 1. Same process as with communication diagram 2. Choose a use case - Input models -- activity diagram, SSD, classes 3. Create first-cut DCD 4. Extend input messages - Add all required internal messages - Origin and destination objects - Elaborate each message 5. Add other layers as desired (view, data access) 6. Update DCD *[Example: Fill Shopping Cart]* Input activity diagram - Note the activity flows that cross the system boundary A diagram of a product Description automatically generated SSD - Note the input and return messages - Note the repeating message  First-Cut DCD A diagram of a product Description automatically generated First step in addItem message. Create a cart if first item in the purchase - Note true/false test, two types of return values, named objects, activation lifelines, message origins and destinations  Completion of addItem message A diagram of a customer Description automatically generated Note origin and destination objects and visibility - createCart() -- cart handler knows if first item - aCrt:=createCart() -- customer owns onlineCart - addItem() -- forwarded messages - createCartItem() -- cartItem responsible for creating itself and getting values - getPrice() -- just returns the price - getDescription() just returns description - updateQty(qty) -- initiates updates *addAccesory* message (with objects and lifelines)  *[Guidelines]* From each input message - Determine all internal messages - Determine all objects (from classes) as origins or destinations - Flesh out each message with true/false conditions, parameters and returned values *[Assumptions]* **Perfect Technology Assumption** - No logon or other technical issues **Perfect Memory Assumption** - No need to read or write data **Perfect Solution Assumption** - No exception conditions, no error handling *[Multilayer Sequence Diagrams]* Add the view layer for **input screens** to handle input messages Add **data layer** to read and write the data *[View Layer]* Example: *Add customer account* use case A diagram of a computer program Description automatically generated Partial example: *Fill shopping cart* use case  *[Data Layer]* Data layer for reading or updating existing persistent objects A diagram of a computer program Description automatically generated Data Access to instantiate a new object **-- Two methods** - Instantiate the object in memory, the object invokes the data access to get any required persistent data - Send a message to the data access object, and it obtains the required persistent data then instantiates the new object *[Instantiating a New Object]* Method 1. The instantiated object gets the data  Method 2. The data access gets the data and instantiates the object A diagram of a process Description automatically generated *[Partial Fill shopping cart with Data Access]*  *[Updated DCD]* A diagram of a customer Description automatically generated *[Class Packages]* A **package** is a namespace **that organizes a set of related classes and interfaces.** Conceptually you can think of packages as being similar to different folders on your computer You might keep HTML pages in one folder, images in another, and scripts or applications in yet another Because software written can be composed of hundreds or thousands of individual classes, it makes sense to keep things organized by placing related classes and interfaces into packages OO Programming languages such as Java,.net, have pre-established Class packages in their APIs  *[Package Diagrams]* Can be used to define formal packages such as subsystems Can be **used informally to group classes together for understanding** **Dependency relationship** - A **relationship between packages or classes within a package in which a change of the independent component may require a change in the dependent component.** Indicated by **dashed line**. Read in the direction of the arrow, i.e. A B is A depends on B Three-layer package diagram of classes Dependencies - View layer depends on Data Access Layer - SearchItemWindow depends on ProductItem - Etc. A diagram of a data flow Description automatically generated *[Implementation Issues]* -- Three Layer Design **View Layer Class Responsibilities** - Display electronic forms and reports - Capture such input events as clicks, rollovers, and key entries - Display data fields - Accept input data - Edit and validate input data - Forward input data to the domain layer classes - Start and shut down the system **Domain Layer Class Responsibilities** - Create problem domain (persistent classes) - Process all business rules with app - Prepare persistent classes for storage to the database **Data Access Layer Class Responsibilities** - Establish and maintain connections to the database - Contain all SQL statements - Process result sets (the results of SQL executions) intro appropriate domain objects - Disconnect gracefully from the database *[OOD -- review]*  - First-cut DCD - Extend use case with Communication Diagram - Final DCD - Package diagram Summary of Lecture This chapter went into more detail about use case realization and three-layer design to extend the design techniques from last chapter Three-layer design is an architectural design pattern, part of the movement toward the use of **design principles and patterns** Use case realization is the design of a use case, done with a design class diagram and interaction diagrams. Using interaction diagrams allows greater depth and precision that using CRC cards. Use case realization proceeds use case by use case (use case driven) and then for each use case, it proceeds layer by layer Starting with the business logic/domain layer, domain classes are selected, and an initial design class diagram is drawn The systems sequence diagram (SSD) from analysis is expanded by adding a use case controller and then the domain classes for the use case Messages and returns are added to the interaction diagram as responsibilities are assigned to each class The design class diagram is then updated by adding methods to the classes based on messages they receive and by updating navigation visibility Simple use case might be left with two layers if the domain classes are responsible for database access. More complex systems add a data access layer as a third layer to handle database access Lecture 17 \~ Packages and Design Patterns *[Final Topics:]* - Design Principles - Design Patterns *[Fundamental Design Principles]* 1. **Object Responsibility** - A design principle that states ***that objects are responsible for carrying out system processing*** - A fundamental assumption of OO design and programming - Responsibilities include **"knowing"** and **"doing"** - Objects know about other objects (associations) and they know about their attribute values - Objects know how to carry out methods, do what they are asked to do - If deciding between two alternative designs, choose the one where objects are assigned responsibilities to collaborate so as to complete tasks (don't think procedurally) 2. **Separation of Responsibilities** - AKA Separation of Concerns - Applied to a group of classes - ***"Segregate classes into packages or groups based on primary focus of the classes"*** - **Basis for multi-layer design --** - View - Domain, - Data - **Facilitates multi-tier computer configuration** 3. **Protection from Variations** - A design principle that states that: ***parts of a system unlikely to change are separated (protected) from those that will surely change*** - Separate user interface forms and pages that are likely to change from application logic - Put database connection and SQL logic that is likely to change in separate classes from application logic - Use adaptor classes that are likely to change when interfacing with other systems - If deciding between two alternative designs, choose the one where there is protection from variations 4. **Indirection** - A design principle that states that: ***an intermediate class is placed between two classes to decouple them but still link them*** - A controller class between UI classes and problem domain classes is an example - Support **low coupling** - Indirection is used to **support security** by directing messages to an intermediate class as in a firewall - If deciding between two alternative designs, choose the one where indirection reduces coupling or provides greater security 5. **Coupling** - *A quantitative measure of how closely related classes are linked (tightly or loosely coupled)* - Two classes are tightly coupled if there are lots of associations with another class - Two classes are tightly coupled if there are lots of messages to another class - It is best to have classes that are **loosely coupled** - If deciding between two alternative designs, choose the one where overall coupling is less 6. **Cohesion** - *A quantitative measure of the focus or **unity of purpose** within a single class (high or low cohesiveness)* - One class has high cohesiveness if all of its responsibilities are consistent and make sense for purpose of the class (a customer carries out responsibilities that naturally apply to customers) - One class has low cohesiveness if its responsibilities are broad or makeshift - It is best to have classes that are **highly cohesive** - If deciding between two alternative designs, choose the one where overall cohesiveness is high *[Summary]* CRC Cards technique can be used to design how the classes collaborate to complete each use case. CRC stands for Classes, Responsibilities, Collaborations Once responsibilities are assigned to classes, the design class diagram is updated by adding methods to classes and updating navigation visibility Decisions about design options are guided by some fundamental design principles. Some of these are coupling, cohesion, protection from variations, indirection, and object responsibility *[Design Patterns]* Design patterns became widely accepted after the publication of *Elements of Reusable Object-Oriented Software*, (1996) by Gamma et al (the "Gang of Four") - A **Design pattern** is a general repeatable solution to commonly occurring problem in software design - A design pattern isn't a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situationis - Design patterns can speed up the development process by providing tested, proven development paradigms - Effectiv