OOSAD Chapter5 (2024)

Object Oriented System
Analysis and Design

(OOSAD)
INSY3063
5/14/2024 Prepared by Meseret Hailu(2024) 1

Chapter V:
Determining what to
Build: OO Analysis
(OOA)

Chapter 5:Determining what to Build: OO Analysis (OOA)
5.1.The focus of OOA
5.2. System Use Case Modeling
5.3. Sequence Diagrams: From Use Cases to Classes
5.4. Activity diagramming
5.5. Conceptual Modeling :Class diagrams
5.6. User interface prototyping
5.7. Evolving your supplementary specification
5.8. Applying Analysis Patterns Effectively
5.9. Remaining Agile
5.10. User Stories
5.11. System User Stories?
Objectives
 Identify the focus of OOA
 To build System Use Case Model
 Practice building Sequence Diagrams, Conceptual Modeling :Class

diagrams, Activity diagramming and User interface prototyping
 Identify which modeling is structured and behavioral modeling
 From structured modeling identify static and dynamic modeling
 Identify the difference between User Stories and System User Stories

End-to-end EUC and EUI prototyping
approach
 End-to-end EUC and EUI prototyping approach

Work Breakdown Structure (WBS)
 Work Breakdown Structure (WBS) represents the project as a hierarchical

organization of tasks

The focus of OOA
 The focus of Object-Oriented Systems Analysis

 Analysis is the process of identifying problems, conceptual solutions, and their related
concepts in the problem space (or problem domain).
 "OOSA“ is a method used in software development process for analyzing and designing
systems. The focus of Object-Oriented Systems Analysis typically includes:
1. Object-Oriented Concepts: Understanding and applying concepts like classes, objects, inheritance,
polymorphism, and encapsulation.
2. Requirements Analysis: Identifying and documenting user requirements for the system. This involves
understanding what the system needs to do and how users will interact with it.
3. Use Case Modeling: Describing system functionalities in terms of use cases, which represent interactions
between users and the system to achieve specific goals.
4. Behavioral Modeling: Capturing the dynamic behavior of the system, including interactions between
objects, using tools like sequence diagrams, state diagrams, and activity diagrams.

The focus of OOA
 The focus of Object-Oriented Systems Analysis

5. Structural Modeling: Describing the static structure of the system, including classes, relationships between
classes, and the attributes and methods of classes, using tools like class diagrams.
6. Analysis and Design: Analyzing requirements and creating a design that fulfills those requirements using
object-oriented principles.
7. Verification and Validation: Ensuring that the system meets the specified requirements through testing and
validation processes.
 Overall, the focus of Object-Oriented Systems Analysis is on understanding user requirements, designing a
system that fulfills those requirements using object-oriented principles, and ensuring that the system
behaves as expected.

System Use Case Modeling
 System Use Case

 System use case modeling is a technique used in Information system to capture the
functional requirements of a system from the perspective of its users.
 It helps in understanding how users interact with the system to accomplish
specific goals or tasks. Here's an overview of the key concepts and steps involved
in system use case modeling:
1. Identify Actors: Actors are entities outside the system that interact with it to achieve
certain goals. They can be human users, other systems, or external entities.
 Identify all the actors involved in the system and categorize them based on their
roles and responsibilities.

 System Use Case

2. Identify Use Cases: A use case represents a specific functionality or behavior of the
system that provides value to its actors. Use cases describe the sequence of steps or
interactions between actors and the system to achieve a particular goal. Identify and
define use cases based on the requirements gathered from stakeholders.
3. Create Use Case Diagrams: Use case diagrams provide a graphical representation
of the actors, use cases, and their relationships in the system.
 Actors are represented as stick figures, while use cases are depicted as ovals with names
describing the functionality they represent.
 Use case diagrams help in visualizing the overall system functionality and its interactions
with actors.

 System Use Case

3. Document Use Case Specifications: For each use case, document detailed
specifications describing its preconditions, postconditions, main flow of events,
alternate flows, and exceptions.
 Use a structured format such as a use case template to ensure consistency and
clarity in the documentation.
4. Identify Relationships Between Use Cases: Analyze the relationships between
different use cases to identify dependencies, associations, and extensions. Use
techniques such as include relationships (where one use case includes the
functionality of another) and extend relationships (where one use case extends the
behavior of another).

 System Use Case

5. Prioritize Use Cases: Prioritize use cases based on their importance, criticality, and
impact on the system and its stakeholders. This helps in focusing on the most
essential functionalities during development and ensuring that the system delivers
value early in the development process.
6. Validate with Stakeholders: Review and validate the use case model with
stakeholders to ensure that it accurately represents their requirements and
expectations.
 Gather feedback and make any necessary revisions or refinements to the model based on
the feedback received.

 System Use Case

7. Iterate and Refine: Use case modeling is an iterative process, and the use case
model evolves over time as more information becomes available and the system
requirements are refined. Continuously iterate and refine the use case model
throughout the development lifecycle to ensure that it remains up-to-date and
aligned with the evolving needs of the stakeholders.
 By following these steps, system use case modeling helps in eliciting, organizing,
and documenting the functional requirements of the system in a structured and
systematic manner, laying the foundation for the design and implementation
phases of software development.

 System Use Case

 The template will be the same as the essential use case documentation except
that the “Include” and “Extend” part will be exercised (included) at this
level.
 Typical System Use Case diagram - University Registration

 System Use Case


