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

Groups > comp.lang.php > #15377

Re: Online Job Portal System Use Case Diagrams

Show all headers | View raw

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
==================

Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web