Module3 - Object Oriented Analysis & Functional Model.pdf

Module 3: Object-Oriented Analysis and Functional Model
Software Engineering
Computer Science
Academic Year 2023/2024
Gerard Albà Soler
1

Contents
1. Introduction
• What will we learn
2. Object Oriented Analysis and Design
• OOA/D in the SDLC process
• Functional, Static and Dynamic views vs OOA/D
3. The Unified Modeling Language (UML)
• Views of the modeling
• Diagrams
4. Functional Model
• Use Cases
• UML: Modules 3-6

1. Introduction
What will we learn?
• Object-Oriented Analysis and Design (OOAD) is a software engineering methodology
that employs object-oriented principles to model and design complex systems.
• We may distinguish modeling activities into the three most essential components or
models: functional, static and dynamic. They are different perspectives on one or
more specific aspects of the system. We will cover the three models over the next
modules: 3 to 6.
• The Unified Modeling Language (UML) is a standardized notation for creating diagrams
that represent different aspects of a software system. OOAD uses UML diagrams to
represent the different components and interactions of a software system.
• Use Cases: are a way of describing the different ways in which users interact with a
software system. OOAD uses use cases to help developers understand the
requirements of a system and to design software that meet those requirements.

1. Introduction
What will we learn?
• Functional model (in this Module 3): basically it focuses on how the system is supposed to
function satisfying the users or stakeholders. It illustrates the activities of the systems, the
transformation and the functionality, while concentrating on the interaction among the
resources, goals and rules in the organization.
• Static model (Module 5): it concerns about the structuring of databases for all kind
information or resources used in the organizational business, and contain all information
about the objects participating in the business. Data models are usually static, because the
entity types do not change during their life cycles. The changes are only objects that
belong to their respective classes.
• Dynamic model (Module 4): it describes the behaviour of the system containing each
important resource and interacts between several different resources. The behaviour
concerns the evolution of objects in the system in terms of the changes they undergo in
response to interaction with other objects inside and outside the system.

1. Introduction
What will we learn?

1. Introduction
What will we learn?
OOA/D
Functional
Model
Dynamic
Model
Static
Model
UML
Use Cases
OOA/D

1. Introduction
• Book References
ü Object-Oriented Analysis and Design with Applications 3rd ed. G Booch et
al. Ed Addison-Wesley Object Technology Series
ü Head First Object Oriented Analysis and Design. B McLaughlin. Ed O’Reilly
ü The Object-Oriented Thought Process 5th ed. M. Weisfeld. Ed Addison-
Wesley Professional
ü Applying UML and Patterns 3rd ed. C. Larman. Ed Prentice Hall
ü UML in Practice. P Roques. Ed Wiley
ü UML 2.0. R Miles. Ed O’Reilly

2. Object-Oriented Analysis and Design
• Some software systems are not actually complex. Small applications that are specified,
constructed, maintained, and used by the same person, usually the amateur programmer or
a professional working alone. Usually they have a very limited purpose and a short life span.
• But we are more interested in the challenges of developing what we will call industrial-
strength software. Applications that exhibit a very rich set of behaviors in many business
applications. Those profesional software applications are inherently Complex.
• Complex systems can be understood by focusing on either things or processes. There are
compelling reasons for applying object-oriented decomposition (as seen in Module 2), in
which we view the world as a meaningful collection of objects that collaborate to achieve
some higher-level behavior.
• Object-oriented Analysis and Design (OOA/D) is the method that leads us to an object
oriented decomposition.
• OOA/D uses a notation and process for developing complex software systems and offers a
rich set of models with which we may reason about different aspects of the system.

• By applying object-oriented design:
ü We achieve a greater level of confidence in the correctness of our software through an
intelligent separation of its state space.
ü We create software that is resilient to change and written with economy of expression.
ü It helps create systems that are easier to understand, maintain, and extend by
organizing functionality into reusable and interconnected components.
ü Ultimately, we reduce the risks inherent in developing complex software.
• We studied in Module 2 the principles on which object-oriented development is founded:
abstraction, encapsulation, inheritance, polymorphism.
• In the following Modules (3-5), we will learn the notation (UML) and process (SDLC of
Module 1) of object-oriented design.
The Models of Object-Oriented Development

• We are going to study OO modeling for software development according to this two
criteria:
1. The three views of modeling: Functional, Static and Dynamic
2. The two levels of abstraction: Analysis and Design
• The next table shows a summary of the UML diagrams and modeling phase by Modules
of this course