Enroll in <<include>>
Enroll in
Registrar
University Course
<<extend>>
Applicant
Perform Enroll Family

Security Check Member of Staff
International Applicant
RCMP Security System

 System Use Case Template

System Use Case Description
 An Example of System Use Case Description
Name Sell Item
Identifier UC-008
Description Sell available items in a store to a customer
Actor Sales Clerk
Pre Condition None
Post Condition The sales clerk will sell the item if available in store
Extends none
Includes UC-001
Basic Course of Action
1.The Sales Clerk want to sell an item
2.The Sales Clerk logs into the system using “UC-001: Login”
3.The system displays the main Window “UI-002: Main Menu”
4.The Sales Clerk selects “Sell” from the Main Menu
5.The system displays the Sell interface “UI-006: Sell Item”
6.The Sales Clerk selects the items and quantity he want to sell
7.The system check the availability of the items according to the business rule “BR-012: check availability of item”
8.The system displays the total amount of money to be paid with the item list via “UI-013: Payment Voucher”
9.The Sales Clerk indicates he want to print the payment voucher.
10.The system prints the payment voucher
11.The use case ends when the Sales clerk receive the money and give the payment voucher to customer.
Alternative Course of Action A: The item is not available in store

A.8. The system determines that the item is not available.
A.9. The system informs the Sales Clerk that the transaction can not be completed via “UI-014: Item Quantity not
Available”
A.10.The use cases resumes at step 6 of the basic course of action
Essential Use Case Modeling
 Developing Use Cases(Behavioral Modeling )

 Uses of Use Case Modeling: A Framework for Development

Sequence Diagram
 A sequence diagram(One of Dynamic Modelling)

 Sequence diagrams are a type of interaction diagram that illustrates the
sequence of messages exchanged between objects or components in a system
to accomplish a specific task or scenario.
 They provide a dynamic view of the system's behavior, focusing on the
interactions between objects over time.

Sequence Diagram
 A Here's an overview of the key components and elements of sequence diagrams:

1. Objects(Participants ): Represented by boxes along the top of the diagram, objects are
instances of classes or components participating in the sequence of interactions.
 Each object is labeled with its name and optionally its class type. visually using
different notations.
 the name of an object may be written(underlined) in any of the three following
forms: ( mind the capitalizations)
 objectName Object name only
 :ClassName Object class only(anonymous object)
 objectName :ClassName Object name and class name
Optionally, stereotypes for objects are indicated textually as
<<stereotype*>>
Sequence Diagram

2. Lifelines: Vertical dashed lines extending from each object's box represent the lifespan of
the object during the sequence.
 They show the period of time over which the object exists and can send or receive
messages.
 Most objects will be in existence for the duration of the interaction
 Objects may also be created, or destroyed during the interaction.
3. Messages: Horizontal arrows between lifelines represent messages exchanged between objects.
 Messages can be synchronous (denoted by solid arrows), asynchronous (denoted by dashed
arrows), or self-referential (looping back to the same object).
 They indicate the flow of control or data between objects.
 Messages show the actions that objects perform on each other and on themselves.

Sequence Diagram

4. Activation Boxes: Optional rectangular boxes along the lifelines represent the period
during which an object is active or processing a message. They show when an object is
actively executing a method or operation.
5. Return Messages: Messages sent in response to a received message are shown as dashed
lines with an open arrowhead. They indicate the return value or response from the
recipient object to the sender.
 A focus of control, which is a tall thin rectangle that sits on top of an object’s
lifeline
 It shows the period of time during which an object is performing an action,
either directly or through subordinate procedure
 The bottom part of a focus of control can be marked by a return message

Sequence Diagram

6. Optional Elements: Sequence diagrams may also include optional elements such as
loops, conditions, and parallel execution regions to represent more complex interactions.
7. Focus on Time: Sequence diagrams emphasize the chronological order of message
exchanges between objects, helping
8. Interaction Fragments( Interaction details):
 Represented by different types of boxes (such as alt, opt, loop, etc.), interaction
fragments provide additional structure to sequence diagrams, allowing for the
representation of alternative paths, optional behaviors, loops, and other complex
scenarios.

Sequence Diagram

 Sequence diagrams are valuable during the design and development phases of software
development for understanding system behavior, specifying interactions between objects,
and identifying potential design flaws or bottlenecks. They facilitate communication
among developers, designers, and stakeholders by providing a visual representation of
system dynamics and behavior.
 Sequence diagrams play a crucial role in bridging the gap between use cases and classes
in software development, providing a visual representation of interactions between objects
or components during runtime.

Sequence Diagram
 Here's how sequence diagrams can be used to transition from use cases to
classes:
1. Identify Use Case Scenarios: Begin by identifying the key scenarios or flows of events
described in the use cases. These scenarios represent the sequences of interactions
between actors and the system to achieve specific goals or tasks.
2. Identify Participating Objects: For each use case scenario, identify the objects or classes
that participate in the interaction. These objects represent the entities or components
within the system that collaborate to fulfill the use case requirements.
3. Map Use Case Steps to Sequence Diagram: Map the steps or actions described in the
use case scenario to sequence diagram elements, including lifelines (representing objects),
messages (representing interactions), and activation boxes (representing the time when
objects are actively processing messages).

