Systems Analysis and Design Midterm 1

Chapter 1: Introduction to Systems and Analysis and Design

- Systems Development Life Cycle (SDLC): the process of understanding how an

information system (IS) can support business needs by designing a system, building it,
and delivering it to users.
- 4 fundamental phases, each phase is composed of a series of steps, which rely
upon techniques that produce deliverables (specific documents and files that
provide understanding about the project).
- Each phase refines and elaborates on the work done previously
- Planning
- The fundamental process of understanding why an information system
should be built and determining how the project team will go about
building it.
- (1): project initiation, the system’s business value to the organization is
identified.
- System request: presents a brief summary of a business need, and it
explains how a system that supports the need will create business
value.
- Project sponsor that generated the system request works with IS
department to conduct a feasibility analysis, which is then sent to
approval committee to decide whether the project should be
undertaken.
- (2): project management, the project manager creates a workplan, staffs
the project, and puts techniques in place to help the project team control
and direct the project through SDLC.
- Deliverable is a project plan, which describes how the project team
will go about developing the system.
- Analysis
- Answers who will use the system, what the system will do, and where and
when it will be used.
- Investigates any current system(s), identifies opportunities for
improvement, and develops a concept for the new system.
- (1): analysis strategy is developed to guide the project team’s efforts.
- Analyzes as-is system (current system)
- Ways to design to-be system (new system)
- (2): requirements gathering (through interviews or questionnaires)
 - System concept is then used as a basis to develop a set of business
analysis models, which describe how the business will operate if
the new system is developed.
- (3): system proposal (includes analyses, system concept, and models) is
presented to project sponsor and decision makers to decide whether or not
to continue project
- Design
- Decides how the system will operate, in terms of the hardware, software,
and network infrastructure; the user interface, forms, and reports; and the
specific programs, databases, and files that will be needed.
- Determines exactly how the system will operate
- (1): design strategy clarifies whether the system will be developed by the
company’s own programmers, whether the system will be outsourced to
another firm, or whether the company will buy existing software package.
- (2): develop basic architecture design for the system, which describes the
hardware, software, and network infrastructure to be used.
- Interface design specifies how the users will move through the
system
- (3): database and file specifications are developed which defines exactly
what data will be stored and where it will be stored.
- (4): program design which defines the programs that need to be written
and exactly what each program will do.
- Implementation
- Longest and most expensive phase of SDLC in which the system is
actually built
- (1): system construction is where the system is built and tested
- (2): installation is the process by which the old system is turned off and
new one is turned on.
- Training plan to teach users
- (3): establishes support plan which includes a formal or informal post-
implementation review to identify changes needed
- Systems Development Methodologies
- Methodology is a formalized approach to implementing the SDLC.
- Process centered methodology emphasizes process models.
- Data-centered methodologies emphasize data models as the core of the
system concept
- Object-oriented methodologies attempt to balance the focus between
process and data both in one model.
- Structured Design (1980s)
 - Adopt a formal step-by-step approach to the SDLC that moves logically
from one phase to the next.
- Waterfall Development: analysts and users proceed in sequence from one
phase to the next.
- Deliverables are typically long and presented to project sponsor as
the project moves from phase to phase.
- Parallel Development: attempts to address the problem of long delays
between the analysis phase and the delivery of the system.
- Performs a general design for the whole system, and divides the
project into a series of distinct subprojects.
- Rapid Application Development (RAD) (1990s - early 2000s)
- Attempt to address both weaknesses of structured design methodologies
by adjusting the SDLC phases to get some part of the system developed
quickly
- Phased development-based methodology breaks an overall system
into a series of versions that are developed sequentially
- Prototyping-based methodology performs the analysis, design, and
implementation phases concurrently, and all three phases are
performed repeatedly in a cycle until the system is complete.
- System prototype, a quick-and-dirty program that provides
a minimal amount of features.
- Throwaway Prototyping: similar to prototyping
- Design prototype
- Agile Development (Today)
- Based on agile manifesto and a set of 12 principles.
- Emphasis on manifesto is to focus on the developers on the
working conditions of the developers, the working software,
customers, and addressing changing requirements.
- Extreme Programming (XP) is founded on four core values:
communication, simplicity, feedback, and courage
- User stories that describe what the system needs to do →
programmers ode simple modules to meet those needs
- Scrum: rugby term, chaos breaks out no matter how much you plan
- React to scrum → sprint until next scrum → deliver the system to
customer
- Selecting the Appropriate Development Methodology
- Clarity of user requirements
- Familiarity with technology
- System complexity
- System reliability
 - Short time schedules