Modeling view Diagrams Seminar
Module
Functional Use case diagram
Activity diagram
Sequence diagram
Module 3
Static Class diagram
Component diagrams
Object diagram
Deployment diagram
Module 5
Dynamic State diagram
Collaboration diagram
Activity diagram
Sequence diagram
Module 4
Analysis “Analysis” level comprising the functional view, as well as a subset of static and
dynamic views, excluding component, deployment and collaboration diagrams.
Module 3-5
Design “Design” view, emphasis on collaboration diagrams and the design detail of class
diagrams. Also introduces component and deployment diagrams.
Module 6

• In Module 1, we discussed the overall software development process (the general, or macro,
SDLC process).
• The analysis and design process can be understood as a micro process that is part of the
macro SDLC process.
• Specifically, the OOA/D process takes the requirements provided by the SDLC process and
produces design specifications that are implemented, tested, deployed in the SDLC process.
OOA/D in the SDLC process

• Analysis takes the requirements and produces an initial solution, and Design takes the
results of analysis and produces a specification that can be implemented, tested, deployed.
• Analysis is about understanding the problem to be solved better. Is a critical part of the
overall SDLC process and it will result in a more robust and understandable design, with a
clear separation of concerns and a balanced division of responsibility between elements.
• Analysis focuses on behavior, not form. In analysis, you seek to model the world by
identifying the elements that form the vocabulary of the problem domain and describing
their roles, responsibilities, and collaborations. Rather, analysis must yield a statement of
what the system does, not how it does it.
Analysis Design

• In Design, you invent the elements that provide the behavior that the analysis elements
require. You begin the design process as soon as you have some reasonably complete model
of the behavior of the system.
• It is important to avoid premature designs, wherein development begins before analysis
reaches closure. It is equally important to avoid delayed designing, wherein the organization
thrashes while trying to complete a perfect and hence unachievable analysis model (a
condition commonly referred to as analysis paralysis).
• We also need to understand the separation of concerns when developing the architecture
versus the individual components during analysis and design. Architecture is concerned
with the relationships between the parts of the systems (e.g., components), their
responsibilities, interfaces, and collaboration. In contrast, analysis and design of system
components focus on the internals of those components and how they will satisfy the
requirements.

3. UML
• The Unified Modeling Language™ (UML) was developed jointly by Grady Booch, Ivar
Jacobson, and Jim Rumbaugh with contributions from other leading methodologists,
software vendors, and many users. The UML provides the application modeling language
for:
ü Business process modeling/ Requirement Analysis with Use-cases.
ü Static Design with Class and object modeling.
ü Dynamic Design with sequence, collaboration and activity diagrams.
ü Component modeling.
ü Distribution and deployment modeling.
• In 1997 UML was adopted as a standard by the Object Management Group (OMG), and has
been managed by this organization ever since. In 2005 UML was also published by the
International Organization for Standardization (ISO) as an approved ISO standard.
https://www.uml.org/

3. UML
• From the late 1980s to the 1990s, many methods and languages for the representation of
OOP were developed. The result was a variety of methods that were largely dissimilar. To
unify these, these three developers (James Rumbaugh, Grady Booch and Ivar
Jacobson) decided to merge several existing languages into a common, standardized one.
• The three had already created their own OOP development methods: the Booch method,
the object modeling technique (OMT) and the OO software engineering method (OOSE)
• UML should define the semantics for the representation of these methods as the
modeling language. Under the name “UML Partners”, the developers started working on
the completion of UML in a team in 1996. They then handed it over to the Object
Management Group, who introduced the unified modeling language version 1.1 as the
standard in 1997.
• The developers set up a task force to improve the language over several versions. A major
revision was UML 2.0 in 2005.
• UML v 2.5.2 appeared in December 2017.

3. UML
• The Unified modeling language is a standard way to visualize a software system.
• UML has several diagrams defined which are used to show structural, and behavioral
aspects of a software system and those diagrams help:
ü end users to clarify their requirements, understand to the software system
ü and helps software engineer to model, analyze and design software system.
• Teams can work with each other easily as the blue print developed using standard notations
and is easy to understand.

3. UML
• Tools for writing UML: https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
https://www.umldesigner.org/overview/

3. UML
• UML diagrams are classified into (see Modules 4-6 to learn more):
• Structural Diagrams (Static): represent individual elements in a system. The static
representation does not represent a change, but rather represents states and dependencies.
ü Component Diagrams
ü Object Diagrams
ü Class Diagrams
ü Deployment Diagrams
ü Package Diagrams
• Behavior Diagrams (Dynamic): represent dynamic processes.
ü Use Case Diagrams
ü State Diagrams
ü Activity Diagrams
ü Interaction Diagrams: Sequence Diagrams, Collaboration Diagrams