Sequence Diagram
classes:
4. Identify Message Flows: Determine the sequence of messages exchanged between objects during
the execution of the use case scenario. Messages may represent method calls, signals, or events
triggering specific behaviors within the system.
5. Refine Object Interactions: Refine the interactions between objects based on the system's class
structure and relationships. Consider how objects collaborate to fulfill their responsibilities, invoke
methods on other objects, and exchange data to achieve the desired behavior.
6. Identify Collaborating Classes: Identify the classes corresponding to the participating objects in the
sequence diagram. These classes represent the structural elements of the system and encapsulate the
behaviors and attributes necessary to fulfill the use case requirements.

Sequence Diagram
classes:
7. Update Class Diagrams: Use the information gathered from the sequence diagrams to
update the system's class diagrams. Add or refine classes, associations, attributes, and
methods based on the identified interactions and collaborations between objects.
8. Ensure Consistency: Ensure consistency between sequence diagrams and class diagrams
by validating that the interactions depicted in the sequence diagrams align with the class
structure and relationships defined in the class diagrams.
9. Iterate and Refine: Iterate on the sequence diagrams and class diagrams as needed to
incorporate feedback, address design complexities, and refine the system's architecture.
Continuously refine the design based on evolving requirements and design decisions.

Sequence Diagram
classes:
10. Document and Communicate: Document the sequence diagrams and class diagrams to
communicate the system's behavior and structure to stakeholders, developers, and other
project team members. Use these diagrams as visual aids to facilitate discussions, clarify
requirements, and guide implementation efforts.
 By leveraging sequence diagrams to transition from use cases to classes, software
development teams can effectively translate high-level user requirements into detailed
system designs, ensuring that the resulting software system meets the desired
functionality and quality standards.

Sequence Diagram
 A sequence diagram
 You can build either a sequence diagram or
collaboration(communication) diagram from the use-case and classes
(CRC) identified before.
 Each use cases in a use-case diagram has its corresponding sequence
or collaboration diagram
 You model the diagrams from the main flow of events, or the
alternate flow of events, or the scenarios, of each use case
 Every object that you have identified in the sequence or
collaboration diagram, MUST have its corresponding class in the
class diagram

Sequence Diagram
 A sequence diagram has four key elements: -

Sequence Diagram

Sequence Diagram

Sequence Diagram

Sequence Diagram

Sequence Diagram
 A sequence diagram  Messages are the

means by which
objects interact
with each other
and with the
outside world.
 What an object
does (or
operations) is
defined by the
class; how the
Figure
operations are
carried out is
decided by their
implementation
(or methods)

Sequence Diagram
Message Operation
The sender of the Parameters are
message must containers (or
provide a variables) filled
container for the by the values
return value. from the
message.

Sequence Diagram
 Make Appointment: Sequence Diagram( Dynamic Diagram)

Sequence Diagram
 A sequence diagram for the Automated Trading House System

Sequence Diagram
 A sequence diagram
 Sequence diagrams are commonly used during the analysis and design phases of software
development to visualize and validate the dynamic behavior of a system.
 They help in understanding how objects collaborate to fulfill specific use cases or
scenarios, identifying potential issues such as message sequencing errors or deadlocks,
and communicating system behavior to stakeholders and developers.
 When creating sequence diagrams, it's important to focus on capturing the essential
interactions and message flows without getting bogged down in unnecessary detail.
 They should be clear, concise, and aligned with the system's requirements and design
objectives.

Activity Diagram
 Activity Diagram
 A use case is a flow of activity in words. If the flow is simple and linear, it can
be understood on its own.
 If the flow is complex and iterative, words will not suffice.
 In a model-driven development process, however, no one model has to
stand alone.
 Where words fail us, an activity diagram can paint a clearer picture.
 Activity diagram is the tool that UML provides for business process modeling.
 Activity diagram is a flexible tool and its application is not limited to use
cases.

Activity Diagram
 It can be attached to any dynamic model or to any operation whose flow needs
clarification.
 The level of detail that an activity diagram reveals or hides is mostly up to us.
 To keep the diagram clear, we can hide a set of activities in a placeholder and
expand it in another diagram if and when the need arises.
 Make Appointment for example has one activity, labeled Find Patient, that the
use case assumed would be understood as a part of the process.
 However, we have made it explicit in the activity diagram to clarify the decision
point that follows it:
 Is the patient a new one or an old one?
Activity Diagram
 To keep it clear, we have avoided exposing the logic inside the activity. (We
may need an activity diagram for Find Patient at a later stage.)
 In the same manner, the activity Create Patient hides an extending use case with
the same name, called from an alternate step in Make Appointment.
 If the flow of a use case is too complex for one clear activity diagram, we may
use the technique of hiding a set of activities under a label and expanding it
in another diagram.
 Activity Diagrams are the most popular form of dynamic modeling, and for a
good reason: They are the best in representing the complexities of logical flow

Activity Diagram
 Before we do this, however, we should ask whether the flow is not too complex
by itself.
 The activity diagram has few elements.
 With a little care in what to show and the careful labeling of what is shown,
 it can be an effective means of communication between development
stakeholders, technical or nontechnical alike.

Activity Diagram

Activity Diagram
 Example of an
Activity
Diagram
 The Logical Flow
of Make
Appointment

Activity Diagram
 Activity Diagram for ATM machine

Activity Diagram
 Summary
 Activity diagramming is a modeling technique used in software engineering and
business process management to represent the flow of activities or actions within a
system or process.
 It is part of the Unified Modeling Language (UML) and provides a graphical
representation of workflows, business processes, or use cases.
 Here are some key points about activity diagramming:
1. Visual Representation: Activity diagrams use a set of standardized symbols and
notation to represent activities, decisions, transitions, and concurrency within a
system or process. These diagrams provide a visual representation that is easy to
understand and communicate among stakeholders.

Activity Diagram
 summary
2. Activities and Actions: In an activity diagram, activities represent the units of work or actions that
are performed within the system or process. These activities are typically represented as rounded
rectangles. Actions, which are the specific steps or tasks within an activity, are depicted as
rectangles within the activity.
3. Control Flow: Activity diagrams show the flow of control between activities through directed
arrows or transitions. These transitions indicate the sequence in which activities are performed and
can include conditions, such as decision points (diamond shapes), which determine the path of
execution based on certain criteria.
4. Concurrency and Parallelism: Activity diagrams can depict concurrent activities, where multiple
actions occur simultaneously. Fork and join symbols are used to represent parallel execution paths,
allowing for the modeling of concurrent processes within a system.

Activity Diagram
 Summary
5. Swimlane: Swimlanes are used to organize activities based on the roles or responsibilities of
different actors or system components. Each swimlane represents a distinct participant in the
process, and activities within the swimlane indicate the tasks performed by that participant.
6. Tool Support: Various software tools support the creation and manipulation of activity diagrams,
ranging from specialized UML modeling tools to general-purpose diagramming software.
 Activity diagramming is valuable for documenting, analyzing, and designing complex systems
or processes, particularly in software development, business process reengineering, and workflow
management. By providing a visual representation of activities and their relationships, activity
diagrams aid in understanding system behavior, identifying potential bottlenecks or inefficiencies,
and facilitating communication among stakeholders.

Activity Diagram
 EXERCISES
1. After reading this chapter carefully, read the narrative again and see if you can
discover additional use cases that you missed in Use Cases: The Basics.
2. Create a use case template for your course work project
3. Generalize your actors if necessary.
4. Identify “include” and “extend” use cases.
5. Generalize your use cases if necessary.

Activity Diagram
 EXERCISES
6. Create a use case diagram complete with “include” and “extend” use cases.
7. Read and try to understand what Collaboration Diagram and State Chart
Diagram.
8. Draw sequence diagrams for your course work project
9. Try to draw Collaboration Diagram and State Chart Diagram for your
course project

Structural Diagrams
 Structural Diagrams
Unit Topics
➤ Structural modeling within the
context of a conceptual information
system.
➤ Classes as building blocks of
structural modeling and objects as
units of information systems.
➤ Basic object-oriented concepts in
the context of structural modeling.
➤ Discovering class candidates by
parsing use cases.
➤ Elaborating and defining classes by
specifying and expanding their
responsibilities

Structural Diagrams
 Behavioral modeling is the starting point for modeling software, but any
system must rely on a structure that supports that behavior.
 It emphasizes the dynamic behavior of the system by showing
collaborations among objects and changes to the internal states of
objects.
 Structural modeling represents a view of the building blocks of a system
or an entity and their interrelationships within a given scope.

Structural Diagrams
 Building the Conceptual Structure: From Use Cases to Structural Modeling

Structural Diagrams
 Conceptual Modeling :Class diagrams

 Conceptual modeling using class diagrams is a fundamental aspect of object-
oriented analysis and design (OOAD) in software deployment process.
 Class diagrams are used to represent the static structure of a system, capturing
the classes, attributes, relationships, and behaviors that constitute the system's
conceptual model.
 The following is breakdown of conceptual modeling using class diagrams:

Structural Diagrams

 Conceptual modeling using class diagrams is a fundamental aspect of object-
oriented analysis and design (OOAD) in software deployment process.
 Class diagrams are used to represent the static structure of a system, capturing
the classes, attributes, relationships, and behaviors that constitute the system's
conceptual model.

Structural Diagrams

 The following is breakdown of conceptual modeling using class diagrams
1. Classes: Classes represent entities or concepts in the system being modeled. They encapsulate both
data (attributes) and behavior (methods or operations). Each class is depicted as a rectangle with
three compartments: the top compartment contains the class name, the middle compartment lists the
class attributes, and the bottom compartment lists the class methods or operations.
2. Attributes: Attributes represent the properties or characteristics of a class. They describe the state
of objects belonging to the class. Attributes are typically listed in the middle compartment of the
class rectangle.
3. Relationships: Relationships define how classes are connected or associated with each other.

Structural Diagrams

 The main types of relationships in class diagrams include:
 Association: Represents a bi-directional relationship between two classes. It can be simple or complex,
indicating the multiplicity and role names.
 Aggregation: Represents a "whole-part" relationship between classes, where one class (the whole) contains
or is composed of other classes (the parts). It is denoted by a diamond shape on the containing class end.
 Composition: Represents a stronger form of aggregation, where the parts are strongly tied to the whole and
have a lifecycle dependency. It is denoted by a filled diamond shape on the containing class end.
 Inheritance (Generalization): Represents an "is-a" relationship between classes, where one class (subclass
or child class) inherits attributes and behaviors from another class (superclass or parent class). It is depicted
using a solid line with a triangle arrowhead pointing to the superclass.

Structural Diagrams

