Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #15371 > unrolled thread

Online Job Portal System Use Case Diagrams

Back to article view | Back to comp.lang.php

Contents

  Online Job Portal System Use Case Diagrams Brara morad35 <bramorad35@gmail.com> - 2015-05-31 10:58 -0700
    Re: Online Job Portal System Use Case Diagrams Denis McMahon <denismfmcmahon@gmail.com> - 2015-05-31 19:29 +0000
      Re: Online Job Portal System Use Case Diagrams Matthew Carter <m@ahungry.com> - 2015-06-01 01:00 -0400
    Re: Online Job Portal System Use Case Diagrams Jerry Stuckle <jstucklex@attglobal.net> - 2015-05-31 16:32 -0400
    Re: Online Job Portal System Use Case Diagrams Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-06-01 15:41 +0200
      Re: Online Job Portal System Use Case Diagrams Denis McMahon <denismfmcmahon@gmail.com> - 2015-06-01 15:11 +0000
      Re: Online Job Portal System Use Case Diagrams Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-01 12:33 -0400
      Re: Online Job Portal System Use Case Diagrams Brara morad35 <bramorad35@gmail.com> - 2015-06-01 10:51 -0700
      Re: Online Job Portal System Use Case Diagrams Brara morad35 <bramorad35@gmail.com> - 2015-06-01 10:52 -0700
        Re: Online Job Portal System Use Case Diagrams Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-06-03 10:23 +0200

#15371 — Online Job Portal System Use Case Diagrams