3. UML
• UML can be used in different ways and according to their use:
1. As a sketch, a blueprint or even as a programming language:
ü Use UML to make brief sketches to convey key points. These are throwaway
sketches—they could be written on a whiteboard.
ü UML as a blueprint. Provide a detailed specification of a system with UML
diagrams. It would be generated with a UML tool. This approach is generally
associated with software systems and usually involves using forward and reverse
engineering to keep the model synchronized with the code.
ü UML as a programming language. This goes directly from a UML model to
executable code.

3. UML
2. When you are using UML to model a software system, the “degree of UML” you apply
is partially influenced by the software development process you use. A software
development process is one of the recipes we studied in Module 1.
ü The waterfall method attempts to pin down the requirements early in the Project
life cycle. After gathering requirements, software design is performed in full. UML
would be used as a blueprint in the waterfall SDLC.
ü Iterative methods attempt to address the shortcomings of the waterfall approach
by accepting that change will happen and, in fact, embracing it. They encompass a
wider range of approaches (e.g., agile iterative processes), and they can range from
using UML as sketch to using UML as blueprint.
ü Agile methods use iterations in short bursts and attempt to minimize risk by always
having a working system of expanding capabilities. Agile methods emphasize using
UML as a sketch.

3. UML
3. UML can also be used in different views when representing all relevant information
about a system’s architecture. You usually need to present multiple views.
• There are different opinions as to what views are required. Krutchen well-known 4+1
view model suggests that there should be four fundamental architectural views, which
are related using use cases or scenarios.

3. UML
• The 4+1 views that he suggests are:
1. A logical view: shows the key abstractions in the system as objects or
object classes. It should be possible to relate the system requirements to
entities in this view.
2. A process view: shows how, at run-time, the system is composed of
interacting processes. This view is useful for making judgments about
nonfunctional system characteristics such as performance and availability.
3. A development view: shows how the software is decomposed for
development, that is, it shows the breakdown of the software into components
that are implemented by a single developer or development team.
4. A physical view, which shows the system hardware and how software
components are distributed across the processors in the system. This view is
useful for systems engineers planning a system deployment.

3. UML
• For example, the Unified Process Model
(UP) method in SDLC (See Module 1) uses
UML in different views when doing the
architectural design (that is concerned
with understanding how a system
should be organized and designing
the overall structure).
• UP uses the SDA (Software
Architecture Document) of the next
chart

3. UML
https://youtu.be/KY81igoV8W0?si=FoRw0JgQufnoD1h-

4. Functional Model
• We introduced requirements in Module 1 as the first step in the SDLC. Requirements can be
initially still a little fuzzy, and they are all written in the language of the user.
• How do you take this initial loosely defined requirements and distill it into a format for your
designers without losing important detail? UML has some diagram tools to support in this
phase. Specifically, UML use cases.
• A use case is a case (or situation) where your system is used to fulfill one or more of your
user’s requirements; a use case captures a piece of functionality that the system provides.
• Use cases are an excellent starting point for object-oriented system development, design,
testing, and documentation.
• They describe a system’s requirements from the outside looking in; they specify the value
that the system delivers to users. Because use cases are the functional requirements, they
should be the first serious output from your model after a project is started.
• How can you begin to design a system if you don’t know what it will be required to do?

4. Functional Model
• Use cases will influence many aspects of a Project -
including OOA/D- and will be input to many subsequent
artifacts.
• This chapter explores basic concepts, including how to
write use cases and draw a UML use case diagrams. Use
cases are not only diagrams, they are also text.
• The essence is discovering and recording functional
requirements by writing stories of using a system to
fulfill user goals; that is, cases of use. It’s often difficult
to discover what’s needed and write it well.
• The use cases can influence many other analysis, design,
implementation and test artifacts.

4. Functional Model
• We start with the requirements.
• The main idea now is to create a software requirement model from gathered
specifications.
• Once we have the specifications, we can use the Use Case Model diagram of UML:
ü Identify the actors: it can be the user or anyone that interacts with the system
ü Identify use cases: specify the sequence of actions (scenarios) that an actor
perform to achieve a goal.
ü A single use case can have many scenarios: the main one, alternatives and
exception scenarios.
ü So, the use case diagram will capture actors, use cases and relationships, using
diagrams easily understandable.
Requirements Specification and Use Case Model