4. Multiplicity: Multiplicity specifies the number of instances of one class that can be associated with a single
instance of another class in a relationship. It is represented using numeric values or symbols (such as "", "0..1",
"1", "1..", etc.) near the association lines.
5. Behavioral Notation: While class diagrams primarily focus on static structure, they may include behavioral
notations such as method signatures or operation details to provide additional information about the class
behaviors.
6. Constraints: Class diagrams may include constraints or rules that govern the system's behavior, such as
preconditions, postconditions, or invariant conditions, expressed using OCL (Object Constraint Language) or
natural language.
 Conceptual modeling using class diagrams is essential for understanding the domain concepts, identifying class
hierarchies, defining relationships between classes, and establishing a foundation for system design and
implementation. It serves as a communication tool among stakeholders and helps in validating system
requirements and architecture.
Structural Diagrams
 Structural modeling
Structural modeling can
have one of three aims:
1. Understanding an
existing structure.
2. Changing an existing
structure.
3. Building an entirely
new structure.
The structure of an information system must be able to

accommodate both the behavior of the system and the dynamic
interchange of the components required to support that behavior

Structural Diagrams
 Structural Diagrams(Static )
 This Diagram emphasizes the static structure of the system using objects,
attributes, operations, and relationships.
1. Class Diagram – set of classes and their relationships. Describes
interface to the class
2. Object Diagram – set of objects (class instances) and their relationships
3. Component Diagram – logical groupings of elements and their
relationships
4. Deployment Diagram - set of computational resources (nodes) that host
each component.

Structural Diagrams
 This unit explores how to arrive at classes, the basic building blocks of an
object-oriented information system, and their relationships
 It also introduces the class diagram, the most widely used tool in modeling for
object-oriented development.
 A class is:
1. An abstraction of objects.
2. A template for creating objects.
3. A building block of modeling.
 Class Diagram:- describes the structure of a system by showing the system’s
classes, their attributes, and the relationships among the classes.
 Classes are the building blocks of structural modeling and the blueprints for
objects; objects are the structural units of the actual information system

 Structural Diagrams
1. Class Diagram
 Class diagram shows a set of classes and their interrelationships. It describes
interface to the class.
 A class diagram is the most important visual tool in our modeling toolbox.
 All object-oriented development environments support it better than other
modeling tools:
 In this example, the diagram shows that one student may attend one or more courses,
while the teacher may teach one course or more.

 Structural Diagrams
1. Class Diagram

Structural Diagrams
2. Patient and Its Associations:

Structural Diagrams
3. Class Diagram

Structural Diagrams
4. Class Diagram

Structural Diagrams
5. Class Diagram
 This class diagram

models the
relationships of
the Patient class
from a different
viewpoint.
 Multiplicity
specifies how many
instances of one
class can associate
with instances of
another class.

Structural Diagrams
6. Class Diagram
 Aggregation and
Composition: How
Parts Relate to the
Whole

Structural Diagrams
 Class Diagram
 Assignment
1. Identify the possible classes of your system in the course work project
2. Draw the corresponding class diagram clearly specify the association
and the multiplicity
3. If there is any aggregation or composition try to show in your project
class diagram

User interface prototyping
 User interface prototyping
 User interface (UI) prototyping is a crucial phase in the design and development of
software applications, websites, and other interactive systems. It involves creating
mockups or prototypes of the user interface to visualize and test the layout,
functionality, and usability before proceeding with full-scale development. Here are
some key points about UI prototyping:
1. Visualization of Design Concepts: UI prototypes allow designers and stakeholders to
visualize design concepts and ideas in a tangible form. They provide a concrete representation
of the user interface, including layout, navigation, controls, and visual elements.
2. Iterative Design Process: UI prototyping is often an iterative process, where multiple iterations
of prototypes are created and refined based on feedback from users, stakeholders, and usability
testing. This iterative approach helps to refine the design, improve usability, and address
potential issues early in the development process

3. Low-Fidelity vs. High-Fidelity Prototypes: UI prototypes can be categorized as low-fidelity or
high-fidelity based on the level of detail and fidelity to the final design. Low-fidelity prototypes are
quick and simple representations that focus on basic layout and functionality, while high-fidelity
prototypes closely resemble the final product in terms of appearance and interaction.
4. Tools and Techniques: Various tools and techniques are available for creating UI
prototypes, ranging from paper sketches and wireframes to interactive mockups and
clickable prototypes. Common tools include Adobe XD, Sketch, Figma, InVision, Axure
RP, and Balsamiq, among others.

5. User Feedback and Testing: UI prototypes are used to gather feedback from users through
usability testing, interviews, and surveys. By observing how users interact with the prototype,
designers can identify usability issues, navigation problems, and areas for improvement.
6. Communication and Collaboration: UI prototypes serve as a communication tool for designers,
developers, and stakeholders to collaborate and align on the design vision and requirements. They
help to ensure that everyone involved in the project has a clear understanding of the intended user
experience and interface design.
7. Risk Reduction: UI prototyping helps to mitigate risks associated with design decisions by
allowing designers to experiment with different layouts, features, and interactions in a low-risk
environment. By identifying and addressing potential issues early, UI prototypes can help to avoid
costly redesigns and rework later in the development process.

 In general UI prototyping is an essential part of the design and development
process, enabling designers to create user-centered interfaces that are intuitive,
efficient, and enjoyable to use. By iteratively refining and testing prototypes,
designers can ensure that the final product meets the needs and expectations of users
while aligning with business goals and technical constraints.

Evolving a supplementary specification
 Evolving a supplementary specification

 Evolving a supplementary specification involves updating and refining the document over