- Schedule visibility
- Typical Systems Analyst Roles and Skills
- Business Analyst
- Focuses on business issues surrounding the system
- Planning and design phases, most active in analysis phase
- Systems Analyst
- Focuses on the IS issues surrounding the system
- Develops ideas and suggestions for how information technology can
improve business processes, designs new business processes
- Less in the implementation phase
- Infrastructure Analyst
- Focuses on the technical issues surrounding how the system will interact
with the organization’s technical infrastructure
- Less in planning and analysis phases
- Change Management Analyst
- Focuses on the people and management issues surrounding the system’s
installation
- Mostly Implementation phase, also analysis and design phases
- Project Manager
- Responsible for ensuring that project is completed on time and within
budget and that the system delivers all benefits intended by project
sponsor.
- All phases
- Basic Characteristics of Object-Oriented Systems
- Classes and Objects
- A class is the general template we use to define and create specific
instances, or objects.
- Every object is associated with a class.
- Object is an instantiation of a class
- Has attributes that describe information about the object
- State of the object is defined by the values of its attributes and its
relationships with other objects at a particular point in time
- Each object has behaviors that specify what the object can do
- Methods and Messages
- Methods implement an object’s behavior; an action that an object can
perform
- Messages are information sent to objects to trigger methods (procedure
call from one object to another object)
- Encapsulation and Information Hiding -interrelated
 - Encapsulation: the combination of process and data into a single entity
- Information hiding: only the information required to use a software
module is published to the user of the module
- Inheritance
- Inheritance is used to identify higher-level, or more general, classes of
objects → superclasses → subclasses
- Polymorphism and Dynamic Binding
- Polymorphism means that the same message can be interpreted differently
by different classes of objects.
- Dynamic binding: technique that delays typing the object until run-time
- Object-Oriented Systems Analysis and Design (OOSAD)
- Mostly associated with phased development RAD or agile methodology.
- Attempt to balance the emphasis between process and data by focusing the
decomposition of problems on objects that contain both data and processes.
- Use-Case Driven
- Use cases are the primary modeling tools defining the behavior of the
system
- Use case describes how the user interacts with the system to perform some
activity
- Identify and communicated the requirements for the system to
programmers
- Architecture-Centric
- The underlying software architecture of the evolving system specification
drives the specification, construction, and documentation of the system
- Functional (external) view describes the behavior of the system from the
perspective of the user
- Structural (static) view describes the system in terms of attributes,
methods, classes, and relationships
- Behavioral (dynamic) view describes the behavior of the system in terms
of messages passes among objects and state changes within an object
- Iterative and Incremental
- Undergoes continuous testing and refinement throughout the life of the
project
- Implies that the system analysts develop their understanding of a
user’s problem by building up the three architectural views
- Works with the user to create functional representation of the
system → build structural representation of the evolving system
→ create behavioral representation of the evolving system
- All architectural views of the system are interlinked and dependent
on each other
 - Benefits of Object-Oriented Systems Analysis and Design