4. Functional Model
• Goal: Understand client needs in order to write functional specifications. A use case
model tries to reply three questions:
1. Define the main usages of the system: What is it used for?
2. Define the system environment: Which elements will use or interact with the
system?
3. Define the limits of the system: Where the system responsibilities end up?
• Let’s see in more detail how the use case model is done. Module 4 will also dig
deeper on UML Use Cases.
Use Case

4. Functional Model
• A use case captures textually the steps an actor must follow to accomplish a goal.
Use cases must contain, at least:
ü Title: what’s the goal?
ü Primary actor: who desires it?
ü Success scenario: how is it accomplished? (Specifying all needed steps)
Use Case

4. Functional Model
• Use cases can be written in different formats and levels of formality, but generally,
in the industry, the used format is divided in two parts:
ü Summary: Title, Description, Actors, Version, creation date
ü Flow of events: Main Scenario, Alternative and error scenarios, Preconditions
and Postconditions
• Brief: terse one-paragraph summary, usually of the main success scenario. When?
During early requirements analysis, to get a quick sense of subject and scope.
• Casual: informal paragraph format. Paragraphs that cover various Scenarios.
• Fully dressed: all steps and variations are written in detail, and there are
supporting sections, such as preconditions and success guarantees. When? After
many use cases have been identified and written. See an example in the next slide.

4. Functional Model
Use Case section Comment
Use Case Name With a verb.
Scope The system under design.
Level “user-goal” or “subfunction”.
Primary Actor Calls on the system to deliver its services.
Stakeholders and Interests Who cares about this use case, and what do they want?
Preconditions What must be true on start, and worth telling the reader?
Success Guarantee What must be true on successful completion, worth telling.
Main Success Scenario A typical, unconditional happy path scenario of success.
Extensions Alternate scenarios of success or failure.
Special Requirements Related non-functional requirements. (See Module 1)
Technology and Data Variations List
Varying I/O methods and data formats.
Frequency of Occurrence Influences investigation, testing, and timing of implementation.
Miscellaneous Such as open issues.

4. Functional Model
• Actor: external entity involved in some of the use cases of the system we are
developing.
ü Can send and/or receive information from the system.
ü It can be a person, a device or a subsystem.
ü Use cases focus on the actor’s goals, not the technology.
ü Proper identification and understanding of actors are crucial for accurately
modeling system behavior.
Actors

4. Functional Model
• Example: use case diagram of an
eCommerce system.
• An actor is drawn in UML
notation using either a stick man
or a stereotyped and is labeled
with an appropriate name, as
shown in the figure.
Actors

4. Functional Model
• Deciding what is and what is not an actor is tricky
and is something best learned by experience. The
next figure shows a simple technique for
analyzing a “thing” that you’ve found in your
requirements and how to decide whether it is an
actor or not.
• Actors don’t have to be actual people. While an
actor might be a person, it could also be a third
party’s system, such as in a business-to-business
(B2B) application.
• Think of an actor as a black box: you cannot
change an actor and you are not interested in
how it works, but it must interact with your
system.

4. Functional Model
• Identifying the actors:
ü An actor is anything that interacts with the system, living outside of it.
ü External computer systems or organisations we need to communicate with,
can be actors.
ü Human actors can be involved in many use cases, with different roles:
§ An editor needs to modify product details.
§ An administrator can create new products.
§ And a customer can buy a product.
ü Use cases can have primary and secondary actors. A primary actor are the
ones that initiate the user case.
Actors

4. Functional Model
• In addition to obvious primary actors and goals, the following questions help identify others
that may be missed:
ü Who starts and stops the system?
ü Who does system administration?
ü Who does user and security management?
ü Is “time” an actor because the system does something in response to a time event?
ü Is there a monitoring process that restarts the system if it fails?
ü Who evaluates system activity or performance?
ü How are software updates handled? Push or pull update?
ü In addition to human primary actors, are there any external software or robotic systems
that call upon services of the system?
ü Who gets notified when there are errors or failures?
ü …
Actors

4. Functional Model
• Once you have captured an initial set of actors that interact with your system,
you, the next step is to find cases where the system is being used to complete a
specific job for an actor (use cases or scenarios).
• A use case, or job, might be as simple as allowing the user to log in or as
complex as executing a distributed transaction across multiple global databases.
The important thing to remember is that a use case is a complete use of the
system; there is some interaction with the system, as well as some output from
that interaction.
• Remember, if use cases are truly requirements, then they must have very clear
pass/fail criteria. The developer, the tester, the technical writer, and the user
must explicitly know whether the system fulfils the use case or not.
Use cases (Scenarios)