time to accommodate changes in project requirements, stakeholder feedback, or evolving
business needs. Here's a step-by-step guide to evolving your supplementary specification:
1. Identify Change Drivers: Determine the reasons behind the need to evolve the supplementary
specification. This could include changes in business objectives, new regulatory requirements,
feedback from stakeholders, or shifts in technology.
2. Gather Stakeholder Input: Engage with stakeholders to collect feedback on the current
supplementary specification and gather insights into the desired changes or additions. This could
involve conducting meetings, surveys, interviews, or workshops.
3. Analyze Impact: Assess the impact of proposed changes on the existing system requirements,
design, and implementation. Determine how the changes will affect other project artifacts and
deliverables.


4. Prioritize Changes: Prioritize the proposed changes based on their importance, urgency, and
feasibility. Consider factors such as business value, risk mitigation, and alignment with project
goals.
5. Update Documentation: Make revisions to the supplementary specification document to reflect
the approved changes. Clearly document the updated requirements, including any new features,
functionalities, or constraints.
6. Review and Validate: Conduct reviews of the updated supplementary specification with
relevant stakeholders, including business analysts, developers, testers, and project sponsors.
Ensure that the changes accurately reflect stakeholder needs and expectations.
7. Obtain Approval: Obtain formal approval for the updated supplementary specification from key
stakeholders and decision-makers. Ensure that all parties involved are in agreement with the
proposed changes before proceeding further.


8. Communicate Changes: Communicate the updated supplementary specification to all project
team members and stakeholders to ensure everyone is aware of the changes and their
implications. Provide clarification and address any questions or concerns.
9. Track Changes: Maintain a version control system to track changes to the supplementary
specification over time. Document the rationale behind each change and keep an audit trail for
future reference.
10. Iterate and Improve: Continuously monitor and assess the effectiveness of the evolved
supplementary specification. Solicit feedback from stakeholders and be prepared to make further
revisions as needed to ensure the document remains relevant and useful throughout the project
lifecycle.
 By following these steps, you can effectively evolve your supplementary specification to
accommodate changes and ensure the successful delivery of the project while meeting
stakeholder needs and expectations.
 Applying analysis patterns effectively

 Applying analysis patterns effectively involves leveraging established solutions to common
problems in domain modeling to improve the quality, consistency, and efficiency of software
development. Here are some key steps to apply analysis patterns effectively:
1. Understand the Domain: Gain a deep understanding of the domain you are working in. This
involves understanding the business processes, rules, entities, and relationships that characterize
the domain. Engage with domain experts and stakeholders to gather insights and clarify
requirements.
2. Identify Common Patterns: Identify recurring structures, behaviors, or problems within the
domain that can be addressed using analysis patterns. Study existing literature, reference
materials, and domain-specific resources to identify relevant patterns.


3. Select Appropriate Patterns: Choose analysis patterns that are well-suited to address the
specific needs and requirements of your project. Consider factors such as domain complexity,
scalability, maintainability, and alignment with business goals.
4. Adapt Patterns to Context: Tailor the selected analysis patterns to fit the specific context and
requirements of your project. Customize the patterns as necessary to accommodate unique
business rules, constraints, or variations in the domain.
5. Integrate Patterns with Modeling Techniques: Incorporate analysis patterns into your
modeling process using appropriate modeling techniques such as class diagrams, sequence
diagrams, state diagrams, or use case diagrams. Apply the patterns consistently across different
modeling artifacts to ensure coherence and alignment.


6. Document Patterns and Rationale: Document the analysis patterns you have selected and the
rationale behind their use. Clearly articulate how each pattern addresses specific domain
concerns or improves system design. Provide examples and illustrations to demonstrate the
application of patterns in context.
7. Validate Patterns with Stakeholders: Validate the selected analysis patterns with stakeholders,
domain experts, and other project team members to ensure their relevance, accuracy, and
effectiveness. Solicit feedback and incorporate suggestions for improvement as needed.
8. Reuse and Refine Patterns: Encourage reuse of analysis patterns across projects and within the
organization. Establish a repository or catalog of reusable patterns and promote knowledge
sharing among team members. Continuously refine and evolve patterns based on feedback and
lessons learned from real-world implementation.


9. Monitor Pattern Usage: Monitor the usage and impact of analysis patterns throughout the
software development lifecycle. Assess the effectiveness of patterns in addressing domain
complexities, reducing development time, and improving system quality. Adjust patterns as
needed based on empirical evidence and feedback.
10. Iterate and Improve: Treat the application of analysis patterns as an iterative process.
Continuously assess and refine your approach to pattern selection, adaptation, and integration
based on evolving project requirements, technological advancements, and changing business
needs.
 By following these steps, you can effectively apply analysis patterns to enhance the quality and
efficiency of domain modeling, leading to better-designed software systems that more closely
align with business objectives and user needs.

Remaining agile
 Remaining agile
 Remaining agile in software development involves embracing the core principles of the Agile
Manifesto while adapting to changing requirements, delivering value iteratively, and fostering
collaboration within the development team and with stakeholders. Here are some key strategies
for remaining agile:
1. Customer Collaboration over Contract Negotiation: Continuously engage with stakeholders,
end-users, and customers to gather feedback, validate assumptions, and ensure alignment with
their needs and expectations. Prioritize collaboration and communication to build trust and
transparency.
2. Responding to Change over Following a Plan: Embrace change as a natural part of the
development process. Be flexible and responsive to changing requirements, priorities, and
market conditions. Adapt plans, strategies, and deliverables iteratively to maximize value
delivery.