I  want to create Job website with this actors The user is not registered(don't have a Account) and his children job seeker(have a Account),employer(have a Account)In addition to administrator.I do not know if what I did is correct or not. Any help?

[toc] | [next] | [standalone]

#15372

On Sun, 31 May 2015 10:58:36 -0700, Brara morad35 wrote:

> I  want to create Job website with this actors The user is not
> registered(don't have a Account) and his children job seeker(have a
> Account),employer(have a Account)In addition to administrator.I do not
> know if what I did is correct or not. Any help?

Flip a coin. If it turns into a butterfly and flies away, possibly, 
otherwise probably not.

Sorry, but based on your post, this is the most accurate answer I can 
offer.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#15374

Denis McMahon <denismfmcmahon@gmail.com> writes:

> On Sun, 31 May 2015 10:58:36 -0700, Brara morad35 wrote:
>
>> I  want to create Job website with this actors The user is not
>> registered(don't have a Account) and his children job seeker(have a
>> Account),employer(have a Account)In addition to administrator.I do not
>> know if what I did is correct or not. Any help?
>
> Flip a coin. If it turns into a butterfly and flies away, possibly, 
> otherwise probably not.
>
> Sorry, but based on your post, this is the most accurate answer I can 
> offer.

Hahaha

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

[toc] | [prev] | [next] | [standalone]

#15373

On 5/31/2015 1:58 PM, Brara morad35 wrote:
> I  want to create Job website with this actors The user is not registered(don't have a Account) and his children job seeker(have a Account),employer(have a Account)In addition to administrator.I do not know if what I did is correct or not. Any help?
> 

You need to further define what you need.  A inheritance chart includes
not only the class names, but the attributes and methods.  And often
times as you define the attributes and methods, your inheritance chart
will change.

For instance - both job seeker and employer must have logins.  But User
does not.  Are you going to save people without accounts?  If so, how
are you going to identify the user?

Start by defining all attributes and methods (on a paper diagram - no
coding) in both job seeker and employer.  Then look to see what you may
be able to extract into a common class.  Note that you will not always
be able to do it, if there is insufficient overlap.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#15375

On 5/31/2015 7:58 PM, Brara morad35 wrote:
> I  want to create Job website with this actors The user is not registered(don't have a Account) and his children job seeker(have a Account),employer(have a Account)In addition to administrator.I do not know if what I did is correct or not. Any help?
>

In addition to Jerry and Denis. (Ahum)

My approach:
Never start thinking about problems in OOP (classes/subclassing), but 
start thinking on the database-relations: tables (entities), relations 
(foreign keys), etc.

So start with the structure on paper: Don't write code.
Later you can translate that to a relevant database structure.
Or translate it into classes, if you wish to go OOP (not a necessity). 
Both will come natural once you know what you are relating to what.

My advice: Focus first on relations, not the details.
For example:
An employer has maybe a selection of jobtypes the company offers.
There is a relation: You must define jobtypes somewhere (tblJobType) AND 
make it possible for an employer to point to them (foreign keys in 
database).
That is a relation.
Make sure you find them beforehand, they are important.

Details: If you later want to add the favorite food of the CEO, you can 
just add a column to, eg, tblEmployer: If won't hurt your logic.

So start with drawing a few circles on a big paper.
A circle for each entity you can think of.
Put next to each entity a list of properties you deem important, and 
then start drawing out the relations between entities.

If you are new to this, don't worry: you will screw it up, we all did. 
Just start again until all relationships feel natural to you.

As an aside:
There are a lot of different approaches to designing your application.

For example: Jerry seemed to go "naturally" into the direction of OOP, 
while I first think about relations in the database. Of course there is 
a huge overlap, and I bet we would come up with similar designs 
afterwards, because we needed to solve the same problems.
I expect Jerry's OOP code would be more readable than mine. ;-)

There are also a myriad of software design solutions available to help 
you design, like Entity Relationship Modelling:
http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
or stuff like UML:
http://en.wikipedia.org/wiki/Unified_Modeling_Language

Personally I don't like any of them, but that is just me.
They might work for you.

Good luck.


Regards,
Erwin Moller

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [next] | [standalone]

#15376

On Mon, 01 Jun 2015 15:41:14 +0200, Erwin Moller wrote:

> Details: If you later want to add the favorite food of the CEO, you can
> just add a column to, eg, tblEmployer: If won't hurt your logic.

favoriteFood is an attribute of person, not employer. :)

He's right about paper though. All my databases start out as blank sheets 
of paper with things each of which has a list of attributes and lines 
showing connections (1:1, 1:*, *:1, *:*) to other things etc etc.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#15377

On 6/1/2015 9:41 AM, Erwin Moller wrote:
> On 5/31/2015 7:58 PM, Brara morad35 wrote:
>> I  want to create Job website with this actors The user is not
>> registered(don't have a Account) and his children job seeker(have a
>> Account),employer(have a Account)In addition to administrator.I do not
>> know if what I did is correct or not. Any help?
>>
> 
> In addition to Jerry and Denis. (Ahum)
> 
> My approach:
> Never start thinking about problems in OOP (classes/subclassing), but
> start thinking on the database-relations: tables (entities), relations
> (foreign keys), etc.
> 
> So start with the structure on paper: Don't write code.
> Later you can translate that to a relevant database structure.
> Or translate it into classes, if you wish to go OOP (not a necessity).
> Both will come natural once you know what you are relating to what.
> 
> My advice: Focus first on relations, not the details.
> For example:
> An employer has maybe a selection of jobtypes the company offers.
> There is a relation: You must define jobtypes somewhere (tblJobType) AND
> make it possible for an employer to point to them (foreign keys in
> database).
> That is a relation.
> Make sure you find them beforehand, they are important.
> 
> Details: If you later want to add the favorite food of the CEO, you can
> just add a column to, eg, tblEmployer: If won't hurt your logic.
> 
> So start with drawing a few circles on a big paper.
> A circle for each entity you can think of.
> Put next to each entity a list of properties you deem important, and
> then start drawing out the relations between entities.
> 
> If you are new to this, don't worry: you will screw it up, we all did.
> Just start again until all relationships feel natural to you.
> 
> As an aside:
> There are a lot of different approaches to designing your application.
> 
> For example: Jerry seemed to go "naturally" into the direction of OOP,
> while I first think about relations in the database. Of course there is
> a huge overlap, and I bet we would come up with similar designs
> afterwards, because we needed to solve the same problems.
> I expect Jerry's OOP code would be more readable than mine. ;-)
> 
> There are also a myriad of software design solutions available to help
> you design, like Entity Relationship Modelling:
> http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
> or stuff like UML:
> http://en.wikipedia.org/wiki/Unified_Modeling_Language
> 
> Personally I don't like any of them, but that is just me.
> They might work for you.
> 
> Good luck.
> 
> 
> Regards,
> Erwin Moller
> 

Erwin,

Yes, I start out with the OO side.  I create the entities (objects) that
I will need for my business logic.  It is also the most critical,
because it's where I'll have the most code, and I need the objects here
to reflect the requirements of the business logic layer.

I find it much easier to define the relationships between entities once
I know what the entities are.  Once I've defined the relationships, I
can design the database layer.

Except in the simplest programs, my business layer is separate from my
database layer.  For instance, in my business layer I may have a
requirement for a Department.  This department will have a Manager and a
list of Employees. Here we have three classes, with Manager derived from
Employee.

But this design doesn't work well in a database.  There I would have
three table: Department, Employee and Department-Employee link (If I
have an OO database I'll also have a Manager derived from Employee; in a
non-OO database I would make Manager a flag in Employee with appropriate
constraints).  The database layer would have an object for each of the
tables, and the code in these objects would be responsible for
populating and saving the data in the business layer.

This keeps a clean separation between the working data and the stored
data, and if I need to make a change in the way the data is stored, it
doesn't affect the main part of the program (business layer).

And BTW - I may also have a display layer to control the screen.

All of this may seem to be overly complicated and redundant, but once
you've worked on some rather large programs, you should see that keeping
the layers separate has its advantages.

But this is just the way I've found it to work.  It's way overkill for
most of the web programming we do, and if designing the relationships
first works for you, that's great - neither way is right nor wrong.  But
long-established habits are hard to break :)


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#15378

thank you ,you can give me your email.

[toc] | [prev] | [next] | [standalone]

#15379

you can give me your email

[toc] | [prev] | [next] | [standalone]

#15393

On 6/1/2015 7:52 PM, Brara morad35 wrote:
> you can give me your email
>

Hello Bara,

I don't understand what you mean by "You can give me your e-mail".
You can just reply in here comp.lang.php.

Or, if you to contact me personally, just send me an email.
You can use the one I use now: erwinmollerusenet@xs4all.nl

Regards,
Erwin Moller

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web