4. Functional Model
• A use case in UML is drawn as an oval with a name that
describes the interaction that it represents.
• A communication line connects an actor and a use case
to show the actor participating in the use case.
• There is an implicit separation between actors (external
to your system) and use cases (internal to your system)
that marks your system’s boundary. UML does provide
another small piece of notation to show your system’s
boundary on a use case diagram: draw a box around all
of the use cases but keep the actors outside of the box.
It’s also good practice to name your box after the
system you are developing.
Use cases (Scenarios) in UML

4. Functional Model
• Main success scenarios is also known as: Basic flow of events o Normal path.
• Success scenario = list of steps resulting in the user completing its goal.
• A scenario, in general, is made up by several simple and discrete steps:
ü Actions performed by the actor.
ü Actions performed by the system.
ü Communication between the actor, system and secondary actors.
• Alternative scenario = list of steps, other than the main path ones, resulting in
the user completing its goal.
• Exception scenario = undesirable path that avoids completing the goal. Even
when the system fails, it should respond to the user in an appropriate way.
Use cases (Scenarios)

4. Functional Model
• A diagram showing the use cases and actors may be a nice starting point, but
it does not provide enough detail.
• Every use case should be accompanied by a text-based description.
• There are no hard and fast rules as to what exactly goes into a use case
description according to UML. See the next example, or the previous slide at
the begining of the section.
Use cases

4. Functional Model
Use case description detail What the detail means and why it is useful
Related Requirements
Some indication as to which requirements this use case partially or completely fulfills.
Goal In Context The use case’s place within the system and why this use case is important.
Preconditions What needs to happen before the use case can be executed.
Successful End Condition What the system’s condition should be if the use case executes successfully.
Failed End Condition What the system’s condition should be if the use case fails to execute successfully.
Primary Actors The main actors that participate in the use case. Often includes the actors that trigger or
directly receive information from a use case’s execution.
Secondary Actors Actors that participate but are not the main players in a use case’s execution.
Trigger The event triggered by an actor that causes the use case to execute.
Main Flow The place to describe each of the important steps in a use case’s normal execution.
Extensions description of aalternative steps from the ones in the Main Flow.

4. Functional Model
• Example: suppose we’re defining
requirements for a weblog content
management system (CMS).

4. Functional Model
• In the next Module 4, we will learn some additional UML diagrams for
completing the description of the use cases.
• For use cases, we recommend the activity diagram, as users find it far easier to
understand since it resembles a traditional diagram. However, the state diagram
may be useful for use cases that are very interactive.
• For certain scenarios, the sequence diagram works well. We recommend that
you present it by showing the primary actor on the left, then an object
representing the system in a black box, and finally, any secondary actors that
may be requested during the scenario on the right of the system.
Use cases

4. Functional Model
Use cases in UML
• Module 4 will dig further in UML Use Case Diagrams.

4. Functional Model
• Preconditions state what must always be true before a scenario is begun in the
use case. Preconditions are not tested within the use case; rather, they are
conditions that are assumed to be true. Typically, a precondition implies a
scenario of another use case, such as logging in, that has successfully completed.
• Note that there are conditions that must be true, but are not worth writing, such
as “the system has power.” Preconditions communicate noteworthy assumptions
that the writer thinks readers should be alerted to.
• Success guarantees (or postconditions) state what must be true on successful
completion of the use case—either the main success scenario or some alternate
path. The guarantee should meet the needs of all stakeholders.
Use Cases: preconditions and postconditions

4. Functional Model
• Guideline to find and define use cases:
1. Choose the system boundary. Is it just a software application, the hardware and
application as a unit, that plus a person using it, or an entire organization?
2. Identify the primary actors—those that have goals fulfilled through using services of
the system.
3. Identify the goals for each primary actor.
4. Define use cases that satisfy user goals; name them according to their goal. Usually,
user-goal level use cases will be one-to-one with user goals, but there is at least one
exception, as will be examined.
• Of course, in iterative and evolutionary development, not all goals or use cases will be fully
or correctly identified near the start. It’s an evolving discovery.
Use Case

4. Functional Model
https://youtu.be/zid-MVo7M-E