Remaining agile
 Remaining agile
3. Iterative and Incremental Development: Break down the project into small, manageable
increments or iterations. Deliver working software early and often, focusing on delivering high-
priority features and functionalities incrementally. Solicit feedback from stakeholders at the end
of each iteration to inform future development efforts.
4. Cross-Functional Teams: Foster collaboration and self-organization within cross-functional
teams composed of individuals with diverse skills and expertise. Encourage teamwork,
knowledge sharing, and collective ownership of project goals to maximize productivity and
innovation.
5. Continuous Integration and Delivery: Implement practices such as continuous integration,
continuous delivery, and automated testing to ensure that code changes are integrated frequently
and delivered to production environments rapidly and reliably. Streamline the development
process and minimize cycle times to accelerate value delivery.

Remaining agile
 Remaining agile
6. Adaptive Planning: Embrace adaptive planning techniques that allow for flexibility and
responsiveness to changing requirements and priorities. Use lightweight planning tools such as
user stories, Kanban boards, or Scrum backlogs to prioritize tasks and manage workloads
dynamically.
7. Regular Reflection and Improvement: Foster a culture of continuous improvement by
regularly reflecting on team processes, practices, and outcomes. Conduct retrospectives at the
end of each iteration to identify strengths, weaknesses, and opportunities for improvement.
Encourage experimentation and innovation to drive evolutionary change.
8. Empirical Process Control: Embrace empirical process control principles by making decisions
based on real-time data, feedback, and empirical evidence rather than relying solely on
predictions or assumptions. Use metrics, key performance indicators (KPIs), and feedback loops
to monitor progress, identify bottlenecks, and adapt strategies accordingly.

Remaining agile
 Remaining agile
9. Risk Management and Mitigation: Proactively identify and address risks throughout the
project lifecycle. Implement risk management techniques such as risk analysis, mitigation
planning, and risk tracking to minimize the impact of potential threats on project success.
Encourage open communication and collaboration to address issues and resolve conflicts
effectively.
10. Embracing Change as a Competitive Advantage: View change as an opportunity for
innovation, growth, and competitive advantage rather than a hindrance or disruption. Embrace a
mindset of continuous learning, adaptation, and resilience to thrive in dynamic and uncertain
environments.
 By embracing these principles and practices, software development teams can remain agile,
responsive, and adaptable in the face of changing requirements, market dynamics, and
technological advancements, ultimately delivering value to customers more effectively and
efficiently.
User stories
 User stories
 User stories are concise, informal descriptions of a software system's functionality from an end
user's perspective. They are a key component of Agile development methodologies, particularly
Scrum, and are used to capture user requirements and drive development efforts. Here's a
breakdown of user stories:
1. Format: User stories are typically written in the format: "As a [user role], I want to [perform
some action], so that [achieve some goal]". For example, "As a registered user, I want to be able
to reset my password, so that I can regain access to my account".
2. User Role: This identifies the type of user or persona who will benefit from the functionality
described in the user story. It helps to provide context and clarify who the intended user is.
3. Action: This describes the specific action or functionality that the user wants to perform within
the system. It should be written in clear and actionable language, focusing on what the user
wants to accomplish.

User stories
 User stories
4. Goal: This explains the purpose or objective behind the user's action. It clarifies the benefit or
value that the user expects to derive from the functionality described in the user story.
5. Independence: Each user story should be independent and deliverable on its own. This allows
for prioritization and incremental delivery of value to users.
6. Negotiable: User stories are meant to be a starting point for conversations between stakeholders,
product owners, and development teams. They should be open to negotiation and refinement
based on feedback and evolving requirements.
7. Estimable: User stories should be small enough to be estimated and implemented within a single
iteration or sprint. They should not be too large or vague, making it difficult to estimate effort
accurately.

User stories
 User stories
8. Testable: User stories should be testable, meaning that there should be clear criteria for
determining when the functionality described in the user story is complete and meets the user's
expectations.
9. Acceptance Criteria: This outlines the specific conditions or criteria that must be met for the
user story to be considered complete. Acceptance criteria provide a shared understanding of what
constitutes a successful implementation of the user story.
10. Prioritization: User stories are prioritized based on their value to users and the business. The
most valuable and essential user stories are typically prioritized higher and implemented first.
 User stories serve as a lightweight, collaborative tool for capturing user requirements, fostering
communication and collaboration among stakeholders, and guiding the iterative development of
software systems in Agile environments. They help ensure that development efforts are focused
on delivering tangible value to users and stakeholders throughout the project lifecycle.

System user stories
 System user stories

 System user stories are similar to traditional user stories but focus more on describing system-
level functionalities rather than user interactions. While traditional user stories are written from
the perspective of end users, system user stories are written from the perspective of the system
itself or its components. They are commonly used in Agile and iterative software development to
capture technical requirements, architectural decisions, and system behaviors. Here are some key
characteristics of system user stories:
1. Focus on System Functionality: System user stories describe specific functionalities, behaviors,
or features of the system from a technical or architectural perspective. They may address aspects
such as performance, security, scalability, maintainability, or integration with external systems.
2. Written from System's Perspective: Unlike traditional user stories that focus on end-user needs
and goals, system user stories are written from the perspective of the system, its components, or
subsystems. They describe what the system needs to do to fulfill its technical requirements and
constraints.
System user stories