- Enable analysts to break a complex system into smaller, more-manageable
modules, work on modules individually, and easily piece the modules
back together to form an information system.
- Basically, modularity is gr8
- The Unified Process
- Specific methodology that maps out when and how to use the various Unified
Modeling Language (UML) techniques for object-oriented analysis and design
- Two-dimensional systems development process described by a set of phases and
workflows
- Phases
- Support an analyst in developing information systems in an iterative and
incremental manner
- Describes how an information system evolves through time
- Inception phase: business case is made for the proposed system
- Technical feasibility, economic feasibility, organizational
feasibility.
- Elaboration phase: analysis and design workflows are the primary focus.
- Construction phase: focuses heavily on programming the evolving
information system.
- Implementation workflow
- Transition phase: addresses aspects typically associated with the
implementation phase of a traditional SDLC approach
- Testing and deployment workflows.
- Workflows
- Describes the tasks or activities that a developer performs to evolve an
information system over time: engineering and supporting workflows
- Engineering workflows deal with activities that produce a technical
product
- Business modeling uncovers problems and identifies potential
projects within a user organization
- Requirements workflow
- Analysis workflow addresses creation of an analysis model of the
problem domain
- Design workflow transitions the analysis model into a form that
can be used to implement the system: design model
- Implementation workflow creates an executable solution based on
the design model
- Testing workflow increase quality of evolving system
- Deployment workflow is most associated with transition phase
 - Supporting workflows focus on the managerial aspects of information
systems development
- Project management
- Configuration and change management workflow keeps track of
the state of the evolving system
- Environment workflow
- Operations and support* addresses issues related to supporting the
current version and operating the software
- Infrastructure management* support development of the
infrastructure necessary to develop object-oriented systems
- *part of the enhanced unified process
- Unified Modeling Language
- Objective was to provide a common vocabulary of object-oriented terms and
diagramming techniques rich enough to model any systems development project
from analysis through implementation.
- Current version is version 2.5 which defines a set of fifteen diagramming
techniques to model a system
- Structure diagrams provide a way to represent data and static relationships
in an information system (i.e. class and object)
- Behavior diagrams provide the analyst with a way to depict the dynamic
relationships among the instances or objects that represent the business
information system. (i.e. activity, sequence, and use-case diagrams)
- Review

Chapter 2: Project Management

- Project management is the process of planning and controlling the development of a

system within a specified time frame at a minimum cost with the right functionality.
- Project is a set of activities with a starting point and an ending point meant to
create a system that brings value to the business.
- During the inception phase of the UP of a new systems development project,
someone typically identifies some business value that can be gained from using
information technology
- Project sponsor proposes system request → performs feasibility analysis →
approval committee reviews request
- Project Identification
- Project is identified when someone in the organization within business unit or IT
identifies a business need to build a system
- Business needs can surface when the organization identifies unique and
competitive ways to use IT (for emerging technology)
 - Project sponsor is someone who recognizes the strong business need for a system
and has an interest in seeing the system succeed.
- Business need drives the high-level business requirements for the system
- Business value
- Tangible value can be quantified and measured easily (i.e. 2% reduction in
operating costs)
- Intangible value results from an intuitive belief that the system provides
important, but hard-to-measure, benefits to the organization (i.e. improved
customer service)
- System Request
- Document that describes the business reasons for building a system and
the value that the system is expected to provide
- Project sponsor completes this form as part of a formal system
project selection process within the organization)
- Five elements
- (1) Project sponsor: describes the person who will serve as the
primary contact for the project
- (2) Business need: presents the reasons prompting the project
- (3) Business requirements: business capabilities that the system
will need to have
- (4) Business value: benefits that the organization should expect
from the system
- (5) Special issues: other information that should be considered in
assessing the project
- Feasibility Analysis
- Guides the organization in determining whether or not to proceed with a project
- Identifies the important risks associated with the project that must be addressed if
a project is approved.
- Technical Feasibility
- Can we build it?
- Familiarity with function area
- Familiarity with the technology
- Project size, larger projects → more risk
- Compatibility, new technology and applications need to integrate with the
existing environment
- Economic Feasibility (critical)
- Should we build it?
- Cost-benefit analysis which identifies the financial risk associated with the
project
 - Determined by identifying costs and benefits associated with the system,
assigning values to them, and then calculating the cash flow and return on
investment for the project.

- Assigning values to costs and benefits → determining cash flow →

