Applied Software Engineering

STUDENT NAME:
STUDENT ID:
Task 1:
Use Case Model: Knowledge Sharing and Retrieval
Use Case Description: Accessing Project Knowledge
Primary Actor: H&K Employee
Stakeholders:
 H&K Project Managers
 H&K Clients
Preconditions:
 The user's login credentials are legitimate.
 The hk.net Extranet is available to the person who uses it.
Postconditions:
 The user obtains pertinent project information with success.
Main success scenario:
 Actor accesses the Extranet at hk.net.
 The user's credentials are verified by the system.
 The actor opens the desired project folder.
 An array of the endeavors/projects that the user is participating in or has access to is
displayed by the system.
 An actor chooses a certain project.
 The system displays files pertaining to the project, which include case studies,
administrative data, and correspondence.
Alternative scenarios:
 In the event that the user has zero projects assigned to them, the system alerts them of
this in Step 4 and none of the projects are presented.
 If there are no emails saved for the chosen project, then in Step 6, the user is notified
by the system that the project they have chosen does not have any emails attached to
it.
 In the event that the user has trouble connecting, then in Step 2, the system shows an
error notice, and the use case terminates if connectivity problems prevent the user
from being validated.
 In the event that the user experiences delayed data transfer, then in Step 6, the system
notifies the user of possible delays and shows a loading notice if retrieving project
information is slower due to poor network connectivity.
Use case factoring:
 Refactor 1: Obtaining Information Unique to a Client
o Give users the option to classify projects according to customers, which would
increase productivity for staff members who handle several clients.
o Steps of the situation: Add a step wherein the character chooses a customer
and then moves on to Step 4 immediately following Step 3.
 Refactor 2: Collaborative Project assessment:
 o This refactor allows several users to assess and provide input to project-related
material at the same time, facilitating cooperation.
o Steps in the scenario: Change Step 5 to allow for several users to gain entry to
the same project at once.
 Refactor 3:
o Offline Accessibility to Project Information: This refactor addresses probable
connectivity concerns by giving users a way of downloading project-related
data for offline usage.
o Steps in the scenario: Provide users with the option to save the project data for
offline usage in Step 6, along with the ability to synchronize it once they are
back online.
Task 2:
Key classes, their characteristics, and linkages must be determined in order to create a class
diagram according to the use case model that has been supplied. This is a class diagram that
has been streamlined and appropriately applies object oriented principles:

<<Entity>> <<Entity>> <<Entity>>

User Project ProjectFolder

-username: String -projectId: int -folderName: String

-password: String -projectName: Str -contents: List<Doc>
-client: Client
+login() : void +addDocument()
+logout() : void +removeDocument()
+searchDocuments()

<<Entity>> <<Entity>>
Client Document

-clientId: int -docId: int

-clientName: Str -title: String
-logo: Image -content: String
-dateCreated: Date
+getClientInfo()
+viewDetails()

Class Descriptions:
 User:
o H&K employees who interact with the system.
o Attributes: username, password.
o Methods: login(), logout().
 Project:
o H&K project.
o Attributes: projectId, projectName, client (association to Client class).
o Methods: No explicit methods in this simplified model.
 ProjectFolder:
o Folder for storing documents.
o Attributes: folderName, contents (List of Document objects).
o Methods: addDocument(), removeDocument(), searchDocuments().
 Client:
o H&K clients.
o Attributes: clientId, clientName, logo.
o Methods: getClientInfo().
  Document:
o Document in project folder.
o Attributes: docId, title, content, dateCreated.
o Methods: viewDetails().
Principles of Object Orientation Applied:
 Encapsulation: Classes reveal pertinent methods and encapsulate their characteristics.
 Association: Associations are represented by relationships between classes (e.g., User
interacts with Project).
 Inheritance: Since it might not be specifically necessary for the use case at hand,
explicit inheritance is not reflected in this model.
 Polymorphism: Polymorphism might be added in more sophisticated circumstances
(e.g., distinct sorts of Documents with unique behaviors), albeit it is not explicitly
demonstrated in this basic model.
System Class:
<<Subsystem>>
Knowledge

+loginUser() : void
+logoutUser() : void
+addProject() : void
+removeProject() : void
+searchProjects() :
+addDocumentToProj:
+removeDocumentFro:
+searchDocuments() :
The essential features of project management, document processing, and user authentication
are represented by the ‘Knowledge’ subsystem. The system's primary operations in relation to
the given use case model are contained in the public methods.
Task 3:
A sequence diagram shows how several items or elements of a system link to one another as
time passes. The sequence diagram for the chosen use case, "Accessing Project Knowledge,"
looks like this:

+---------------------+ +------------------ + +---------------------+

| User | | System | | ProjectFolder |
+---------------------+ +------------------ + +---------------------+
| | | | | |
| login() | | | | |
|------------------->>| | | | |
| | | | | |
| | | | | |
| selectProject()| | | | |
|------------------->>| | | | |
| | | | | |
| | | | | getContents() |
| | | | |------------------>>|
| | | | | |
| | | | | |
| | | | | [empty] |
| | | | |<--------------------|
| | | | | |
| | | | | |
| viewDocument() | | | | |
|------------------->>| | | | |
| | | | | |
| | | | | display() |
| | | | |------------------>>|
| | | | | |
| logout() | | | | |
|------------------->>| | | | |
| | | | | |
+---------------------+ +------------------ + +---------------------+
+---------------------+ +------------------ + +---------------------+
 Explanation:
o Utilising the login() function, the User object logs into the system to start the
sequence.
o The user chooses a project from a list once the System verifies their identity
(selectProject()).
o The getContents() function on the ProjectFolder object is then called by the
System to obtain the files of the project folder that has been chosen.
o In response, the ProjectFolder object gives the document list (display()).
 o When a user uses viewDocument() to choose a particular document, the
system fetches and shows the content of the document.
o The logout() function is used by the User to log out after engaging with the
system.
 Guards:
o To determine whether the user has chosen a project, the getContents() function
in ProjectFolder is guarded. A blank answer is sent if it isn't.
o The ProjectFolder for the chosen project is empty, as indicated by the [empty]
message, meaning that zero documents are present.
 Iterations:
o Since the primary success scenario is the focus of this simple example,
iteration is not clearly indicated. Loops might be added to indicate iterations in
a more thorough scenario, such as when a user is perusing a list of papers.
 Message operations:
o For the sake of simplicity, message operations are not specifically described in
this example. Each message might contain parameters and particular actions
carried out by the receiving object in a more thorough manner.
Task 4:
The relationships and arrangement of software elements inside a system are depicted in a
component diagram. We'll use an abridged Knowledge Management System component and
related interface methods in this setting.
KnowledgeManagementSystem

-userManager: UserManager
-projectManager: ProjectManager
-documentManager: DocumentManager

+loginUser(username, password)
+logoutUser()
+getProjectList(user)
+getProjectDetails(projectId)
+getDocumentContent(document)
Explanation:
 KnowledgeManagementSystem Component:
o symbolizes the Knowledge Management System as a whole.
o oversees subcomponents that are used to handle documents, projects, and
users.
 Interface methods:
o loginUser(password, username): Allows a user to log in to the system.
o logoutUser(): Exits the active user session.
o getProjectList(user): Returns an array of the user's connected projects.
o obtainProjectDetails(projectId): Returns information on a particular project.
o Get the contents of a certain document with the
getDocumentContent(documentId) function.
Component composition:
 UserManager: include methods like validateCredentials(username, password).
 ProjectManager: include methods like getProjects(user), getProjectDetails(projectId)
 DocumentManager: include methods like getDocumentContent(documentId).
Significance of design:
 Modularity:
o To encourage modularity, every sub-component (UserManager,
ProjectManager, DocumentManager) emphasises a different facet of the
system.
o Updating and maintaining one component is made easier since modifications
to one are far less probable to affect others.
 Encapsulation:
o Each sub-component's internal features are concealed from view, improving
encapsulation.
o Via clearly laid out interfaces, clients communicate with the Knowledge
Management System component.
 Reusability:
o Every sub-component has the ability to be reused in multiple projects or in
additional components of the system.
o One system that needs user authentication may utilize UserManager again.
 Scalability:
o Every sub-component of the system may be grown individually according to
its own needs as it expands.
o For example, improvements to the DocumentManager can be performed
without impacting other components in the event that document management
grows more sophisticated.
 Ease of testing:
o The testing procedure may be made simpler by individually testing each sub-
component.
o It becomes easier to mock or replace a single sub-component for testing
reasons.
 Clear interfaces:
o Developers may more easily comprehend and put into effect the interactions
between components when interface methods are used to provide
unambiguous contracts between them
Task 5:
Business Rules and Constraints:
 User Authentication:
o Business Rule: To log in, a user has to supply a valid username and password.
o OCL: self.username.notEmpty() and self.password.notEmpty() (in the login
method of User).
 Logout Operation:
o Business Rule: Only those who are currently authorized may log out.
o OCL: self.isAuthenticated (in the logout method of User).
 Access Project List:
o Business Rule: The full set of projects is only accessible to logged-in users.
o OCL: user.isAuthenticated (in the getProjectList method of
KnowledgeManagementSystem).
 Project ID Validity:
o Business Rule: For information regarding a project to be retrieved, project IDs
need to be integers that are positive.
o OCL: projectId > 0 (in the getProjectDetails method of ProjectManager).
 Document ID Validity:
o Business Rule: For the purpose of accessing document content, document IDs
have to be integers that are positive.
o OCL: documentId > 0 (in the getDocumentContent method of
DocumentManager).
 Non-Empty Project List:
o Business Rule: The system's supplied listing of projects shouldn't be null.
o OCL: result->notEmpty() (in the postcondition of getProjectList method in
KnowledgeManagementSystem).
 Non-Null Project Details:
o Business Rule: The information on a project that the system has collected
shouldn't be empty.
o OCL: result <> null (in the postcondition of getProjectDetails method in
ProjectManager).
 Non-Null Document Content:
o Business Rule: A document that the system has retrieved shouldn't have null
content.
o OCL: result <> null (in the postcondition of getDocumentContent method in
DocumentManager).
Syntax:
context User::login()
pre:
-- Preconditions
self.username.notEmpty() and self.password.notEmpty()

post:
-- Postconditions
self.isAuthenticated

context User::logout()
pre:
-- Preconditions
self.isAuthenticated

post:
-- Postconditions
not self.isAuthenticated

context KnowledgeManagementSystem::getProjectList(user: User)

pre:
-- Preconditions
user.isAuthenticated

post:
-- Postconditions
result->notEmpty() -- Ensure the result is not empty

context ProjectManager::getProjectDetails(projectId: Integer)

pre:
-- Preconditions
projectId > 0 -- Assuming project IDs are positive integers

post:
-- Postconditions
result <> null -- Ensure the result is not null

context DocumentManager::getDocumentContent(documentId: Integer)

pre:
-- Preconditions
documentId > 0 -- Assuming document IDs are positive integers

post:
-- Postconditions
result <> null -- Ensure the result is not null