3. Technical Details: System user stories often include technical details, implementation
considerations, and architectural decisions necessary for system development. They may specify
technical interfaces, data formats, protocols, algorithms, or system behaviors.
4. Non-Functional Requirements: System user stories may include non-functional requirements
(NFRs) or quality attributes such as performance, reliability, security, usability, or compliance
with regulatory standards. These requirements describe system qualities or characteristics rather
than specific features or functionalities.
5. Integration and Interoperability: System user stories often address integration points,
interoperability with other systems or components, data exchange mechanisms, and
communication protocols. They ensure that the system can interact seamlessly with external
systems or services.
5/14/2024
Prepared by Meseret Hailu(2024) 90
System user stories

6. Dependency Management: System user stories may identify dependencies between system
components, modules, or services and specify requirements for managing these dependencies
effectively. They ensure that changes or updates to one part of the system do not adversely affect
other parts.
7. Acceptance Criteria: Similar to traditional user stories, system user stories include acceptance
criteria that define the conditions for the story to be considered complete and satisfactory. These
criteria may include technical tests, performance benchmarks, or compliance checks.
8. Collaboration with Stakeholders: System user stories foster collaboration between technical
stakeholders, including developers, architects, system engineers, and quality assurance (QA)
professionals. They facilitate shared understanding of system requirements and guide technical
implementation decisions.
5/14/2024
System user stories

9. Prioritization and Iterative Development: System user stories are prioritized based on their
technical significance, impact on system architecture, and alignment with project goals. They are
implemented iteratively, with higher-priority system user stories addressed earlier in the
development process.
10. Continuous Refinement and Improvement: Like traditional user stories, system user stories
are subject to refinement, iteration, and evolution throughout the software development lifecycle.
They may be updated, revised, or decomposed into smaller stories based on feedback, changes in
requirements, or emerging technical challenges.
 In general, system user stories play a crucial role in Agile software development by capturing technical
requirements, guiding system design and implementation, and ensuring that the system meets its functional
and non-functional objectives effectively. They promote collaboration, transparency, and agility within
development teams and enable the iterative delivery of high-quality software systems.
5/14/2024
Chapter Four: Requirement Gathering and Modeling
The End of Unit Five

OOSAD Chapter5 (2024)

Uploaded by

Copyright:

Available Formats

You might also like

OOSAD Chapter5 (2024)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OOSAD Chapter5 (2024)

Uploaded by

Copyright:

Available Formats

Object Oriented System

Analysis and Design

5/14/2024 Prepared by Meseret Hailu(2024) 1

5/14/2024 Prepared by Meseret Hailu(2024) 2

 Identify the focus of OOA

 To build System Use Case Model

 Practice building Sequence Diagrams, Conceptual Modeling :Class

 Identify which modeling is structured and behavioral modeling

 From structured modeling identify static and dynamic modeling

5/14/2024 Prepared by Meseret Hailu(2024) 4

 End-to-end EUC and EUI prototyping approach

5/14/2024 Prepared by Meseret Hailu(2024) 5

 Work Breakdown Structure (WBS) represents the project as a hierarchical

5/14/2024 Prepared by Meseret Hailu(2024) 6

 The focus of Object-Oriented Systems Analysis

5/14/2024 Prepared by Meseret Hailu(2024) 7

 The focus of Object-Oriented Systems Analysis

5/14/2024 Prepared by Meseret Hailu(2024) 8

 System Use Case

5/14/2024 Prepared by Meseret Hailu(2024) 9

 System Use Case

5/14/2024 Prepared by Meseret Hailu(2024) 10

 System Use Case

5/14/2024 Prepared by Meseret Hailu(2024) 11

 System Use Case

5/14/2024 Prepared by Meseret Hailu(2024) 12

 System Use Case

5/14/2024 Prepared by Meseret Hailu(2024) 13

 System Use Case

5/14/2024 Prepared by Meseret Hailu(2024) 14

 System Use Case

Perform Enroll Family

5/14/2024 Prepared by Meseret Hailu(2024) 15

 System Use Case Template

5/14/2024 Prepared by Meseret Hailu(2024) 16

Alternative Course of Action A: The item is not available in store

 Developing Use Cases(Behavioral Modeling )

5/14/2024 Prepared by Meseret Hailu(2024) 18

 A sequence diagram(One of Dynamic Modelling)

5/14/2024 Prepared by Meseret Hailu(2024) 19

 A Here's an overview of the key components and elements of sequence diagrams:

 A Here's an overview of the key components and elements of sequence diagrams:

5/14/2024 Prepared by Meseret Hailu(2024) 21

 A Here's an overview of the key components and elements of sequence diagrams:

5/14/2024 Prepared by Meseret Hailu(2024) 22

 A Here's an overview of the key components and elements of sequence diagrams:

5/14/2024 Prepared by Meseret Hailu(2024) 23

 A Here's an overview of the key components and elements of sequence diagrams:

5/14/2024 Prepared by Meseret Hailu(2024) 24

5/14/2024 Prepared by Meseret Hailu(2024) 25

5/14/2024 Prepared by Meseret Hailu(2024) 26

5/14/2024 Prepared by Meseret Hailu(2024) 27

5/14/2024 Prepared by Meseret Hailu(2024) 28

5/14/2024 Prepared by Meseret Hailu(2024) 29

 A sequence diagram has four key elements: -

5/14/2024 Prepared by Meseret Hailu(2024) 30

 A sequence diagram has four key elements: -

5/14/2024 Prepared by Meseret Hailu(2024) 31

 A sequence diagram has four key elements: -