determining NPV and ROI
- Organizational Feasibility
- If we build it, will they come?
- How well the system ultimately will be accepted by its users and
incorporated into the ongoing operations of the organization
- Strategic alignment, the fit between the project and business strategy
- Stakeholder analysis
- Project champion, high level, non-informations systems executive who is
usually the project sponsor who created the systems request.
- Organizational management support conveys to the rest of the
organization the belief that the system will make a valuable contribution
- System users ultimately use the system once it has been installed in the
organization
- Project Selection
- Once feasibility analysis has been completed, it is submitted to approval
committee who decides whether to approve the project, devline, or table it.
- Portfolio management: takes into consideration the different kinds of projects that
exist in an organization
- Maintain an optimal mix of projects based on:
- Size, cost, purpose, length, risk, scope, return on investment
- Maximize cost/benefit ratio (select projects with highest NPV)
- Limited resources require trade-offs
 - Selected projects enter the project management process
- Traditional Project Management Tools
- Aid in creating workplans
- Identify all tasks, their sequence, and estimate the time to complete each one
- Work Breakdown Structures (WBS): a hierarchy of tasks to identify
- Duration of each task
- Current status of each task
- Task dependencies (shows which tasks must be completed before others
can begin)
- Gantt Chart
- Horizontal bar chart that shows the WBS graphically
- Network Diagram
- Program Evaluation and Review Technique (PERT): network analysis
technique that can be used when estimation times are uncertain
- Critical Path Method (CPM): identification of the critical path taken
- Burndown rate for agile development
- Project Effort Estimation
- Estimation involves trade-offs between functionality, time, and cost
- Process of assigning projected values for time and effort
- Use cases represents a major business process that the system will perform that
benefits the actor(s) ( a role that a user of the system plays) in some manner.
- Most accurate estimates come from experience
- Use-case points are based on unique features of use cases and object
orientation
- Technical complexity factors
- Environmental factors
- Creating and Managing the Workplan
- Workplan: a dynamic and sequential list of all tasks needed to complete a project
- Approaches:
- Modify existing or completed projects
- Derive the tasks from the methodology
- Unified Process:
- Workplan is Iterative and incremental
- Tasks and time intervals follow the phases
- Different tasks executed for each workflow
- Evolutionary Work Breakdown Structures and Iterative Workplans
- Organized in a standard manner across all projects
- Created in incremental and iterative manner
- Enable the comparison of current projects to previous projects
- Unified process:
 - Workflows are decomposed along the phases
- Tasks are added as each iteration is completed
- Managing Scope
- Scope creep happens when new requirements are added to the project
- Deal with this using iterative and incremental process
- Techniques to manage project scope
- Identify all requirements at the outset
- Allow only those changes deemed absolutely necessary
- Carefully examine the impact of changes
- Delay future enhancements
- Timeboxing
- time -oriented approach that places meeting a deadline over above
delivering functionality
- Refining Estimates
- Managing Risk
- Staffing the Project
- Determining how many people are required, match skill set to required activities,
motivate the team to meet objectives, and minimize conflicts.
- Characteristics of a Jelled Team
- A team of people so strongly knit that the whole is greater than the sum of
its parts
- Low turnover rate
- Strong sense of identity
- Feeling of eliteness
- Team vs individual ownership of the project
- Team members enjoy their work
- Staffing Plan
𝑝𝑝𝑝𝑝𝑝𝑝−𝑝𝑝𝑝𝑝ℎ𝑝
- Number of people = 𝑝𝑝𝑝𝑝 𝑝𝑝 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 (𝑝𝑝 𝑝𝑝𝑝𝑝ℎ𝑝)
- 40 person-month project needs to be completed in ten months = 4
people needed
- Lines of communication increase exponentially as people are
added to a project
- subteams
- Deliverable includes:
- Number and kind of people assigned
- Overall reporting structure
- The project charter
- Motivation
- Handling Conflict
- Cohesiveness
 - Clearly defining roles