4. UML Modules 3-6
• The lessons on UML are divided into parts or Modules in accordance with the
three views of modelling: functional (Module 3), static (Module 5) and dynamic
(Module 4), whilst emphazising for each the dominating UML diagrams.
• Remember also that, in order to make a second differentiation - this time between
the levels of abstraction in the SDLC - a distinction has been made between: an
analysis level (comprising the functional view, as well as a subset of static and
dynamic views), excluding the component, deployment and collaboration
diagrams; and a design view (Module 6), which places emphasis on collaboration
diagrams and the design detail of class diagrams, and which also introduces
component and deployment diagrams.

4. UML Modules 3-6
• Let’s now see a summary of the steps that we will follow over the next modules
about using UML in this analysis phase.

4. UML Modules 3-6
• Work on the domain model once we
have the use cases.
• The domain model shows the basic
domain concepts and their relationships.
• It helps and must identify all the
conceptual classes of the system.
• Once we have the user cases, we can:
ü Draw the UML domain model
ü Add associations between the
identified objects.
ü Add the attributes necessary to full
fill the current use case.

4. UML Modules 3-6
• Considering the use cases diagram, we
can extract all the system events. They
are interactions from the actor to the
system with a reply from the system.
• SSD show events that actors generate in
one scenario of the use cases. It will
show the first interaction and how things
evolve after that. Showing the answers
and operation from the system.
• It shows the interactions between
external entities (actors) and the system,
and general interactions between parts.
System Sequence Diagram (SSD)

4. UML Modules 3-6
• Considering Use cases or system features
are the main ways to describe system
behavior, and are usually sufficient.
• Sometimes a more detailed or precise
description of system behavior has value.
• Operation contracts use a pre- and post-
condition form to describe detailed
changes to objects in a domain model, as
the result of a system operation.
• A domain model is the most common
OOA model, but operation contracts and
state models can also be useful.
Operation Contracts

4. UML Modules 3-6
• It shows the internal structure of the
software we are building.
• Similar to our domain model, adding
abstract clases.
• Classes will be completed with visibility,
multiplicity, associations, attributes,
operations.
• It’s basically a detailed representation of
the classes and object in a system.
Class Diagrams

4. UML Modules 3-6
• Sequence Diagrams are interactions that
show a set of objects and messages
between them.
• It illustrates the dynamic view of the
system, focusing on interactions between
system objects.
• For each system operation and using the
operation contract we will construct a
sequence diagram showing the
responsibilities assignments for the
objects.
Sequence Diagrams

4. Functional Model
UML topic Video tutorial
Introduction UML https://youtu.be/-OWd0tJAK10?si=lC8wS76SQCuxejzK
OOA/D in UML https://youtu.be/3LrOpwhsplY?si=Sx5ur8Zbs-8D65r1
UML Modeling https://youtu.be/qoxoX3ZiazI?si=hjMVkshhZ--z-h-s
Use Case Diagram https://youtu.be/yZWVx_esIq8?si=D6sKokG1idZLfmYl
https://youtu.be/DUjBnEvIm1M?si=lyfWXoO7CUtWN2t4
Class Diagram https://youtu.be/kNV-NvBuH7M?si=DD5UW_PrxOar-7kW
https://youtu.be/NEmZZX8Xgns?si=ZRHvNPqzTpZzSpjy
https://youtu.be/wkTuCIScFQI?si=8GpNOVVTVYoOCZNU
https://youtu.be/sKqMDsDoeQ8?si=zgkNWfeVMrLnmCFO
Object Diagram https://youtu.be/Rhgg3hSI6I0?si=ASMFoc61a_PCOlLI
Sequence Diagram https://youtu.be/H_GnFIhMXDg?si=kLnQ-1qkLcQJtRHc
https://youtu.be/nOtF-IY9uWA?si=9gBiChjBnIaOa14t
State Diagrams https://youtu.be/Rk3cPADj__M?si=2nAFvudPVhlhj4NY
https://youtu.be/j77wzk4hbMg?si=NqCxJk3ayrPA-5y-
Activity Diagrams https://youtu.be/GoYdpOVhDRc?si=w9j6NfkXaL3DZZ6J
https://youtu.be/y1pItD9z5Rs?si=JADEVl1yqqQkVaZa

Module3 - Object Oriented Analysis & Functional Model.pdf

Recommended

Recommended

More Related Content

Similar to Module3 - Object Oriented Analysis & Functional Model.pdf

Similar to Module3 - Object Oriented Analysis & Functional Model.pdf (20)

More from Gerard Alba

More from Gerard Alba (20)

Recently uploaded

Recently uploaded (20)

Module3 - Object Oriented Analysis & Functional Model.pdf