- Environment and Infrastructure Management
- Environment: choose right set of tools
- Infrastructure: document the project appropriately
- CASE tools
- Computer aided software engineering (CASE) is a category of software
that automates all or part of the development process
- Increase productivity and centralize information
- Utilize diagrams
- Standards
- Same procedures to reduce complexity
- Documentation
- Detailed information of the tasks in the Unified Process
- Review

Chapter 3: Requirements Determination

- The systems development process aids an organization in moving from the as-is system
to the to-be system
- Requirements determination is the single most critical step of the SDLC
- Changes can be made easily in this stage
- Many system failures are due to issues with requirements which is why the iterative
process of OOSAD is effective.
- Small batches of the requirements can be identified and implemented as the
system evolves over time
- Requirements Determination
 - Purpose is to convert high-level business requirements (from the system request)
into detailed requirements that can be used as inputs for creating models.
- Defining a requirement
- A requirement is a statement of what the system must do or a
characteristic it must have
- Focus on the needs of a business user → business requirements
- Developers perspective → system requirements
- Evolves into a technical description of how the system will be
implemented
- Functional: relates to process a system has to perform or data it needs to
contain
- Non-functional: relates to behavioral properties that the system must have
- performance or usability
- Requirements definition
- Straightforward text report that lists out the functional and nonfunctional
requirements in an outline format
- Provides information needed in subsequent workflows
- Defines the scope of the system
- Determining Requirements
- Creating a Requirements Definition
- Determine the types of functional and non-functional requirements
applicable to the project
- Use requirements-gathering techniques to collect details
- Analysts work with users to verify, change. And prioritize each
requirement.
- Be careful of scope creep
- Requirements that meet a need but are not within the current scope are
added to future enhancements
- Requirements definition evolve over time
- Real-World Problems with Requirements Determination
- Requirements Analysis Strategies
- Problem Analysis
- Asks users to identify problems with the current system
- Asks users how they would solve these problems
- Good for improving efficiency or ease-of-use
- Root Cause Analysis
- Focus is on cause of the problem, not its solution
- Users generate list of problems → prioritize these problems → generate
possible root causes for the problems → investigate
- Duration Analysis
 - Determine the time required to complete each step in a business
process→ compare this to total time required for entire process
- Large differences suggest problems that might be solved by integrating
some steps together
- Perform steps simultaneously in parallel
- Activity-Based Costing
- Examine cost of each step → compare to total cost of entire process
- Similar to duration analysis but applied to costs
- Informal Benchmarking
- Analyzes similar processes in other successful organizations
- Introduces ideas
- Outcome Analysis
- What does the customer want in the end?
- Focuses on understanding the fundamental outcomes that provide value to
the customers
- Technology Analysis
- Apply new technologies to business processes and identify benefits
- Develop list of important technologies → identifies how technology can
be applied → identifies how technology can benefit.
- Activity Elimination
- Eliminate each activity in a business process in a “force-fit” exercise
- Problems in requirements determination:
- Analysts may not have access to correct users
- Requirements specifications may be inadequate
- Requirements-Gathering Techniques
- Used to uncover all requirements and to build support and trust among users
- Interviews
- (1) Select interviewees and create a schedule
- (2): Design interview questions
- Open-ended leave room for elaboration
- Closed-ended questions require specific answer
- Probing follow up to learn more
- (3): Prepare for the interview
- Structured interviews with closed ended questions take more time
to prepare than unstructured interviews
- (4): Conduct the interview:
- Top-down: more specific and high-level → more broad and low-
level questions
- Bottom up: more broad and low-level questions → more specific
and high-level questions
 - (5): Post interview follow-up
- Interview report
- Prepare notes and sent to interviewee for verification
- Join Application Development (JAD)
- JAD is an information-gathering technique that allows the project team,
users, and management to work together to identify the requirements for
the system.
- Reduce scope creep and prevent the system’s requirements from becoming
too vague or too specific
- Joint user-analyst meeting hosted by facilitator
- 10-20 users
- 1-2 scribes to record the session
- Meetings can be held electronically and anonymously and held remotely
- Sessions require careful planning to be successful
- Users may need to bring documents or user manuals
- Ground rules
- Questionnaires
- A set of written questions (paper based or electronic) used to obtain
information from individuals
- (1): Select Participants:
- Use representative samples for large populations
- (2): Design the questionnaire
- Careful question selection
- More specific rather than vague and ambiguous
- (3): Administer questionnaire
- Offer incentive for good response rate
- (4): Follow-up
- Results to participants
- Thank you
- Document Analysis
- Provides information about the “as-is” system
- When user’s have to add in information to the form, this is indication that
the “as-is” system needs to be improved.
- Observation
- Checks validity of information gathered in other ways
- Behaviors may change when people are watched
- Therefore, keep a low profile and don’t interrupt/influence workers
- Don’t ignore periodic activities.
- Selecting the Appropriate Techniques
- Combination of techniques may be used
 - Document analysis and observation is ezpz
- JAD sessions are more challenging
- Alternative Requirements Documentation Techniques
- Concept Maps
- Represent meaningful relationships between concepts
- Focus individuals on a small number of key ideas
- User Stories, Story Cards, and Task Lists
- Associated with agile development methods
- Functional and non-functional requirements
- Story Cards and Task Lists
- File card with single requirement
- How much effort required to implement
- Task list is created for each requirement
- Prioritized by risk level and importance
- User Stories:
- Associated with agile development methods
- Typically captured using story cards and recorded on a task list
- Stakeholders always write the user stories
- Let users write, not developers
- Indicate estimated size of effort to implement
- Indicate priority
- Include unique identifier
- Typical format:
- As a [role] I want [something] so that [benefit]
- The System Proposal
- Combines all material created in planning and analysis; no more than a single
page
- Executive summary
- Critical information in summary form to help executives determine which
sections to read in more detail
- Review

Chapter 4: Business Process and Functional Modeling

- Business Process Identification with Use Cases and Use-Case Diagrams

- Use case diagram illustrates in a very simple way the main functions of the
system and the different kinds of users that will interact with it
- Elements of Use-Case Diagrams
- Identifying the Major Use Cases Creating a Use-Case Diagram
- Business Process modeling with Activity Diagrams
- Business process models describe the different activities that, when combined,
support a business process
- Activity diagrams are used to model the behavior in a business process
independent of objects
- Elements of an Activity Diagram
- Guidelines for Creating Activity Diagrams
- Set the scope of the activity being modeled
- Identify the activities; connect them with flows
- Identify any decisions that must be made
- Identify potential parallelism in the process
- Draw it
- Creating Activity Diagrams
- Choose a business process identified previously
- Review the requirements definition and use-case diagram
- Review documentation
- Identify activities used in business process
- Control flows and nodes
- Object flows and nodes
- Minimize crossing lines
- Business Process Documentation with Use Cases and Use-Case Descriptions
- Use cases are the primary driver for all UML diagramming techniques
- Describes 1 and only 1 function
- Depicts activities performed by the users
- Describes basic functions of the system:
- What the user can do
- How the system responds
- Building blocks for continued design activities
- Types of Use Cases
- Overview use case
- Essential use case

- Elements of a Use-Case Description

- Overview: Name → triggers
- Relationships:
- Association: communication between the use case and the actors
- Extend: extends the functionality of a use case
- Include: includes another use case
- Generalization: allows use cases to support inheritance
- Flow of events:
- Normal flow: the usual set of activities
- Sub-flows: decomposed normal flows to simplify the use-case
- Alternate or exceptional flows: those not considered the norm
- Optional characteristics
- Guidelines for Creating Use-Case Descriptions
- Clear, concise, logical
- Creating Use Case Descriptions
 - (1): pick a high-priority use-case and create an overview
- (2): fill in the steps of the normal flow of events required to complete the
use-case
- (3): ensure that the steps listed are not too complicated or long and are
consistent in size with other steps
- (4): identify and write the alternate or exceptional flows
- (5): carefully review the use-case description and confirm that it is correct
- (6): Iterate over the entire set of steps again
- Verifying and Validating the Business Processes and Functional Models
- Use-cases must be verified and validated before beginning structural and
behavioral modeling
- Utilize a walkthrough, a peer review of a product
- Perform a review of the models and diagrams created
- Facilitator (schedules and sets up the meeting), presenter, recorder
(scribe)
- Verification and Validation through Walkthroughs
- (1): ensure one recorded event in the flows for each action/activity on the
activity diagram
- (2): All objects must be mentioned
- (3): Sequence of use-case should match sequence in activity diagram
- (4): One and only one description for each use case
- (5): All actors must be shown
- (6): Stakeholders listed may be shown
- (7): All relationships must be depicted
- (8): All diagram-specific rules must be enforced
- Functional Model Verification and Validation
- Review

Chapter 5: Structural Modeling

- Structural modeling supports the creation of an internal structural or static view of a

business information system in that it shows how the business is structured to support the
underlying business processes.
- Structural Models
- A structural model is a formal way of representing the objects that are used and
created by a business system
- Goal: to discover the key data contained in the problem domain and to
build a structural model of the objects
- Drawn using an iterative process in which the model becomes more
detailed and less conceptual over time.
 - Conceptual, business-centric way → technology-centric way
describing actual databases and files → more and more detail
added in each iteration
- Create a vocabulary for analysts and users for effective communication
- Classes, Attributes, and Operations
- Classes: templates for instances of people, places, things
- I.e. box
- Attributes: properties that describe the state of an instance of a class (an
object)
- I.e volume, material
- Operations: actions or functions that a class can perform
- I.e. fill() empty()
- Relationships
- Describes how classes relate to one another
- (1) Generalization enables inheritance of attributes and operations
- Represents relationships that are “A-kind-of”
- (2) Aggregation relates parts to wholes or assemblies
- “A-part-of” or “has-parts”
- (3): Association are miscellaneous relationships between classes
- Weaker form of aggregation
- Object Identification
- Textual Analysis of use-case information
- Nouns suggest classes
- Verbs suggest operations
- Creates a rough first cut to provide an object list
- Brainstorming people offering ideas
- Initial list of classes (objects) is developed
- Attributes, operations and relationships to other classes can be assigned in
a second round
- Common Object Lists
- Physical things, incidents, roles, interactions
- Patterns
- Useful groupings of collaborating classes that provide solutions to
common problems (are reusable)
- Developed patterns provide a starting point for work in similar domains
- Class-Responsibility-Collaboration (CRC) cards
- Used to document the responsibilities and collaborations of a class
- Responsibilities and Collaborations
- Responsibilities:
- Knowing: what a class must know manifested as attributes
 - Doing: what a class must do manifested later as operations
- Collaboration:
- Objects working together to service a request
- Requestor (client)
- Responder (server)
- Bound by contract

- Elements of a CRC card

- Role-Playing CRC Cards with Use Cases
- Help discover additional objects, attributes, relationships, and operations
- Utilize activity diagrams to run through the steps in a scenario
- Class Diagrams
- A static model that shows classes and their relationships to one another
- Elements of a Class Diagram
- Multiplicities:

- Simplifying Class Diagram

- Show only concrete classes
- View mechanism shows subset of classes
- Packages show aggregations of classes
 - Object Diagrams
- Class diagrams with instantiated classes
- Used to discover additional attributes, relationships, and/or operations or
those that are misplaced

- Creating Structural Models Using CRC Cards and Class Diagrams

- (1): Create CRC cards
- (2): review CRC cards
- (3): Role-Play the CRC Cards
- (4): Create Class Diagram
- (5): Review Class Diagram
- (6): Incorporate Patterns
- (7): Review the Model
- Campus Housing example
- Library example
- Verifying and Validating the Structural Model
 - Review

Homework 1
Homework 2
Homework 3
Homework 4